• Poor communication is often cited as a reason IT project fail
• Communicate with business in business language not technical
• Adjust communication for who you’re speaking to, ie MD, shop floor, etc

• People need to trust you and impart knowledge to you, you may need their help
• Take interest in other people

• Identify stakeholders and influence each differently as to where they stand on the proposal and how decision making takes place
• Especially required if conclusion is at odds with preconceived ideas and against hidden agendas
• May need to take the middle ground between different groups

• Internal and external
• “The way things get done round here”

• Not settling for the obvious or established thinking, root cause and holistic thinking
• Digging deeper until a true situation is uncovered
• Why? What? Where? How? When?

• Plenty of data and information in every aspect

• A mindset that problems can be approached and solved

• Develop a vision, taking ownership and ensure actions to implement vision are realised

• Confidence in yourself, in quality of your analysis, helps influence

• Finance & the Economy
• Understanding of P&L, ROI, NPV and balance sheets
• Business Case Development
• Must be able to literate the financial costs & benefits of a analysis and Understand the above
• Understand technical costs & benefits

• Understanding of the business and the industry it operates in
• Helps to know what is acceptable and what isn’t

• Ie Strategy. Domains (ie Banks), etc

• Don’t have to be an IT expert
• Level of knowledge will depend on subject
• Systems frameworks (ie agile, waterfall, UML, supplier management, etc)

• How to centralise a process or improve customer service
• Supplier Management
• Contractual agreements, Time & Materials, Fixed Price Delivery, Risk & Reward

• Project Management, Ie PMP, Prince2, ISEB PM,
• Strategy Analysis

• Strategy exists because there is uncertainty and it helps to moderate this uncertainty
• Organisations are doing everything they can to help increase flexibility and responsiveness
• BAs must be able to understand the strategy in terms of global uncertainty

• The direction of the business, otherwise known as goal or mission
• A timeframe in which to operate, usually long term
• The organisational resources available
• The markets and environment and how the company applied itself
• The management and implementation of change
• Corporate Strategy – Overall purpose of business, shaped by investors, governments
• Business Unit Strategy – Translation of the above into operational steps
• Operational Strategy – Using BUS and Corporate strategy to deliver

• Focus for the organisation and understanding of the reasons behind actions
• Framework for allocation of resources (inc money)
• Guides where innovation is needed
• Performance measures (have we achieved our goal?)
• External communication (this is what we do)

• Individuals/Entrepreneurial (ie Richard Branson or flashes of inspiration that business agree on)
• Decentralised & Empowered Organisations (managers after analysis)
• Planning (what do we want to do and where do we want to be?  How do we position ourselves to realise the benefits?)

• Political (ie trade unions)
• Economic (ie competitors, interest rates, unemployment)
• Sociocultural (ie demographics, social mobility, working practices)
• Technological (ie reduction of barriers to entry)
• Legal (ie regulation, employment law)
• Environmental (ie waste, ‘green’)

• Bargaining Power of Suppliers (ie lots of companies to buy from or not, difficulty in changing suppliers)
• Bargaining Power of Buyers (ie how big is the market?  Is it saturated? Can they change easily?)
• Threat from Substitute Products (ie VHS to DVD to Blueray, can we do without?)
• Threat of new Entrants (ie is it expensive to set up as a competitor? Can consumers switch easily?)
• Industry Competitors – Rivalry Among Firms (ie how many companies are there doing what we do?)

• Mission – Statement declaring what the organisation wants to achieve
• Objective – Goals to realise the mission
• Strategy – The approach to be taken to complete the objectives
• Tactics – The detailed steps required from the strategy

• Physical (buildings, plant, equipment, land, etc)
• Financial (stability, balance sheet, turnover, etc)
• Human (expertise, number, commitment, etc)
• (Intangible) Know-how (organisational knowledge, patents, trademarks, etc)
• (Intangible) Reputation (brand recognition, loyalty, or not, etc)

• Strengths (ie strong product branding, customer loyalty, etc)
• Weaknesses (ie expensive manufacturing compared to competitors, high product returns, etc)
• Opportunities (ie new markets opening for products)
• Threats (ie low barriers of entry to our market, product isn’t green)

• Time (ie how quickly)
• Scope (ie big or little change)
• Capability (ie how does business and markets react to change?)
• Readiness (ie is the organisation and market ready for the change?)
• Strategic Leadership (ie who leads the change, doesn’t have to be the top management, a leader and celebrates success)

• (Hard Component) Structure (ie how it will change)
• (Hard Component) Strategy
• (Hard Component) Systems (ie how they will support)
• (Soft Component) Shared Value (ie guiding concepts of organisation)
• (Soft Component) Style (ie how things get done round here)
• (Soft Component) Staff (ie how they will react to change)
• (Soft Component) Skills (ie organisational knowledge and staff talent)

1. Mess finding (ie statement of the situation, informally identify the boundaries for the problem, use rich pictures or mind maps)
2. Data Finding (ie analysing the options, concerns in the previous stage and obtaining starting data, see part 5)
3. Problem Finding (ie the root issue(s), find the right problem not the easy one)
4. Idea Finding (ie ideas and criteria that may solve the problem, use creative thinking or brainstorming)
5. Solution Finding (ie focus on ideas from previous step to provide solutions)
6. Acceptance Finding (ie managing the implementation of the solution, use business case and implementation of change)

• See Part 5
• Choose most appropriate methods dependant on level of detail required, ie stakeholder analysis, rich picture or prototyping
• Study background material, initial investigation with stakeholders, document outcomes
• Produce minutes, rich pictures, mind maps, list of issues, business needs log
• Techniques, questionnaires, sampling and above
• Considering Perspectives

• Quickest and simplest way to get a view of the organisation, how it brands itself and how it wants to be perceived
• Branding is very important message
• Customer reviews and the like
• How it views quality/cost

• Statutory documents (ie companies house & shareholder documents)

• Study current systems (perhaps analyse them)
• It gives the expected ‘what is’ (may be different from what actually happens)

• Reporting lines, hierarchy, flat or tall, etc

• Qualitative – in words
• Quantitative – in numbers

• Current functions that need to be covered
• Problems with the current situation
• New features to be implemented

• Understand viewpoints
• Investigate new areas
• Collect documentation
• Appreciation of political factors
• Environmental

• Expensive and time consuming
• Can create follow up actions (ie documentation requests)

1. Who? – STOP model (as a pyramid), Strategic management level, Tactical middle management, OPerational level
2. Why? – Why a particular interviewee is going to be selected, from obtaining business information to good stakeholder management
3. What? – Considering the information that may be useful and explored
4. When? – Considering the venue, timing and duration of the interview, try limiting interviews to an hour
5. Where? – Consider own territory, observing working and sources to relevant information

• Useful in obtaining information about business environment and work practices
• Make sure those being observed know the purpose of the observation
• Useful if perceived situation differs from the actual processes or a lack of understanding as to what is going on
• You will get a much better idea of the issues facing the business and it’s users
• Will help to devise workable solutions based on observation
• Runs the risk of being shown what is the official procedure as opposed to how it is done

• Asking people to perform a task and describe each step they take, an excellent way to obtain tacit knowledge
• “Performing & Describing”

• Following a person for one or two days to find out what a particular role involves
• Important and good to build rapport
• Gives excellent context from interviews

• Especially useful if time and budget issues are constraining the project
• Gains a broad view of the area under investigation
• Much quicker that individual meetings
• With collaboration stakeholders are more likely to buy in to the process
• Gain consensus
• But, time consuming to run and organise
• But, individual participants can rule the forum
• But, difficult to get required level of authority in one place

• What do you want to achieve?  Try breaking down requirements into individual components
• Make sure attendees are invited, and representative of what you are trying to achieve
• Interests of participants are understood, and their viewpoints considered
• Structure of the workshop needs to obtain the results you need and the people present (think STOP and social issues)
• Arrange a suitable venue, neutral issue vs workplace issues

• Brainstorming – Ideas and evaluation are conducted simultaneously and points recorded usually on a flip chart of similar device
• Round Robin – Participants are asked for their opinions in turn
• Brain Writing – Participants write down their thoughts and then these are collected
• Stepwise Reinforcement – Where we take a statement and keep asking “Why?” until we get back to the heart of the situation
• Break Out Groups – Smaller groups work on the issue then present findings

• Discuss the objectives and try to obtain buy in, try using the business sponsor to open the discussion
• Ensure that the conversation and discussion does not go too off track from the objectives
• Keep notes of key points of the discussions, make sure non-verbal clues can be recorded
• Summarise all the points made for further buy in and follow up by sending participants the information

• Bring together a group of people with a common interest to discuss a topic
• Usually used for marketing, ie why a group of customers are unhappy with a certain service
• Scenarios
• Telling a story of a task or transaction, helps when a user who is uncertain about what is needed from a new business process or system to visualise it more clearly
• Key strength is that they provide a framework for discovering exceptional situations that require alternative paths to be followed

• They require the user to include each step and transition between the steps, and as a result remove the opportunity for omissions
• Ensures there are no taken for granted steps
• All possibilities should be explored
• All steps must be marked as “true” to progress to the next one
• Can feed into a UML diagram

• Important technique for eliciting, analysing, demonstrating and validating requirements
• Offers stakeholders an opinion on how things could work, ie screenshots or flow charts
• A scenario can be used to show how the prototype will work

• Useful to get a limited amount of information from a lot of people, where interviews would not be practical
• Not always practical in that return ratio isn’t always good
• Questionnaires have to be careful designed in order to realise the objectives

• Ie, keeping a tally on how many times a certain action is performed or how much time people spend a day doing x

• Ie how much time a day is spend on x, how much on y?

• Reviewing samples of documents to uncover information about an organisation, process or system
• How is the document done? Who completes it? Controls? Who uses it? When? How many? How long is it retained? What information?

• Provides an overview of the ENTIRE business situation
• Can show the human interactions and thoughts as well as cultural issues

• Useful for summarising a lot of information in a concise form that highlights interlinking ideas and information
• The business issue is in the middle, main issue as those branches, second branches concerned with the detail

• A diagrammatic technique to show the physical movement and interactions of stakeholders
• Useful to be drawn up during observation

• Can use 4 Ms – Manpower, Machines, Measures & Methods
• Can use Alternative 4 Ms – Manpower, Machines, Materials & Methods
• Can use 6 Ps – People, Place, Processes, Physical Evidence, Product & Performance

• Customers – Those who use a product or service, how to manage change without loosing, large or small, regular or occasional, wholesale of retail, corporate or private, etc
• Partners – Those that work with our organisation or specialist providers
• Suppliers – Those that supply goods and services to our organisation
• Competitors – Want our customers
• Regulators – Make sure that changes are legal
• Owners – Either shareholders or those that own the company
• Employees – Including trade unions
• Managers – May be many levels (ie STOP)
• Others – Ie government, law enforcement, interest groups

• High Power Watch Keep Satisfied Constant, Active Management
• Some Power Keep Onside Keep Onside Keep Onside
• No Power Ignore Keep Informed Keep Informed
• No Interest Some Interest High Interest
• Stakeholders may not stay in same quadrant for the whole project, may move as it progresses, people may get promoted or lifecycle may move
• No Interest or Power – Keep cursory information
• No Interest but Some of High Power – Likely to be Senior Management, keep informed
• Some Interest & High Power – Project will probably affect them in some way
• High Interest & High Power/Influence – Likely to be affected directly by project

• Businesses can be considered to be a system
• Used where there is plenty of opinion, and the situation isn’t clear cut
• Use like rich pictures as ‘world views’
• Take a holistic approach to the business
• Business Perspectives
• Stakeholders should be asked for their views
• Based on a sentence to explain
• SSM Offers CATWOE – (Customers [beneficiary], Actors [perform the activity], Transformations [the input output], World View [beliefs about the business and why it happens], Owner [can make decisions], Environment [see PESTLE])

1. Planning Activity – The type of resource and how performance will be monitored
2. Enabling Activities – Resources and facilities required
3. Doing Activities – Achieving the transformation
4. Monitoring Activities – Collection of metrics to assess success of plans
5. Control Activities – Act when monitoring indicates action is required

• All the various BAMs should be reduced into one definitive BAM
• Will have to built consensus to build definitive BAM

• External forces, much like PESTLE
• The four areas are those which require consideration, including materials, services, people, finance and ideas
• Customers in not only service users but other beneficiaries (ie managers and owners)
• Competitors, those who want access to our market and customers
• Evaluate each sector accordingly

• How does the organisation react to external environment?
• Consider the core processes
• All businesses = Input -> Processes -> Output
• For an order process it could be:
• Customer Places Order -> Record Order -> Take Payment -> Arrange Delivery – Receives Goods

• Google Here (too complex for me to draw!)
• Identifies areas of the business that are performed by an organisation
• Primary Activities – ie creating the product
• Support Activities – Pulling it all together

• Product/Service Attributes
• – Functionality, what the product does
• – Price
• – Quality
• – Choice (bespoke abilities)
• – Availability (how quick to react to customer)
• Image (how the product is seen by the customer)
• – Relationship
• Can differentiate by:
• – Being the most efficient (low cost)
• – Having the best products (high quality and innovation)
• – Providing the best customer service (exceed expectations)

• Helps with identification of problems with existing processes
• Look at when processes or item is changed between people, queues may form when not syncronised or not enough resource

• Some processes may have been in place for a number of years and may have changed slightly to perform the necessary tasks
• Look for problems such as duplication of work, lack of standardisation, inconsistent measurement and control

• Remove the problems and challenge assumptions

• Remove un-necessary stages (ie reports being produced that don’t get used)

• Remove Bottlenecks
• Make sure capacity is adequate for the task

Change the Sequence of Tasks

• Very often computer-based methods will be an imitation of the clerical tasks

• Identify the triggers for starting and finishing and what needs accomplishing to satisfy the requirements

• What can be done in house or contracted out (ie outsourced payroll)

• Often derived from organisational objectives, CSFs and KPIs
• Often focuses on what the organisation does as opposed to what the customer wants

• Time take to complete a task
• Financial measures such as costs and prices
• Quality measures (accuracy and effectiveness)

• Timeframes for completion of a task or service
• Performance Issues
• Measures and targets need to be selected with care, especially if there are incentives to achieve targets
• What gets measured gets done – sometimes to the detriment of others

1. Define the problem
2. Measure the data
3. Analyse the Problems
4. Improve the process by looking at root cause
5. Control to stop problem occurring
6. Gathering the Requirements

• Lack of relevance
• Lack of clarity
• Duplication
• Conflicts in requirements
• Difficult to assess if requirements have been achieved
• Assuming of a solution
• Business not identifying requirements
• Inconsistent levels of detail

• Objectives (both business and project objectives)
• Scope (and boundaries of the project)
• Constraints (budget, timescale, quality measures, et al)
• Authority (conflict resolution)
• Resource (available)

• Requirements elicitation: gathering information, requirements and needs
• Requirements analysis: looking over overlap and themes
• Requirements validation: sign off the catalogue of requirements

• Business Representative (Project Sponsor) – agree the initialisation document, deliver agreed benefits, fund raising, accept deliverables, rule on conflicting requirements
• Domain Expert – High level advice on requirements, process input, internal or external, be wary of own agenda
• Project Manager – Reports to the project sponsor, creates work packages, management and monitoring and corrective activities
• Business Analyst – Requirements engineering and management

• Skills (ie how to change gear)
• Taken for granted (terminology, best practice or ‘domain knowledge’)
• Front Story/Back Story (applying ‘spin’)
• Useful to apply observation, shadowing or probing questions ‘how does it work?’, ‘how are problems discovered and rectified?’
• Conceptualising Requirements (lack of expertise may need leading, useful to have a workshop)
• In-depth Understanding – Detailed investigation of issue
• Intuitive Understanding – Brought on through experience and expertise
• Norms of behaviour and communication
• Organisational Culture – The way Management and staff behave
• Communities of Practice – Discrete groups who work by task

• Techniques: interviewing, shadowing, workshops, prototyping, scenario, analysis, protocol analysis

• Requirement Source Comments- ie reduce widget use A Smith Non-functional, but relevant to requirement 4

• Helps to raise everything that is important and where it is appropriate

1. Categorisation – General, technical, functional and non-functional
2. Well defined
3. Duplication or Overlap – Allow for merging or refinement
4. Unravelling (normalisation) – Only one requirement
5. Necessity – Aligned to project and business
6. Feasible – Technical, business & financial
7. Conflict Resolution – Negotiate a solution with conflict
8. Solutions – Not needing addressing
9. Quality (SMART)

• Clear language
• Concise
• Consistent
• Relevant
• Unambiguous
• Correct
• Testable
• Traceable

• Business sponsor – Confirms alignment and scope
• Business owners – Express the business requirements
• Domain expert – Confirm correct practice
• Developers – Technically feasible
• Testers – Can be tested
• Project management – Correct requirements have been followed

1. Communication that related activities are consistent
2. Gives firm basis for validating the requirements are correct
3. Further work will use it as an input

1. Introduction & Background – Description of business drivers
2. Business Process Models – ‘To be’ state and possible ‘as is’ state descriptions
3. Functional Models – ie Context diagrams and Case diagrams
4. Data Model – Useful where requirements will build a software product
5. Requirements Catalogue – Information about each requirement
6. Glossary of Terms – Defines any terms used
7. Requirements Catalogue- (Requirement as Requirement Analysis)
8. General Requirements & Constraints (Business Constraints – Budgets, timescale, resources, etc, Business Policies – Standards & Business Policy decisions, Legal & Regulatory Constraints, Branding – Image of the organisation (ie style guide), Cultural – ie vision of organisation, Language – ie Globish, Business Continuity – Business policies for reacting to threats, Technical Requirements & Constraints, Hardware – ie makes and models, Software – ie OS, Interoperability – Interfaces required, Internet – Governance of internet and web connectivity, Functional Requirements & Constraints, Data Entry – What data is required, Data Maintenance – How will it handle change, Procedure Requirements – How they will be adopted or changed, Retrieval Requirements – Reports, queries and management information, Non-Functional Requirements, Speed of Performance – How quick does it have to be, Levels of Security – Types of confidentiality and statutory, Access Permissions & Constraints – Definition of stakeholder groups, Backup & Recovery, Archiving & Retention, Maintainability – Servicing, problems investigation & correction, Availability – ie 24/7 or 99.999%, Usability – How easy it is to learn and use, Capacity – How much will it have to contain)

• Requirement ID – Unique, and easy to cross-reference
• Requirement Name – Short, descriptive phrase
• Requirement Description – Clear definition
• Source – ie Person, group, policy or legislation, the initial source
• Owner – The responsible stakeholder
• Author – Who elicted the requirement
• Type of Requirement – ie general, technical, functional, non-functional
• Priority – MoSCoW (Must have, Should have, Could have, Won’t have)
• Business Area – ie appropriate function or department
• Stakeholders – Those interested
• Associated Non-functional Requirements – ie customer service policy guaranteeing certain responses
• Acceptance Criteria – ie how to know it’s been met
• Related Requirements – ie higher level requirements or related by function, Requirement ID
• Related Documents – Where to find further information, ie meeting minutes
• Comments – Any other useful information
• Rationale – The Business Justification
• Version History – ie reason for changes and Configuration Management

• Backwards Traceability – Must be traceable to the initial source (ie who identified this?), useful if conflicts arise
• Forwards Traceability – Who dealt with this requirement?
• Configuration Identification (CI) – Can be traced back to the requirement
• Configuration Control – Maintain the changes made to CIs

• Actors – People or external systems (stick figures or rectangle with <<word>>)
• Use Case – Represent a function (oval with text)
• System Boundary – Rectangle showing Functions
• Associations – Lines connecting Actors to Use Case
• <<include>> – Connects a Use Case to another Use Case with a dotted arrowed line, implies a Function using another
• <<extend>> – Extends the original Use Case with additional Case

• Attributes (/Data Items) – Entities contain and are described by attributes
• Relationships – 1:m (forked line), 1:1 (straight line), m:m (forked lines)
• Optionality – Dotted line
• Exclusive Relationships – Denoted with parenthesis on line and a letter

• Account //Class name
• AccountNumber //Attributes
• Name
• CreditLimit
• CreateAccount //Methods
• UpdateCreditLimit

• Business process change (improvement)
• People changes – Training, redefined, moved, etc
• Changes to organisational structure – Posts may disappear
• Changed to IT systems – Support the business processes

• The external factors (PESTLE, Porter, etc)
• Culture of organisation (inc stakeholders)
• Business context for change
• Constraints on the project
• The priority
• The drivers

• Provides good control from a project management perspective
• Highly structured (which can led to a long drawn out project and not handling of change very well)

• Allow explicit connections between activities especially testing and analysis
• BA should be involved

• Context – Corporate standards, complexity, resources etc
• Delivery – ‘Big bang’ delivery or incremental
• Development – Consider analysis, does it need to be done in isolation

• Responds quickly to fast changing business situations
• Difficulty in knowing what is needed early on in the project
• Flexibility in deliverables
• Focus on meeting business needs

• Cheaper, faster implementation, support and maintenance and updates
• But! Likely won’t be a perfect fit and not likely to provide competitive advantage and may need to change business processes to fit
• May be best to leave the decision to business and knowledge stakeholders

• Project manager, business analyst, developer and tester
• Involvement will likely change dependant on stage in the lifecycle and which framework is being used

• Training exercise (so deliverables could be training material)
• Documentation for any process change could be considered a deliverable

• A business case is a living document and should be revised and revisited
• Should make sure it’s reasons are still valid
• Finance information should be revisited at every stage to make sure they’re still accurate and could be used to measure against the final deliverable

• Consider the audience (and corporate standards)
• Keep it succinct and appropriate
• Good structure
• Keep it looking good
• Identifying Options

• Business Options & Drivers – What the solution will do in terms of business terms
• Technical Options – How the solution will be implemented (ie ICT or business change)

• Identify options – ie through workshops, meetings, industry practice or brainstorming
• Short list options – ie look at cost, complexity, time, etc for 4 options
• Evaluate shortlist – ie a bit more scientifically, evaluated in terms of cost, time and quality or ‘basic’, ‘basic +’ and ‘full’
• Business case – Put available options into business case with calculations
• Always consider ‘do nothing’ is an option and should be documented

• Business – Will the project provide business advantages
• o Strategic fit
• o Market conditions
• o Timeliness
• o Physical infrastructure
• o Organisational ‘fit’
• o Cultural ‘fit’
• o Process compatibility
• o Within competencies
• o Legality, regulators & governance
• Technical – Not specifically ICT
• o Availability
• o Reliability
• o Maintainability
• o Performance
• o Security
• o Scalability
• o Technical skills
• o Compatibility
• o Whether proven
• Financial
• o Within budget
• o Funds available
• o ROI
• o Cash flow
• o Payback

• Consider inside and outside benefits and score accordingly

1. Introduction – Defines scopes and objectives
2. Management Summary / Executive Summary – Detail the whole document succinctly
3. Description of Current Situation – ‘As is’, problems and opportunities
4. Options Considered – All the shortlist
5. Analysis of Costs & Benefits – (see below)
6. Impact Assessment – How will it affect the business?
7. Risk Assessment – Description, assessment, probability, countermeasures, ownership
8. Recommendations – Succinct with timescales (ie GNATT chart)
9. Appendices

• Tangible Costs – Quantifiable costs ie staff costs, user costs, hardware, infrastructure, software, relocation, training, and ongoing costs
• Intangible Costs – Desruption & recruitment
• Tangible Benefits – Quantifiable, ie staff costs, effort, speed, reductions, inventory,
• Intangible Benefits – Job satisfaction, customer, information, flexibility, marketing, communications
• Avoided Costs (if applicable) – ie Y2K bug