Project Cost Management
By Joseph Phillips | minute read
I'm not a huge fan of country music, but Lyle Lovett is one of my favourites. 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 organisation 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 labour have funds attached to them; someone, somewhere is paying for that labour. 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 honour 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 maths 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 organisation'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.
Your WBS should use a code of accounts to number each deliverable in the WBS. For example, 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 organisations, that cost can include more than just the materials, it may take into account labour, 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 organise 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 word 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.
Got Your Mind on Your Money?
As the project moves toward completion, there will likely be a need to revise the project's price. If the project started with a ROM estimate, the original estimate could be wildly wrong. The customer who reads the ROM estimate should know that the final cost is likely to be much different from that estimate. No doubt the customer will be anxious to hear your more accurate definitive estimate.
Of course, from ROM to definitive, estimates can be just plain wrong. It's not fun to have to approach your sponsor, stakeholders, or customer with hat in hand and beg, plead, scrounge for more cash because your project estimate was way, way off. Poor planning is the major cause of poor estimates. Rushed estimates, bloated estimates, or estimates that are "low-balled" just to get the project moving are bound for budget reviews, unpleasant conversations, and project reassessments.
Sometimes, thankfully, it's not the project manager's fault when the estimate must change: The cost of materials has changed, the anticipated time to complete the project work was wrong, or the bases for decisions were faulty. In these instances, the project manager still has to communicate the variances, which isn't fun, but it's easier than taking the blame when that blame is all yours.
Poor estimates can also be the fault of the customer, stakeholders, or even the project sponsor. When the stakeholder is responsible, the increase in cost is usually tied to a change request. Contrary to public opinion, change requests are not good things. Ideally, when the customer and the project sponsor sign off on the scope statement, no changes should ever be made to that scope. Of course, errors and omissions, technological enhancements, and value-added changes all affect the scope's resistance to change.
If the customer demands new deliverables in the project scope, however, a price tag is usually associated with those demands. The monies needed to implement the change have to come from somewhere, and not your wallet. Even changes that replace current scope components may have a price; time and monies may already have been invested in these deliverables. In my opinion, change after the scope statement is a bad, bad thing.
We'll talk more about change management in a future article. For now, know this: When the project scope changes, the budget usually has to change as well. Changes generally cost something, and that means a budget increase.
IT and Project Cost Control
Do you ever feel like you're playing on the budget dartboard? The vendor's cost has increased. The historical information is flawed. Time estimates are incorrect. The project team is spread too thin. The bribe was lower than expected. Excuses, excuses, right?
IT suffers from a universal law: the first-time, first-use penalty. The concept of the first-time, first-use penalty is that it's next to impossible to accurately estimate the cost of something that has never been attempted. IT is so unique, so multifaceted, and has so many fronts that the constant movement of its variables creates a love-hate relationship for any organisation trying to create an IT cost estimate.
Consider any IT project, from replacing hardware to rolling out an entire new system, and I bet you've got a first-time, first-use scenario in there somewhere. Sure, that type of work may have been done before, but not in this project's specific environment. You've got different types of hardware, firmware, software, and don't forget users, banging up against your solutions. All of these factors are often ignored, dismissed, or assumed to be non-issues. Mistake! When it comes to cost and things that can affect cost, the project manager must consider the risk and ramifications of the first-time, first-use penalty. This universal law can spell disaster for any IT project. The longer a project manager goes without at least nodding in the direction of the first-time, first-use penalty, the bigger the pending fall.
Cost and the Project Manager
Project managers are in a tough spot: They're the liaison between the customer and the project team that will complete the customer's project. In most organisations, it's generally easier to get more time than money, and there's usually more concern about how much than how long. Project managers and their stakeholders need to go into any project with a common goal: Identify an affordable scope and a plan of how to achieve it. Too often, and maybe because of the subject matter itself, cost is ignored in project planning. For projects to be successful, someone has to foot the bill, and until the estimate is requested or provided, it's not a mystery, just a constant dread.
Cost management really is like a Lyle Lovett song: It can be painfully sad, honest, and focused on M-O-N-E-Y, without ever really saying that word.
Joseph Phillips is the author of five books on project management and is a PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about project management training, please visit Instructing.com