Introduction
The scope of a project constitutes all the work to be carried out on the project for a given cost, to an agreed quality, and by a given time. Scope is one of the three elements of the “classic” iron triangle and triple constraints in project management. It is, therefore, an important aspect of project controls because without controlling the scope of a project, the project will experience scope creep. Scope creep occurs when a project’s scope and deliverables change and expand in an uncontrollable way, beyond the scope that was originally planned, causing the project to experience cost overrun and time overrun. Scope creep can happen deliberately or additional elements of work may “creep” unintentionally onto the project as a result of various stakeholders on a project making changes to the project scope without considering its impact and project controls.
The importance of scope management is evident in the research that underpins the PCIM project control methodology where design and scope changes were found as the leading project control inhibitor for both cost and time control. Additionally, many other studies have shown the importance of scope control to project success; for example, the research by PMI (2020) found that scope creep affects 35 percent of projects. Successful project control is impacted by a clear definition of the scope of the project at the outset and the ability to manage change effectively through the project. These include scope management, such as controlling the quality of the contract documents, quality of response to perceived variations, and extent of changes to the contract. Little wonder why the PCIM research identified the effective management of scope and design changes as a leading factor influencing effective project cost and time control. The remaining sections of this chapter present an overview of some of the key principles of scope management.
The APM Book of Knowledge (BoK) (2019) states that scope management is the process whereby outputs, outcomes, and benefits of a project (see Chapter 11 for benefits management) are identified and controlled. In essence, scope management is the process required to ensure that the project includes all the work required to complete the project successfully. As summed up by the PMI (2021), scope management is primarily concerned with defining what is, or not, included in a project. Additionally, scope management helps in determining and documenting all the project goals, tasks, deliverables, deadlines, and budgets of a project right at the outset of the project, enabling the costing and scheduling of work and facilitating the management of changes and associated cost and time impact as the project progresses.
It is worthy of note that scope management is not about preventing changes from happening on a project since it is not always feasible to expect that a project will be completed without any change. The progressive elaboration characteristics of projects means that as the project progresses, more is known about the project and there might be a need to make changes to the original scope. Additionally, because projects are usually delivered over a time period and are not immediate deliverables like operations, the circumstances that the project was originally conceived might have altered (e.g., economic changes or client objectives) requiring changes to be made to the project.
Finally, scope management is aimed at managing changes in a controllable way with impact assessment carried out as well as the appropriate governance for approval in order to make the best decision for the project and its stakeholders. The aim of scope management is to prevent scope creep on a project, which can occur easily if a project scope is not properly defined, documented, and/or controlled. In addition to its control function, scope management also involves the process of quantifying what is included, and what is excluded to be delivered on a project and subdividing the scope of work into manageable work packages.
Components of Scope Management
Scope management involves three areas: initiation, scope planning, and scope control as shown in Figure 9.1.
Figure 9.1 Components of scope management
Initiation
The initiation component of scope management covers the rationale for the project and how it fits into the organization’s strategy. Initiation is the first phase of a project’s life cycle and is focused on starting up a new project. The project initiation phase of a project is where the business problem or opportunity that the project is required to solve or exploit, respectively, is identified. Additionally, the initiation phase of a project is where the business case (see Chapter 11 for more on business case) for the project is developed. The business case presents the problems or opportunities for the project and the options available to solve the problems or exploit the opportunities and the preferred solution selected for implementation. In essence, the solution selected sets the context for the scope of work to be delivered because different options will have different scope. In addition to the business case, the initiation phase will usually be required to produce the following output in order to get the project established:
• Project brief: A statement of the situation, outlining the problem/opportunity.
• Project proposal: An outline either of a solution to the problem, or how to maximize the opportunity presented. This is issued in response to the brief.
• Project charter: Contains the project’s terms of reference, that is, the formal approval of the existence of a project, including assigning of project name and identification number (ID number). A project charter should be a tightly worded document outlining what is to be done and the project’s boundaries. It formalizes the project and should be documented and approved by the relevant stakeholders in line with the governance arrangement of the project. The project charter should also include:
The background to the project
Key assumptions
The business and other needs
The scope of work
Identification of key activities, budgets, and dates o Comments on how the project is to be managed
The role of the project manager (responsibility and authority) and reporting structure
Scope Planning
Project scope planning is concerned with the definition of all the work needed to meet the objectives of a project successfully. The aim of scope planning is to enable a clear identification of all the required work of a project, the documentation of the deliverables and outcomes, and the definition of the boundary conditions required to complete a project. Additionally, scope planning involves identifying the goals, objectives, tasks, resources, budget, and timeline of a project. Scope planning enables the project management team to have clear information about all the work that needs to happen on their project as well as the work that is not required. Furthermore, scope planning facilitates the updating and documentation of changes to the scope as the project progresses. In essence, it is the basis for control in a project.
At the heart of scope planning is scope definition. Scope definition is the identification, description, and documentation of all the work necessary to complete a project. A well-defined project scope is a necessity to ensure the success of a project. Project definition is achieved strategically through the project scope statement. The project scope statement establishes the project baseline and boundary conditions, which cannot be compromised without the approval of the project sponsor or responsible stakeholder as determined by the governance structure of an organization. Scope planning is implemented on a project through the work breakdown structure (WBS) (we look at this in detail later in this chapter) or product breakdown structure (PBS).
As contained in APM BoK (2019), a product breakdown structure (PBS) is a hierarchical structure of things that the project will make or outcomes that it will deliver; it decomposes a “main project’s product” into its constituent parts in the form of a hierarchical structure. A project consists of deliverables; however, these deliverables are not what is referred to as products, it is the features of these deliverables that need to be specified by the users, and then need to be designed, developed, and tested, or reviewed, to ensure they meet the users’ specifications that are products. In essence, the focus is on products to be produced, not the work to be done to produce them. Therefore, if the product is deemed to have met the specifications, then invariably the deliverable has been delivered correctly. For example, in a project, scheduling the project is an activity or project deliverable while the approved project schedule is a product. While in an IT project, an example of a project product is the user acceptance testing approval document. In contrast, the work breakdown structure (WBS) provides a hierarchical structure of project activities (see Section titled “The Work Breakdown Structure” later in this chapter and Figure 9.2), that is, the project “to-do list.” The WBS focus is always on the work to be delivered and not the documents to confirm that the work has been carried out. For example, in a civil engineering project, “carry out compression testing” is part of the work while “approved compression testing certificate” is a product.
These breakdown structure tools (WBS/PBS) specify very clearly what is included, and just as importantly, what is excluded from the project (and is to be done “by others”). An important aspect of scope planning is decomposition of the work, that is, breaking the product and the work into tasks. Therefore, the use of breakdown systems depends upon the conceptual deconstruction of the project into its constituent products and parts. Breakdown structures systematically help with the planning for and communication of the work that needs to be done on a project. One of the key rules of breakdown structure is the popular “100 percent rule,” which states that the WBS must include 100 percent of the work defined by the project scope and capture all deliverables (work to be completed, including project management activities).
Scope Control
All projects are subject to scope changes at some point during their life cycle. A scope change control system is a system that is designed to manage the change of scope process effectively. As mentioned earlier, only scope changes that are beneficial to the project should be allowed following a robust impact analysis. The project management team should install a robust system to monitor, evaluate, and approve all changes in accordance with the delegated authority governance structure of the project and organization before these changes are incorporated into the plan. Any scope change control process should be agreed upon by the project team and communicated to all the project stakeholders at the outset of the project as previously explained in Chapter 5. The process of scope control should be robust enough to cope with managing change to the deliverables of a project as they evolve through the project life cycle. The governance, administrative, and approval activities related to the identification, analysis, and communication of proposed changes should be made clear. There are two aspects to scope control. These are (1) scope development or design development and (2) scope changes or design changes.
Scope design and development: Design development is the process by which a specification, outline scope, schematic design, or high-level design and scope for a project is translated into the detailed design and scope that allows for the execution and delivery of the project.
Scope and design change: Scope and design changes involve variations to the project scope or design that have already been agreed. Any change to the scope or design of the project after the scope has been agreed upon will be a variation to the contractually agreed scope of the project. Therefore, it is important not to confuse design change (variations) with design development. In essence, in relation to the agreement and contractual sign-off of the project’s scope, delivery timescale, and design before this milestone are “development. While changes to scope and design that happen once these have been contractually agreed upon or outside the parameter of the scope are design/scope changes, which are considered additional to the contract and may attract a time extension and additional costs since they are likely to impact the established contractual time and budget agreements.
Change impact analysis: It is important that any scope changes are assessed for impact by not just the scheduler (for time implication) and cost expert (for cost impact) but by the technical discipline responsible for the area of change. This will enable the project management team to understand the feasibility of implementing the change technically, the consequential effect on the technical aspect of the project as well as the resultant cost and time implications. Other areas of the project that need to be assessed for an impact of changes include procurement, production (resource impacts) quality, legal obligations (is the change permitted or will it infringe any legal obligations?), and risk (will the change introduce additional risks to the project that need to be mitigated or is the consequential risk significant enough to avoid the change?).
The Work Breakdown Structure
It is evident from this chapter that an important part of scope management and control is the work breakdown structure (WBS). Therefore, for completeness, this chapter concludes by looking at the concept of WBS in more detail. Projects can be broken down in a number of ways, for example, by functional areas, physical grouping, products (the PBS described earlier in the chapter), and activities of work (the WBS described earlier and discussed in detail here). The WBS is the most common way projects are broken down. The WBS, according to APM (2015), is used to break down a project into smaller elements and create packages of work to define responsibility for delivery and facilitate project control.
The WBS is vital for project control because cost and time control cannot be carried out effectively without the principle of the work breakdown structure. The WBS is the framework or skeleton upon which the whole project rests. It is the work scope organized into a detailed hierarchical format and ties all the three sides of the project iron triangle (work scope, schedule, and cost) together. As stated previously, the WBS is the breakdown of the project into all the activities and tasks needed to design, procure, implement, and complete the project. Furthermore, WBS helps present the physical subsystems to be developed and links the components of work to be done to each other and to the overarching project when finished. The relationship between WBS, cost, and time is that quite often the breakdown of cost is based on the WBS while the WBS informs the development of the schedule.
The WBS is the fundamental framework for defining the work content of the project, for organizing the cascade of activities, and for coding activities on a consistent basis. Typically, a work breakdown structure (see Figure 9.2) is organized into levels of detail as follows:
Level 0: The overarching project and the outcome or deliverable Level 1: The overarching project schedule
Level 2: Work packages
Level 3: Group of activities or tasks that are required to deliver the work packages
Level 4: Individual activities or tasks
Figure 9.2 A typical work breakdown structure
The Purpose of Work Breakdown Structure in the Planning and Control Process
The WBS is crucial in achieving effective control of a project. As defined by the APM (2015), the WBS provides a common framework for the development of the planning and control of a project. Kezner (2017) goes further by asserting that the WBS is the single most important element of planning and control because it provides a common framework from which many of the activities of planning and control are implemented. For example, due to the WBS:
• The planning of a project can be carried out and documented more accurately, especially when a WBS code is assigned to all the work of the project;
• The overall project schedule can be simplified into smaller components and aggregated back to form the overall schedule in a logical manner enabling a better understanding of the project;
• Costs and budgets can be determined for the whole project and for various levels of the project;
• The key performance metrics of a project such as time, cost, and resources can be monitored;
• Reporting approach for the key performance metrics (including scope) of the project can be established to enable accurate reporting; and
• Ownership and responsibility for the completion of various areas of the project can be done easily and enables the production of a robust responsibility assignment matrix.
Conclusion
This chapter has shown the importance of scope management to the project control process. Scope control is the link between time control and cost control. This is because time control aims to control the planned scope of a project at the planned time while cost control aims to ensure that the cost of the scope of work being delivered is within the planned cost for that scope of work. A lack of control of the scope will invariably affect the cost and/or time of the project. Therefore, as far as projects are concerned, a clear change and scope control procedure should be installed that defines how changes are recorded, evaluated, authorized, and implemented in a controlled manner. The scope control process should define clearly the responsibilities, accountabilities, approval thresholds, and associated timeframes required to impact assess and approve a scope change request. Additionally, as part of the scope control process on projects, there should be a formal recording of change control requests and approvals. This should be undertaken using standardized templates or a software tool. The change control tracker should be up-to-date and include details about the scope change such as the change owner, the estimated cost, budget availability and associated timeframes, and impact on time, cost, quality, and project benefits.
The governance approach for accepting changes in projects should be structured and robust to achieve an effective project control. Therefore, the evaluation, approval, rejection, or deferment of scope change requests should be carried out in accordance with the agreed governance regime of an organization, for example, the delegated authority matrix. The practice in most projects is to send the design or scope change request to a change control board or panel for approval. As a minimum, the cost, schedule, technical, and quality impact should be assessed in a robust way and attached to change control requests. The change control board or panel should be made up of people with good authority in the business with the right balance of skills and experience. This will enable them to make the right decisions about the change request that do not threaten the ongoing viability of the project’s business case, associated benefits, and is congruent with the project’s objectives and the organization’s strategy.