The Objective Blog

Keep up with what we're thinking, reading, and doing.

Defining Project Boundaries (and Keeping Your Client Within Them)

April 10th, 2007 - by Brett Derricott - Salt Lake City, Utah

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, and 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 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 Objective 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  we’re responsible for preventing.

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.

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.
    At our company, 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 nearly 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. While it’s tempting to believe a client is capable of perfectly defining their requirements at the beginning of a project, the reality is that 100% of the time, seeing the actual product will always lead to revisions.

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? I can promise you it won’t. If you can’t assume the worst when estimating your time, then do your optimistic estimates and double it afterwards.
  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. Don’t let your excitement at signing the project cloud your judgement and make you overly optimistic.
  8. Set expectations up front.
    Tell the client 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:

Have questions about managing scope creep? We’d be happy to talk.