There is a notion that the scope of a project has to be defined before the project starts. Experienced business analysts know that it is yet another myth.
The initial phase of business analysis – discovery – often results in discovering some aspects of the business problem that were not included in the scope of an approved and funded project.
Some connections or relationships may have been missed. Some aspects of the problem may not have been widely understood or were taken for granted. Thus, the scope of the initiative needs to be amended.
So, in a way, the scope of business analysis comes first, followed by a better-defined project scope.
How can we define the scope of business analysis, then? How can we capture it to help planning the discovery phase or planning iteration?
A simple context model is a good start – every project should have one. The work required to create a context model is valuable – it can help identify gaps before too much investment is made going in a wrong direction.
Context modelling can be done as part of pre-project analysis or feasibility studies. It may be created by a business architect or an enterprise architect.
In many small and mid-size companies, though, it is often up to a business analyst to do.
A context model outlines the environment of the business problem or the desired solution. What entities are involved and will need to interact with the solution or process? Do they need to exchange information, materials, or things? What do these entities provide to each other?
Here is an example exploring the context for the future order processing solution. This model visually highlights key components that the future solution needs to consider. Business analysis activities will need to tackle each of these areas for the related business requirements.
This model can also help divide up the business analysis work among multiple business analysts on a large initiative while minimizing the possibility of gaps and “orphaned” requirements.
From a BA practice perspective, asking a business analyst to step in and create high-level architecture artifact like this is a win-win.
You get a valuable communication tool, a better understanding of the scope of the initiative, and develop your BA resource into a more strategic role, to the benefit of the whole enterprise.
Even if the model is not perfect – it’s still a good start. A childish drawing sometimes extracts more information and creates a better dialogue than an intimidating schematic. Learn how easy it is to create context models with this video.