The Estimation Contract

Lately, I've been chatting with some colleagues about estimation in the context of a business decision making process. It seems that we shared ideas about the outputs of the estimation process, how they must be comunicatred in full context, with all assumptions and risks, but we forgot to talk about the inputs to the process.

I suggest that we look at estimates in this context as a sort of "contract". If you want to know how much time MegaApp 2.0 is going to take and what it'll cost, there are a few things I need from you. If you fall short on your end of the deal, then I can't offer the best estimate and it'll be lacking in certainty and packed with more risks.

So, here's my first stab at it:

In return for:

• A vision statement (elevator statement or similar)

• A rough project scope

• A list of essential features

• A list of known exclusions

• A feasible resource profile for development and testers

I promise to provide:

• A most likely completion date and a 90% confident finish date

• A most likely cost date and a 90% confident cost

• A list of assumptions made during the estimation process

• A list of the major risks that could affect the project cost and timeline, together with a rough action plan (high risk = delegate upwards, medium risk = suggested mitigation plan, low risk = no action)

Now I'm not suggesting that there won't be an estimate without the proper "payment", and that the estimate will be water tight given an excellent set of inputs. What I'm trying to suggest here is a format for communication that does its best to be explicit about the inherent process of estimation, while also being aware of the reasons for producing the estimate: to drive a business decision.

This is by no means a set of exclusive rules, nor is it a minimum list: I'm sure plenty of people can find cause to adjust this contract for particular cases. If you do, I'd be interested to know.