Business Analysis Homebase

Every project and organisation is a bit different. If you’re working in a fixed team with a fixed product, you might have a radically different experience to someone who works in projects moving between domains and product/service/policy areas. But at the heart of the Business Analyst role is a general set of non-prescriptive steps that we all flex, change, and adjust to suit our needs.

Hopefully this, in combination with our “What is a Business Analyst and what do they do?” article helps give you some guidance on where to start. We’ve tried to link templates where possible as samples.

By the Textbook

BCS recommend the problem solving model (Isaksen and Treffinger, 1985) as it provides a view on BA’s common activities/functions:

1. Mess finding – Understanding the complexity of a problem situation
2. Data finding – Discovering and documenting opinions, concerns, knowledge and ideas
3. Problem finding – Isolating the specific issue that needs to be addressed
4. Idea finding – brainstorming and working with subject matter experts to propose solutions
5. Solution finding – evaluating ideas and testing their validity prior to implementation
6. Acceptance finding – managing implementation of the change and measuring the benefits.

In simpler terms

To expand and provide a different interpretation, below might be a little more clear way to approach a BA’s role in a project, product, service or policy:

1. Understand the problem – Generally you’re presented with a question or a problem, so it’s valuable to clarify terms, ask what they’re expecting the outcome to be, and the timelines.
2. Understand the context – This may be interviews, workshops, desktop research, observations, glossaries of work terms, etc. Your goal is to make sense of everything surrounding the problem that could impact a solution you propose. Start by understanding an aspect of POPIT (People, Process, Org, or IT) then expand out until you have enough knowledge to document.
3. Document the current “As-Is” state – Take the knowledge and get it on paper, as knowledge purely in your head doesn’t help anyone. Depending your level of documentation needs this can be process models, reports featuring observations, Requirements Specifications, data dictionaries, etc. This is the point you’d like to measure time/cost/satisfaction so you can measure if your work provided benefits.
4. Document the future “To-Be” state – Document what a future solution could look like. You might have multiple versions depending multiple circumstances or variables. Depending your level of documentation needs this can be process models, user stories, reports featuring recommendations, change management plans, etc.
5. Help design or determine the Solution – Work with others (technical or otherwise) to decide and implement a solution using your knowledge and findings from prior steps. This might involve anything, but typically change planning, acceptance criteria, developing training and transition documentation, etc.
6. Measure the benefits – Using your earlier measurements from documenting the now superseded current “As-Is” state, verify that your benefits were realised aligned to Benefits Realisation plan, and maybe include documenting Lessons Learned.

There isn’t a formal prescriptive way to approach the process, above are some different ways and frameworks you might be able to apply to your work. Feel free to tweak, change, flex and adapt to suit. Even one of our resume guides takes a slightly different approach!

In the ideal world, our roles are better defined so a BA know exactly what they’ll be analysing and their position in a role. A traditional Business Analyst will gather business requirements, a Solution Designer or Technical Business Analyst will convert to functional technical requirements, a Solution Architect will make sure it fits the technical platform/environment, a Strategic Business Analyst will make sure it fits the strategic goals, etc. In reality, the BA role gets involved across all these activities, so step 5 (in both areas) might be fairly different between projects.

More so than any other article, we’re keen to understand your advice, thoughts, concerns, queries or clarifications. If you do have feedback, please jump in the Business Analysis Space Discord or via email (feedback at businessanalysis.space, just so the email harvesting bots don’t spam it!). We’re working on getting our “Was this helpful” platform back in the mean time!

Stefan Carton