Imagine a business analyst starting a new job in a large organization. After being shown around and getting oriented, the analyst gets a demo of the new requirements management or application lifecycle management tool.
“All of our requirements are now tracked in this tool”. “You don’t need to create documents anymore”. “Just make sure you populate all the required fields”. “We now have full traceability”. “Your job is to ensure the integrity of our requirements repository”.
The analyst is happy to have joined such a mature organization. No more filling in the business requirement document templates. No more notes. No more keeping extra spreadsheets or old-fashioned writing of requirements. It’s a new age now. Insert the requirement into the tool, follow the format – and the code will write itself.
If only things were ever so simple… In practice, the monstrous tools often have high demands. Depending on how they are set up and administered, and the level of governance and oversight, there will be attributes to fill, traceability to include, names to attach, versions to assign, multiple dates to track, and approvals to collect in a pre-set hierarchical order….
The requirements meetings will evolve into the tool update sessions, with everyone supplying the required information, and the analyst spending several hours a day making updates, linking, creating traces and running integrity reports.
What epic should we slot this under? Should it trace to here or to there? What’s the business value? Should we say 20 or 40? Who said 40? No, 30 is not an option.
Shall I include you as an owner? Why not? In that case, I would have to confirm with her, since she is not at the meeting. Can we have two owners? Let’s see whether the tool allows two owners.
What about the diagram? Oh, it’s already attached to another requirement? OK, then I’m going to reference it and add the same keyword.
What’s the title? Oh, sorry, that title is too long, it does not fit. Can we shorten it a bit? Oh, you can’t approve it yet, I need to collect the first level of approvals first. You will receive a notification…. And so on and so forth.
Before long, the analyst becomes a glorified repository administrator, feeding the tool all the time as you would feed a hungry beast.
Now, don’t get me wrong, I’m not against the tools. Some requirement management tools are very powerful and can support an efficient requirements management process if used wisely.
Any tool can be helpful if we use it right and becomes a burden or even a danger if misused.
Dear Business Analyst:
Whether you use the fanciest tool or the old-fashioned business requirements document, your role and job are still the same:
A. Understand the business problem and discover its root cause
B. Help business stakeholders articulate and visualize the future state
C. Map out current and future state to identify what the gaps are
D. Turn out the results of your analysis into articulate, clear and unambiguous requirements
E. Ensure that all stakeholders, including the business and technology side, reach and maintain a shared understanding of the requirements
Yes, you may use various tools to capture and track requirements when you get to D and E – but please remember to first get A, B and C right.
As you lead business stakeholders and customers along the business analysis path, don’t start with populating the tool – start with “Tell me about your problem”.
Don’t let any tools dictate to you what questions you need to ask to understand the business and its challenges.
Don’t let fields and hierarchies overpower the mind map that you need to build in order to understand different facets of the issue and to discover hidden gaps.
Remember the power of distraction: do not let feeding the tool with data, properties and flags distract you from the analysis itself.
And be wary of the illusion of completeness: however complete and densely populated with data the records in the requirements repository may look, however much you’ve shovelled in to keep the beast happy, you will not know whether a set of requirements is complete until you validate it using the analysis tools.
Be especially careful to manage expectations of the business stakeholders: a deep hierarchy of themes, epics and user stories taking up twelve screens, or a dense matrix filled in with codes may create expectations that the requirements are complete. Even you, the analyst, may fall into the same trap if you are taking over a set of requirements in progress. Don’t – validate, look at the big picture and make sure you understand the full context before you can judge the completeness of a set of requirements captured in a tool.
And remember that regardless of the tool, you still need to create and share with stakeholders the high-level view of the solution. Models and diagrams are even more important when the detailed requirements are forced into a strict uniform format.
More posts in the Business Analysis Pitfalls category.
Find all Business Analysis Pitfalls posters in the Business Analyst Mindset Digital Toolkit.
Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
This is fascinating!