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 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 to improve collaboration with your stakeholders? Let’s explore this dimension in this second 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 elicitation challenge
Eliciting requirements is one of the foundations behind business analysis work. Through stakeholders inputs, the BA is capturing business and system requirements in order to define a working solution that should solve a business problem once implemented.
One of the key issue in this process is to determine whether or not elicitation is completed. Stopping elicitation before all requirements are identified can indeed lead projects to disaster.
One effective way to improve requirements coverage is by involving your stakeholders more closely in the exercise.
Techniques to improve collaboration
Talking to people can only get you some information, no matter how good your questions are. One of the best ways to engage your stakeholders and have them give you richer requirements data is by using scenarios and prototypes. By using these techniques, you’ll break the ice more easily, and you’ll be able to use other techniques more fluently with your stakeholders (as we’ll see below).
Side note: there are many, many variations on these two concepts. No matter which one you use, you’ll reach the same objective of eliciting more requirements from your stakeholders.
Having your stakeholders walk through a specific, business-related scenario, or having them playing with a low- or high-tech prototype, will make them think about situations requiring a special treatment or a completely different process. It will highlight specific information required to perform given tasks. It will make business rules stand out.
Having a good knowledge of current business processes is essential to lead such walkthroughs. The precious input gathered is hard to get just by asking questions; it’s even harder when you act like if you were the stakeholder.
Improve collaboration to increase benefits
By using your BA deliverables to work with your stakeholders, and not only using them to store information, you will get richer requirements, covering various domains:
- Information architecture | Working with prototypes will help you get a better grip on how information should be structured to be useful for your stakeholders and end users. Information architecture on Wikipedia can cover a large range of concepts, from high-level system navigation, to detailed user interfaces and activity flows, to reports structure. In the end, it’s all about how the solution should support end users information needs.
- Logical data structure | Information architecture provides details on structure, but not on the content itself. However, by working closely with your stakeholders, you will be able to identify many information attributes and entities that are required to support their activities in the business processes, especially when dealing with special cases and exceptions. This will be essential to create artefacts such as entity-relationship diagrams (ERD).
- Interactions between data elements | Information entities rarely live on their own; they interact with each others to bring business processes to life. Working hand in hand with your stakeholders will give you essential input to fully understand there dynamics between those entities, which can then be documented in various artefacts (such as UML sequence, state, or activity diagrams).
- Business rules | They are often buried deep down in policies and procedures documentation, making them hard to harvest through standard documentation analysis. However, having your stakeholders involved in creating your deliverables will bring those business rules to life, allowing you to capture them and complement what you might have already found.
- Non-functional requirements | These requirements are often forgotten during elicitation phase, because they are often less obvious to your stakeholders. However, once they’re actively working with scenarios and prototypes (especially high fidelity prototypes), they are usually more prone to expressing their needs and concerns regarding performance, reliability, accessibility check for others of the future solution.
By working with all these artifacts and your stakeholders, you will be able to capture much more information from them. However, this comes with some challenges, as most people are not used to work like this. You also have to take care of not giving the impression of outsourcing your own work to your stakeholders 🙂
In the end, both of you will benefit from working together closely, making the solution more adapted to business needs while easing transition and change management efforts.
In the next post of this series, we will take a look at how Business Analysis deliverables can help you support the project team during the implementation of the solution. Don’t want to miss this? Simply subscribe to Eric the BA newsletter below!
Do you like what you’re reading?
Did you get other benefits from working hand in hand with your stakeholders? Share your thoughts in the comments below!
Image credits: ukodi @ flickr.com
