Unrealistic project estimates: The IT consultant as an enabler

Takeaway: All IT consultants have given clients unrealistic estimates at one time or another. Get tips on how to resist the pressure to give ad hoc estimates.

Here’s an all too familiar scenario:

Bob the client calls and says, “We need to add this small feature to our application. How long will it take?” You respond that you need to draw up some requirements and talk to users, but Bob counters, “Oh, just gimme a ballpark estimate.”

The gears start turning in your brain as you imagine implementing the feature as described. Your natural optimism thinks you could complete the work in three days, but you know you can be overly optimistic, so you answer, “Two weeks.”

Guess what? You’re still short. You forgot these important factors:

• Requirements. Your client contact, whether they’re the CEO, CIO, project manager, or whomever, cannot have a complete picture unless she or he is the only user — and even then it’s dicey. Besides, there’s no guarantee that what you took from their brief description even matches what they meant.
• Design. You don’t want to jump in and start cowboy coding without a proper design of each component. I’m not talking about flowcharting everything or generating piles of UML that nobody will ever read again; your design needs to be flexible but well thought out. Even though this seems like it adds time to the project, failing to do this step adds even more time in the long run.
• Testing. I’m a big believer in writing your tests before you write the code to satisfy them — or at least, in parallel. This is another step that saves you time down the road.
• Iterations. No matter how well you define the requirements up-front, somebody will forget something important or something nobody even knew. You need to build in time for providing prototype versions so the client can use the product and provide feedback that drives new requirements.
• Documentation. A system that isn’t documented will be reinvented. If you want the project to have any shelf life, you need to provide usage instructions for people you may never meet and put enough comments in the code that you’d be able to understand it even if you hadn’t written it.
• Training. No matter how well you write, users may not be able to grok what’s going on without some personal guidance.

Taking shortcuts that cost more time in the long run

Consultants often leave out some or all of the above steps in an attempt to provide results quickly. Bob may be impressed when he gets the new feature in less than a week, but pretty soon, he’ll find out that the project isn’t quite done yet. In fact, you’ve only completed the first iteration, and even that was half-baked. The project will probably drag on for months or even years, as you tweak the features, fix the bugs, and give the users the same instructions over and over again.

So, why do consultants take shortcuts that make the journey longer? Here are four reasons:

• Client pressure. Bob wants you to give him a low number, so he can justify the work. You don’t want to disappoint Bob, and you want him to approve the project.
• Competition. If you aren’t the only bidder on the project, you want to be the lowest bidder so you get the gig.
• Hubris. No matter how much you pad an ad hoc estimate, it still isn’t worth the air that it’s written on. But once you’ve stated a number, your pride and your standing with the client won’t let you admit that you were wrong. So you cut corners.
• Pure evil. Some consultants get the client on the hook by intentionally engineering the project to require follow-up work after it’s “done.” Those consultants give the rest of us a bad name. (They should really read my column, “An independent consultant’s code of ethics.”)

Fending off pressures to give ad hoc estimates

I have three recommendations for how to resist these pressures:

First, consultants have to be aware that these pressures exist. When I was a newbie consultant, I had no idea why projects always took longer than expected — my estimate always seemed reasonable to me at the beginning. Learn from past projects — what went well and what didn’t, both in your experience and in the experiences of others.

Second, consultants have to educate clients on what a well-executed project requires. Clients need to understand that by taking a month instead of a week, they’ll get a finished product that meets their needs instead of one that does exactly what they said but not what they meant. And even if it does require modifications after delivery, they’ll be easier to implement without breaking something else.

Third, consultants should not give ad hoc estimates. If your client won’t stop bugging you until they get one, then say, “sometime between a month and 10 years” because frankly, that’s about as precise as you can be without more information. Instead, you should push for approval of an exploratory project to establish requirements and compute a decent estimate.

Building a reliable reputation

Unfortunately, because so many self-styled consultants are willing to cut corners, they’ve set the expectations in clients’ minds about what estimates mean. The more intelligent clients have come to expect that the project estimate will be far less than what’s really required when all is said and done. So when they receive a more accurate estimate, they’re likely to think that the actual timeframe for having something usable will be much longer. You need to build a track record of reliability before your client can trust your prognostications.