5 Proven Techniques to Control Scope

Scope creep puts projects schedules at riskI’ve always thought that the greatest effort any Project Manager would expend on a project was in directing and managing the project work. However, there were times I wondered if it might be in controlling the project scope. If not the most work, scope control carried the greatest concerns and frustrations. If anything would cause a project to fall behind schedule, it was typically scope creep.

How do projects get behind schedule? As one of my managers used to say, “One day at a time.” I would like to extend that to say, “One day at a time if we take our eyes off the scope.”

What does it mean to control scope?

Does it mean that once the project schedule and scope statement are finalized, all tasks and activities will be executed as documented? Does it mean that once the requirements are defined and approved there will be no changes?

Not at all.

To control scope, the Project Manager must continuously monitor project status while managing those inevitable changes to the scope baseline. Change is inevitable. For example, as the project progresses, detailed requirements may be further elaborated resulting in changes. New business practices may be instituted for which new requirements would be introduced. Regulatory changes may occur resulting in rule additions, changes, and deletions. Opportunities for changes in project scope are endless.

The Project Manager is responsible to ensure that the project stays on time for the entire duration. It is incumbent on her to pay attention to scope even as her primary focus is on directing and managing the project work. To lose track of scope is to lose control of the project; and to lose control of the project is to risk failure.

It is my experience that if the Project Manager controls and manages scope using the following five techniques, the project will progress much more smoothly. Yes, changes will happen, but they will not cause loss of control of the project.

  1. Define the scope, document the requirements. “But wait a minute,” you say, “I thought this article was about controlling scope, not about defining it.”

    This article is about controlling scope. However, having well-defined, well-documented statement of scope and detailed requirements is half the battle. The project team that spends significant time in scope definition and requirements gathering activities will have far fewer requests for change later. There will be much less scope creep. Legitimate changes will still occur; but the myriad of changes that result because of poorly documented, ambiguous requirements will not.

    So, simply put, scope control begins with good scope definition. I discussed several techniques for developing a solid scope baseline in the following articles:

    “Why You Should Plan Scope Management, not Just Do Scope Management”,

    “Why You Should Create a Not-in-Scope Management Plan”,

    “This is How to Develop a Great Project Scope Statement”,

    “These are the People Considerations for Successful Scope Definition”,

    “This is Why Project Teams Fail at Requirements Gathering”, and

    “16 People-Focused Techniques for Better Requirements Definition”.

  2. Establish change control process. “But wait a minute,” you say, “I thought this article was about controlling scope, not on how to handle changes.”

    This article is about controlling scope. However, having a well-defined, well-documented change control process is the other half of the battle (from a process point of view). When the client understands what all is required to implement change control, especially the further along the project has progressed, they are less likely to request changes. They consider every potential change seriously in terms of impact to project timelines and budget.

    Change would still happen without a change control process, but so would chaos.

    Change control and scope control are completely integrated with each other and with the directing and managing of project work. Changes in scope require formal change control. Change control directly affects the ongoing project work. Project budgets and timelines are almost always affected. Hence the need for formal change control to understand the complete impact of the change in scope.

    So, simply put, scope control includes good change control processes. I wrote extensively on the topic of implementing integrated change control in the articles, “How to Make Project Change Control Work for You” and “What to Consider When Estimating Change Requests”.

  3. Manage stakeholder expectations. Manage not only stakeholder expectations, but also the expectations of client staff on the project. The previous two techniques, while prerequisite to controlling scope, help the client and the project teams to work together towards common project goals throughout the life of the project.

    If a solid scope definition and detailed change control process are not in place, requirements will constantly change, schedules will be missed, budgets will be overrun, the client will be displeased, and the IT team will be unhappy. This is classic scope creep and its effects on the project.

    The most important aspect of managing stakeholder and client staff expectations is to ensure that they understand the project scope and detailed requirements. That they understand the necessity for change control. It is not enough to require a formal client sign-off of the scope deliverables. It is incumbent upon the project team to ensure the client understands in detail what is being accepted. Too many projects have failed simply because the client team thought they understood the scope as documented, and the project team never followed up to ensure they did.

    Managing client expectations is another important prerequisite for controlling scope.

  4. Involve the project team. No one is more affected by uncontrolled changes in scope then the project team. Imagine being an analyst or developer working on completing his tasks when a request for change comes out of the blue. This results in more work added to an already aggressive schedule, and the team member has little time to explore what other functionality may be affected by the change.

    Similar to the client team and stakeholders, the project team must be well-versed in the detailed project scope and the change control process. The team’s understanding of these critical deliverables will help them to recognize when changes are requested outside of the formal process, and when they themselves are tempted to introduce changes.

  5. Stay alert. Scope creep happens quickly and often the Project Manager is unaware. Almost any Project Manager has witnessed conversations like the following:

    “It’s such a small change. It’s not worth going through all the paperwork of change control.”

    “While you’re in there, can you make just this one small change?”

    “I’ll remove that functional requirement if you do me a favor and add these three reports.”

    “No, I didn’t check with my boss, but I’m pretty sure it’ll be okay.”

    “I was just trying to be helpful. I didn’t think it was that big a deal.”

    One of my worst nightmares on a project occurred on the day we were to implement the new system. While making final preparations the night before, the senior developer decided he did not like the way the menus worked (even though they had been tested and signed off by the user acceptance tester team). He made a change, recompiled the modules, and prepared them for the next day’s implementation. You guessed it … the first users logged onto their new system and could proceed no further. Our reputation took a huge hit.

    Sometimes the biggest culprit in scope creep occurs deep within the inner workings of the project. Invariably, the IT project team and the client project team form a strong bond as they work together on a project. Young IT professionals, not yet steeped in project management process, want to please their client counterparts. Thinking that small changes would be inconsequential, they implement them without going through the formal process. This almost never ends well.

    But I have also witnessed Project Managers or one of their senior leads do something similar. They forego the formality of change control “just this once”. And pay for it later.

Scope control is seldom a technology or process issue. It almost always stems from people changing their minds, or wanting something different, or having missed a requirement. These are the people aspects of project delivery that all Project Managers deal with. Having strong processes in place before scope changes are requested will help keep the project on track.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.