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, 25-percent change in requirements over the life of the project. Let's explore how to manage project scope.
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) 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 are 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:
What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:
Want more clarification on product and project scope? Read this article from Villanova University.
When it comes to 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, it is helpful to use an adjective when talking about requirements. 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 into greater detail.
How do you eat an elephant? One bite at 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 in order 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. Learn how to build a WBS.
“Any goal can be achieved if you break it down into enough small parts.” -Brian Tracy
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.
Project managers should meet with their teams on a regular basis 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.
Many project managers think their job is 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—project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.
Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.
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.