22

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?

enter image description here

5 Answers 5

13

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.

9
  • 1
    Exactly this. As a Business Owner I will consider your estimate to be an educated projection based your experience, skills and qualification. To the OP; if you made an estimate, you need to stand by it. The truth is, I very rarely care what your estimate is as long it is the left side of my final timing. However, if you say a time then that time becomes yours to live and die by. You said it, you own it. I recalculated my projections, my finances and my resources based on it. You should have said a range of estimates but you didn't. Estimates becomes deadlines because of your own fault. Oct 1, 2014 at 20:53
  • 3
    @Venture2099 Sorry, but no. As a business owner, the responsibility is yours. An estimate is just an educated guess based on current information; it is the stakeholders' job to fund projects that continue to produce value, and to terminate projects that aren't meeting expectations. You are absolutely guaranteed death and taxes; everything else in life is a statistical probability. If you want to open a related question on how to improve the the accuracy of some subset of estimates, please do. However, continuing to juxtapose estimates and targets just underlines the OP's original question.
    – Todd A. Jacobs
    Oct 1, 2014 at 23:32
  • 6
    When estimating a future value, there is a continuum of probability of any value being correct from "we don't know" at the start when you know little, to "we know with absolute certainty" at the end when it has been delivered. The estimated value of any dimension should be reviewed and refined as you move from the beginning to the end. To pretend that an estimate at the beginning, when nothing is known, attracts the same level of certainty as at the end when you know everything, is naive. Accuracy of estimates is solely a factor of how certain you are about critical contributory factors.
    – Marv Mills
    Oct 2, 2014 at 11:40
  • 2
    @Venture2099, in response to working with someone like you, I'd get the team to estimate best and worst case estimates, and then I'm multiple the latter by four and would give you that figure. If you want me to give you a guaranteed figure for what is after all just a guess, I'll exaggerate it to the extreme to protect myself. Neither of us wins here. Far better you simply accept estimates are just that and accept they will be wrong (and generally lower than the actual as people tend to be optimistic with estimates).
    – David Arno
    Dec 22, 2014 at 14:02
  • 1
    @Venture2099, you may like to listen to dotnetrocks.com/default.aspx?showNum=1073, in which someone who runs a successful software development business describes how he multiples his estimates by pi and by pi squared for difficult customers. When dealing with difficult managers/clients, who refuse to accept agile contracts, this is common practice. If fact it's likely that all those with whom you have dealt with in the past who appear to "estimate accurately" (an oxymoron) use this technique too.
    – David Arno
    Dec 23, 2014 at 15:17
5

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.

1
  • +1 to projects cannot be approved open-ended and also the line about expertise. Dec 27, 2014 at 6:29
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.

3

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.

3
  • I normally agree with everything you write CG but this answer I have to disagree. Your tone is downright disrespectful to those with MBA's and also makes huge, sweeping, unverified generalisations about the industry. The simple fact is this; if I ask you for an estimate and you are being hired as an expert capable of making an estimate then I expect your estimate to be close to the truth. If you say it will be done by April, am I to pay you until July just because I have an MBA and am apparently bad at statistics? Or is the reason I am paying you until July because you screwed up an estimate? Oct 1, 2014 at 20:49
  • @Venture2099 If you hire me to give you an estimate, you will get a statistical estimate with bounded probabilities and a confidence interval. If you want a guarantee (e.g. fixed scope & fixed price), I charge a lot more for that. If you still choose to treat an estimate like a management target, then that's entirely up to you, but it certainly won't be what's in the contract you signed. YMMV.
    – Todd A. Jacobs
    Oct 1, 2014 at 23:15
  • 1
    Bounded probabilities are fine. The OP clearly is not applying that methodology. The question was in the spirit of "An estimate should be held to account." It is disingenuous to blame management for responding to an estimate when presented without contingency. Oct 2, 2014 at 7:01
2

@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. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.