Real World Project Management: Estimating Your Project Costs
- Got Your Money on Your Mind?
- Got Your Mind on Your Money?
- IT and Project Cost Control
- Cost and the Project Manager
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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."
- Sponsors demand a speedier schedule. We respond, "Thank you, no. I'll take some M-O-N-E-Y."
Get the point?
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.
Figure 1 High-level WBS components for the HQ Network.
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.