What is it?
Requirements for a project need to be mined, compiled, analysed, negotiated, specified, validated, tracked, and updated during the life of a project. All of this has to take place within a controlled environment so that;
- All stakeholders know exactly what is to be delivered by the project team.
- There is governance placed around the authorising of changing requirements.
- The solution can be supported into the future. i.e. new personnel can read the requirements and get a FULL understanding of the system intent.
- Each requirement can be traced back to a specific commercial outcome.
What can it look like?
The method of requirements delivery will vary from project to project normally based on project complexity. As well as complexity the level or type of requirements management can vary for risk, cost or political purposes. Here are some common project requirement configurations across simple, standard and complex project categories;
Each organisation may use different document titles however the purpose and content should be very similar. Some organisations may also use a version system on each of the documents. The core concept here is that collectively all requirements are trapped and documented.
The Commercial Imperative?
The requirements delivery for a project is directly related to the projects commercial outcomes. Every requirement delivered should exist in one of the requirements documents and each of the requirements should have an associated commercial cost (even if it is $0). A problem we see too often is project teams failing to document $0 changes. Whilst they may think that this is saving time on admin they are actually causing the following potential problems;
- Future support engineers may not be able to understand what was delivered by reviewing the documentation.
- They miss the opportunity to show the client what value add they have delivered [especially if there were multiple “no-charge” changes.
- Having a change made to the deliverable without the appropriate authorities knowledge or approval.
This diagram shows the accumulation of cost [or revenue if you are a service provider] that should attach to the requirements.
What happens when we get it WRONG?
Research tells us that approximately 50% of projects have a frustrated delivery and approximately 25% of projects have a complete failure to deliver. Poor requirements management is a major contributor to both of these outcomes.
Failure to manage requirements can lead to any or all of the following NEGATIVE outcomes;
- Stakeholders feel they have lost control of the project and withdraw support.
- Unneeded requirements can be delivered.
- Critical requirements can be missed.
- Forward support of the solution can be costly and time consuming.
- The project can experience poor commercial outcomes.
- Loss of reputation from delivering a poor outcome.
The good news is that with proper planning and care any organisation can become good at project requirements management. See our other blog posts for additional related information;
At FileBound we would love to hear any thoughts you have around this subject matter. Have we missed anything? Have you noticed similar outcomes?