Contingency wars

Thu, Mar 8, 2018

Recently I attempted to explain to a senior member of staff my thoughts about estimation. I wrote a brief outline for him describing a couple of ways of calculating the risk associated with duration and cost. He replied, “Well you just build in contingency don’t you, that’s how you manage that”.

This senior, experienced manager was just talking about a different thing. And as with the careful distinction between estimate, target, and committment, it’s a good idea to analyse the words being used. Simple confusion of terms is often the cause of tension, disagreement, and recrimination.

Terrible practice everywhere
Changes, changes, changes

Changes, changes, changes

This is how a lot of estimation goes:

Projects at some point required developers to produce single-point estimates (remember that single-point estimates are not estimates ). Developers know that their ‘estimates’ will quickly become project committments, so they build in a sizeable buffer - perhaps as much as 25%-50%, so fearful are they of being held to their numbers.

Project managers closely associated with the development team will add in an habitual buffer of perhaps 10-15%

Managers aren’t blind to this buffering and they will often persuade, cajole, and threaten developers to produce a number they’re happier with – or will simply cut the numbers themselves without referring back to developers.

Believe me, I’ve seen it happen.

Contingency Wars

We now have sides drawn up. The first casualty of war is truth, of course, and here we have each side dealing in fantasy figures. Developers are generating single-point estimates with buffers that are not informed by experience or data but by a reasonable desire not to spend the last month of the project working until 10pm; and managers are arbitarily reducing developer estimates to meet a preferred date.

Developers have produced targets. Managers have produced committments. And the real estimatation has been lost.

Work with real numbers

There is a better way - and it starts with all parties recognising that estimates should not be interfered with by anyone who’s not producing the estimate. If you build your project on finagled figures you are preparing a failure from the start.

Next up: simple estimation


A series of short articles about software estimation. Here's a list of all posts in Estimation. The first in this collection is Estimation: Introduction

comments powered by Disqus