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.