
It can be easy, when I’m finally finishing that challenging, infuriating chunk of requirements I’ve battled with over weeks or possibly months, to overlook the real purpose of the stakeholder review.
As a less-experienced BA, I fell into the trap of thinking a review was about showcasing my analysis skills and seeking validation. As I matured and gained more experience, I realised the true value lies in helping business stakeholders critically examine the requirements and fully understand their implications for the project. While challenging, and however uncomfortable it may feel, revealing any gaps or misinterpretations up front is much less uncomfortable (and costly) than having them reveal themselves in development, or even worse, in production.
Before I hand over my artefacts, I put myself in my stakeholders’ shoes and ask:
Have I provided a cohesive narrative? Each artefact should clearly articulate a different aspect of the requirements, with interconnections that are easy to follow.
Have I made assumptions about stakeholder knowledge? My artefacts should contain all the relevant information they need.
Have I clearly articulated complex concepts? I should have anticipated and clarified areas of potential confusion or ambiguity.
Have I completed basic hygiene checks? Spell check, formatting, and consistency in terminology, all contribute to helping my stakeholders easily understand what I’ve written.
I’m conscious of the fact that business stakeholders often juggle a day job in addition to their participation on my project, and there’s a chance they’ll be reviewing my work at 11pm at the end of a very busy day. The easier it is for them to do an effective review, the better the outcomes will be for the teams downstream and for my project as a whole.
Are there any other questions you’d include in this list?
Comments