How to Manage Project Scope

    2=Planning, 4=Control

  •  Minute Read

How many times have you experienced scope creep? You know the drill—you elicit and document the requirements. You receive sign-off. You continue to see changes to the requirements. Many projects experience 10, 20, and 25-percent changes in requirements over the project's life. Let's explore how to manage the project scope.

Scope is Not a Mouthwash

You cannot manage what you do not understand. Let's get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK), Seventh Edition defines scope as the sum of the products, services, or results.

When we use the word "scope", it is helpful to specify the type of scope—product scope or project scope. The product scope is the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.

Imagine that you plan to have a painter paint your living room. Here are some product scope questions:

  • Do you want the walls painted?
  • Do you want the trim painted?
  • Do you want the ceiling painted?
  • Do you want a coat of primer applied before the first coat of paint?
paint
  • What color do you want for the walls, trim, and ceiling?
  • What brand and type of paint do you want?
  • Do you want a second coat of paint?

What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:

  • Will someone remove the furniture from the room before the room is painted?
  • Will the painter clean the walls and trim before painting?
  • Will the painter tape the trim before painting the walls?
  • Will the painter use a brush or a paint sprayer?
  • Will someone inspect each step before the painter moves to the next step?

Manage Your Project Requirements

Regarding requirements, I wish I could read my user's minds. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.

A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.

Like the word scope, using an adjective when talking about requirements is helpful. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.

I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements in greater detail.

  • Business requirements - the high-level business goals of the project (e.g., Increase customer retention by 5% by the end of the year).
  • User requirements - a task of a user group (e.g., Quote an insurance policy).
  • Systems requirements - the detailed specifications of the features and conditions needed in the system (e.g., The system shall invoice customers at month-end).

WBS: Define Your Scope

How do you eat an elephant? One bite at a time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.

The WBS is a hierarchical decomposition of the work to be performed to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project. 

“Any goal can be achieved if you break it down into enough small parts.” -Brian Tracy

Click to Tweet

Use Prototypes to Analyze Requirements

Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.

Monitor and Control Project Scope

Project managers should meet with their teams regularly to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.

Manage the Changes

Many project managers think their job is to ensure that no changes occur. Make no mistake about it—change happens. Expect it!

Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don't get me wrong. Project managers should not just add anything that is requested. The requested changes should support and align with the project's overall goals.

Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.

Your Turn

Project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user's needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.

You may also like

What is a RAID Log?

What is a RAID Log?
>