4squareviews

The last process 5.2 Collect Requirements not only collected the requirements, but analyzed, prioritized, and selects the final requirements that will go into the product, service or result that the project is going to create.

The requirements of a project are like the structural members of a building that provide the weight-bearing structure that holds the building up.    The scope of a project are the connecting structures of a building:   the walls, floors, ceilings, and windows that connect the building into a seamless space.

This process 5.3 Define Scope takes the final requirements that were decided upon as the output of the last process and develops a detailed description of both the product and the project that will create it.   It creates the boundaries of the product and project, listing not just what is going to be included, but what is going to be excluded.   Also, the acceptance criteria for the scope are developed so that in the process 5.5 Validate Scope, there is no room for misunderstanding between the customer who ordered the product and the organization that did the project to create it.

This post will cover the inputs to this process.

5.3.1 Define Scope:  Inputs

5.3.1.1  Project Charter

The high-level project description and list of product characteristics as well as approval requirements are provided in the Project Charter.   This is the first place to go for finding out about the scope of the project.

5.3.1.2  Project Management Plan

In particular, the Scope Management Plan component of the master Project Management Plan will document how to do all the scope management processes, including this one.

5.3.1.3  Project Documents

• Assumption log–created as an output of the same process that created the Project Charter, the assumption log identifies the high-level assumptions and constraints about the product, project, environment, stakeholders, and any other factors that may influence the project and product scope.   If these assumptions change, then it may cause the project and product scope to change as well.
• Requirements documentation–created as an output to the last process 5.2 Collect Requirements, this is where you should go (after the Project Charter listed above) to identify those requirements that will be fleshed out into the product and project scope during this process.   The requirements documentation may take the form of a Requirements Traceability Matrix.
• Risk register–created as an output to process 11.2 Identify Risks.   Sometimes a strategy to avoid or mitigate a certain risk may involve
  • reducing or changing project or product scope
  • hiring a vendor to handle a certain portion of the project or product scope that your organization doesn’t have the expertise to handle
  • entering a business partnership to work together with another company that has expertise with a certain portion of the project or product scope

5.3.1.4  Enterprise Environment Factors

The complete list of factors is listed on p. 152 of the PMBOK® Guide 6th Edition, but the factors that could affect this process 5.3 Define Scope include the following:

• the culture of an organization (is it leaning towards traditional project management methodologies, agile methods, or some hybrid in between)
• marketplace conditions (what are the competitors doing in this same area),
• the company’s infrastructure (which may determine if vendors are needed to handle some of the scope, or if the company needs to acquire additional resources for the project).

5.3.1.5 Organizational Process Assets

The organizational process assets that could influence the process 5.3 Define Scope are:

• Policies, procedures, and templates for a project scope statement (which should be included in the Scope Management Plan, the output to process 5.1 Plan Scope Management)
• Project files from previous projects (why re-invent the wheel?)
• Lessons learned from previous phases or projects (produce new mistakes this time around–don’t waste time repeating old ones!)

In the next post, we will go through the tools and techniques used in this process.   Like any decision-making process, these will include the generic tools used for such a process like expert judgment, data analysis, decision making, and interpersonal and team skills, but will also include a tool and technique called “Product Analysis” that is specific to this process.

Filed under: Uncategorized |