Forgot your password?

Project Management Practitioner: Project Scope Control

This article has been generously donated to InfoBarrel for Charities.
By Edited Aug 6, 2016 0 0



  • Introduction
  • Terms
  • Phased Projects
  • Multi-Phased Projects
  • Lessons Learned:  Words for Advice
  • In-Scope/Out-of-Scope
  • Breakdown Structures
  • Lesson Learned:  No-Go
  • Breakdown Structure
  • Final Words


As we’ve covered many areas of the project management process or discipline, the term Scope is used quite often. The concept of Scope is at the foundation of a project. In the lessons for Scope Management, Scope Statement and Scope Creep, we clearly defined the content of scope, why it exists and how it is used in defining the project end-state. Now we will look at another commonly used term: Scope Control. Don’t worry, this will not be a long read. Much of scope control, as you will see, is accomplished in Change Control, Risk Management, Quality Control, and Scope Verification. [1][2][3]

Scope Verification will be address is another separate lesson/article because of its inter-relation with Quality Management functions, Project Completion and Close-out responsibilities.



Scope Control and the term Scope Change Control are generally used interchangeably. That’s fine. What term you use is an internal organization decision. Current doctrine, according to the Project Management Institute (PMI), is to use the term Control Scope in Chapter 5 of the Project Management Body of Knowledge (PMBoK) 5th Edition (2013). If you are studying for the Project Management Professional Exam, you will need to use PMI’s lexicon.

For our purposes here and from a practitioner’s perspective, we will use the “old School” terms of Scope Control and Change Control. We will also briefly touch on the topics of: In scope and out of scope, associations and/or relationships to a few of the Breakdown Structures (Work Breakdown Structure/Project and Product Breakdown Structures), and then a final word on one of the PMI terms: Integration Scope Control. [5][6][4]


As you know, scope affects the entire project from beginning to end. There are two versions of scope: one for the product or service that results from the project and one for the project itself from an all-inclusive output and PM functionality. Product versus Project will be another of our shorter lessons to be published in the next few days following this article. For the remainder of this lesson we will reference scope from the impact or affect and the control there of, relative to both a product and a project perspective. 

Phased Projects

Projects may be large enough that a phased approach is beneficial. The original scope, both the project and product scope defined at the outset of the project, drives and is affected by everything from the initiation of the first phase through close-out of the final phase. Each phase will have its own scope in relationship to the larger scope. All five processes will exist within each phase of a multiphase project; thus these process groups are linked iteratively – the results and realized scope of one phase become the initiation and defined scope of the next phase. Any alteration to the product or project scope as each phase progresses has to be reconciled with the original scope. Long involved projects will experience multiple planned scope change events, scope creep/unplanned events, risk threats, to include impact on cost and schedule.


For example: Your business wants to add a new original automobile to its next year’s marketing plan. The project management office (PMO) determines that this is a multi-phase operation. The project is broken down into four phases: Concept, Detailed Design, Build, Test and Evaluations.

Concept Phase: A new product design might require a concept phase; the purpose of which is to determine “what the product should be; what do we want to create.” It begins with the overall product and project scope: Your team may not have a full picture of what they want to create therefore we have a Concept phase define what we want to build. The desired end-stated of this phase is a well thought-out set of features and functions desired in the new vehicle along with a scaled model of what the vehicle is to look like. The product of the Concept Phase is the Initiation of the second phase – the Detailed Design Phase.

Detailed Design Phase: The scope of the Detailed Design Phase is derived from the output of the Concept Phase. This next phase scope statement will establish a defined end-state. The goals and objectives of the phase might include a fully developed set of design specifications, a scale model of the product, possible component scale models, if necessary, a list of specified parts and instructional information. 

Build Phase: Scope outcome of this phase will be a full size/fully functional product based on the closeout of the Detailed Design Phase.  

Test and Evaluation Phase: Includes scope verification and product acceptance.

That being said, a follow-on phase can begin before the previous phase is closed-out. Planning for each phase begins as soon as there is sufficient information and details relating to the scope specifications necessary to breakdown and defines the work activities or work packages for each progressive phase. For instance, before the concept phase closes out the design phase scope can begin development. Once the Detailed Design and Specifications of the product are nailed down, a rough draft of the scope for testing and evaluation procedures can begin, even though that phase follows the Build Phase. In this way a project manager and the sponsor can continually measure the current state scope against the original project/product scope to ensure the original goals and objectives are consistent with the final phase scope. 

Lesson Learned

Scope control is critical as each phase progresses. Failure to control scope throughout the project will result in a project outcome unrecognizable to the original project’s intent and purpose. Remember these words, words I’ve said to other leaders and managers: Don’t just stand still watching grass grow. Continually develop plans, check status, evaluate performance against the plan, identify risk and scope changes, make necessary adjustments to the plan and or the product, document, refine the plan and test/evaluate and verify results against the agreed on scope and project goals and objectives.  


Multi-Phase Project

Here is an example of a multi-phased project run by an overall Program Manager with separate Project Managers running two of the major phases. I developed this many years ago for training project managers. This is another way to look at the concept of multiple phases for a project. As stated earlier, the original scope established at the project’s outset, defined with the customer client and sponsor, must be continually checked as the project progresses towards its end/completion.

Scope Control is the not so simple task of keeping the project’s outcome (product or services) in line with the original Scope Statement, Definition(s), Scope of Work, and Contractual Obligations.

Scope Change Control is how we deal with planned and unplanned changes to the project or product scope. Any change to the project scope, planned or unplanned, almost always requires an adjustment to the project cost, schedule, risk assessment, quality planning, scope verification planning, as well as ensuring that the changes are consistent with the original purpose, goals and objectives that breathed life into the project in the first place. For more on this topic see the Project Management Practitioner article on “Change Control Management.”


In-Scope versus Out-of Scope

Referring to something as being “In-Scope” or “Out-of-Scope” is a convenient way to designate what side of the line an alteration to the original scope will fall. This is one of the project manager’s and sponsor’s (as well as contracting and procurement office’s) best ways to communicate and argue (from a logical argument perspective) whether a proposed, planned, or unplanned alteration to the original scope is consistent with the original scope. It is a very effective way to avoid or deter talk and unapproved actions that someone might want to call “the grey areas” of scope. It’s natural for members of a project team, workers, users, client members and suppliers to make alterations to the project or product with good intentions, yet those alterations are completely out-of-scope and may cause drastic changes (usually negative) the cost and duration of the project.

The first time In-Scope and Out-of-Scope items will come to the surface is during the effort to develop a Scope Statement and in the Scope Definition. As issues are brought up, usually in the form of suggestions or desires by the team members, subject matter experts and client/users, during the defining of the project/product outcome those items need to be designated as whether they are “in” or “out” of scope.

How do we determine or track whether there is a Scope Control issue?

It’s all about monitoring, reviewing, tracking, analyzing the plan against the actual performance as the project progresses. Communications and the methods used in performance reporting are crucial to knowing where the project sits against the plan. Formal and informal performance reporting, MBWA (management by walking around: something I discuss in the article on Project Leadership) project team meetings, along with quality checks are the primary means of identifying changes to the project/product scope. 

Other sources of information affecting scope are the more direct:

  • Change requests (formal or informal);
  • Legally mandated or business decisions that require an alteration to the project;
  • Planned parts or resources (to include human resources) that once implemented, fail to achieve project goals/objectives; and,
  • Technological changes that would benefit the project with minimal affect to cost/time;
  • Surprise changes can be created by externally resources/procured items that, when delivered, are not what was ordered. This situation will require a quick assessment as to the impact to scope of accepting the item(s) as is or returning them for the correct items. You’ll have to assess what are the options and what is the risk(s)/affect(s) to the project.


Lesson Learned

Anything that is clearly out-of-scope needs to by recorded and posted along with the project status charts or reports. For example, if you have a project office, war-room, or work room of some sort, it’s a good idea to record and post those out-of-scope items (what I also call “No-Go” items) where everyone can see and be reminded as such. Sometimes you’ll have a team member or client/user that is like a dog on a bone and won’t want to let go of one of those items. By posting those no-go items in the room along with the project schedule and performance reports, you should be able to reduce the re-hashing of old arguments. If at some point, a No-Go item is slipped into the project, and it happens, you can then run it through the Change Control Processes to determine the remedy options and if that includes added cost and time, you place the approval authority for that in the hands of the sponsor.

Breakdown Structures

  • Work Breakdown Structure (WBS)
  • Project Breakdown Structure (PjtBS)
  • Product Breakdown Structure (PdtBS)

Changes, planned and unplanned, must be gaged and reconciled with the breakdown structures. This might be best explained with an example:  The sponsor has approved an additional feature to the product. Change control documentation is completed. An additional feature represents a change to the scope of the project/product. The additional feature must be added to the WBS, PjtBS and PdtBS. Relevant work packages must be modified or added. Cost assessments and adjustments must be made to the project and integrated into the overall budget, schedule, and cost and schedule performance projections to include the role-up values. [5][6][4]

Final Word

The bottom line is that the PM, the team, sponsor and users (client/customer) must be on the same page as to knowing what is “in” and “out” of scope. When something happens that affects the scope to the detriment of a project and product (in terms of the contracted and approved scope) the PM take corrective action.

The PM must determine:

  • What caused the scope change?
  • Who initiated the change?
  • What corrective action was taken, if any?
  • What is the impact on the project?
  • Can this be remedied with little to no adverse effect to the project?
  • If there has been or will be an adverse effect and how can this be minimized?

Corrective action based on the answered to the above questions will take many forms to include: Change Control Process, Risk Identification, Analysis and Contingency Planning or Response, alteration/revision of the project schedule and cost projects, and pretty much whatever it takes to bring the project back in line with the plan; even if it becomes a completely revised plan.



Add a new comment - No HTML
You must be logged in and verified to post a comment. Please log in or sign up to comment.


  1. Cory Stophlet "Project Management Practitioner: Project Scope." InfoBarrel. 14/11/2014 <Web >
  2. Cory Stophlet "Project Management Practitioner: Creating a Scope Statement." InfoBarrel. 14/11/2014 <Web >
  3. Cory Stophlet "Project Management Practitioner: Scope Creep." InfoBarrel. 14/11/2014 <Web >
  4. Cory Stophlet "Project Management Practitioner: Project Breakdown Structure." InfoBarrel. 14/11/2014 <Web >
  5. Cory Stophlet "Project Management Practitioner: Work Package Authorization." InfoBarrel. 14/11/2014 <Web >
  6. Cory Stophlet "Project Management Practitioner: Techniques for Work Breakdown Structures." InfoBarrel. 14/11/2014 <Web >

Explore InfoBarrel

Auto Business & Money Entertainment Environment Health History Home & Garden InfoBarrel University Lifestyle Sports Technology Travel & Places
© Copyright 2008 - 2016 by Hinzie Media Inc. Terms of Service Privacy Policy XML Sitemap

Follow IB Business & Money