Estimating Project Costs

The first job in estimating the cost of a maintenance or engineering project is to identify the scope of the project. The second step is to identify all the resources (materials, human, etc.) needed to execute it. The third and final task is to estimate the cost of all the required resources, including identifying a contingency plan to allow for the expected level of risk to the project.

So if that’s it, what could go wrong? Read on.

Unintended scope omissions: As mentioned in the previous column ( Magazine, Dec. 2007pg. 26), there can be problems with scope definition with any project. A lack of experience or knowledge could cause some parts of the scope to be overlooked. Not investing sufficient time and resources to the front-end loading (FEL) effort can also result in the scope not being fully defined and properly costed.

In some projects, the linkage between the scope requirements and its benefits may not be fully understood. In the maintenance world, CMMS/EAM (Computerized Maintenance Management System/Enterprise Asset Management) implementation is probably one of the more critical examples.

For example, what amount of quantifiable savings are you likely to achieve in automating your existing maintenance management processes? None, if in your efforts in automating, your processes cannot reduce the head count required after the implementation. So how would you get value from a CMMS/EAM implementation?

The software, like a well-implemented and effectively used accounting and financial management system, can help enable better decisions to be made and to be made more quickly. While that has considerable value, it is not quantifiable.

The software can also be an enabler or catalyst for change to processes that allow the maintenance group to perform its work more effectively (e. g. improved work management). If the expectation is that the benefits of implementation are to be improved work management, but no resources are allocated to train and use planners and schedulers because they were overlooked in the scope, then there is little likelihood of success in achieving that objective. This may help explain some of the statistics on the failure rate of CMMS/EAM system implementations in meeting their objectives.

One other area that is sometimes missed is where the project is developed based upon using in-house resources, and those resources are either not capable or not available. The result may be the use of outside resources and the additional costs that may incur. To maintain the initial project budget, the quality of deliverables or the project scope may become compromised.

Intended scope omissions (“because that is the way we do it!”): Different organizations have different requirements for approving CAPEX (capital expenditure) and OPEX (operating expenditure) budgets. Such approvals can be a problem where a CAPEX project that is proposed and supported by one part of an organization has an impact on the OPEX of another part of the organization.

Projects can often have one-time OPEX impact (e. g. training, spare parts, special tools, etc.). While for financial accounting reasons it is important to properly allocate capital versus operating expenditures, any significant changes to OPEX should be identified, and if necessary approved. If that decision is left out, there’ll be a problem meeting the budget.

Intended scope omissions (“to make the numbers”): I hope you are not the end-user of an implementation with solely a ‘making the numbers’ project focus.

Since there usually is considerable pressure to improve the financial performance of an organization, projects are a way of making significant changes. The result typically is that projects are approved only if the organization believes they will achieve the organization’s targeted payback period or rate of return. To achieve these targets, there may be considerable temptation to either propose projects with higher risk, or to try to claim that potential benefits can be achieved without making the necessary full investment.

If projects are not audited to see if they have met their promised objectives, then there may be little risk to the individual proposing a flawed solution.

An example of this occurred to me several years ago, where a material handling system configuration was proposed that was risky, but the more expensive configuration would not have been able to achieve the required return. Bottom line: The risky configuration that was installed was not workable, and after considerable project delays, rework and effort, the system had to be revised to the more expensive configuration.

A more recent example involves the installation of surplus used robotic equipment without refurbishing it prior to installation. The risk is that it will not achieve the needed output without increasing the maintenance and/or operational cost, until it is refurbished (which is not likely to happen under the original project budget).

Impact on maintenance and engineering

For projects that have an impact on your area, you will need to find some way to provide input and be actively involved in the project proposal process. Otherwise you may find yourself on the outside looking in, and having to deal with whatever is dealt to you.

You should ensure sufficient frontend loading is performed, and all scope items and one-time costs are identified and costed in the project proposal, regardless of whether they are CAPEX or OPEX.

Any potential changes to OPEX budgets resulting from the project should be identified and quantified. Including onetime OPEX costs or changes to OPEX budget information in the capital project will help provide a forum to discuss and approve the changes, as the same people would typically be involved in both CAPEX and OPEX budgets.

Special resources (quantity, skills required, capabilities, etc.) required for the project should be identified in the project proposal, regardless of it being inhouse or outsourced. The use of in-house resources can have a profound impact on the project schedule and budget, depending upon the capabilities and availability of those resources. The impact on the project budget could be significant if outside resources are unexpectedly required (i. e. because of problems with the capabilities or the availability of in-house resources), if the use of in-house resources was used for costing.

Similarly, project assumptions should be identified in the proposal (e. g. ‘There is sufficient capacity in all in-plant utility systems, including electrical, natural gas, compressed air, and process steam., for the new project’.). Assumptions are things that we believe are true, but if they are not actually true, they can have a significant impact on the project.

Identifying assumptions in the project proposal helps to highlight potential issues where you may not have all the information. In the above example, you could research the required information and determine that your proposal will, by itself, not bring any of the utility systems above their operating limit. But when the project is combined with other initiatives, it may exceed the limits of one of the systems.

Len Middleton of Asset Management Solutions of Toronto can be reached at len@asset-management-solutions.com. His next column will be on estimating project benefits.