How can a contract reduce the need for estimates?

You are going to meet a customer tomorrow. You will discuss about developing a new product. You know she will ask for a bunch of features, a deadline and a budget. She will ask for estimates.

You have developed products since many years ago, maybe 5, maybe 10, maybe even 15 or 20 years ago! Through all this time you have learned many things and one keeps on popping up into your mind every time you are preparing a meeting like this: estimates are a loss of time.

  • You know they won’t add any value up, because no product will ever generate value out of an estimation rather than out of the best set of features and an amazing user experience.
  • You know you will have to spend precious hours – usually days – to complete a full estimation round, because details will keep on emerging and it will be hard to know which ones are worth the attention they ask for and which are not.
  • You know you could generate more money if you could spend those days working on the product itself, to get to deep insights and learning as fast as you can.
  • You know you could spend those days working for other costumers, which are now foregone opportunities.
  • You know the request for estimates will lead to positional bargaining. Trust and chances of an healthy collaboration will fade away while the customer defends her capital of money – trying to depreciate the value of your effort – and you defend your capital of skills – trying to raise the estimate with a safety buffer.
  • Last but not least, reality will just… change, invalidating your estimation.

All in all, there is no other chance with fixed price or time & materials contracts: both parties have to agree on an estimate to fill in the gap of trust existing at the beginning of a collaboration. In the traditional context, contracts relying on estimates are a replacement for true trust.

It would be lovely if we could build a climate of collaboration and test it very fast. It would be even better to have some value – some real value – delivered to the customer in the same amount of time we would burn to estimate and quote the whole project. It would be perfect to have the customer say: “hey, you delivered more value than I expected and I can pay for it after this trial”.

Consider the typical conversation:

  • Customer: “Hello, I need this”.
  • Vendor: “What do you mean with ‘this’?”
  • C: “I mean this, this and that”.
  • V: “Uhm… we need to talk about the details for the next 5 days.”

Now imagine if we could turn that conversation into the following one:

  • Customer: “Hello, I need this”.
  • Vendor: “What do you mean with ‘this’?”
  • C: “I mean this, this and that”.
  • V: “Uhm… let’s talk one hour now. I will build something to start validating your needs and be back to you in 5 days.”

We could then start working for no money for a few days, deliver something and then check with the customer if our delivery is truly valuable. If it was, we could be paid and just… restart again: discuss needs, build something, validate the assumptions, get paid.

In high volatility scenarios this would allow for knowledge to build up, with a great momentum and minimum commitment for both customer and supplier. This would allow to allocate the budget

  • only on the next learning step
  • only a posteriori, having already learned something

The customer’s only rule would then be: if I only pay for the (n-1)th step, it is perfectly fine to wait for the n-th step to be completed for free!

Should we get rid of planning then? Well… maybe not, maybe yes. It depends on the value it delivers. As long as it helps the team anticipating known unknowns thus preparing the team to react to unknown unknowns, it may keep some value. Sure though we could ease the dependency of any collaboration from any upfront estimation. If we became able to release value frequently then we could experiment and learn with some tactic to get rid of the need for estimations.

Extreme Contracts were also meant for this. Check them out.

#NoEstimates: knowing the difference between an estimate, a forecast and a promise

A few weeks ago I attended a NoEstimates workshop held by Woody Zuill and Vasco Duarte in Helsinki. It has been an intense and fruitful day and here is the main insight I brought back home.

The day was led with a very nice pace, the two speakers showing a very different style in explaining their ideas. Their continuous turnover on stage made the workshop very light to follow though packed-up with contents.

The concepts explained during the workshop resonated a lot with what I have discovered through the years about planning product or software development: an estimate is not a promise and both are not a forecast. The first two are quite unhandy too.

According to Merriam-Webster, an estimate is

an opinion on the nature, character, or quality of something.

forecasting is

to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data predict

while a promise is

a statement telling someone that you will definitely do something or that something will definitely happen in the future

Well, that’s enough to spot a linguistic abuse: we are always asked for an estimate, thus for an opinion, while we are committing to a promise and no one cares enough about forecasting – if any useful at all.

I would recommend this workshop to anyone willing to get out of the big bubble lie “sharp estimation is the key factor for success”.