Networking

Three rules for building off-the-cuff estimates for “little

It's not the big projects, but rather the "little" off-the-cuff projects which generally cause us the most problems. Here's three simple rules for making a decent SWAG at a little project's effort requirements when someone forces you to give a projection.

Who has ever sat down and been asked to, off the cuff, produce a project estimate for some massive and complicated piece of work? I'm sure it happens, but not nearly as often as our nightmares would lead us to believe. Most people can recognize the really big projects when they see them. Instead, people ask for estimates on the “little” projects, the ones they think they can sneak in under the radar. You know the ones; where “we'll just have to do a little code” or “install a vendor supported server”.

It's these little projects which lead us down the well-intended path to disaster. People already “know” what it will take to do them. They ask us for our opinions to verify their own initial impressions. If we happen to disagree, then they will just go ambush some other project manager in another meeting until they hear what they want to hear. Then the system will go in, consuming untold resources and causing problems for everyone.

When I'm faced with these “little” projects, I try to keep the following three rules in mind.

First, and most important, what will the “little” project interface with? Assume each interface will take at least one week of work. For example, a stand-alone system which is part of a basic network security system has to interface with at least an identify provider (usually a directory of some kind) and probably a firewall or VPN. That's two weeks of work (probably not full time, but elapsed) for someone.

Second, does anyone other than the person asking for the estimate want the product? If so, you can count on relatively modest political overhead (about 1 week for every 4 weeks of work). If no, then expect a fairly non-trivial amount of documentation, persuasion, and testing (about 1 week for every 2 weeks of work).

Third, how much customization will you have to do? I've as of yet to see an “out of the box” installation of anything except a Microsoft Office product. Even then, some people can spend weeks building a company approved dictionary. I assume that with an unknown product it will take about 2 weeks of research per module for the technical team to get familiar with it; we can then spend another week per module doing tweaking if we go with minimal configurations.

These rules give me my envelope calculations on what we have to do to take a product from out of the shrink-wrap to minimally functional in an environment. They do not cover the overhead associated with various project approval processes, lead times required (I know one environment where it takes 12 weeks to get a server order), or other marginal factors. Those factors vary so much from company to company that making portable rules for them never quite works out.

Now I need to get back to work. I've got to translate some envelope calculations into a somewhat more legible format so I can explain to someone how his “little” project is going to eat one of my client's IT budgets for the coming year.

Editor's Picks

Free Newsletters, In your Inbox