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.
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").
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
- Manage project expectations through status reporting
- Use this framework to manage expectations on your project
- Define project expectations with this criteria acceptance form