Data Management

Three tips for avoiding project estimating mistakes

Project cost oversights are incredibly common, but IT project managers can avoid estimating mistakes by being well prepared up-front. Erik Eckel offers some advice.

Most every IT project manager knows the sick, sinking sensation of unease when first encountering a project cost estimation error. Unfortunately, project cost oversights are incredibly common.

Clients' habit of either neglecting to mention important details, or simple ignorance of systems' configurations or previous band-aid strategies, often place project managers squarely in the crosshairs. In fact, having prepared, sold, and completed numerous projects, I'm amazed any projects come in on time and on budget. Countless "known unknowns" and "unknown unknowns" work against IT professionals whose jobs it becomes to make old systems, legacy code, and proprietary systems magically work as intended.

Here's one example gleaned from my experience. Say a retail chain with multiple stores is upgrading its financial management platform. After reviewing an equipment inventory prepared by the client, exploring server and Windows licensing options, researching router and firewall models, preparing project cost estimates, and selling the client on a $25,000 project, the time arrives to implement the plan. Imagine the discomfort upon discovering the client inaccurately inventoried existing systems. Learning so late in the process that seven of 18 systems don't meet minimum hardware requirements can kill a project (replacement workstations can easily run 30 percent of the original budget).

You can avoid common costing mistakes by being well prepared up-front; in fact, this is the only defense against "known unknowns." And, by eliminating as many "known unknowns" as possible, you minimize potential project disruptions. Here are tips for sidestepping the top three project estimating mistakes.

#1: Confirm all assumptions (aka Trust No One)

Client confusion often makes IT project managers look bad. Never accept a client or other IT project manager's word as gospel. Know that clients sometimes don't know what they think they know.

How's that?

If a client says he has 25 32-bit Windows XP Professional workstations, don't believe that to be true until you've visited the client site and completed your own inventory. Otherwise, discovering a handful of 64-bit Windows Vista workstations late in a deployment can throw you for a loop the client expects you to manage without extra cost (and programmers can tell you that two OSs can possess significantly different software development requirements).

Or, if a client states the organization already has two servers running Windows Server 2008 with SQL Server 2008 (which will be required to power the platform your company develops), don't accept that fact when factoring new hardware and software purchases or upgrades. You must conduct all hardware and software dependency research yourself (or have a representative of your firm confirm these facts). Clients simply become confused. I've seen clients who are unable to differentiate between SQL Server 2008 and SQL Server 2008 Express. Don't let such confusion cause major cost overruns with your projects; verify all important project details (including the small ones) when preparing cost estimates. By eliminating these potential project landmines, you can mitigate "known unknowns" or elements that can commonly trigger cost overruns.

#2: Don't expect trouble-free projects (aka plan for "unknown unknowns")

You only have so much information upon which to base estimates. Since project cost estimates include time as well as material, it's important that time be allotted for unforeseen snags, scope changes, incompatibilities, and other issues.

While it's difficult to provide a simple standard or calculation that can be used for all projects, determine the bare minimum amount of time that will be required to complete a project. Then ask, based on years of experience and real lessons learned completing similar projects, which steps or stages are likely to encounter trouble and how long likely delays might require to resolve.

I've seen hardware vendors miss shipping dates; freight companies lose shipments; developers and administrators become ill; and platforms that should automatically integrate fail to do so.

Be sure to build the appropriate time into original project planning documents, recommendations, proposals, and costs to accommodate inevitable problems. While you can't compensate for all "unknown unknowns," you can at least take steps to responsibly plan for contingencies.

#3: Specify exactly what estimates include (aka put it all in writing)

Miscommunication is easy. Clients may hear you say a project estimate includes the time, equipment, and software to deploy a new customized database. Clients won't differentiate between back-end SQL Server requirements and client-side Microsoft Access needs. Deployment is a bad time to learn that a client thought her Microsoft Office Small Business Edition volume license agreement included Microsoft Access on 25 machines.

State exactly which items are covered when building project estimates and proposals. Be sure to include language in a contract or project agreement stating additional labor, equipment, and software not covered by the project's cost estimate may be required to complete the project. For example, for a custom database roll-out, be sure to state that the costs of a new server include one new server with a specific CPU, RAM, disk configuration, operating system, and CAL license count and any additional software. That way, if a discrepancy arises when it's determined the client possesses no Microsoft Access licenses, you're covered (although if you've done the homework discussed earlier, you'll have avoided that potential "known unknown").

Fear itself

Analysis paralysis isn't just for politicians and leaders in other industries -- it affects IT managers as well.

There's only so much project preparation work you can do. Efficient projects must also get started quickly, so be cautious of delaying cost estimates out of fear. Take your best effort, trust your skills and experience, and begin work.

If you've done your homework by reviewing dependencies carefully, allowing time for unforeseen issues, and documenting the project's specifics in writing, you'll be much better positioned to accommodate "unknown unknowns" when they arise. Better yet, you likely won't have to cover the costs (time or money) out of your pocket due to your own oversight.

Related TechRepublic resources

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Erik Eckel owns and operates two technology companies. As a managing partner with Louisville Geek, he works daily as an IT consultant to assist small businesses in overcoming technology challenges and maximizing IT investments. He is also president o...

14 comments
resimpa
resimpa

In a recent study we did we found that the 3 things that made the difference were: Engaging all the stakeholders in the planning stage. Test Manager as a key stakeholder Regular checkpoints with all stakeholders However personally I used to say to all my stakeholders bad news is not like wine it does not get better with age. Having a sense of humour helps too! If you want to read some of the best & worst practice stories we have a free white paper based on 100 interviews at the Customer Experience Foundation.

uFunctional
uFunctional

These are all good hints for getting better. But I believe that all the forces on software development are making estimation harder, not easier, and that we will never get accurate enough to make the estimation problem go away. http://wistechnology.com/articles/5190/ If you accept this, it leads you straight to the agile methods, because they preserve value better in the face of an estimation error, as this toy example illustrates. http://wistechnology.com/articles/5514/

ChipN
ChipN

For example, creating a common vision of success is key. As you do this you will find that new requirements or redefinition of existing requirements will occur, and that affects both scope and estimates. Below are links to two relevant white papers that I wrote on Earned Value Management a few years ago. They discuss scope management and estimating - two things that are essential to project success. http://comp-soln.com/EVM_scope.pdf http://comp-soln.com/EVM_estimating.pdf There are certainly many other reasons that projects fail, but getting a solid start to a project will minimize the chances of failure. And, using EVM on an ongoing basis will help identify problems early-on, giving you time to make corrections early before things get out of hand. Cheers, Chip

dwwright99
dwwright99

As Napoleon said. "A plan is only good until the battle is joined."

bobk
bobk

While I agree with the three tips, with respect to tip #2, I am curious about how anyone may have dealt with the inevitable client questions that come up when you add "contingency" as 25%, for example, of a total budget. I agree with Tony that clients are quick to forget the definition of estimate, but my experience has been that they have a hard time signing off on a reasonable dollar amount to cover unknowns, even though, as you suggest, they are all but inevitable.

Tony Hopkinson
Tony Hopkinson

of estimate. ie it's not an actual. Once you've assumed your estimate is precise, kiss all hope of not being surprised goodbye. Identifying known unknowns is simply a quaestion of how much resource you are prepared to spend up front before you plan, this usually works out at none. Unknown unknowns is simply a contigency estimate, which unfortunately is often confused with the range of error put on the estimate of the known unknowns..... I am not even going to mention tearing out contigency in order to make a cost/timeline look more acceptable.... :p

MikeFisherAK
MikeFisherAK

Not to be overly picky, but the risks you identified are known unknowns. Unknown unknowns are those things that you don't know about (and therefore can't even list in an article). The first known/unknown refers to whether you know about a potential risk event. The second unknown refers to knowledge of the state of the risk (probability and impact). You mentioned, "hardware vendors miss shipping dates; freight companies lose shipments; developers and administrators become ill; and platforms that should automatically integrate fail to do so." These risks are things that every project manager should think about, and are great starting thoughts for a thorough risk assessment. I enjoyed the article, but I didn't want the risk terminology to slip by (since project risk management is an area of expertise).

Mark Johnson
Mark Johnson

I have learnt from experience to concentrate on documenting what is out of scope, but related to the project. This usually drives an interesting conversation that exposes the clients assumptions and subsequently improves the proposal and the estimate. Of course it provides a nice back stop when you can remind the client later that something is out of your scope, and that in fact you brought this up and they decided not to include it!

Tony Hopkinson
Tony Hopkinson

Seen that, his boss told him it had to pass.......

uFunctional
uFunctional

Estimates mysteriously turn into commitments, management plans projects and staffing, and sales makes promises to customers. When things start to slip (and something always does), the shock spreads quickly through the overconstrained system. Forced overtime leads to abandonment of good practices and defects introduced by tired, stressed people, slowing things down even more. When it's done, we fire the people who we paid to learn the lesson. And we keep doing it, over and over and over and over...

Erik Eckel
Erik Eckel

Mike, Thanks for responding. I appreciate your taking the time to write. I'm not sure I agree that a freight company losing a shipment is a known unknown, as all equipment associated with a project may ship on time. Same thing with a developer getting sick or a hard disk failing; you don't know for certain that those items will fail, whereas, you do know for certain that Windows XP Home systems don't maximize domain membership, for example. I think we agree in principal: you have to budget for things going wrong. I tried to lay out, in the beginning of this piece, that by planning for all contingencies you know can arise (missing licenses, incompatible hardware, etc.) you can minimize known unknowns, but unknown unknowns are just that: things you don't know that can go wrong. I think of unknown unknowns being any of the following. 1. Discovering that a device driver that's supposed to provide compatibility with a new software platform actually doesn't work, necessitating hardware replacement. 2. Learning that an API that's supposed to provide application interoperability doesn't work as promised. 3. Finding that a client didn't realize their inventory includes seven classes of data tracking, not five as may have been planned. Does that make sense?

Tony Hopkinson
Tony Hopkinson

They've failed somewhere or they are just there to replaces the smilies on teh dashboard when 90% of the resource has been used up. If there's on bunch of IT wonks, who should communicate well with management, it's PMs.....

Scott_N
Scott_N

We usually add contingency to our estimates. The less detail in the requirement, the bigger allowance for contingency (or unknowns). A simple example we had just last week was the addition of a new item for a data warehouse extract. We were told the field existed in the tables (always check), however, it was not in the table used for the extract. Only a half day of work, but it wasn't known at planning time. Contingency allowed us to absorb the additional time.

Editor's Picks