Create Requirements Management Plan

The Requirements Management Plan describes how you will elicit, analyze, document and manage the requirements of the project. This plan will cover the up-front gathering of high-level project and product requirements, as well as the more detailed product requirements that you will collect during the project lifecycle. This plan should especially focus on how you will manage changes to the requirements after they have been originally approved.Adhering to a Requirements Management Process helps the project team focus on the requirements that have been developed and maintains the integrity of the requirements throughout the lifecycle of the project. Sections of the plan could include the following information:

• The requirements gathering process. In this section you will describe the process that you will use to elicit, analyze and document the requirements.
• Roles and responsibilities. This section lists the roles that will be involved with managing the requirements through the rest of the project lifecycle. Roles could include the project manager, lead analyst, clients, etc. The project manager, for instance, should have the overall responsibility for scope change management of the requirements. Someone, perhaps the lead analyst, should have overall responsibility for the integrity of the requirements throughout the rest of the lifecycle.
• Tools. Describe any automated tools that will be used to manage the requirements. There are a number of tools that can be used to document, manage and track requirements throughout the lifecycle.
• Change control. There should be a formal process to manage changes to the requirements. Hopefully, the entire project is using a formal scope change process. If so, then this overall scope change process should be specifically applied to the changes in requirements. If there is no formal overall scope change process, a specific change control process should be documented here.
• Requirements traceability. If your project team is tracking (tracing) requirements from Analysis to Design and through the rest of the lifecycle, the overall process should be described here. This process should then be added to the schedule to ensure the proper tracking of requirements occurs throughout the rest of the project.

Work With Your Client When He Cannot Completely Define the Project

Sometimes the project manager places too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project and the client will not have all of the information needed. This happens all the time and it does not mean that the client does not know what he is doing. In many cases, especially for large projects, the client has a vision of what the end results will be, but cannot yet articulate this vision into concrete deliverables. He may also not know all of the answers on scope, risks, project organization, etc.  Based on having less-than-complete information, the project manager may feel the need to guess on the details. This is not a good solution. Instead, if you are faced with this situation there are a couple ways that you can proceed.

• State up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty of the work. Your estimate may have a contingency of 20%, 40% or even higher.

Although you do not know everything, you should at least know enough that you can plan the work for the first 90 days. You plan the short-term work in more detail, and leave the long-term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more-detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

• Break the work down into a series of smaller projects (as described previously). Even if the final results cannot be clearly defined, there should be some amount of work that is well-defined, which will, in turn lead to the information needed for the final solution. You should only define a project to cover as far as you can comfortably “see” at the time. Then, define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables.

tenstep