AgencyByte
technology for creatives

I suspect most of you have experienced “scope creep” before. Scope creep begins at the moment when your client asks for something outside of the scope of work for which you’ve contracted (you do have a contract, right?). Naturally, they’re asking for this thing to be included at no extra cost. Actually, they’re probably not asking. They’re probably acting like it’s always been understood that this thing will be included. Duh.

Scope creep is the bane of custom work. Defining the boundaries of a project can be extremely challenging and becomes more difficult the larger the project is. Many clients have difficulty understanding why estimating a creative endeavor can be difficult but for their success and for our sanity we, the vendors, need to understand the side effects of scope creep, its causes, and some possible remedies.

Scope Creep’s Side Effects

Scope creep has at least the following four nasty side effects, probably more:

  1. It causes fixed-fee proposals to be priced higher than necessary to account for the risk scope creep will happen.
  2. It causes clients to feel like their vendor isn’t very customer service oriented because the vendor seemingly responds to every additional request with a fee (for those vendors who resist scope creep).
  3. It erodes project profit margins to zero and beyond (for those vendors who don’t resist scope creep).
  4. It eventually forces vendors to create all sorts of protections against it in the form of wordy contracts, protective clauses, rigid processes, and whatever else can be put in place to make sure the client doesn’t have their cake and eat it too.

At Agency Fusion we’ve experience our fair share of scope creep. In the early days we assumed that scope creep was a byproduct of working with a bad client. Bad clients do tend to push for as much free stuff as you’ll allow and it does behoove the wise vendor to weed out the bad clients and keep the good ones. But over time we’ve come to better understand the nature of the dreaded creeping-of-the-scope and we now view it as a problem for which we’re responsible.

With that said, here are several reasons scope creep occurs and some suggestions for how to address it, in terms of both prevention and treatment. Scope creep is so universal a problem that I anticipate many of you have suggestions or tips of your own. Please comment below for our benefit!

Why Scope Creep Happens

I think scope creep is so common for several reasons.

  1. Clients don’t always know exactly what they want.
    Clients often have a general idea, but it’s usually not detailed enough initially. Vendors who fail to ask the dozens and dozens of follow up questions necessary to create a tight scope of work will usually suffer later on.
  2. Vendors are too busy to elicit detailed requirements.
    We’ve stopped lamenting about clients and their vague requirements. Most of our clients don’t know they’re bringing us insufficient information so it’s our job to ask for it. If a vendor is too busy to do the work of requirements gathering odds are good the scope is at risk of changing later on.
  3. Bulleted lists are a client’s best friend.
    Clients often present their requirements in a concise, bulleted list. While the list may provide a good summary of what they want, each bullet is usually too vague for accurate estimating. A client may say to us, “I need a secure login area.” This could be accomplished with 1 hour of programming or 100 hours, depending on what the client means. We always smile lovingly when we see an RFP that has vague requirements like these:
    1. E-commerce functionality
    2. Secure login area
    3. Newsletter signup
    4. Integration with shipping
  4. Assumptions, assumptions, assumptions.
    Most discussions about scope creep will involve either the client or the vendor or both saying, “Well, we just assumed that feature XYZ [was][was not] included.” Assumptions are at the root of all scope creep.
  5. I’ll know it when I see it.
    Most people are pretty visual and as a result, are better at critiquing things than designing them. This commonly leads clients to find issue with their project once it’s delivered.

What to Do About It

As with many challenges in life, the best approach to addressing scope creep is to focus on only those things within your control.

  1. Learn to estimate pessimistically.
    Most of us are too optimistic when we estimate. We’re skilled at what we do so we tend to estimate like we’re playing golf. Low score wins. True, you might be able to do the task in 2 hours if everything goes as planned but what if it doesn’t? If you can’t assume the worst when estimating your time, then do your optimistic estimates and double it later.
  2. Define the ins and outs.
    Getting the scope tight means documenting exactly what you will do for the client. That’s what is “in scope.” Defining what is “out of scope” can be as important as defining what is in, especially because you probably already know the areas in which clients usually tend to push the limits. Write them down and include them in your proposal. Tell them that these things are not included for this price.
  3. Use ranges for risky requirements.
    Maybe most of the client’s requirements are fine but there is one that you think could be risky. Propose a cost range for that section if you can’t get sufficient detail to ease your discomfort. Explain your discomfort to the client and tell them you’re reasonably sure it will cost somewhere within this range.
  4. Identify common tip-of-the-iceberg requests.
    We often hear, “I need a secure login,” a common tip-of-the-iceberg phrase for us. Who knows what they want beyond the login itself? Requests like these need to be either fleshed out or we need to have a well-defined solution ready to present each time we get this request.
  5. Embrace the fact that it will probably happen.
    Show your client progress often and keep the ship on course. It’s easier to make several small course corrections along the way than to present the final project and find out it’s half wrong. The Agile programming approach is somewhat based on this principle. You know your clients will have new ideas when they see the first deliverable, so embrace that fact and show them something early. Don’t make the final product the first thing they see. You’ll think you’re done but they’ll have a laundry list of changes they need.
  6. Recognize you are different.
    Having a well-defined scope means different things to you and to your client. Educate them about the level of detail you need. Don’t assume they see things the way you do.
  7. Never assume it’ll all work itself out.
    When you’re busy it’s easy to tell yourself the scope looks detailed enough and those two or three vague portions will all work themselves out. Remember this: when those vague sections get worked out it will rarely be in your favor.
  8. Set expectations up front.
    Tell them that the scope represents exactly what they’ll get. If it isn’t in writing they shouldn’t expect to get it. Tell them you’ll charge them for all work outside the scope. Don’t assume they read the clause in your contract about this. Tell them in person and tell them you want to avoid having them feel like you’re being unfair when you inform them of additional costs. Be blunt now; it’s easier than doing it later.

For more reading on this subject, check out these resources:

Now it’s your turn! What advice do you have for others who’re fighting scope creep? How do you manage your clients’ expectations and remain profitable in the process?

Bookmark and Share

Comments

Mike  April 10th, 2007, 11:41 am

Great discussion on creep. Thanks for the ideas on how to combat it. One more suggestion: (and you eluded to it)

Keep open communication during the ENTIRE project process. The moment you even smell a hint of possible creep, talk with your client and let them know where you sense there is something missing. Your client will eventually appreciate the heads up. This is way better than the after-the-fact conversation about scope creep. And remember, your client will always win battles over creep. Best to try to avoid creep in the first place.

Brett Derricott  April 10th, 2007, 11:59 am

@Mike: Thanks for the great comment. You’re absolutely correct that great communication is required throughout the project. Clients (at least the good ones) will appreciate and respect the candid conversations and your desire to “stick to the plan” that was agreed upon in the beginning.

I also like your point about the client always winning battles over creep. My experience definitely supports that!

Justin  April 12th, 2007, 8:04 am

Great discussion on scope creep. I remember discussing it in a class will getting a degree in software. While working at a software company as a junior developer, I saw a project get way out of control, and the project manager lost all control. A $40,000 project turned into a $200,000 mess. Because the project manager was such in a hurry to get the project going, he did not understand all the requirements of the project and got to work. As it turned out the program was much larger than he thought. And his contract he wrote was very vague. The client had every right to stick to the contract he signed and demand what was on it.

I have had my share of clients to work you for everything you can get, but bad project management is just as bad as a bad client.

Brett Derricott  April 12th, 2007, 8:11 am

@Justin: Sounds like a nightmare project! Bad project management is most certainly to blame for many disastrous projects. I think PMs can be so anxious to get a project into development that they’ll create contracts that are too vague, as you observed your PM do in your example.

Justin Grover  May 8th, 2007, 9:59 pm

Great post. Scope creep affects us all. The company I work for (Omniture) makes the client pay for consulting hours upfront then gives the client a set period of time to use those hours (ie. 3 months). After that they either have to purchase more hours or go without. Definitely not the way for every company but it works for what we do.

Brett Derricott  May 14th, 2007, 7:23 am

@Justin: Thanks for the suggestion. It can be difficult to draw the line and stop doing work for a client when they’ve spent their budget. Your company’s approach tackles that problem head-on by establishing the limit right up front. I think setting proper expectations at the beginning of a project like this is very helpful.

» 5 Reasons To Break Projects Down  July 3rd, 2007, 3:40 am

[...] Scope creep isn’t caused by long project timelines but is more likely to occur in bigger projects with lengthier schedules. The risk of experiencing scope creep, however, can be somewhat mitigated by establishing frequent milestones and reviewing the project’s progress against the agreed-upon scope at each milestone. [...]

» LinkSwitch – A Roundup of Great Links Across the Web  September 8th, 2007, 11:27 pm

[...] from Agency Byte helps us Define Project Boundaries (and Keep Our Clients Within Them). Hooray for [...]

Raimond Garcia  September 9th, 2007, 11:02 am

Hi, I think we should not have fixed contracts at all. Using agile development techniques such as the ones encouraged by Ruby on Rails, you can show progress to your client in a day to day basis and allow him to guide you through out the whole project. Something like, “what would you like me to work on today?” you do it, get feedback and improve.

I personally hate fixed-rate contracts, partly because I suck at estimating costs and I always end up having to explain to my client a whole bunch of tasks that I didn’t take into account and had to be completed to achieve a milestone. I rather my client gives me an idea and we polish it day after day without establishing from the beginning everything that needs to be done, its more fun and less stressful, than having to meet deadlines, I hate dealines too :)

Bookmarkables for 10 September 2007 : FocusMinded.com  September 10th, 2007, 6:11 am

[...] Define Project Boundaries (and Keeping your Client Within Them) – an excellent article on the scope creep (those clients who like to go outside the scope and expect it to have been understood as part of the quote). A Must Read [...]

Brett Derricott  September 10th, 2007, 2:28 pm

@Raimond: Agile development techniques are great when they can be used. From my experience most clients (especially those hiring a designer/developer for the first time) are unwilling to begin a project without a set schedule and price, though.

The reality is that most of us are bad at estimating accurately and we fail to account for all of the extra tasks that a project requires, like bug fixing or design revisions. Unfortunately it’s hard to find clients that are sympathetic to our plight!

If you’ve found a way to convince all of your clients to let you use an agile approach please post a comment and let us know your secret!

Tidbits » Zen and the Art of Nonprofit Technology  September 10th, 2007, 4:37 pm

[...] has a great article on how to prevent scope [...]

Defining Project Boundaries (and Keeping Your Client Within Them) / Web Words / WizarDev  September 17th, 2007, 7:12 am

[...] Read Defining Project Boundaries (and Keeping Your Client Within Them) [...]

Web Design Nashville  November 2nd, 2007, 6:11 pm

Great article! We have been plagued by scope creep for years and now our projects are getting bigger, so is the scope creep problem. We have implemented more detailed estimates on the front end as well as a deliverables document outlining exactly what the client is getting.

Definitely need to have good project management and communication. Most delays we have are because no one thought through the website and built it in their head first and asked all the right questions…

Details details. We prefer to get more information up-front then pay for it in the end.

Resources for Designers, Post One | Wisecup Design  February 12th, 2008, 8:24 pm

[...] Defining Project Boundaries (and Keeping Your Client Within Them) [...]