Business Analysis is mainly about communication, where your ultimate goal is to understand, summarize and communicate your stakeholders’ requirements. From business processes models to detailed solution requirements and UML diagrams, your deliverables and requirements packages will be at the center of your work as a Business Analyst.
However, these deliverables should not be the end of your work; they are only the means to work more closely and efficiently with your stakeholders so that everyone will be on the same level of understanding about the requirements.
How can you use your BA deliverables as an insurance policy for the implementation of a solution? Let’s explore this dimension in this last of a 4-posts series.
In the Taking Business Analysis deliverables to the next level series, I explore the various ways a Business Analyst can use deliverables for more than pure requirements documentation. Whether they are used for improved collaboration, team support our as an insurance policy, BA deliverables can be brought to the next level as long as they meet quality standards and are relevant to stakeholders.
The lost art of mastering business needs
After they are defined and agreed on, requirements are often lost and forgotten as stakeholders usually focus on building the solution based on this requirements image. However, changes will occur until the delivery of the solution, and unless the project team is prepared to handle them, these changes will cause harm to (or even lead to the cancellation of!) the project.
Even if you’re ready to handle these changes, things might derail if requirements are misunderstood by the development team (or any of the stakeholders). And like changes, misunderstandings will occur in the life of your project.
In many cases, people will blame requirements (because when in doubt, blame weak requirements). So what a BA can do to prevent this?
An insurance policy against misunderstandings
Misunderstood requirements can introduce much noise in a project, no matter how will they are documented. This can lead to many problems, ranging from frustration and rework to delays and change requests (oh! the dreaded word).
One of the most important role of the BA at this point is to ensure that everyone in the development team has the same knowledge about the requirements and the solution to be implemented. This requires great communication skills and can be achieved through many different techniques (structured walkthroughs, daily scrums, etc.), but the one thing that these techniques have in common is your BA deliverables.
Your deliverables will not only be useful as a reference for what needs to be done, but they will also provide guidance and context about the whole solution. This highlights the need to keep this information up to date with changes that will occur in the project.
An insurance policy against changes
Organizations change over time, so will requirements. Dealing with those changes is therefore a critical process for all projects unless they can handle the risk of delivering an irrelevant solution for stakeholders.
However, defining a change in requirements, identifying its impacts on implementation efforts and determining whether or not it can be considered in project scope can be challenging when you don’t have a clear understanding of the solution to be implemented.
This is where your BA deliverables will be useful once again. By providing a clear view of the requirements and the solution, your various requirements packages (together with your involvement as a BA) will help your stakeholders to deal with changes, especially the project sponsors and the project manager who might not be aware of every detail of the solution.
Leadership by knowledge
Business Analysis is leadership without authority. By being involved actively in the implementation phase of a project, the BA acts as the go-to guy for every stakeholder, enabling a common understanding of the requirements until the delivery of the solution.
The BA is also a good ambassador of the solution among his BA colleagues. This becomes particularly critical in organizations where multiple projects are going on at the same time, since you want to make sure that all these projects make sense together, from an organization perspective.
Do you like what you’re reading?
Do you have other examples of how your deliverables provided such an insurance policy over a solution? Share your thoughts in the comments below!