Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been inside enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.
In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.
Practice #1 – Requirements Reviews and Buy-In
It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.
When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.
But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.
This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.
Practice #2 – Include All Possible Stakeholders
While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.
This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.