原文:Project Cost ManagementBy Joseph Phillips Im 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 youve 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 Im trying to make is that I like Lyle Lovetts music: rhythm and blues, big band, good ol country. In one of Lovetts songs, he croons, Would you like a kiss? She said, Thank you, no. Ill take some M-O-N-E-Y. Project managers are like the girl in Lovetts song: *Management asks, Would you like more time? We respond, Thank you, no. Ill take some M-O-N-E-Y. *Customers offer, Would you like to reduce the scope? We answer, Thank you, no. Ill take some M-O-N-E-Y. *Sponsors demand a speedier schedule. We respond, Thank you, no. Ill 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; didnt 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 dont 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 dont, 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 cant know the final project cost until the project is complete because we cant 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, Thatll 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 were 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 theres a disagreement in price, assumptions, or range variance, its 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 birds-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 shouldnt invest too much time in creating these initial estimates, just as the customer shouldnt place too much confidence in the accuracy of the ROM estimate. Unfortunately for both parties, theres 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 projects initial perceived costs. The Budget Estimate (or top-down estimate) is a bit more accurate. Formulated fairly early in the projects 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 weve 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