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.