The Business Analysis Methodology Model


We have two business analysis frameworks at our disposal to enable us to place all the various techniques that we use in context and structure our approach to projects.  One framework is for problem solving & the other is the business analysis process model, which guides us through the tools & techniques we can use to deliver change initiatives to a business.

The below is the business analysis process model which we utilize to identify and implement change within an organization. In the below, I’ve split out each of the processes & provided each with sample inputs and outputs. It’s important to note that business context spans all processes & must be considered throughout the lifecycle of the project.  The business context is the MOST statement (Mission, Objectives, Strategy, Tactics) as discussed in a previous article.

Business Context: understanding the Mission, Objectives, Strategy and Tactics of the business (MOST) is key throughout all stages of this process.

Investigate Solution: identifying the underlying problems behind a symptom. We can use interviews; observations and workshops as examples of investigation techniques. This will require some stakeholder analysis too. We can document this stage using mind maps, rich pictures or fishbone diagrams.

Consider Perspectives: investigating different stakeholders interest, influence and needs from the project. Through this stage, we need to explore stakeholder conflicts & resolve them where possible.

Analyse Needs: completing a gap analysis which identifies where improvements can be made to the system.

Evaluate options: generate a range of potential changes & group them together into ‘improvement packages’. During this stage, we should develop and document each option in detail considering the technical and financial feasibility of the options. All of this should feed into a business case for the consideration by management. We should complete an impact and risk assessment of each option.

Define requirements: producing well-formed requirements document covering the changes. This document should include descriptions of each requirements and enough information that we can trace the origin of a requirement (i.e. who drives the requirement).

We then have a final step that isn’t included on our model below.

Deliver change: During this stage, we should define the lifecycle and approach that we’re going to adopt; we should develop a business change strategy; we should identify pre-change training requirements & organizational changes; review the predicted benefits of the change and identify all the actions we need to take in order to realise those benefits.  We may use use-case diagrams; decision tables; state charts and benefits planning tools during this phase.


  • Business change processes & organizational design.
  • IT software solutions + intended changes.
  • Approved business case.


  • Business change plan.
  • Comms plan.
  • Training approach & materials.
  • Revised job roles & descriptions.
  • Benefits plan.
  • Benefits review document.

So there we have it, an overview of the processes we should follow as business analysts. Of course, these are frameworks and aren’t to be enforced and followed religiously. Your project may require more emphasis on one phase & less on another. It is however, important to use it as a guideline and ensure you spend some time in each of the phases. The outputs / deliverables from each stage will depend on your project / change initiative.

Content based on study of the BCS Business Analysis course – Business Analysis 3rd Edition (Debra Paul, James Cadle and Donald Yeates).