Real World Project Management: Estimating Your Project Costs

Like a character in a Lyle Lovett song, project managers have to focus on the M-O-N-E-Y when providing project estimates. "How much will it cost?" Well, did you want a ROM estimate, a budget estimate, or a definitive estimate?

From the author of

I'm not a huge fan of country music, but Lyle Lovett is one of my
favorites. How can you not like Lyle Lovett? After all, he married Julia
Roberts. (Ah, Julia Roberts—if you've read my articles before, you
know how much I admire that smiling beauty. Sure, she snubbed Keifer, dumped
Lyle, had a set of twins, and refuses to return my phone calls. Still, she
is Julia Roberts.) Anyway, the point I'm trying to make is that I
like Lyle Lovett's music: rhythm and blues, big band, good ol'
country. In one of Lovett's songs, he croons, "Would you like a kiss?
She said, 'Thank you, no. I'll take some M-O-N-E-Y.'"

Project managers are like the girl in Lovett's song:

Management asks, "Would you like more time?" We respond,
"Thank you, no. I'll take some M-O-N-E-Y."

Customers offer, "Would you like to reduce the scope?" We answer,
"Thank you, no. I'll take some M-O-N-E-Y."

From IT to construction, most projects have to purchase materials: routers
and cables, shingles and cement, and so on. We almost always must buy some
things to complete the project work. Think back to your last project;
didn't you have to buy something? A piece of software. A book. A large
double-cheese and sausage pizza for your team. Someone—you or the
organization you work for—had to cough up the cash to buy that stuff.

Regardless of scope or schedule, projects need funds to complete the work.
Technically, even projects that use only labor have funds attached to them;
someone, somewhere is paying for that labor. What happens if you don't have
the correct amount of funds to complete the project scope? Your project is
doomed.

Got Your Money on Your Mind?

How do we know what a project will cost? We really don't, until the
project is complete. I sound more like a car mechanic than a project manager,
but the truth is—and this may sting just a little—we can't know
the final project cost until the project is complete because we can't
accurately predict the future.

What we can do is create an estimate. An estimate is more than
pulling a random number out of the air, adding 20% for good measure, and then
saying, "That'll work." A real estimate evolves as project
details become available. This is progressive elaboration. Project
estimates start out broad, and as the project deliverables come into focus
we're able to more accurately define our estimates.

Each estimate should provide an acceptable range of variance, the conditions
of the estimates, and any assumptions made by the estimate provider. For
example, an estimate to build a new warehouse may state that the warehouse will
cost $350,000, +/– 10%, is valid for 30 days, and assumes that the
warehouse will be built in the month of June.

Notice the range of variance, the assumptions, and the stated work? A good
estimate clearly defines what the project will accomplish, the assumptions made,
how long the estimate is valid, and how much the project will cost based on
current information. A good estimate presents to the stakeholder everything
relevant to the proposed work, without holding back any secrets. If there's
a disagreement in price, assumptions, or range variance, it's better to
discuss this issue now rather than four months into the project execution.

There are three major estimate types that project managers should rely
on:

The ballpark estimate is also known as the rough
order of magnitude (ROM). A ROM estimate is based on high-level
objectives, provides a bird's-eye view of the project deliverables, and has
lots of wiggle room. Most ROM estimates, depending on the industry, have a range
of variance from –25% all the way to +75%. Like I said, lots of wiggle
room.

The project manager shouldn't invest too much time in creating these
initial estimates—just as the customer shouldn't place too much
confidence in the accuracy of the ROM estimate. Unfortunately for both parties,
there's a consistent breakdown in expectations when it comes to ROM
estimates. Typically the project manager blindly throws out the ROM estimate
like a bride tossing her bouquet, and the customer clings to the ROM bouquet
like the maid of honor at the same wedding. ROM estimates, regardless of your
role in the project, are simply for eyeballing the project's initial
perceived costs.

The budget estimate (or top-down estimate)
is a bit more accurate. Formulated fairly early in the project's planning
stage, the budget estimate is most often based on analogous
estimating—taking budget lessons learned from a similar project and
applying them to the current project. Do a little math magic and we've got
ourselves a budget estimate. Abra-cadaver!

With the budget estimate, we start at the top and work our way down into the
project details. Like the ROM, this estimate should include conditions, a range
of variance, and any assumptions that went into your calculations. A budget
estimate is quick, but not very accurate. The range of variance on the budget
estimate is from –10 percent to +25 percent.

The definitive estimate (or bottom-up
estimate) is the most accurate of the estimate types, but takes the
most time to create. The definitive estimate requires a work breakdown
structure (WBS). A WBS is not a list of activities. (I know, everyone at
your office says it is, but they're all wrong.) A WBS is a
deliverables-oriented decomposition of the project scope. That's
decomposition of the deliverables that your project will
create for the customer—nouns, not verbs.

For example, suppose you need to create a network from scratch in your
organization's headquarters. Your WBS will stem from the project name HQ
Network. Below HQ Network, you create a family tree of major deliverables: LAN,
WAN, server room, workstations, and so on. Then you decompose these major
deliverables into smaller deliverables. Figure 1 provides a view of the
high-level WBS components.

Your WBS should use a code of accounts to number each deliverable in
the WBS. For example, in Figure 1, assume that the HQ Network is project number
427. The WAN section of this project might be 427.1, and the elements under the
WAN deliverables would then be 427.1.1, 427.1.2, and so on. This code of
accounts clarifies for all participants the deliverable that is being
referenced, providing an accurate record for any element the project manager
promises as part of the project completion. You don't have to use a code of
accounts, but it's easy enough to implement—and can save time
downstream.

You need a WBS in order to create the definitive estimate because you and/or
your experts will account for the cost of each deliverable. In some
organizations, that cost can include more than just the materials—it may
take into account labor, consultants, team development, and so on. The point is
that each deliverable in the WBS can have time and costs associated with it.

Depending on the size of your project, you may want or need to create a
WBS dictionary to take advantage of the code of accounts for each of
the WBS elements: defining each element, the party responsible for the element,
time and costs associated with each component, and other notes or relevant
facts.

A WBS dictionary, coupled with the code of accounts, helps to prevent or
resolve miscommunications, provide accurate references, and organize the project
deliverables. Tied to the WBS dictionary are time, costs, and relevant info on
each deliverable. Now you and Larry from Accounting can be best friends forever.
You can move to any deliverable in the project and give an accurate estimate of
what each thing will cost to implement.

A definitive estimate takes lots of time to create, but it's the most
accurate estimate you can provide. You may know this as a bottom-up estimate
because you start from zero (the bottom) and account for each freakin'
thing the project will purchase, create, or deliver. The range of variance on a
definitive estimate is relatively low: –5% to +10%. This makes sense
because it's much easier to predict how much something will cost when you
can see everything the project will create. How many projects have you been
involved in where you can see everything the project will create from the
get-go? Probably not too many, or only projects that you've completed
repeatedly and therefore know exactly what's expected. For example, an IT
integrator may have a project template that defines all of the work to implement
a prepackaged solution in any environment.

While definitive estimates are ideal for accuracy, they're not easy to
create because so much effort has to go into the project before the project
manager can create the definitive estimate. This requires education not just for
you as project manager, but for your stakeholders, who need to understand that
the only way a precise estimate can be created is to invest time in the project
itself, by creating the WBS.

With any type of estimate, the project manager must provide the range of
variance and an explanation of how the estimate was created. Without these
explanations, the customer is led to believe that the price you've
quoted—the price you've "promised"—is the final price
that the customer will see. And should the price tag change, there'll be
hell to pay.