If an estimate is correct, then it’s not correct. And this is correct (or the Estimation Paradox)

As a client, I often get estimates and start thinking that now I know what exactly I’m going to receive and when it will be ready. I’m waiting for my order in a restaurant, I expect to get to work on time based on driving directions, or I believe that builders will have completed repairs on my house by next Saturday.

I remember the words:

• “Your order will be ready in 20 minutes”
• “The trip will take half an hour”
• “We do it every day. We will repair your house in 33 days”

But why does it never happen on time or the way I expect it to? And why do I continue to be optimistic that this is the time the result will actually meet expectations?

I imagine that, when thinking as a client, I build my expectations on the idea that estimates are carved in stone. Maybe because somewhere deep in my mind, I’d like to believe that I have control and a full understanding of the situation. Or I trust that the people I’m working with are professionals, they know what they do, and therefore I trust their assessments. Then I receive my products or services late, something is wrong, or the quality just isn’t there. And then I start to recall that, in my professional life, I’m a project manager.

Getting From Point A to Point B

As a project manager I love order. But on the other hand, I welcome the challenge of chaos as well. If you are afraid of chaos and uncertainty, it would be hard to be a project manager because real projects create a lot of surprises—and not always positive ones. We deal with chaos and create order; this is an ongoing process. And the first level in this game is the process of estimation.

Google Maps, for example, is a very good model of city roads. But it’s only a model, it’s not an actual city, today, at 8:00 a.m.

Assuming you are a good driver, you know the city, or at least the route to your office. Let’s say, usually it takes about 30-45 minutes. As a project manager of your project called “Get to the office,” you add an extra 15 minutes for “just in case” and start your journey. You text your colleague and say, “sure, see you at 9.” Your navigator says “38 minutes” and a catchy song is playing. Then in five minutes you see an orange line on your map and then in a couple minutes it turns into a red one and a notification says “+12 minutes.” Not great, but at least you have a time buffer. Then it becomes worse, you turn onto an alternate route, you’re almost saved—and then the car tire goes flat and the game is over.

What are your options?

a) put on a spare tire (hot fix)

b) find a repair service (replan the project and change timelines and budget)

c) or leave the car on the roadside and take a taxi (also extra budget for an additional “developer,” who usually can’t start today, which also leads to extra money and delay)

Maybe you’ll get to the office by 9:30 in the best case scenario. Or you will need to cancel or reschedule your meeting (change the deadline).

But who knows, maybe you can afford a helicopter taxi! And if your meeting at 9 a.m. is very important, it may make sense to pay for it.

Of course there is an opposite scenario. Today is a public holiday, but for some reason you go to work in the office anyway. In this case, you can get there in 15 minutes, which is also different from your 30- to 45-minute estimate.

Sure this example is about risks, and you can say “you should manage your risks better.” But how much better can you do it if you have “budget restrictions” equal to one hour? (And “sleep less” certainly isn’t a tenable long-term solution.)

Estimating Development Projects Like an Action Hero

Bringing it back to IT, I’d like to say that there are countless risks which may or may not happen. Should project managers include them all in an estimation? That wouldn’t be reasonable, and also factors such as the size of the team and who specifically will do what job impact the accuracy of estimation and can change it drastically.

Some questions that I like to ask myself when putting together an estimate are:

• Do I know the exact team members if I create an estimate for a project that was not sold yet?

Generally, no.

• Do I know the amount of risk clients can accept while also adding a buffer?

No, I can only guess or base my assumptions on acceptable risks for my company.

• Do I have a well-defined scope before estimation?

I doubt it.

But why am I talking about estimates at all if most of our clients want to work under Time & Material terms (as opposed to based on a fixed price for a project)? Because like it or not, even being ready to work T&M, you still want to know the budget of the project and appropriate deadlines. Even working under T&M, a company needs to make projections for resources for at least a quarter. If you have received a ballpark or preliminary estimate at the beginning of the project, it’s good to keep all these considerations in mind. It’s only a best guess, similar to a Google Maps driving time projection.

Every hero in the movie thinks that his or her first action will lead to the desired goal and usually we hear the phrase, “I have a plan.” Do you actually believe everything will go as planned for our hero?

Saying “I have a plan” is the same as, “here is your estimate.” Then the protagonist faces obstacles and initial “estimates” or “plans” need to be revised or even changed. And something that was “correct” becomes inaccurate or even downright wrong. Maybe the right question is not, “Do you have an accurate estimate?” but “Do you have a good driver who knows the city?”

My thought is that even Google Maps’ estimate for your trip is approximate, but even that estimation model, with all its flaws, is incredibly sophisticated. And no model can fully match a dynamic reality. It means even if you can and want to pay for your estimate and you have a lot of time to work though details, there is no guarantee that your estimate will be 100% accurate. That’s why if your estimate is correct at the outset, then it’s not correct for the life of the project, and this is correct.

Even so, an estimate is a good baseline for a project start, and a good driver will take all the needed corrections along the way to get you from point A to point B.

And by the way, how are your plans going for 2020? Any changes? Though your estimates may not have gone exactly as planned, hopefully your organization has found new ways to pivot and stay on track through this tumultuous year.