Any project’s lifeblood is its requirements. At least, that’s my opinion. Poorly defined requirements can lead to a lot of rework, missed deadlines and budget overruns, frustrated customers, or failed implementations. It’s like trying to drive your car without gas in the tank. It won’t work with any chance of success.
Having said that, once the scope and requirements have been defined at the start of the project planning process, is it done? Some PMs and members of the project team may argue that we are done. It is not true. Requirements management, Ai regardless of whether you realize or not, is an ongoing process throughout a project engagement. The four activities below highlight the fact that this process, which is initiated during initial requirements planning, is a continuous repeatable process.
Definition of Requirements
The requirements definition activity is the foundation of any requirements management process. Many customers enter an engagement with their requirements in hand. These requirements are rarely detailed and are often not accurate. If you accept the requirements as-is, you will be failing your customer and team. Ask tough questions and ensure that the requirements are clear, precise, and concise. This phase is not something to be taken lightly. It will lead to customer frustrations that will come back to haunt your company later.
Create a Requirements Traceability Maprix
This is an optional option, but it’s a good idea. For complex projects, a requirements traceability matrix can prove to be very helpful. It is basically a process or tool that allows the project team to document the project requirements one at a time and then update the matrix as design and development takes place. This information includes information about where each requirement is found in the solution. It serves two purposes. It ensures that all requirements are included in the solution and provides documentation for testing teams to follow when testing the solution against the scope of the effort.
Review the suggested changes to the scope of the project
Customers can request changes at any time. This happens on almost every project (ok, most projects since the beginning). The PM and team are responsible to verify that the request is within the project’s scope. This scope is determined by the requirements that were established early in the project’s development. The project team must ensure that all requests are within the scope of the solution they are creating. They will end up doing unnecessary work for clients and spending too much on work that is not planned or paid for.
For customer review, prepare any necessary change orders
Any work that was not covered in the previous step must be documented and presented to the customer along with a change order. This will include an estimate and signoff/approval options. This allows the delivery team, which includes the PM and your team as project managers, to charge customers for work that is not within their scope. It also keeps the project on schedule in the project tracking system and on-budget. This is a crucial factor in ensuring that the deployment goes smoothly and on-time.
Summary
See? Do we have to stop once the requirements are set? No! Not even close. We are actually only at the beginning stages of the requirements management process. We are now in scope management. This is the point at which we have a defined scope, based on the requirements that were documented during the initial requirements definition phase.