Why are estimates treated like deadlines?

Question

This is one thing that I've always taken as a given, the "status quo" in my line of field (software development) but never really gave it a deep thought. And even now that I do, I still don't understand.

I'm not talking about estimating something you've done over and over again, but stuff you have never built, you don't have the experience for, the specifications are incomplete (if you even have such a luxury), placing an estimate effort on powerpoint presentations during the presentation, etc.

I mean, it defeats all logic, but this is constantly what happens. Why?

Why does this always happen?

Answer 1

I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved.

I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge impact in how the client treats those estimates later on. And then, during the course of the project, the way I present additional information can have a big impact on how anchored to the original estimates the client is.

One of the biggest things to keep in mind is that any time you give estimates, you are setting expectations. The more precise your estimates sound, the more likely the client is going to treat them as a hard deadline. Why? The client is hiring you as an expert, and you've given them your expert opinion. Surely an expert is going to know what they are talking about?

For example, consider how your client would react to you telling them that the project that you estimated would be done on November 6th won't actually be done until November 20th.

Now think about how that same client would react if you had instead originally told them that you estimated that you would be done between October and November, with a 75% likelihood that you'd be done the first week of November. Your slip to the 20th means you still missed your 75% likelihood, but you still fell within the range that you had originally established with them.

Most (though definitely not all) clients will have a much more accepting reaction to the second case than the first one.

The other big factor is to make sure to have frequent and clear communications with the client as the project progresses. Make sure that the client sees where the project is compared to where the ideal progress would be. Make sure to talk about any issues that may be impacting the project's schedule compared to the original estimates. Make sure the client has visibility about how decisions that are being made are causing additional scope to be added, existing scope to shift, unplanned work to need to be undertaken, or impediments that are keeping progress from proceeding at the original expected pace.

Don't simply use text to present this information. Having something like a burnup chart can make increasing scope much more visible to the client (and more impactful to their understanding) than simply listing percent complete numbers.

Answer 2

There is a difference between estimates and planning values and I find most either ignore or confuse the two...probably the latter. Work effort is probabilistic and a proper estimate should reflect that and be provided as a range of possible results. For example, an estimate to build a wall might be six to 15 days, most likely nine. If you built that wall 100 times and documented the number of days, your actual results should mirror this distribution.

Your planning value is a number within that range that reflects your target and should be a value that reflects the degree of risk you are willing to assume. In the wall estimate, my planning value might be eight days, suggesting my risk appetite is more aggressive than what I am most likely to achieve.

You have to have planning values, and these become deadlines. Projects cannot be approved open ended. No one will put their money on the line with the expectation it will take as long as it takes and cost as much as it costs. Would you hire someone who says that?

There are types of projects that are extreme innovation events or research in nature and those are approached a bit differently, but even then you have established limits where you would cease the project if progress is not achieved. Those limits are, in a way, planning values or targets.

Answer 3

When the client request for the timeline estimate they are looking upto the PM as an expert who can tell them what they need to communicate to stakeholders that the client is working with. So while communicating the time estimates it's important that the factors defining the time estimates and criteria of meeting those should be highlighted. Many a times as project managers when being asked by when you can finish most of us end up giving only the schedule and lot of times only the deadlines without emphasizing the factors that will enable us meet timeline and by what percentage there could be variation. Again when we communicate variation one cannot simply tell it is at 50% variation that needs to be quantified on what factors we conclude it is so.

Client will accept timeline as estimate if it is supported with 1. Factors of achieving the timeline 2. Potential risks to schedule 3. High level unknown's which could become issues.

Answer 4

TL;DR

Why are estimates treated like deadlines?

1. Because human beings are inherently bad at statistics.
2. Because business schools teach managers to set targets.
3. Because the project manager has failed to educate stakeholders about the difference between an estimate and a target.

Examining Each Item In Greater Detail

People are bad at statistics.

Estimates are, at heart, risk assessments. They are often used as proxies for schedule risk, potential process impediments, and the level of chaos or risk of the unknown within the project. The psychological literature is filled with examples of how poorly people estimate risk. In the security domain, Bruce Schneier often writes about the gap between perceived risk vs. actual risk.

While this might seem like it just makes for bad estimates, if you think about how people use estimates for measuring schedule risk, project risk, or other risk, you'll quickly find that people are emotionally wired to treat estimates as high-probability action items. This is no different than how most human beings treat probabilistic weather reports.

Consider the typical weather report that says:

Today will be clear in the morning, with a 60-80% change of thunderstorms in the afternoon.

Sadness. Well, cognitively there's a non-zero chance that it will rain all day, a non-zero chance that it won't rain at all, and a statistically signficant chance that it will rain sometime after lunch and before I leave work. That's a lot of information, which I'm sure most of us simply treat as shorthand for "I guess I'd better take an umbrella to work, just in case." We've just turned an estimate into a firm target for how to plan our day.

Business Schools Teach Targeting

I'm not sure how to prove this one except anecdotally, but every freshly-minted MBA I have personally ever worked for worships at the altar of MS Excel. Business schools teach accounting and financial analysis, but either don't teach rigorous statistics or don't emphasize them enough within the realm of business processes.

Part of this is the nature of higher education (e.g. it is often teaching lessons learned from the prior business generation), and part of it is that higher education often suffers from an ivory tower syndrome. This isn't peculiar to management; ask any recent computer science graduate if a computer science degree really prepared them to work on a large, mission-critical e-commerce application.

Enough soapbox material. Here's a more practical example. If you are a manager, you read articles like this one in the Wall Street Journal:

Begin with the end in mind. It’s not enough to simply choose a course; you must have a clear sense of where that course will lead you. You need to decide both what you are going to do and where it is going to take you. In short, you must have a strategy.

The reader could be forgiven for confusing estimates with goals. Management-speak is all about strategies, goals, and (of course) budgeting. An estimate is a probability, not a strategy, but if you squint really hard it might look like one. Your mileage may vary.

Project Managers Must Communicate the Distinction

Project managers, Scrum Masters, or other project referees have the responsibility of ensuring that stakeholders understand the difference between an estimate and a contractual guarantee. This is not easy to do, and can burn political capital if it's not a message stakeholders want to hear. Still, it's part of the job.

In Scrum, the Scrum Master shares this responsibility with the Product Owner. The Scrum Master is responsible for the process, including making sure that the Development Team communicates effectively and transparently about its processes, including the estimation process. However, the Product Owner is the person primarily responsible for managing stakeholder expectations; even if this responsibility isn't explicit, it is essential to the core tasks of prioritizing Product Backlog items and setting Sprint Goals for each iteration.

If none of the project's guardians or executors can communicate the distinction between an estimate and a guarantee, then this is a communications process failure. Inspect-and-adapt your communications process until the point is effectively made, and just accept that the point will likely need to be made again and again, especially when something is mis-estimated and there's a budgetary or scheduling consequence.

Answer 5

@user12198 The reality is that sometimes deadlines is what they want, and in software we have a way of fixing the time instead of features. But that has to be the process, and it has to be built into the triangle. Remember a team/project must choose two. Many software development plans attempt to fix all of them, or at least don't explicitly say that one WILL be neglected.

In your case, it sounds like you want to fix the number of features (scope) to what the client wants, and fix resources. The issue is that you probably haven't said that schedule MUST be variable.

A solution that a software PM could take is Timeboxing. This allows for a fixed schedule and resources but NOT fixed scope. A software plan would have to use some sort of prioritization scheme like MoSCoW. Where the client must quantify features, and that way in a time box you only do the highest value things - your goal for a project can't be to complete all features but instead to finish on time.