Guide Stakeholders Along the Business Analysis Path

Guide Stakeholders Along the Business Analysis Path Cover
Noelene Noone

July 5, 2017 in Uncategorized

Think business need, requirements scope and feasible solution with this three-step framework to help guide stakeholders along the business analysis path.

Some years ago I followed an online course presented by Michael Boyle on the business analysis path. Michael laid out the analysis path in three simple, yet powerful, steps which echo through each type of business analysis project.

No matter the need – whether a new product, a new department, a new tool or new legislation – every business change can be successfully managed by following this standard path of analysis.

And by taking the approach a level further, the business analysis path can overcome the troubles with requirements templates and serve as a framework for producing an engaging, living requirements document that provides for evolving stakeholder requirements.

The Standard Business Analysis Path

The business analysis path follows this three step framework:

  1. What problem needs solving?
  2. What are all the requirements and issues tied to the problem?
  3. Knowing what is required, what solution works best?

Navigating these three steps, as the analysis of an assignment matures, moulds a business requirements document to the delivery path. With each step in the analysis process opening a new section of the requirements document to address the enhancing requirements, and never letting go of the stakeholders along the way.

Section 1 – The need

The business need is a concise summary of the business requirement in hand.

Content can be gathered from a variety of sources – a project charter, interviews with the business owners, official documents published on the subject or, even, assignment e-mails – and combined to describe the business situation.

The focus is to stick to defining the business requirement, and to avoid prematurely looking at business solutions.

In this analysis phase, it is often a tendency of business to describe the solution, rather than state the problem or need. Keep any solution suggestions for the later solution section. The need definition must stay independent of any suggested solutions, and base the business assignment on the actual needs and analysis findings.

Section 2 – The scope definition

The scope definition can be one or many pages, depending on the size of the assignment.

Source information from workshops, interviews, job shadowing and existing documentation, and use analysis techniques like context diagrams, relationship tables, high-level process flows plus other models, as they are appropriate.

The success of this section is in finding the golden midway between detail and relevance, to accurately define the scope.

List related documents in a document table and populate the scope definition with findings that will have a direct impact on the assignment under analysis. To get perspective, involve systems architects and developers to understand how the assignment touches their world and speak with any other third-party providers.

Section 3 – The solutions

For some assignments, this section may spin-off multiple feasible solutions.

Structure this section to specify the potential solution options, perhaps referencing multiple underlying documents – each addressing a specific alternative, which could be assigned for independent investigation to one or more different analysts.

This section captures decisions made as well as the reasons supporting these decisions, with the pros and cons clearly stated.

Different solutions may bring a different emphasis or address different aspects of the assignment. Here techniques such as a decision matrix or a matrix stating importance versus priority can be useful. Once a preferred solution is chosen, consider potential impacts on the business system, operational procedures, change management and training.

Sign-off for a living document

As you move from one section to the next ask stakeholders to sign-off on the findings, as insights in the current section may prompt changes in a previous section and help ensure any misalignment is caught early.

With each iteration, it is important to allow stakeholders to understand what has been changed since their last sign-off.

Stakeholders tend to focus on the section they can relate to. Typically, executives are interested in the problem statement, subject matter experts and business specialists focus on the scope whilst solution architects and systems analysts focus on the different solutions considered. Developers and testers focus on the final solution agreed upon.

A guiding light

Following this three step framework, keeping your audience in mind for each section and knowing the tools and techniques you can use will be of tremendous help to you through your many assignments.

Focus squarely on the area that you are addressing at the time, instead of muddling the problem scope with the solution a business owner has in mind, or worrying that you’ve not taken all the issues into account when getting to a solution.

Whether working in a waterfall or an agile environment — whilst the language of the solution section might differ — this framework works. And should you need to move off an assignment, any replacement analyst can follow the details uncovered to date and continue along the analysis path, putting your business owners mind at ease.

The power of a business analysis document lies in the readership it will entice, …

and building a living requirements document while engaging stakeholders along the business analysis path will serve as a guiding light for the business analyst in getting to a business solution to a business problem, no matter its size or nature.