Why are estimates treated like deadlines?
- Because human beings are inherently bad at statistics.
- Because business schools teach managers to set targets.
- 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.