Getting Back On Project Budget

Posted on 18th March, by JimYoung in Blog. Comments Off on Getting Back On Project Budget

Part of successful project management is completing our project within the prescribed budget, yet a lot of projects overrun their budgets, particularly the IT variety.  Cost overruns are the additional percentage or dollar amount by which actual costs exceed our estimates, appreciating of course that an exact estimate is an oxymoron.


While this blog item is about getting back on budget when actual expenditure exceeds planned expenditure, clearly it is much better to have an adequate budget in the first instance.  See here for a blog item on estimating and budget preparation.  We then regularly track expenditure against the budget to detect cost variance (that’s the difference between budgeted and actual costs).  We need to detect such variance early, particularly if we wish to solve any over-expenditure easily.  Should cost variance be greater than our project can tolerate or is trending in that direction, we then identify and employ strategies to get back within our budget.  Should these measures fail it might be time to quit the project (although that’s not usually our decision as project managers) and free resources up for other propositions.


Importantly, we need to track costs as they are incurred and keep a running total. This will help us avoid nasty surprises at the end.  It’s always better to know how much things are costing now so we can make timely decisions based on our budget.  Not keeping up with the costs our project is incurring or planning to incur can be the single biggest reason why people are shocked with the excessive expense of the project at completion.  Probably the best way to track and predict project expenditure is by Earned Value Analysis (EVA) where the estimated total cost at completion (EAC) is the project budget divided by the current Cost Performance Index (CPI), all of which I think warrants a separate explanation – perhaps another blog article.

Some things that blow the project budget include poor estimating, unexpected risks that necessitate expensive mitigation measures for which there has been no allowance made in the budget, risks whose financial impact exceeds anticipated contingency allowances, scope creep and variations, rework, unexpected increases in equipment, material and labour costs and so on.  While we should do our best to ensure we have an adequate budget from the start that includes sufficient provision for possible problems, listed below are some strategies we might consider should unacceptable over-expenditure be detected on our project.


1.  Ask for more money.  During project conception the cost of our project may have been under-estimated.  This is typically because the project cost estimate at this early stage is based on limited knowledge about the project and the use of pretty crude top-down order-of-magnitude estimating techniques.  Also, on occasions the cost may have been deliberately held down by overly keen project sponsors in order to show a return on the investment that warrants the project’s approval.  Part of the project manager’s subsequent detailed planning process is to prepare a more accurate bottom-up estimate of cost based on the decomposition of work needed to achieve the required deliverables.  Should this process reveal an inadequate budget, then we project managers have the ammunition to justify our request for a budget increase.  However, in some instances a “competitive” firm fixed price has already been agreed and no budget increase is possible without some reduction in an already tight profit margin.


2.  Reduce project scope.  If the budget is proven to be inadequate, but no further money is forthcoming, we might then suggest that the project scope be reduced accordingly.  The best way to accomplish this is to prioritise and cost the project’s features and functions and progressively remove those of lower priority until we are within our budget.  This process usually requires we liaise with users and other stakeholders concerning the essentiality of project deliverable features and functions.  A useful tool for this purpose is a paired comparisons matrix or multi-attribute grid analysis as it’s sometimes called.  It’s about separating needs from wants.

3.  Check the schedule.  An ambitious project schedule is often an expensive schedule.  The optimum timeframe from a cost perspective may be something considerably longer or shorter than currently proposed.  Thus, reducing or increasing the time allocated for the various tasks that comprise the project may cause a commensurate reduction in their cost.  If an excessive number of people are assigned to a task, their productivity may be limited due to the 6C problems of congestion, co-ordination, control, co-operation, conflict, and communication – as enshrined in Brooks’ Law.


4.  Renegotiate deliverable specifications.  While I mentioned that a reduced project scope might help solve the cost issue, we could also examine the specifications for the final deliverables.  We can curb ultra-perfectionists by removing expensive gold plating and settle for good enough.  In particular, we should ensure specifications have maximum tolerance in dimensions etc where appropriate.  So, where performance would not be adversely affected, we use off‐the‐shelf components to save costs, rather than one‐off specially manufactured items. This may also reduce lead‐times and help ensure future availability.  And where appropriate specify with figures in preference to adjectives and adverbs – that is, be precise and measurable:  Rather than “light” better to state “not more than 10 grams.” Rather than “quickly” better to state “not less than 10 kilometres per hour.”  And where performance would not be adversely affected, to help minimise cost, provide a range rather than a single figure – that is, allow some latitude or tolerance.  Rather than “100 grams” better to state “98 – 102 grams.”  Rather than “50 metres per second” better to state “48 – 52 metres per second.”


5.  Clamp down on variations.  Variations to the project scope or specifications can be expensive, particularly if such changes occur later in the life of our project.  Thus in the interests of minimising costs we need to very careful vet all request for change.  While such requests can be avoided or reduced through having correct and comprehensive initial specifications, some unscrupulous contractors may depend on variations for their profit margin.  We may accept the lowest fixed-priced tender or quote based on a woolly-worded description, only to find that variations then proliferate.

We project managers must obtain financial authority (ie, the extra budget) before variations are approved.  Also, to help minimise the cost of variations we should agree with the contractor in advance the hourly rates and material costs that will apply should extra work be required.  A variation is outside our original project scope and thus an inflated price for this extra work might be charged.  Of course a variation is also outside our current contract, so we are free to get a quote from another contractor for any variation we may wish to make, although not always without some objections and obstacles from our current contractor that may mean further costs through schedule delays and reduced productivity.  In summary, to minimise costs, avoid or minimise expensive variations.


Scope creep is one of the leading causes of project budget overruns.  As unplanned work finds its way into our project, billable hours mount and the project budget can get out of control.  We must carefully manage the scope of our project by creating change orders for work that isn’t covered by the project’s initial requirements.  Change orders authorise additional funding for the project to cover the cost of extra work, and thus keep the project to its new budget.


6.  Avoid rework. 
 Rework has become an endemic feature of construction and IT projects, which invariably lead to time and cost overruns. There is not much that can blow a projects budget in quite the same way as rework. Whatever the reason for the rework, doing the work all over again will invariably cost the same is it did to do it in the first place. Not only that, but it’s guaranteed to drain staff morale.  Reducing the need for rework releases project time and effort for more productive work and lowers the cost of project delivery. Doing the work properly to specifications in the first place and maintaining good communication with the client and other stakeholders can help to avoid this situation, and if we think the client has asked for rework that is not warranted, we should ask them to cover the cost.  Changes initiated by the client and end-user, errors and omissions in contract documentation, and just straight out poor workmanship are the primary causes of rework.  Implementing quality management practices should help prevent such added costs.


7.   Manage contractors and hired equipment.  There is no shame in outsourcing or getting in contractors to assist with the delivery of our project. One problem comes when we don’t have the resources to effectively manage these additional team members.  Because contractors are often charging for every minute they stay on site, if they are not kept busy, kept on track and used efficiently we could end up with a bill for much more than we anticipated.  And also we must select contractors who can effectively and efficiently manage their sub-contractors.  Some projects require we hire equipment for certain aspects of the job, and if this is the case with our project, ensure we are making the most of the equipment hire time by using it efficiently and effectively while we have it. Some companies charge on a “per use” basis, while others charge by the day or the hour.  We project managers need to plan for the arrival of such machinery and ensure we are all set to make the most of its presence to avoid added expense.


8.  Some other things.  Listed here are some other economy measures that might help resolve project over-expenditure:

– Minimise order quantities and/or purchase economical order quantities (EOQ) and also consider carton unit quantities (CUO).
– Sell off excess inventory for an immediate cash injection.
– Avoid stockpiling since inventory can be expensive due to the costs of warehousing, deterioration, shelf life and obsolescence.
– Practice JIT, which means materials arrive just as they’re needed.
– Eliminate unnecessary control measures, meetings, audits and reviews.
– Substitute cheaper processes, labour, materials and equipment.
– Eliminate advances, deposits, wastage, theft and spoilage.
– Have more progress payments from our client and delay our own payments (ie, improve project cashflow).
– Ensure all charges against project are accurate, legitimate and properly authorised.
– Review delegated financial authorities.
– Centralise financial approvals.
– Vet all purchases.  Cancel the gifts.
– Ensure payments are only made for satisfactory completed work.
– Apply retentions – usually some 5% to 10% for the warranty period.
– Provide contractors with cost-saving incentives.

Finally, on rare occasions our project budget may be excessive.  This too is undesirable and should be declared to avoid unnecessary expenditure and thus free up money for other deserving projects.  Also, unused contingency funds should be declared when the project moves beyond the risks for which they were established.  Otherwise – there may be irresponsible spending towards the end of the project – huge project finish gala perhaps!

Comments are closed.


My latest thoughts on Project Management and life.


My big thanks to the coronavirus lockdown that provided me with an undisturbed opportunity to put together this 104 page booklet on Earned Value...

Project Estimating Checklist

Hofstadter’s Law: “It always takes longer than you expect, even when you take into account this law.”

Hofstadter was right....

Earned Value Management Misconceptions and Limitations

Although EVM offers excellent benefits, and is undoubtedly a very clever thing, it’s not perfect. In this final chapter I’ve discussed in detail a...