Scope, a Small Word with a BIG Meaning

The word SCOPE is a word that is thrown around quite a lot in reference to the scope of a project or the scope of work, but what does it really mean and why is it important?

Scope1Credit: Cory Stophlet, 2014

If money, materials and people represent the ocean, the ship and the crew, scope is both the navigator and our destination point on the map. Without a scope that is well defined, specific with a detailed description, we have no clear direction, no sight of the shore or end-state. We have no common understanding of what done looks like. We won't know where we are going or how we should get there. Projects live, set their direction, schedules, funding, human resources, quality measures, and assessments as to whether or not the project has been completed or not based on "scope" (to include the concept of "scope of work").

A well-defined scope is the foundation of starting a project off on the right-foot. Often where projects go wrong is right up front with unclear project and product scope requirements. A great planned project schedule with lots of money, material and human resources will mean nothing if we don't know what "DONE" looks like - And, we can only know what "DONE" looks like, if we clearly define what our project is to deliver in the form of product(s) or service(s). How do you know when the project or product is successfully delivered?

For people who are familiar with Project Management Institute (PMI) and its Project Management Body of Knowledge (PMBOK) Guide, you probably remember their functional group called "Scope Management." In this industry standard publication, they describe this group as consisting of Scope Planning, Scope Definition, Scope Verification, and Scope Change Control. I only bring this up to make sure the reader is aware that an industry standard definition exists; however, in the remainder of this article, I will stray somewhat from the PMI model in order to focus on scope from a "practitioner's'' view. That being said, in this version, I will discuss Scope Statement, Scope Definition, Design and Specification Document (here is where I stray from the PMI model), and Scope Management and Control from a "Lessons Learned" perspective.

Scope2Credit: Cory Stophlet, 2014

Scope Statement

The scope statement provides a documented basis for making project decisions, for developing common understanding of the project scope among project stakeholders. The statement should include: project justifications, project product, project objectives, and the major deliverables. Project objectives, great and small, must be documented. Remember, good objectives are quantifiable and measureable in terms of cost, time and quality. Where do we get our information to create the project scope statement? Begin with the project charter and continue by gathering together all the background information justifying the project's existence to include (if not already in the charter): the business case, initial risk considerations, constraints and assumptions.

Consider the difference between Project Scope and Product Scope: The scope of a project is inclusive of all the work that must be performed in order to deliver the project. The product scope, on the other hand, is specific to the delivery of all the features and functions required for that product or service. The completion of project scope is measured against the plan; while, the completion of the product scope is measured against the requirements. Remember this when you compile the objectives and plan for performance measurements.

Scope3Credit: Cory Stophlet, 2014

Design and Specification Document

What is it? It's exactly what it sounds like; a detailing of all the specific features, functions, specially requested and or unique pieces and parts that the customer/client/sponsor desires to be included in the project. Before developing the Scope Definition, to include the Work Breakdown Structure, define the project and product in as much detail as possible by collecting the customer/client/sponsor's desires and requirements, analyzing the project and product for technical, regulatory, normally associated requirements, consider cost and benefit analysis of methods in planning for the project, recruit expert judgment and consider any alternatives that may be used to mitigate potential risk issues. Document all the specific requirements. It's not uncommon for the customer/client/sponsor to decide that they want something else, something added, or something they forgot to mention at the outset.

On long projects that involve special technology like a computer or special software, it is fairly common that, after the project and all contracts have been bid-out and accepted, the customer/client/sponsor wants the latest and greatest stuff exchanged for their project, yet, they don't want to pay for it or the extra work and rework. If the project outcome is a software product and the program is to allow for data entry and perform various calculations, nail down the users on how they want to enter the data and how or what/how are the calculations based/performed. If you nail these issues down before creating the work packages and schedule, you will have a more accurate planning model to measure performance against, as well as, reduce risk of errors later in the project. A "Design and Specifications Document" will be crucial in managing the scope and change control.

Scope Definition

After the scope statement, objectives and the design and specifications document are established, the "defining" doesn't stop - it's time to get deeper in the details. Defining the scope into the Work Breakdown Structure (WBS) (and eventually the planned work contained at the lowest level of WBS components becomes work packages). Both the WBS and the Work Package Authorization (WPA) require the project to broken down into quantifiable sub-end-states. What this means is, the project and or product of the project has major elements that will, usually, be reducible further to smaller and smaller sub-elements that are measurable.

PMI refers to this exercise as "Decomposition." For example: If the project is to build a new house, there are the obvious first level major elements: (also first level of the WBS) Foundation, Frame, Roof, Sewage Line, Exterior Construction (Brick), Main Water Line, Main Electric Line, Main Gas Line, Interior Construction, Exterior Construction, Exterior Concrete Surfaces (Driveway/Sidewalks/Porch), so on and so forth… The first level WBS item, "Interior Construction," continues to break-down into the next level items of: Interior Rooms, Kitchen, Garage, etc.; these reducible units are quantifiable and can be more easily converted into work packages that cost and resources can be applied. I’ll publish more specific information on the Work Breakdown Structure (WBS) and Work Authorization Package (WPA) in a separate article.

Scope Management and Control

Scope Management and Control identifies how you will verify and deal with scope changes throughout the project; how you will ensure that approved scope changes will be integrated into the total project; anticipate level of change activity; with the level of detail reflecting the complexity of the project.

Keep your eye on what is in-scope and out-of-scope. As important as "what" is in the scope of your project, you should also list "what is not." If you can anticipate or if, as often occurs, someone or group proposes work, additional features and functions that are not cleared by the client/customer/sponsor and processed via the change control mechanism, communicate to the team that those proposals are out-of-scope. The benefits of reminding everyone what's in and out of scope are: to avoid confusion, remove assumptions, add clarity, reduce the tendency of straying from the schedule and work packages.

Scope Change Control is straight forward: it means the controlling of changes to project scope in terms of recognizing when they occur, formalizing the change control process, evaluating change for effects on time and cost and quality of the project and the resulting product or service.

Once approved, changes to the scope changes are fed back to the planning process to make adjustments to WBS, plan, costs, time, quality and resource. Lessons Learned: If an unplanned and unapproved change occurs determine who initiated the change, what is the impact on the project, what action was taken and why, and take corrective action. This "corrective action" will be dependent on how far the unapproved scope change has progressed. The simplest thing to say is to do whatever you need to do to bring the project back in line with the plan.

Remedy actions may include, dialing back on the change to remove it, run the change through the change control process to allow the client/customer/sponsor to determine whether they want to accept it or not, and don't forget to emphasize with the team and stakeholders the importance of working the system for changes: the Change Control System or Mechanism.

Scope4Credit: Cory Stophlet, 2014

A part of the Scope Management and Change Control process is Scope Verification. PMI/PMBOK states that "…process of obtaining formal acceptance of the project scope by the stakeholders (sponsor, client, customer, etc.). It requires reviewing deliverables and work results to ensure all were completed correctly and satisfactorily." However, in practice this verification mechanism is a continual assessment of the project and product performance in meeting the original scope along with the approved changes implement during the life-cycle of the project. It is not a single event but a continual surveying of the project's performance.

At the conclusion of the project there must be a final scope verification to ensure that all identified project deliverables have been completed satisfactorily. The final formal scope verification is the process of formalizing the acceptance of the completion of the project scope. Once all scope items are verified at the conclusion of the project, a formal acceptance is documented. As a note, the final scope verification and a quality control evaluation of the project results are usually done together.


The scope is a further description of the project. It is attempting to further define the end deliverable. The idea is that as you are proceed through the planning phase you further define the project so that you end up with a picture that everyone agrees on is the end deliverable that they want. More food for thought: A poor scope definition = higher project costs and poor schedule control.