What You Should Know about Defining Scope for the PMP Certification Exam
For the PMP Certification Exam, you’ll need to know that defining scope covers defining the project and product scope in more detail. Clearly defined scope enables project success. Ill-defined scope leads to conflict, rework, and stakeholder dissatisfaction. Therefore, time spent to fully understand project and product scope is time well spent.
Define Scope. The process of developing a detailed description of the project and product.
Define Scope: Inputs
You use the high-level information from the project charter, guidance from the scope management plan, and the more detailed requirements documentation to develop a project scope statement.
Project scope statement. The description of the project scope, major deliverables, assumptions, and constraints.
The project scope statement helps stakeholder understand what is in and out of scope and provides a documented basis for making decisions. For organizations with robust project management processes, you will probably find policies and procedures that give direction to defining the scope. You will probably also find some templates as well.
Define Scope: Tools and Techniques
To move from a high-level understanding of the project, as documented in the project charter and as detailed in the requirements documentation, you need to work with people who understand the product, project, and the technical details. Another way of saying this is that you need expert judgment, and that might come in the form of team members, consultants, customers, or professional organizations.
You might opt to gather these experts and have a facilitated workshop. A JAD session will often assist in collecting the information needed to develop a robust scope statement.
In practice, gathering requirements and documenting the project scope happen at the same time. It is an iterative cycle that continues until the requirements are complete and information on the project scope is fully defined.
For many projects, the end result is one or more products that can be broken down into component parts or deliverables. By analyzing the end product and determining the component elements, you can get a better understanding of the deliverables and appropriate acceptance criteria.
Depending on the type of project you’re working on, you might hear this process referred to as system engineering, product breakdown, requirements analysis, or value engineering.
In project management, there is usually more than one way to go about meeting objectives. You can take into consideration the benefits, costs, risks, and feasibility of various options, be it as simple as deciding whether to outsource work or do work in-house, or assessing whether to use an existing product as a starting place, or reinventing something by starting with a blank slate.
As your team goes through the process of analyzing the product and generating alternatives, project scope becomes clearer, and you can begin to develop the project scope statement.
Define Scope: Outputs
The project scope statement can be as detailed as needed to understand and control the scope. At a minimum, it should include, either directly or by reference to other documents, the following:
Product scope description: A narrative description of the product. It should contain more detail than the project charter.
Acceptance criteria: A description of the conditions or criteria that must be met for the customer to accept the final product or product components.
Deliverables: Include not only the product deliverables but also the project deliverables. This can include training, documentation, reports, research, and the like.
Project exclusions: Clarifying what is not in scope. These exclusions should be implicitly stated to minimize misunderstandings and conflicts later in the project.
One of the easiest ways to control your scope is to clearly define what is excluded. Many stakeholders will assume that if something is not excluded, it is included. Those who have fought this battle a few times have learned to insert this simple sentence into the exclusions: Anything not specifically included, is excluded.
Project constraints: A limitation or restriction. Many times, a fixed budget or contractually agreed-upon milestone dates are constraints. Certain regulatory standards are also constraints.
Project assumptions: Aspects of the project that are thought to be true but aren’t proven should be documented. For example, you could assume that a cafeteria food service vendor will do any food preparation. This won’t be certain until a contract for the extra work is completed, but at this point, you can assume this to be true for planning purposes.
Assumptions. Factors in the planning process that are considered true, real, or certain without proof or demonstration.
Constraint. A limiting factor that affects the execution of a project, program, portfolio, or process.
An example of a schedule constraint is any limitation or restraint in the project schedule that affects when a schedule activity can be scheduled, such as a fixed delivery date or milestone.
Many project managers move their assumptions to an Assumption Log as they are progressively elaborated. You can refer to the log in the scope statement, or keep high-level assumptions in the scope statement and more detailed ones in the Assumption Log.