Project scope issues are the number one reason for unhappy clients and customers. Human nature is such that unauthorized tasks will always tend to slip into a project unannounced, thus project scope management is just as important as the more visible aspects of project management like scheduling and budgeting.
Hence, it is the project manager‘s job to actively manage project scope.
That’s also why the Project Management Institute considers scope management as one of the 10 knowledge areas within the Project Management Body of Knowledge (PMBOK).
Definitions
Project scope is defined as the work performed to deliver a product, service, or result with the specified features and functions. In short, it describes the boundaries of the project – where it begins and where it ends.
In a similar fashion, product scope is defined as the features or functions that characterize a product, service, or result.
The relationship between project and product is relatively easy to understand. Most projects produce some sort of end product, therefore the project is the means and the product is the end.
Steps in Project Scope Management
Although it may seem complex with many overlapping variables, there are a clear set of analytical tools who’s goal is to ensure that the work required to deliver a product, and only the work required to deliver the product, is performed as part of the project.
The three main parts of project scope management are:
- Determine project scope
- Preventing scope creep
- Managing scope change
Determining Project Scope
The first step in proper scope management is to determine what the scope is. This involves the creation of a project scope statement.
Poor scope definition at the beginning of a project ensures that different stakeholders have different expectations regarding what is and isn’t included within the project, which is a certain formula for unwelcome project changes.
Stakeholders, by definition, pull at the project from different directions. A common scenario is that one stakeholder wishes to ensure that a certain aspect of the project is exceptionally well researched (for example, a government regulatory agency), while another stakeholder wishes to minimize the project cost (for example, an investor). For this reason, any ambiguity in project scope at the start of the project is likely to be interpreted by stakeholders in their favor, tending toward a maximum of project changes.
A project scope statement is a great way to begin to manage the project scope, and it is an integral part of all project management methodologies. Scope statements minimize risk. They should be detailed enough to define all of the important project boundaries. The maximum length has been obtained only when the time spent writing it does not reduce a corresponding amount of risk.
Initially, the production of a scope statement starts with the breakdown of the project into tasks, or a work breakdown structure. The tasks are estimated, and schedule dates are determined. Resources are then assigned to each task. The project’s goals and objectives are considered and the scope is finalized into a coherent statement of the project’s boundaries.
Project scope statements have 5 important components:
- Description of the work
At its core, it communicates to all stakeholders what work is being done. It should be descriptive and precise, clearly establishing where the project begins and ends. - Deliverables
The items that will be delivered to the client, customer, or end user are described in detail, again focusing on its boundaries. - Justification for the project
Describing the underlying business case can be very informative and communicate to the stakeholders where the primary motivations lie. Clear communications about underlying business needs can often solve future conflicts about specific project issues. - Constraints / Assumptions
All projects have constraints and assumptions, and these are usually where the conflicts between stakeholders start. Projects assume that resources will be available, project costs will be constant, people will not move, and a myriad of other things. Documenting these assumptions can avoid conflict later on. - Inclusions / Exclusions
Explicitly stating what is and is not included within the project can be a savior when conflicts arise. As a minimum, obvious questions about project scope boundaries should be explicitly answered.
Good scope statements provide strong project boundaries which are communicated to all of the project stakeholders, however keeping those stakeholders within the project boundaries is entirely a different matter.
Preventing Scope Creep
Every project stakeholder tends to think that they are the most important cog in the project wheel. They have seen the project scope statement, but they ask for a little bit more – a bit more analysis here and a bit better quality there. The project team itself is one of those stakeholders. They often bring in more resources or add product quality which was not planned (gold plating) thinking they are helping the project but in reality they add costs that must be dealt with by other stakeholders (the funding ones) after the project goes over budget.
Thus, it is human nature that unauthorized tasks get inserted into projects if the project scope is not actively controlled. Project managers must expect this phenomena from day one. It is called Scope Creep, and it is a cancerous parasite that has been known to eat projects alive.
The solution to scope creep is called Earned Value Management, a process which has been adopted by the Project Management Institute within the Project Management Body of Knowledge (PMBOK).
On predetermined intervals (usually one week), each project task is analyzed for its percent complete, and the following three variables are determined:
- Planned Value (PV)
The time phased amount of progress according to the project schedule, expressed as a project budget. For example, if a task has a budget of $10,000, and the beginning and end dates are June 1 and June 20, and it’s June 10 today, PV = 50% x %10,000 = $5,000. - Earned Value (EV)
The actual progress of the task, expressed as a project budget. For example, if a task has a budget of $10,000, and it is 25% complete, EV = 25% x $10,000 = $2,500. - Actual Cost (AC)
The actual cost of the task. Most organizations track this very well, but if not you can add up employee hours or receipts to determine actual costs.
Once these three variables are determined from actual project statistics, the following four variables represent a snapshot of the current schedule and budget status.
- Schedule Variance (SV)
SV = EV – PV
The SV represents that amount that the project is ahead or behind schedule. Positive means ahead of schedule and negative means behind schedule. It can be compared to the overall project budget, for example, if SV = -$2,500 the project is behind schedule but this is much more concerning for a project worth $10,000 than for a project worth $1,000,000.
- Schedule Performance Index (SPI)
SPI = EV / PV
SPI is a measure of the schedule efficiency of the task (or project). An SPI of greater than 1 means the task (or project) is ahead of schedule, and less than one means behind schedule. For example, if SPI = 1.35 the task is 35% ahead of schedule.
- Cost Variance (CV)
CV = EV – AC
Similar to the Schedule Variance, the Cost Variance calculates the amount that the project is over or under budget. Positive means under budget and negative means over budget. It can be compared to the overall project budget, for example, if CV = -$5,000 the project is over budget, but this is much more concerning for a $10,000 project than for a $1,000,000 one.
- Cost Performance Index (CPI)
CPI = EV / AC
Similar to the Schedule Performance Index, the Cost Performance Index measures the cost efficiency of the task (or project). A CPI of greater than 1 means the task (or project) is under budget, and less than one means over budget. For example, if CPI = 1.2 the task is 20% under budget.
Those four variables give the project manager an excellent snapshot of the current status of the project (both budget and schedule). But that’s not all. The next step takes scope management to a whole new level. These four variables forecast the future project performance rather than just measure the current performance.
- Estimate at Completion (EAC)
- If past efficiency (that is, CPI) will be representative of future efficiency,
EAC = BAC / CPI
- If future efficiency will be at the original planned rate,
EAC = AC + BAC – EV
- If both the cost and schedule efficiency (that is, CPI and SPI) are representative of future efficiency,
EAC = AC + [(BAC – EV) / (CPI x SPI)]
- If the initial plan is no longer valid, a new estimate must be produced,
EAC = AC + New Estimate
The EAC is an important metric. It is the expected final project budget under the current budget and schedule status, and you have several choices regarding how to extrapolate them to the end of the project. Since no project is ever likely to be exactly on its budget and schedule point at any time other than its very beginning (that is, CPI and SPI aren’t exactly 1.0) project managers are constantly trying to forecast the EAC to ascertain if they need to obtain more project funding.
- If past efficiency (that is, CPI) will be representative of future efficiency,
- Estimate to Complete (ETC)
ETC = EAC – AC
The Estimate to Complete is derived from the EAC, and it is the amount of money needed to finish the project. Instead of the overall project budget (EAC), it consists of only the part that is left to spend. So you can compare it to available funds.
- Variance at Completion (VAC)
VAC = BAC – EAC
VAC represents the expected final Cost Variance (CV) upon project completion, given the assumptions in the calculation of EAC.
- To Complete Performance Index (TCPI)
- To achieve the original project budget
TCPI = (BAC – EV) / (BAC – AC)
- To achieve the EAC,
TCPI = (BAC – EV) / (EAC – AC)
- To achieve the original project budget
The beauty of the earned value method is the speed at which the information arrives on the project manager’s desk. The PV and AC of each task is measured right at the point of analysis (i.e. that day) resulting in the SV and CV displaying the scope creep as its occurring, and the magnitude of the scope creep is reflected in the EAC and VAC. Meanwhile, the TCPI shows how efficient the project needs to be to finish on time. For example, if your TCPI = 0.95, you can clearly see with amazing speed and clarity that scope creep has resulted in a need to be 5% more efficient for the remainder of the project, in order to finish on budget.
Managing Scope Change
Generally speaking, scope changes should be kept to a minimum and, when absolutely necessary, approved by the project manager and/or project sponsor. But alas, sometimes scope changes happen. And in those cases, it is important to maintain a strong focus of the definition of project success within the project management plan.
Success is usually best defined using bullet points, for example:
- Finish on time
- Finish under budget
- Minimize environmental damage
- Ensure client satisfaction
Because the definition of a project is an endeavor that is temporary and unique, the first two will almost always factor into project success. However, most projects have a list of secondary stakeholders which have minor interests in the project of a varying nature, and each stakeholder brings requirements to the table which factor into project success.
The project manager must introduce a change in the project scope by ensuring that all stakeholders are consulted and actively managed. By definition, the scope change will affect at least one stakeholder negatively, and that stakeholder should be consulted as necessary to gain acceptance. Negotiation tactics and people skills are paramount to resolving points of difference. The scope change plan must be presented openly and honestly to all stakeholders.
In the PMBOK, the project change control process is initiated to implement the scope change, and the project management plan is updated with the new scope statement, if necessary.
Project Scope Management in the PMBOK
The PMBOK has 6 processes as part of the Project Scope Management knowledge area:
- Plan Scope Management
The process of creating a scope management plan (a component of the overall project management plan), which documents how the project and product scope will be defined, validated and controlled. - Collect Requirements
Determining, documenting, and managing stakeholder needs and requirements to meet project objectives. This process consists of the creation of a list of requirements the project must meet. - Define Scope
This process involves the development of the project scope statement, a detailed description of the project and product. - Create WBS
The Work Breakdown Structure is a subdivision of project work and deliverables into smaller, more manageable components. Unlike the project activity list, which is developed within the Project Schedule Management knowledge area, the WBS is pinned to project deliverables. However, in spite of PMI’s separate definitions, in practice the WBS and Task List are often used interchangeably. - Validate Scope
Validating the scope refers to formalizing the acceptance of the project deliverables. This refers to the acceptance of the final “delivered” project deliverables (during the Monitoring and Controlling phase), not acceptance of what the deliverables will be during the planning phase. - Control Scope
Project scope control involves monitoring the status of the project scope (and product scope) and managing changes to the scope baseline.
Project Scope Management in PRINCE2
The PRINCE2 project management methodology addresses project scope indirectly.
The planning theme requires a work breakdown structure which identifies the tasks that are included within the project. The WBS becomes part of the Project Initiation Document (PID) which defines the project.
The project manager is required to produce a Product Description (A.17) and a Project Product Description (A.21). These documents describe the purpose of the product to a level of detail that is sufficient to plan and manage its development. Together with the work breakdown structure, they define the project scope.
The project scope is re-evaluated at each stage boundary, and an exception plan is produced for any changes in project scope.
Project Scope Management in the IPMA
The IPMA’s Individual Competence Baseline (ICB) contains a competence element called “Scope” in the Practice #3 category. This competence element requires the project manager to understand, define, and manage the specific content of the project.
The key competence indicators are:
- Define the project deliverables
- Structure the project scope
- Define the work packages of the project
- Establish and maintain scope configuration
Project Scope Management in Agile
In Agile projects, the scope changes often from one sprint to the next. The project manager, as a servant leader, collects and documents the scope, rather than dictates it downward. The project team obtain scope information directly from the project sponsor, client, or customer.
This happens at the start of each iteration. Hence, scope is defined at the beginning of each cycle rather than once at the beginning of the project.
Conclusion
The three key aspect of project scope are
- Defining the scope well
- Controlling scope creep, and
- Managing scope change
Master those, and you will have a solid foundation to avoid the number one cause of dissatisfied clients and customers. Good luck, and leave us a comment below to share your experiences with project scope.
