Cost and financial management is an important factor in controlling projects. In this article John McManus advises on activities associated with project cost and financial control.
The time and cost imperative underpins all project activities. Understanding the interrelationship of the measurement of the risk/reward relationship is vital for project managers if they are to deliver successful projects to time and budget.
Important topics to consider include:
All projects carry inherent cost and financial risk and these risks have to be managed preferably from the inception of the business case (that underpins the project).
For many project managers managing budgets along the critical path becomes both a challenge and a source of frustration. For example, many business cases are premised on cost estimates of work to be done and are rarely corrected for accuracy (although project management methodologies such as PRINCE2 advocate stage (or phase) assessments.
Awareness is crucial; historically, research points out we are notoriously bad at estimating. If you estimate a task will take 10 days.
Identify how confident you are that you can deliver in 10 days by using percentages. For example, I'm only 50% certain I can deliver in 10 days. In practice you should aim for 80%. If you do not achieve 80% then re-calculate or seek advice.
In software development projects labour costs can be as much as 70 per cent of the total budget costs so errors in estimating labour costs have a compound effect and are often a major causal factor in failed projects.
Producing good estimates is very reliant on domain knowledge and processes that are proven to be repeatable and well managed. A good estimate consists of a description of the projects scope - work breakdown structure, (WBS) - the estimation technique used and the accuracy of the estimate.
The project size, cost and schedule estimation process should be premised on the requirements - traditional size estimates in software engineering projects come from using function point methods or equivalent source lines of codes.
Associated effort is usually calculated in person-hours which can be translated into cost by using applicable labour rates.
Effort, cost and schedule are all interrelated and a change in one will affect the other two. In my experience a compressed schedule usually results in a higher effort and costs.
Although I personally favour a tool such as MS Project, effort, cost and schedule can be calculated manually although this is not recommended for WBS that goes beyond two levels.
Although project tools are useful they are only tools and need to be managed like all other resources.
As a basis for budgeting and resource allocation the WBS helps by defining work packages – it could be argued that the primary function of the WBS is that of an accounting tool for summing up the task related costs for all project activities.
When dealing with project sponsors the WBS takes on significance in that it helps the individual understand how the project is structured and how the money is apportioned to the activities (see Figure 1).
Research shows that less than 10 percent of all projects are delivered to their original cost and schedule estimates. One reason associated with this failure rate lies in the tracking of effort and cost – estimates should be tracked over time comparing planned to actual outcomes.
The key here is to have a consistent means by which to do it and a mechanism for analysing and storing the data. Pitfalls to avoid when converting estimates to cost include:
Figure 1 Measuring and tracking resource allocation
Whilst the use of propriety project management tools can help alleviate some of the mundane administration of managing project costs, the bottom line issue is what costing method to adopt and why.
In my experience setting up costing and financial systems can be a complex activity. The ploy is to keep it simple. Most seasoned project managers will testify to this key principle.
As the project manager you (and possibly your team) will need to identify the full economic costs of each project activity before they apply, and account for these costs, and ensure that such costs can accommodate within your overall budget.
The core processes that support the majority of costing methods (and systems) are direct and indirect cost accrual and variance reporting. The most important principles associated with these processes are:
Although some organisations use in-house accounting methods and standard costing a common choice amongst many project based organisations is the generic method of activity based costing (ABC).
ABC was originally designed as way to improve the allocation of overhead costs in manufacturing settings in order to develop more accurate product costs.
With this approach, overhead and indirect costs are allocated to products based on the degree to which those products actually consume the repetitive production activities of the organisation, rather than being based on a single factor, such as the number of direct labour hours associated with the product.
In more recent times ABC method as found favour with many software firms. In essence, it traces costs to specific activities undertaken by the project, such as preparing a logical design or undertaking systems testing.
The costs of these activities are then attributed to products within the WBS using estimates of usage of these activities by the cost objects (for example testing software components).
Unlike other costing methods, by inserting activities into the costing process, ABC provides the project manager (and the management team) with rich information because it gives a greater level of detail about how and why costs are incurred.
This information can lead directly to specific adjustments or modifications in a projects activity and can be used as a mechanism to streamline costs. The steps in ABC include to:
However it must be pointed out, ABC does not apply to every situation or project. For ABC to apply well, three conditions need to be met. They are:
The first two criteria go to the relative pay-off from ABC that is the pay-off will be highest to the extent that these two criteria hold. The third criterion is self-evident, in that the whole point of ABC is to use repetitive activities to better account for the costs associated with cost objects.
Taken in isolation, neither the budget nor actual costs are sufficient to show the financial status of a project. What is required is a way of comparing (and combining) the project cost information to the value of work done (VWD).
One method of evaluating the VWD is to use the accounting technique of earned value (EV). EV is particularly useful in monitoring effort on large projects. The EV technique aims to answer questions in relation to the projects business case:
EV can be decomposed to form a cost breakdown structure (CBS) which can be combined with the WBS.
As the project progresses the actual VWD can be plotted alongside the estimates or forecast values (or the cost of work scheduled). In EV terms progress is measured as the budgeted VWD up to a specific calendar date.
One advantage of using EV is in decision making. It is easier to make small rather than large changes to the project plan. Therefore, variances from the baseline must be identified quickly – EV helps us recognise such variances and take corrective action (Figure 2).
In calculating earned value, tasks can be considered as either:
Proper management use depends on effective and tailored analysis that is responsive to management needs. Key attributes of effective EV analysis are:
Throughout the project lifecycle senior management will need to set aside regular time periods to review budget and financial information.
Management must be prepared to contribute this time. In my experience this time is never fully factored into the project budget and for complex projects this could represent hundreds of hours. In essence the cost of this time must be budgeted and accounted for within the project.
This is necessary for three reasons:
Without a formal review process, it is easy for projects to go adrift (and for costs to escalate without sanctions). Original project objectives are turned into a moving target - the project is challenged and may never achieve its original business case.
The financial review process will mitigate the risk of the project overspending and ensure that the project is kept focused and on target. Such financial and budgetary information may include:
At the end of the project, the project manager has an obligation to ensure that all costs are correctly accrued and accounted for in accordance with the procedures of the firm. This includes ensuring that a financial balance sheet is produced for audit and signature.
Documentation should be made available to audit personnel and should include a complete oversight of any adjustments or changes that have been agreed during the projects lifecycle.
Monthly, quarterly, or semi-annually.
Monthly recommended for development or high risk projects
Budgeted time-phased baseline costs to end of program. This format shows significant baseline changes authorized during the reporting period. Data includes estimate at completion, contract budget base, total allocated baseline and completion dates.
Use and format
Used to determine if Over Target Baseline or Over Target Schedule has been incorporated into the programme. Data can be plotted to determine trends or if there has been a shift in the baseline. Analysis can focus on the distribution of cost for authorized changes to the baseline during the period.
Monthly or weekly basis as provided in business case
Report WBS element performance data (for the current reporting month as well as cumulative to date data. Cost and schedule variance are calculated and reported. Identifies any reprogramming adjustment, budget at completion, estimate
Use and format
Isolate key cost and schedule variances, quantify the impact, analyze and project future performance. Performance issues isolated at lowest level and analyzed for impact to overall cost and schedule variances
This article was written in June 2006 by John McManus. He is Rushmore Professor in Management Sciences and Senior Research Fellow at the University of Lincoln. Dr McManus is a specialist in systems integration and project risk management.