Seven steps for avoiding scope creep

Nearly every project falls victim to scope creep. Programming consultant Shelley Doll shows us seven things we can do to avoid (or at least control) this project killer.

By Shelley Doll

The expansion of a project outside of the planned objectives, commonly known as scope creep, is an inherent part of IT development. Scope creep can originate from several sources and is a leading cause of project failure when handled poorly. You must take measures to control project embellishment and to ensure that you and your team don’t fall victim to its unsavory results—deadline delay and budget shortage.

Fortunately, there are a number of strategies you can follow to keep scope creep from derailing your projects. We’ll outline these strategies in a moment. First, however, here’s a short cautionary tale that illustrates how badly things can go awry without proper planning and control.

Horror story
While working at a consulting firm, I witnessed the scope struggles of our sister company during an in-house development effort to deliver a Web-centric desktop environment to users. This project, which began in earnest about five years ago, followed no project plan and had only a lead developer to guide its progress. It was started with a handful of talented Java developers who had only the vision of their non-technical president to guide them.

If this sounds like a nightmare, it was—and still is. Today, this company has one nonpaying client and a product that was surpassed by competitors two years ago. While it continues to limp along, the company itself has become unable to pay its employees, is seen as a bottomless money pit by investors, and is still considered by its management to be a start-up. With no formal project agreement to work from, the scope of this project changed constantly, even daily, and all efforts, from development to sales and quality assurance, became stunted by the massive workload a changing vision created.

On the bright side
The effects of scope creep are not always negative, depending on your situation. If you work as a consultant or for a consulting firm, “feature-itis" can be great for business—as long as it’s handled professionally. For in-house software development, additional features could give your product the edge over your competition. But, that edge is lost if you release a month or two late. Regardless of the perceived effects of scope creep, cost is the bottom line. By controlling your cost of development and by delivering on time, your project can be a success, without compromising flexibility in production.

Scope control starts on day one
Controlling the scope of your project begins before the first line of code is written. Every development effort should have a corresponding project plan or project agreement, regardless of the situation. Even if you’re just one developer trying to make the boss happy, you’ll benefit greatly from documenting your efforts before you begin them. Use the following guidelines to set yourself up to successfully control the scope of your project:
  1. Be sure you thoroughly understand the project vision. Meet with the project drivers and deliver an overview of the project as a whole for their review and comments.
  2. Understand your priorities and the priorities of the project drivers. Make an ordered list for your review throughout the project duration. Items should include budget, deadline, feature delivery, customer satisfaction, and employee satisfaction. You’ll use this list to justify your scheduling decisions once the project has commenced.
  3. Define your deliverables and have them approved by the project drivers. Deliverables should be general descriptions of functionality to be completed during the project.
  4. Break the approved deliverables into actual work requirements. The requirements should be as detailed as necessary and can be completed using a simple spreadsheet. The larger your project, the more detail you should include. If your project spans more than a month or two, don’t forget to include time for software upgrades during development and always include time for ample documentation.
  5. Break the project down into major and minor milestones and complete a generous project schedule to be approved by the project drivers. Minor milestones should not span more than a month. Whatever your method for determining task duration, leave room for error. When working with an unknown staff, I generally schedule 140 to 160 percent of the duration as expected to be delivered. If your schedule is tight, reevaluate your deliverables. Coming in under budget and ahead of schedule leaves room for additional enhancements.
  6. Once a schedule has been created, assign resources and determine your critical path using a PERT Chart or Work Breakdown Structure. Microsoft Project will create this for you. Your critical path will change over the course of your project, so it’s important to evaluate it before development begins. Follow this map to determine which deliverables must be completed on time. In very large projects, I try not to define my phase specifics too early, but even a general plan will give you the backbone you need for successful delivery.
  7. Expect that there will be scope creep. Implement Change Order forms early and educate the project drivers on your processes. A Change Order form will allow you to perform a cost-benefit analysis before scheduling (yes, I said scheduling) changes requested by the project drivers.

If you can perform all of these steps immediately, great. However, even if you start with just a few, any that you’re able to implement will bring you that much closer to avoiding and controlling scope creep. That way, you are in a better position to control your project, instead of your project controlling you.

There is no reference to stakeholders and making sure all the RIGHT stakeholders are in place. This is most important when reviewing and proposed changes to scope. Scope creep is going to happen that is a given. So it is critical to make sure you review process engages all the right people. 


Finally! Now I understand the types of clients I seem to have been plagued with as a freelance designer, and why the influx of this kind of client made me close up shop and re-evaluate my commitment to design. It's due to scope-creep. In other words, watching a small, neat project gradually turn into a long-term nightmare with a wishy-washy client you can't seem to shake. Allow me to share an experience that illustrates what scope-creep looks like, and how easy it is to fall into the trap if one doesn't follow the advice provided in this article. Note that I take full responsibility for failing to prevent this in the first place, and for allowing myself to be manipulated into various situations. (Much wiser now.) I was done with freelance after a series of scope-creep projects, then a friend called with a client and a project she knew I'd just love. My gut said "don't do it" but my wallet said otherwise. Despite the hope of earning some cash, somehow I let myself get wrangled into a barter situation (her services in exchange for mine). The client had about five different projects she wanted to have done, but this initial one was urgent, so I decided to agree to the barter since it was the precursor to bigger paid projects. She had a community festival coming up and needed a tri-fold brochure for the event, and a one-off calendar card with the schedule for that season printed on it so passersby could get info. Not a big job, not too complicated???perfectly suited to a small barter. Did the job. Client thrilled. Event came off beautifully, and she got new clients from it. Then the scope-creep began. "Just a little change to the schedule, won't take but a moment, to update it". Then again, a couple months later. For free, mind you, because although I was clear about my pricing schedule, she wasn't as transparent with hers so there was no real way to know when I'd "used up" my allotment of the barter. (My fault for not having it spelled out.) When she asked about more work, I outlined the scope of the "new" project and reminded her of my fees. She promptly dropped off the face of the Earth for a year. I thought I was done with her, but she popped up again this fall, claiming "time had gotten away from her" and now she was ready to revisit the project we'd been discussing and was I still available to do it. And then she reminded me I still had some time left on her services and she was eager to provide them. And THEN she asked if I also did websites because hers needed an overhaul. It occurred to me that if I let her, she'd milk the barter for the next several months and I wasn't about to have that. I finally got through to her. I explained that the barter only applied to the brochure and one-off calendar, but if there was time left I'd gladly come use that up; and that revising the calendar format for her own personal updating and redoing her website were two completely separate projects, for which I would assume she'd be willing to pay my going rate. Dropped off the face of the earth... again... scope-creep is term applied to the process AND the person, IMHO...


What is the real problem was in this case? Could it have been avoided?

Tony Hopkinson
Tony Hopkinson

of a lack of control in my book. The start of any project is the definition of what is in scope and sometimes even more helpfully what isn't. Why has or does someone want to change the scope ? Was it out of ignorance? Is what you planned to deliver no longer relevant (change is a given), not functional enough to be useful (mis-specified). Someone important mentioned something? Defer it, re-specify, re-assess, whatever you do don't hide from it. Most of the problems in this regard revolve around denial that it is a scope change or mistaking it for a requirements change. Are you controlling / managing expectation, or digging a hole to put your head in, is the way to look at it. Consequences of allowing change versus futile attempts to somehow stop it.


As author said, we should understand the scope change and scope creep. The scope change can be acceptable and on the other hand the scope creep should be properly monitored for resources, technology changes, cost, time, estimated output and dependency impact. But most of the time we are not considerting this while doing scope change or scope creeping which is directly affect the quality and cost of the project.

Editor's Picks