When do you really know the cost of a project?
|
So, you know the final cost of the project at the end, right? When everything is accounted for and all the project-related costs are spent. Michael Cavanagh, author of Second Order Project Management (2012, Gower), doesn’t think so. “Although it has been said often that the only time you know the cost and duration of a project is when it has been delivered, in truth, you don’t,” he writes. “Post-delivery costs including fault correction, maintenance, support and disposal are all subject to the vagaries of implementation in the real world and should be addressed and included in the estimation process.” Cavanagh is talking about putting together a comprehensive contract with a third party supplier, but the same holds true even if you are building your project deliverables in house. However, I don’t completely agree. I have to say that I hadn’t considered the cost of fault correction as a project cost. For me, the delivery of the project does not happen at the point that the deliverable is launched. There is a handover to support period, and in that time you would warrant that the products provided are fit for purpose. If the deliverables have been signed off, but a bug is identified six months later, then this is not a project cost. It’s a cost related to potentially a change in the way the product is used, and is part of the product lifecycle costs but not the project lifecycle costs. I do believe that maintenance and support are project costs, at least for Year 1. Typically – and this will depend on your company’s accounting rules – maintenance and support for the first year are included in the project budget. Maintenance and support for Year 2 onwards are business as usual costs. A lot of this is to do with whether you can capitalise maintenance and support fees, and whether your project has an opex budget or not. Check with your finance team if you are unsure on whether you can include maintenance and support in your project budget, and for how long. Disposal costs are also part of the product lifecycle in my opinion. I would never include in a project budget the costs for disposing of an asset my project brings into service. How would I know what it would cost to dispose of in ten years time? Or longer, depending on what it is? However, there may be some products that are decommissioned directly as a result of your project. For example, as part of a project to replace a piece of software with something new, the old software becomes defunct. The cost of decommissioning this is a project cost. The full product lifecycle costs including disposal, servicing and maintenance should be included in the project business case. That document is all about making good business decisions so they decision makers should know exactly what they are signing up to, both now and in the future in terms of recurring costs like maintenance. But what goes into the business case does not automatically go into your project budget. When you budget, do you take into consideration the life-long costs of the project, or just the implementation and set up costs? Do you agree with Cavanagh? |
Project budgeting is all about using your best estimates to work out how much the project is going to cost. But it never costs what you think. Something always gets in the way. There will be an issue, or a schedule overrun, or an addition to scope that makes the original budget estimate different from what the final cost is.IT and the Credit Crunch
|
This video looks at the impacts of the recession on budgets and covers the benefits of home working as well as the green elements of saving money. There's a white paper here (.pdf) with more information. |
