top of page

How to Avoid the "Creep"


Whether you’re busy closing the quarter, creating supplier partnerships, or writing code for an innovative software solution, you’ve all faced it…the dreaded scope creep.

Any PMP worth his or her salt knows AND PRACTICES the basics of developing the statement of work (SOW):

  • Objectives

  • Scope

  • Schedule

  • Price

  • Key assumptions

  • Acceptance

But what happens when, after everyone has signed off and the project has started (or even been completed), the customer says “well, I assumed that was always part of it”. BAM! You’re a victim of the CREEP!

That’s because, as great as a project manager may be, s/he cannot always plan for ‘interpretation’. A statement of work is only successful if (1) everyone READS it and (2) everyone has the exact same understanding of the language within it. Fat chance.

We’ve long been a proponent, instead, of the COW where Collaboration is key. This Collaboration about the Outcome of the Work is similar to the SOW with one big distinction: it employs a sort of collaborative role playing as a way of uncovering various and sometimes differing interpretations of a project.

More than simply documenting an objective, it is imperative to understand the desired outcome. After all, “the client wants to integrate his access control system with video”, can be very different than “the client wants to ensure that if there is a breach at any of his doors, there will be corroborating high resolution video that can be turned over to the authorities for fast prosecution and quick resolution.” That means asking a lot of ‘what if’ questions and getting really clear on definition of terms (what do you consider a “breach”? Are all doors equally important for capturing storage-hogging high-resolution video?).

It is always less about what is written in the agreement and more about what the customer actually knows is in the agreement. So, before signing off on the project and starting the work, it’s worth a deep dive role play to be sure everyone involved has actually read and understood.

Here’s how we employ a COW:

  1. Host an in depth exploratory, referring to as many scenarios as we can think of that test the objectives.

  2. Create an ordered list including budget, deadline, feature delivery, customer satisfaction metrics. The list justifies scheduling decisions once the project has started.

  3. Clearly define specific deliverables with general descriptions of functionality AND corresponding example scenarios. These create thought triggers that may generate more questions about the desired outcome.

  4. Break deliverables into detailed work requirements with corresponding milestones.

  5. Once a schedule has been created (with lots of check-ins built in), assign resources and determine critical path moments.

The truth is, a service or solution provider should always expect the Creep – he’s pretty much unavoidable. But, communicating that early and often with the project drivers is key. In fact, the “C” in COW could just as easily stand for Communication since it is probably the single most important factor in keeping the Creep in check.

It’s the worst feeling to finish a long, hard project only to have the customer disappointed with the service delivery. So, be a dynamic contributor, collaborator, and communicator. If you truly understand the desired outcome, you are in a position of strength to produce a successful (and non-CREEPY) action plan.


bottom of page