Angela Wicks recently posted an article on BAtimes about “getting requirements done faster”. She shared great insight and thoughts. She also made excellent points about why requirements elicitation and analysis are so critical for success.
Sometimes when a Business Analyst (BA) is asked to document requirements, they pull out the latest and greatest template and get started. I don’t think this is the best first step. No matter at what point in the process a BA is brought into a project and no matter what the urgency is, they should want to fully understand the problem in the current state in order to be most successful. What triggers the problem? Who are the people involved? Is there existing documentation with guidance which should be reviewed and considered? Are there other departments or teams who should be consulted? Only when the problem is fully understood and agreed on should requirements discussions begin and solution options be considered. Without alignment on the problem, there will likely be differing opinions of what the solution should be because each person could be trying to solve a different problem. Or worse, people could expect different results from the same solution due to the differing views of the problem. Also, the question ‘Why?’ should be asked often, and root cause should be identified and agreed upon by all involved. Digging into the problem and understanding the context, breadth and depth helps quantify the problem, and it also will provide details that influence the requirements plan and approach.
A BA brings more to the table than just documentation skills. They are skilled facilitators, and use this expertise to elicit information from Subject Matter Experts (SME). The BA may not have the critical knowledge and expertise, yet by knowing how to ask the right questions they are the ones who are able to define the true business problem. Those who have been involved in projects know this is not an easy task. It requires many conversations and questions to reach the root cause of a problem, be it a problem with process or technology, or possibly both. Just as important as being able to define what ‘is’ the problem, is being able to articulate what ‘is not’ the problem. This is essential to keep the solution scope focused on the problem which needs to be addressed.
Once a BA fully understands the problem to be solved, and all the stakeholders agree, then the most effective requirements discussions begin. All stakeholders are considered, and constraints and impacts are also taken into consideration. This is easy to describe in writing where it all makes perfect sense. In practice, though, it’s not so easy. As a BA, what techniques do you rely on to make sure you fully understand an issue or problem before beginning the documentation process?
