Here’s how it a typical request for an estimate often goes.

Step one, “they” come to you and ask for an estimate. It’s nearly always needed in one of three timelines

1. Immediately — “I just stepped out of a meeting and just want you to ball park it.”
2. By the end of the day — “we promised the client something tomorrow”.
3. By the end of the week — (someone’s on vacation).

So you do the estimate and the response is nearly always, “this is too (long, expensive, overkill, complicated, slow).”

In other words, it’s ridiculed.

Mind you if there are specific objections, that’s fine. But most often there is no reason that they should reasonably think otherwise. They were simply hoping for (shorter, cheaper, simpler, faster).

Then it sinks in that this is your estimate and you’re not going to change it just because they think you should. It is violently opposed.

You get called to a meeting where they tell you that — because of your estimate — the work is being “considered for outsourcing.” BTW, being “considered for outsourcing” means: “will be outsourced.” I’ve never yet had someone say those words then not outsource at least some of the work.

When you point out that your estimate is likely conservative, the reality of staring at that “truth” is just too much. I (we) will often warn that even when outsourced the truth won’t change. In all likelihood it won’t come (shorter, cheaper, less complex, simpler, or faster) just because it’s been outsourced, in fact it will usually take longer because of communication and latency. This warning will be ignored because you are being ridiculous and the plan violently oppose.

Then, when the project launches, the fact that it went (longer, more expensive, had-unforeseen-complication, was more complex, and took more time or resources) is dismissed as “self-evident.” Often hand waved away as, “well these things just go that way.”

Schopenhauer’s prediction is complete.

So, the challenge is how do you get better at making and delivering these estimates? The three stages do indeed seem to be a part of human nature. Humans just cannot resist going through them. How do we do better? Can we even avoid the three stages? Is there someway that anticipating them can help us mitigate them?

I’m still experimenting, but one thing that has worked in the past is if you get the chance to work with the same project manager on multiple projects. It is useful to be able to say, “hey, do you remember last time when you said my estimate was ridiculous and needed to be (shorter, cheaper, less complex, simpler, or faster) but then the reality of the project was that things were (longer, more expensive, had-complication-unforeseen, was more complex, and took more time or resources)? This does seem to work.

However, it can be rare that you get a chance to work with the same PM on multiple projects. So I’m always looking for other strategies.

People will often suggest keeping data on your projects, but I find that technology changes fast enough that it’s impossible to compare my last smart-client project to this new HTML project to a CMS driven project to a mobile project or that new hybrid project. Because of this changing landscape don’t hold out much hope for metrics. Metrics was a very popular subject a generation ago, but they have not panned out.

One suggestion to create an activity map of the activities involved in the estimate. It’s important that the activities be connected by dependency so that activities that lead to other activities are the dependent activities for the subsequent activities. It should look something like this:

Then when you get into the scoping meetings, if someone wants to kill A4, you can say, “but A5, A6, and A7" depend on A4. (By the way, if this isn’t true then you have a bug in your dependency graph. YOU CANNOT do A5, A6, or A7 without A4 or the graph is wrong.)

An activity map can make talking about your estimate more rational.

In the graph above if A5 and A6 are MUST HAVES then you CANNOT kill A4, but you can talk about possibly killing A7, A13, A14 and A15.

Since the dependency graph is SO EASY to do and adds so much value I wouldn't have any scoping conversations without it.

Please let me know if you have any suggestions. I have some thoughts that I may write up in a future post but if you’ve got any ideas please share them.