Project requirements are the lifeblood of any project. At least in my opinion. Poorly defined requirements can mean lots of rework resulting in missed deadlines, budget overruns, frustrated customers, and failed implementations. Think of it as trying to drive your car with no gas in the gas tank. It just can’t happen with any semblance of a successful outcome.
That said, when requirements are defined at the beginning of the project planning process and the scope is set, are we done? Some PMs and project team members may argue that, yes, we are done. But the reality of it is that requirements management – whether you realize it or not – is an ongoing process throughout the project engagement. And that process, that is started during initial early requirements planning is a continuous repeatable process highlighted by the four activities below.
The requirements management process must always start with the requirements definition activity. Many customers come into an engagement with requirements in hand. Rarely are these detailed and rarely are they 100% accurate. You will be failing your customer, team and project if you accept them as-is. Ask the tough questions, make sure the requirements are right and accurate and concise. You will do no one any favors by taking this phase lightly…it will only result in customer frustrations which will come back to haunt you later when the project goes over time and budget due to poor requirements that you could have corrected with the customer had you taken the time to do so and properly planned out the time in the project tracking software.
Create a Requirements Traceability Matrix
This is optional, but never a bad idea. A requirements traceability matrix can be especially helpful on very detailed projects with complex requirements. Basically, it is a tool or process by which the project team is documenting the project requirements one by one and updating this matrix as design and development happens with information about where in the solution any given requirement is met. Its purpose is basically two fold…it ensures that all requirements appear in the solution AND it provides documentation for the testing teams to follow when thoroughly testing the end solution against the planned scope of the effort.
Review Suggested Changes Against the Scope of the Project
Any time customers request a change – and it happens on nearly ever project (ok, probably every project since the beginning of time) – the PM and team are responsible for checking that request against the scope for the project. And this scope is based upon the requirements that were defined early on. So, basically, the project team must constantly be reviewing the requirements to ensure that any requests fall inside the scope they are developing the solution against. Otherwise, they will find themselves doing free work for the client and exhausting the project budget on work that was not originally planned for and not being paid for.
Draw up any Necessary Change Orders for Customer Review
Any work mentioned in the previous step that is identified as out of scope must be documented and brought forth to the customer with a change order that includes an estimate and a signoff/approval option. This gives the delivery team – you the PM and your project team – the ability to charge the customer for the work they need that is out of scope and keeps the project on track in the project tracking system and on budget. That’s a huge factor when trying to keep moving forward to a successful on time and on budget end deployment.
See? Are we done once requirements are defined? No! Not even close. In fact, we are only really at the beginning of the requirements management process. From that point on (the point at which we have a defined scope based on the requirements documented during the early requirements definition phase) we are in scope management mode. Any change to that scope means new requirements, and it means change orders that will result in a modified project scope that will need to be managed against from that point on. It isn’t easy – scope management never is. But it is necessary and not all PMs are good at it. The best ones keep one eye on scope throughout the project and one eye on the work that is being done. And PMs must rely on their project team to help them track scope and identify needed changes to that scope based on customer needs and requests that come up during the course of the engagement.