~ By Joseph Phillips
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:
Would you like more time?We respond,
Thank you, no. I'll take some M-O-N-E-Y.
Would you like to reduce the scope?We answer,
Thank you, no. I'll take some M-O-N-E-Y.
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.
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:
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.
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.
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.
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