We don’t like that estimate. Change it.

CIO: “We can’t go live in six weeks as you want.  It’s going to take at least three months.”

CEO: “That’s … unacceptable!

One of the most recurring memes in IT, for me, has to be hearing “we don’t like that estimate”, coming from stakeholders, senior management, etc. Depending on the mood and/or semi-intellectual rigor of the person saying it, the conversation then typically devolves into one or more of the following:

  1. identifying and removing any hint of schedule contingency (which is often viewed as padding just to make life easier for IT);
  2. mentioning repeatedly the idea of “what if we double the team size to get it done twice as fast” etc.;
  3. conducting a scrutiny, one by one, of the bottom-up estimates (”it won’t really take three days to test that feature”);
  4. volunteering resources (usually less than qualified) to “help”;
  5. insisting on scheduling full-time work for all remaining weekends and holidays between now and the desired launch;
  6. making frequent use of the phrase “why don’t you just …”
  7. declaring that system delivery must occur by a specific date, no matter what.

A real-world micro-example of estimate pushback: one of my Twitter colleagues tweeted this a few months ago: “Me: it’s six weeks effort. Client: what can you give me in two weeks?” That was obviously tweeted in frustration, and was most likely intended to serve as an example of how incredibly unreasonable the client (or manager, or CEO, whatever) can be.

Yet, at core, and read literally, it’s a perfectly natural question coming from an executive who is looking to explore all the possibilities.  IT people need to learn to anticipate such scrutiny, and have coached and practiced enough with their own team to show that they’ve thought through some alternatives.  That’s collaboration as a key business contributor.  That’s strategy. In fact, showing that kind of maturity is what will take IT beyond being mere order-takers.

So the CIO/CTO’s role as leader here is to inculcate the following mindset in the collective team: don’t assume that these management suggestions are simply ignorant or obstinate. In fact, I’m arguing here that management reactions along these lines are understandable, though admittedly sometimes misguided and excessive.  I’ve been there: I’ve done it myself, frustrated (as an exec) by the estimates the team was telling me.  So now, instead of just getting annoyed at the upper management behaviors listed above, I see both sides.  Even better, I have some recommended behaviors that the IT team can adopt that will help in such situations.

First, and this is key, adopt the mindset that every plan needs to withstand some scrutiny. Expect scrutiny and plan how to deal with it. The answer from IT can’t be “these are our estimates, so you just have to accept them.”  Just as with making any management presentation, you need to anticipate the obvious questions, adjust your plan to accommodate them where possible, and have further answers at the ready.  It’s a back-and-forth, not a one-way. Delivery discussions need to be about ways to provide viable business value given the constraints. It’s a collaborative process, not a confrontational negotiation where one side makes demands and the other side caves in.

Second, spend some time seeing and removing your own (IT’s) flaws.  Specifically, consider flaws such as these, common reasons why estimates become regarded with skepticism once an executive drills down:

  • Every task in the schedule, no matter how slight, is assigned at least a day’s worth of work in the plan. IT teams need to doggedly squeeze out the obvious air.
  • Easily understandable tasks (ones that the executive has good familiarity with) are being estimated as taking much longer than they have historically. Way before it gets to an executive presentation, the team needs to challenge every number themselves so that this either doesn’t happen, or can be explained with a supportable rationale as to why things are different this time.
  • More generally, there appears to be little or no historical basis or metrics used in establishing the estimates. Estimates that are based on facts and data, rather than people’s gut, are almost always more credible.
  • Once the executive starts to drill, people cave immediately: “Oh, OK, I guess we could do that in a couple of days, rather than a week.”  Making this kind of admission is throwing raw meat to a hungry bear.  It shouts that your estimates probably had little basis in fact.  Or, that your emphasis on certain must-haves like integration testing isn’t so heartfelt at all.  At the very least, it reveals that you haven’t thrashed through the numbers internally well enough to be able to stand behind them with greater firmness. Believe it or not, and often with all evidence to the contrary, the executive is looking for where there’s strength of conviction, and where there isn’t. Strength of conviction (supported by facts, of course) may ultimately be disagreed with, but it’s usually respected.
  • The team and/or project leader shows little or no recognition that there may need to be some kind of interim solution, some sort of early delivery. There’s no “team attitude”, no searching for midway points (i.e., acceptable scope reduction), no exploration of “what ifs”, such as “what if we delivered the system without an administration GUI at first?”  Once again, there’s no substitute for holding internal practice sessions and staging multiple “devil’s advocate” discussions.
  • Conversely, there’s no clear “line in the sand” visible, meaning points you stick to no matter what, points that cannot be compromised if the company wants a quality delivery.

The very fact that these reasons for estimate-related skepticism even occur in the first place demonstrates the value-add of such skepticism. In other words, everyone needs to realize that it’s actually OK for management to ask people to dig deeper, to explore every option, because it turns out sometimes they don’t on their own.  It’s OK to be asked, and everyone should expect to be asked.  That’s part of everyone doing their jobs, and, cynicism aside, such active scrutiny is most certainly the job of senior management.

Steve McConnell, in his outstanding book on Software Estimation, writes eloquently on this issue.  He points out that executives typically have certain notable characteristics and well-honed skills.  The first two of these?  “Executives will always ask for what they want.” “Executives will always probe to get what they want if they don’t get it initially.”

Example: a developer once told me that it’d take two weeks to generate a report I needed as CIO. Taken aback, I probed into it with him.  Together we determined that the report I was asking for entailed nothing more than a rudimentary SQL SELECT statement, slightly dressed up. Every time a manager drills down into an estimate, only to discover that there was no “there there”, it feeds his or her unfortunate but lingering suspicion that most estimates are grossly padded. Getting the “win” (beating down the number) spurs them into even more dogged drill-down.

So I’m preaching a several-pronged approach:

  • doing one’s homework so that maximum scrutiny has been self-applied long before the estimate reaches the executive;
  • sticking to one’s guns to an extent that is both reasonable and facts-based;
  • and then actively looking for ways to reach value for all.

One important note, though: there are often bad (but unfortunately common) ways to compromise when discussing project delivery estimates.  Here are a couple of important places not to cave:

  • Suddenly deciding that you don’t really need contingency. Until perhaps the last week, it’s usually a huge mistake to assume that the rest of the schedule will go exactly as planned. Contingency in a schedule is not padding!
  • Suddenly deciding that you don’t need thorough testing. Forgoing testing is pretty much a guaranteed way to launch an unstable, buggy product that ultimately will cost you much more work (not to mention the customer backlash) than taking the necessary time up front to shake out the problems.

Where’s the CIO/CTO in all of this? Supplying active leadership: educating everyone on the tenets above, coaching, cajoling, reminding, monitoring.  Strong leadership can and does reduce these common “we don’t like that estimate” kinds of proposed “solutions”. In fact, it is the mettle of the mature and successful CIO/CTO that they constantly “upward and sideways” manage their peers and management to get them to understand the cold harsh realities and weigh appropriate and reasonable trade-offs.


  1. Great post Peter – it’s great to see all of your experiences boiled down like this.

    In addition to estimating, I strongly believe that rapid prototyping is a part of this puzzle too. We’ve all been part of projects where we baked all of the planning up-front, only to find a major change a few weeks into the build that required major re-thinking.

    In the first section of Frederick Brook’s latest book, The Design of Design, he summarizes his belief that this design-then-build approach embodied in waterfall methods is wrong and that a prototype based model to elicit and evolve requirements is a much better way to design, and estimate.


  2. Great Stuff Peter –

    As you’ve suggested, the key here is strong leadership from the CIO/CTO. I like the term “Supplying active leadership”…love it actually.

    Nice article.

  3. Great insight, pragmatic as always … another technique I’ve found successful is to link the estimate durations to groups of logical business functions or feature/feature sets. Start with “architecture” items that are needed even if only one single business feature is requested. Basically, these are your non-negotiable items, your baseline, your foundation, etc. Then, in business terms (not fancy IT buzz words), group IT tasks into logical groupings. Assign high/low/average durations to those business groupings. Consider some math/metrics based testing durations. Add in basic deployment/other tasks that are required “overhead” to deliver basic quality. Then, be prepared to for the negotiation: “if you want to shave off a day/week/month, then if you are willing to drop these business groupings/feature … or push them into a phase 2 deployment …”

    Now, if I had a dollar for every “oh, it takes that long to automate that? Geez, if it takes that long, we can live with a two step manual process …”

    Great stuff!

  4. Steve Romero, IT Governance Evangelist says

    As usual, fantastic real world practical insights and advice. I would like to add one more activity to the CIO/CTO/IT Executive’s role. It may be implied in the great steps you describe, but I want to state it explicity.

    After they have supplied active leadership and refined the estimate, I want them to do some investigating. They should spend some time talking to their people and studying their environment to determine what is causing folks to pad their estimates. In some cases it is simply a matter of improving the estimation process. In others it is an indication that workers in the organization feel the need to build buffers against unreasoned, irrational, and unpredictable workloads. If leadership does not find and eliminate the causes and incentives for estimate padding they will forever be burdened with the overhead of refining them.

    Steve Romero, IT Governance Evangelist

  5. Loved it. Can attest to the truth of the piece, having been on both sides – as well as squeezed in the middle.

    Walking into the boss’s office with a “take-it-or-leave-it” estimate can be risky business. Being able to show the boss what he can get in two weeks, when what you really want is six, can actually help you get six.

    “Good enough” can be one of the hardest concepts to get across to techies when making estimates. Likewise “intent” can be hard to get out of the CEO, i.e. tell me what problem you need solved, not just what to do and how to do it. Sometimes a simple paper printout with a number circled in red pencil will do the trick.

  6. Thanks, Chris, and especially thanks for the pointer to Fred Brooks’ latest book, which I haven’t yet read.

    I think that prototyping is both highly desirable for the reasons you outline, but this post is really covering a separate issue. There are different levels of estimates in any project. No matter what your approach (waterfall, agile, prototyping, etc.), there’s no getting around having to “name that tune” at some level about when you can deliver a system. So I’m not arguing here (by any means) for an approach that “bakes in all the planning up-front”. That said, and allowing for scope changes along the way, an IT department needs to be able to present and justify their overall estimates for delivering badly needed/desired functionality. It’s never a good option to essentially shrug to the rest of the management team that “things may change, so who the heck knows when we’ll be done.” Rather, rapid prototyping can serve really well to identify major disconnects, AND THEN REPLAN.

  7. Exactly, John. The approach you outline is exactly the kind of collaboration I’ve seen work well. What doesn’t work well is the converse: the “throw the requirements over the transom, and get back the estimates as an answer” approach that is adopted by way too many organizations.

    Thanks for commenting, John!

  8. Agreed, Steve: unless you figure out what (organizationally and politically) is causing the padding, it’ll keep happening to some degree. That said, once people start seeing a healthier process for presenting and honing estimates, and what happens when an estimate proves wildly off (collaborative regrouping and replanning, rather than punishment), the behavior starts to change in and of itself.

  9. Absolutely spot on, hits the problems we always have perfectly,
    but most of all I liked your approach: “don’t assume that these management suggestions are simply ignorant or obstinate. In fact, I’m arguing here that management reactions along these lines are understandable, though admittedly sometimes misguided and excessive”

    Don’t try to win, don’t cave in, and scrutinize your estimates before submitting. I agree.



  1. […] We don’t like that estimate. Change it. by Peter Kretzman on CTO/CIO Perspectives […]

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.