Collect Requirements

In order to determine the full scope of the project, the Project Management Body of Knowledge advocates for the intermediate step of collecting requirements.

The Collect Requirements process involves assembling all of the project’s various requirements from all of the various stakeholders.  Most projects have more stakeholders than you think.  Every government regulator, utility company, adjacent landowner, investor, etc. who is affected by the project will impose requirements.  Thus, stakeholder discussion is often important right when the project begins, to make sure all the requirements are identified.

This process falls into the Planning process group, therefore the project management plan should have a dedicated section to it.  This section should include, as a minimum, a listing of all of the requirements the project must satisfy.  For projects where requirements tracking is a major consideration (like software development) a separate requirements management plan might be necessary.  This includes things like how requirements will be prioritized, tracked, and measured, and can be an particularly important when requirements are subject to change during the project.  In this case, a requirements traceability matrix is used to ensure the project schedule and cost stay on track.

Project requirements fall into the following 5 categories:

1. Business requirements
2. Stakeholder requirements
3. Product requirements
4. Transition requirements
5. Quality requirements

Business Requirements

These requirements originate from the needs of the organization undertaking the project.  Business goals come from the corporate strategy of the business and the project manager must translate those into project requirements.

It helps to ask why the project was undertaken in the first place.  The performaing organization has decided to undertake the project with the intention of accomplishing certain business goals, and these goals are the source of project requirements.

The project charter is also a good source for business requirements.

Stakeholder Requirements

These requirements take many different forms.  The PMBOK dictates that a project management plan contain a “stakeholder register” (list of stakeholders) which should be consulted to itemize each project requirement.  Stakeholders come in many different forms but here is a relatively comprehensive list.

1. Owners
2. Investors
3. Financiers
4. Competitors
5. Industry Associations
6. Adjacent landowners
7. Environmental regulators
8. Other regulatory agencies
9. Utility companies
10. Vehicle or pedestrian traffic

Stakeholders, by definition, impose requirements to your project (else they are not stakeholders).  Sometimes they have multiple requirements.  Sometimes their requirements are not clear, for example the landowner near a new oil pipeline site who could turn into an adversary or a supporter.  On the opposite end of the spectrum, some stakeholders have developed publications, such as a design manual, listing the requirements.  These should be listed in the requirements section of the project management plan.

Product Requirements

Projects contain deliverables.  Regardless of whether the deliverable a final product or an interim one, these deliverables have requirements.  They fall into two distinct categories:

1. Functional requirements:  The features, functions, and characteristics the product must have.  i.e. Engineering requirements of the product.
2. Non-functional requirements:  Secondary items like safety and security, and service/support levels.  Also, the environment in which the product is effective.

Transition Requirements

Most projects contain interim or transitional items necessary to deliver the project.  For example,

1. Training of the project team
2. Data conversion
3. Prototypes

These are often hidden and difficult to discern, but can trip up a project just like any other requirement.

Quality Requirements

Almost all projects have standards that product designs must meet.  The International Standards Association (ISO) develops standards for many common products and services.

1. International Standards Association (ISO)
2. American Society for Testing and Materials (ASTM)
3. Institute of Electrical and Electronics Engineers (IEEE)
4. Project owner (sponsor) design requirements
5. Stakeholder or regulatory design requirements

Sometimes the requirements are not fully known and become clearer throughout the project, such as a user interface design or unknown underground conditions for a construction project.  In this case, focus groups or workshops are planned throughout the project to facilitate the refinement of project requirements.  Quality function deployment is widely used in the manufacturing industry to clarify product requirements.

When requirements are not fully known it is extremely important that the project accommodates the uncertainty.  This can be done in two ways:

1. Contingencies.  The project schedule, cost, or quality is given an extra amount to ensure the uncertainties fall within the project plan.
2. Warn Stakeholders.  Where possible, stakeholders can be amenable to project changes if the requirements increase from that assumed in the project plan.  This needs to be agreed to at the project planning stage.

Project Management Plan

The project management plan can accommodate the requirements in several ways:

1. A simple listing of the requirements (minimum).
2. A table listing the requirements and equating them to stakeholders.
3. A more extensive document with stakeholder and requirements analysis, such as what factors influence the requirements, how they might change and how they should be managed.

The size and format of the requirements section depends on the size and complexity of the project.