The following is an overview of a business analysis process. Move the mouse over the pictures to see the referenced models.
Strategy and objectives: What's the vision, mission, structure, culture?
BA's may have to define or investigate tactics - or tactical options - that ensures their projects align with an organisation's strategy, produce conclusions or recommendations, and/or measure performance. Potential analysis includes measuring industry change, an organisation's internal capabilities, assessing SWOT and Ansoff, and coordinating the tactical implementation of a strategy using 7S, four view models, or the balanced scorecard. Prioritise it all using Eisenhower time: what is important is seldom urgent and what is urgent is seldom important.
Investigate situation: What's the scope and system boundary? The problems, issues and opinions?
Uncovering problems and issues requires qualitative or quantitative analysis and documentation of the results. Qualitative research focusses on the people involved, their hopes and fears, the range of facts and opinions, and the perspectives on change (allies or opponents). Techniques for qualitative research includes interviews, workshops and observations. Quantitative research focusses on data metrics, data frequency, the numbers, data samples and testing. Techniques include questionnaires, samples and document analysis. Documenting the results is more than writing up formal reports and can include mind maps, rich pictures, and context diagrams.
Consider perspectives: Who is everyone involved?
Working with stakeholders is crucial. The BA must identify stakeholders and interested parties so that a full range of views can be understood and later conflict avoided in the case of new or missing points of view. Once the people involved are known then examining their levels of influence and areas of concern allows the BA to identify areas of potential conflict, misunderstanding, communication and even resistance. Finally, stakeholder management techniques carried out during a project help everyone to work together in a changing environment, including planning, conflict resolution and principled negotiation. A 'Stakeholder Wheel' groups stakeholders as customers, partners, suppliers, regulators, employees, managers, owners and competitors. For analysis consider organisation diagrams, CATWOE and BAM. For negotiating, establish a party's BATNA (Best Alternative To Negotiated Agreement).
Analyse needs: Where do we need to be?
Before simply setting actions to solve current problems, think about the broader stakeholder visions for the business system. By only addressing the current problems you can miss greater opportunities. Consider modelling business processes, business events and operational rules by, for example, using Porter's value chain, business process analysis, swimlanes, decision trees or tables. Then apply gap analysis to identify actions to take.
Evaluate options: How do we get there?
Once tactics are decided on, the situation is modelled, stakeholders identified, and actions to meet needs are derived, then a BA can consider and present options for change. To make a business case (a) identify options, (b) reduce into a shortlist, (c) prepare the business case and (d) present to management. This may include feasibility studies, cost benefit analysis (tangible and intangible), investment appraisal (breakeven analysis, NPV and IRR) and business case reporting. To make a presentation (1) Tell 'em what you're going to tell 'em (2) Tell 'em and then (3) Tell 'em what you've told 'em.
Requirements I, Elicitation: Where do we start?
Per analysing needs, when interviewing stakeholders it's easy to get entrenched in the detail of the current situation and existing issues, and hence not focus on what's really needed in future. The skill is to look beyond what's said by individual stakeholders and meet true business objectives. Try user scenarios, storyboarding and prototyping to elicit requirements.
Requirements II, Analysis: How do we get on with it?
Structure and organise requirements into functional and non-functional potential actions. Assess where requirements ought to be prioritised and estimate delivery. Prepare for requirements negotiation and review. Use timeboxing and MoSCoW to analyse and set negotiated delivery dates for products. Actions, owners and due dates may be elements within a timebox. Manage further stakeholder reviews.
Requirements III, Development: So what are we doing?
Requirements need to be structured and documented into a specification. That usually contains an introduction, functional model(s), data model(s), a catalogue of requirements, and glossary. Each item in the catalogue needs an ID, name, owner, stakeholder, priority, description, acceptance criteria and validation. Baselining, configuration and version controls are techniques used to manage changing requirements. A behaviour tree is a useful method of managing large numbers of requirements and mappin dependencies between them.
Requirements IV, Modelling: Exactly what are we doing?
A use case can describe a unit of functionality in a system. Depending on the amount of detail they could be defined as diagrams or descriptions or both. Entity Relationship Diagrams and Logical Data Models conceptually represent data and relationships between data items (entities) in a system. Class models show data in terms of name, attributes and operations on the data (behaviour), as well as associations between classes. A CRUD matrix links use cases and class models in terms of Create, Read, Update and Delete operations on data.
Manage change: How is it going?
The last stage of the BA process is to introduce and/or manage the changes and realise and manage the benefits of change, and to articulate the benefits. It involves cultural analysis, unfreezing and transition, the SARAH model (Shock, Anger, Rejection, Acceptance, Hope) and/or a learning cycle or new competency model. In benefits analysis, a project can so often be managed on objectives of delivery dates and budget that the original business objectives are lost. A benefits map can show how changes lead to benefits, and a benefits chart showing changes and benefits against time can help manage a project. A benefits plan consists of (a) vision, (b) map and chart, (c) performance measures, (d) financial analysis, (e) dependencies between benefits, (f) benefit tracking and reporting and (g) owners tasked with achieving the benefits. While a project plan is concerned with technical issues and activities required to execute a project, the benefits plan is concerned with the activites required to achieve the benefits. The theory is major project decisions ought to be made with reference to achieving the benefits plan as well as the project plan.