While scope creep is doing more work than you expected, due to added scope; effort creep is doing more work without added scope.  You’re just taking longer to do the same stuff.

Like scope creep, effort creep is inevitable and manageable.  To manage effort creep we need to understand what causes it.  Three major causes are underestimation, over engineering, and discovering implicit requirements during system design.

Underestimation

I once helped convert a complex Windows application into a giant ActiveX control.  (Kids, don’t try this at home.) Our beta release had a huge memory leak.  Our memory management architecture worked well in stand-alone apps but broke down in ActiveX (it couldn’t cope with page re-loads).  As I recall, we leaked over 10MB per minute.

We never saw that coming.  It was what Robert Read calls an unk-unk, a problem so unforeseen we never even imagined it might exist.

I know what you’re thinking – we made a stupid mistake and we should have seen the problem coming.   Yes, perhaps we should have.  But we didn’t.  And that’s the way it is.  There’s always something unforeseen.

How do you plan for unk-unks, when you don’t know what they are? You simply have to include a bucket of time in the schedule to cover the things you haven’t thought of yet.  How big should the bucket be?  I know of no better answer than to look at past projects of similar size and complexity.  How much time did you spend on their unk-unks?

In the early phases of a project, there’s no such thing as perfect estimation.  You need to allow time in the schedule for unk-unks, and also for overrun on known tasks.

Over Engineering

Some developers tend to over-engineer solutions, building in extra complexity because “someone” might need it “later”.  I think we all have that tendency, to some degree.

XP addresses this issue with the slogan You Ain’t Gonna Need It.  Personally, I’d phrase it differently, although I do agree with the idea. I’m all for creating solid implementations of features that we know are needed; but I’m against speculative implementations of things that “might” be needed “later”.

It’s important to realise that this form of effort creep is completely different from underestimation.  If the customer asks for a Toyota Corolla, then the estimate should be for a Toyota Corolla.  It shouldn’t be for a giant SUV just in case we accidentally build one of those instead.

I don’t have a silver bullet to combat over engineering.  Two things seem to help: discussing ideas with other developers before you build them, and making the true project status visible to everyone.  Often developers don’t really know where the project stands in terms of progress and budget.  When you’ve got nothing but a few dates in a Gantt chart, it seems easy to justify extras that “might” be needed. It’s harder to justify them when everyone sees the full project status, including “budget burn”.   (You can also chart effort creep itself.)

Explosion of Implicit Requirements

When moving from requirements to design, there is an explosion of ‘derived requirements’ … caused by the complexity of the solution process.  The list of these [derived] requirements is often 50 times longer than the list of original requirements…. What may have seemed straightforward from a problem point of view explodes into something quite complex from a solution point of view. — Robert L. Glass, in Facts and Fallacies of Software Engineering

We unearth numerous details and special cases when we take a human-readable problem description, and turn it into a solution so precise that even a machine can execute it.  Were all those special cases (implicitly) included in the original scope?  Customers tend to say “Yes” while suppliers tend to say “No”.   In reality, some are effort creep and some are scope creep, while many others lie somewhere in between.

Fuzzy Grey Boundaries

There’s no clear line between scope creep and effort creep.  Implicit requirements are hard to classify; there’s no precise definition of over engineering; and even the best estimates are never perfect.  If we find ourselves doing something we hadn’t planned, is it:

(a)	An essential part of the original scope?	This is an unk-unk contributing to effort creep
(b)	Not strictly essential, but a very good thing for the overall quality of the product?	These are hard to classify.  Generally, doing a select few is good engineering; but doing all you can think of is over engineering.
(c)	Pure speculation, unrelated to any existing customer need?	This is probably over engineering
(d)	Necessary to meet a newly-discovered customer need?	This is scope-creep

Here’s what I think: In the very best projects there’s something special about the relationship between customer and supplier.  It’s a working relationship that fairly shares the costs of scope creep and effort creep, and avoids squabbling over which is which.

---

I’m not the first to refer to effort creep.  A quick Google search turns up a handful of hits (once you weed out those from the fishing industry – where effort creep means something completely different.)   But I seem to be the first to write a whole page about it 🙂