4squareviews

The first process in the Scope knowledge area, Plan Scope Management, was essentially a place where all the other processes for scope management were detailed, including this first one, Collect Requirements.

The requirements are the conditions or capabilities that the product, which is being produced as a result of the project, are supposed to contain.    These requirements are  the scope of the product; it is distinguished from the scope of the project, which is the work required during the project to produce that product as an end result.

Where do these requirements come from?   They can be specified in the project charter (see 5.2.1.1 below), they can come from business documents like the business case (see 5.2.1.4 below), from agreements (contracts) with vendors or business partners (see 5.2.1.5 below), or from stakeholders.   This post will cover these various inputs into the process of collecting and analyzing these various potential requirements,

5.2.1  Collect Requirements:  Inputs

5.2.1.1 Project Charter

The project charter is the output of process 4.1 Create Project Charter.   The project charter is essentially the “seed” of the project, because it contains a lot of high-level information on the project including any high-level requirements the sponsor wants to include as part of that charter.   This is probably the first place to look for such requirements if you are a project manager.

5.2.1.2  Project Management Plan

The components of the project management plan that are used as inputs for this process are:

• Scope Management Plan–this is the output of process 5.1 Plan Scope Management.   In particular, the scope management plan will show how this process, 5.2 Collect Requirements, needs to be done.
• Requirements Management Plan–the Project Management Plan contains management plans from each knowledge area, like the Scope Management Plan mentioned above, and it also contains some supplemental management plans like this one designed specifically on how to handle requirements.   Given that the subject of this process is requirements, it is easy to see why this management plan is an input.   It is also an output of process 5.1 Plan Scope Management
• Stakeholder Engagement Plan–this is an output of process 13.2 Plan Stakeholder Engagement.    You will need to get many of the requirements from stakeholders to supplement the ones you find in the project charter and the business case, and the Stakeholder Engagement Plan will give you information on who the stakeholders are and what their current level of engagement is with respect to the project.

5.2.1.3 Project Documents

Here are some project documents which may be considered as inputs for this process.

• Assumption log–high-level strategic and operational assumptions and constraints are normally identified in the business case (see 5.2.1.4 below) and will flow into the project charter (see 5.2.1.1 above).   These high-level assumptions are then put into the assumption log, which will later also include lower-level assumptions such as technical specifications, budget and schedule estimates, risks, etc. that will be developed later on in the planning process.
• Lessons learned register–(output of process 4.4 Manage Project Knowledge)the specific area that this register can provide information on is techniques for effective collection of requirements, particularly for projects that are using iterative or adaptive (agile) product development methodology that develop the scope on a cyclical or ongoing periodic basis.
• Stakeholder register–(output of 13.1 Identify Stakeholders) contains information on stakeholders so you can identify those who can provide information on the requirements.   It also contains information on the stakeholder’s expectations and level of engagement with the project which will help you when engaging them regarding these requirements.

5.2.1.4  Business Documents

In particular, the business case, which ties together the a) purpose or objective of the project, b) the business need for the project (why is the project being done, i.e., what need does it fulfill), and c) the strategic alignment of the project (how will it align with the business strategies of the organization doing the project).   This can be done by the sponsor or by a business analyst.

5.2.1.5 Agreements

Agreements with business partners can contain project and product requirements.    (There are also agreements with vendors, but these will enter the picture later on in the planning process.)

5.2.1.6  Enterprise Environmental Factors

Several of these are listed in the PMBOK Guide, but the most important are the organization’s culture, which will determine many requirements on how the project is done (the scope of the project), and marketplace conditions, which will determine many requirements of the product.

5.2.1.7 Organizational Process Assets

The OPAs that can influence the Collect Requirements process include:

• Policies and procedures–this will go into the Scope Management Plan which will outline the process by which the company will do the processes in the Scope knowledge area, including how requirements should be collected and analyzed, which is the subject of this particular process 5.2 Collect Requirements.
• Historical information and lessons learned repository from previous projects–this will contain information not only on how requirements were collected from previous projects, but will also inform the assumptions log which will be helpful in analyzing those requirements.

Now that you have the requirements you have collected from various sources–from the project charter, business case, stakeholders, and project documents such as the assumptions log and the lessons learned register, it is now time to analyze them.   That is the subject of the next post…

Filed under: Uncategorized |