What is scope creep, and how do you control it?

Scope creep is the gradual addition of work that was not part of the original agreement. Control it by writing the scope down, keeping a visible change list and agreeing the cost and time effect of each addition before it is built.

Nobody sets out to cause it. “Could it also…” is a normal and often good idea. The problem is when additions are absorbed without anyone noticing what they cost.

How it happens

  • A function was described loosely and each person understood it differently.
  • New ideas arrive as the product becomes tangible.
  • Small requests are accepted without counting them.
  • Nobody owns the question of whether something is in or out.

A simple discipline

  1. Write the scope, with what is excluded.
  2. Keep a change list. Every new request goes on it, however small.
  3. Price each change in time and money before deciding.
  4. Decide together whether to add it now, swap it for something, or park it for the next stage.
  5. Review the list regularly, so everyone sees where the project is going.

It is not about saying no

Good ideas should be welcome. The point is to make their cost visible so that they are decisions, not accidents. A parked idea that is written down is not lost; it is the start of the next version.

From the developer’s side, a good practice is to say early, “this is a change, here is what it affects”, rather than quietly absorbing it and surprising you later.

All questions