Not a Penny More— Budget-Constrained Planning
We don’t own the budget, but we are expected to develop it.
Our estimates become the budget for the project.
The budget is pre-set by the client—we just work to it.
We have a target budget, but the client always seems able to find additional money.
We only worry about capital expenditure and external resources; we don’t budget for internal resources.
We don’t use budgets!
These are a selection of remarks made to us when discussing planning with project managers. None is particularly healthy, displaying a lack of understanding of the purpose and role of a budget in a project by the project manager, the sponsor, and sometimes by both.
In this chapter, we examine why this might be, how to fix it, and when it is vital to know whether the constraint at the top of the hierarchy is money.
Setting the Budget
It has always amused us when business cases set out the costs down to the nearest cent with the benefits rounded to the nearest hundred thousand dollars. This specious accuracy in presenting costs belies the truth. Often there is as much uncertainty about what will be spent, as in the forecast value of the benefits.
A glance at the findings from just one industry, Rail, hammers this point home. Flyvbjerg et al. (2003) investigated the cost-benefit analyses of many road and rail projects: the message is unequivocal, don’t trust them! As they scathingly advise decision makers:
Take with a grain of salt any traffic forecast that does not explicitly take into account the risk of being very wrong. For rail passenger forecasts and especially for urban rail, a grain of salt may not be enough.
Table 4.1 Forecast and actual traffic in the first year
Project |
Actual traffic/predicted traffic (%) |
Calcutta Metro, India |
5 |
Miami Metro, USA |
15 |
Channel Tunnel, UK, France |
18 |
Paris Nord TGV line, France |
25 |
Humber Bridge, UK |
25 |
Tyne and Wear Metro, UK |
50 |
Mexico City Metro |
50 |
Denver International airport, USA |
55 |
Table 4.1 shows the level of accuracy achieved when forecasting benefits (they would say footfall or traffic) from completing the project. The percentages give you some idea, but when you remember that the predicted numbers were in hundreds of thousands, if not millions, it is a huge ‘miss.’
Table 4.2, is drawn from the same source, and clearly shows that whatever else was driving these road and railway projects; cost was not one of them. Never mind what the political-posturing and public statements said at the time. It is also clear that the planning regimes adopted did not base their decisions and actions on cost-based considerations. Project success was not determined by meeting the cost constraint.
Table 4.2 Rail construction overruns
Project |
Cost overrun (%) |
Boston’s artery/tunnel project, USA |
196 |
Humber Bridge, UK |
175 |
Boston-Washington-New York rail, USA |
130 |
Great Belt rail tunnel, Denmark |
110 |
Joetsu Shinkansen rail line, Japan |
100 |
Washington Metro, USA |
85 |
Channel Tunnel, UK, France |
80 |
Karlsruhe-Bretten light rail, Germany |
80 |
Mexico City Metro line |
60 |
Tyne and Wear Metro, UK |
55 |
Great Belt link, Denmark’s |
54 |
The first story in this chapter is, in our experience, relatively unusual as the budget was tightly linked to the return to be expected from the project, and was varied as the expected returns were revalued, in many cases downwards!
In a significant Digital Delivery Program (DDP) run by a large finance company the basis of the investment—the allocated spend for the project—was to be determined by what could be agreed as the bankable forecast income over a five-year period. A hurdle rate for the return was set. The only thing that now needed to be done was work out what the cumulative value of the income stream would be, and the project budget would be known.
The approach taken was to set a target value—say $700m—for the total new income and then link this value to changes of buying behaviors of the target population. This, in turn, was related to new digital products, portals, and services.
Figures 4.1 and 4.2 illustrate the mapping process. The example chosen is not from the digital project (DPP) as the results of the detailed research done by that project are still confidential, but the general approach is hopefully clear.
In Figure 4.1, the benefit (in this case ‘Cost Avoidance’) is identified as arising from five impacts or ‘significant points of difference’ in the operations of this retail chain. The detail below the benefit and each impact show the key performance indicator (KPI), the profile of the predicted value with time, and the period over which the value will be returned. The strict rule is that unless the impacts and benefits are measurable, they are disallowed!
Figure 4.2 shows one of the impacts being mapped through sub-impacts (and sometimes through sub-sub-impacts, and so on) back to the source of the change, which is usually, as in this case, an output from a project. The impacts are changes in the behavior of people and processes that give rise to the differences in operation. These also have their KPIs and profile.
In this way, there is a chain—a series of links—that can be checked, challenged, and chased. By insisting on having a measure and a target value, and demanding a profile of how and when the change is recognized, the planning gets ‘real’ for everyone, and arm-waving and vagueness plays a much-reduced role in the specifying of the expected value for a project.
Inevitably, it means that to back up analyses like this you need real data. You also need a commitment from stakeholders that given that the information is valid, they can and will deliver the predicted changes in behaviors. For the DPP it turned out that a surprisingly large number of factors needed to be enumerated and validated. These included the size of the target population, the proportion of that population with smartphones, the numbers of individuals who buy insurance products, and so on and so on.
In total, 158 parameters—or factors—had to have values associated with them to allow the modeling of the future income to be carried out. Some could be and were researched. Others were harder to determine. These were treated more circumspectly, their less certain values highlighted and their source of validity assigned to one or more of the stakeholders. In this way, the modeling was more transparent, and the stakeholders more involved. It was now their skin in the game.
One of the effects of developing the impact and benefit profiles is that operational managers can visualize how the predicted changes will be realized. It turns out there are only four profiles, with other curves being combinations of them—see Figure 4.3. The ‘whoosh’ one is universally liked! It means the impact is immediate, obvious, and sustained. The ‘slow-onset’ is the commonest profile when profiling IT implementations, with a gradual adoption, a critical mass is reached, and then most everybody else on-boarding after that. The ‘incremental’ or ‘steady Eddy’ model is unexciting but valuable as the change progresses, and value is returned, in a possibly slow, but predictable way. The last one, the ‘transient’ is trouble. Something happens and there is a positive response, but it fades away, energy is lost, and the gains made disappear. Transients can be useful when looking for ‘quick wins,’ ways of engaging stakeholders, team, and others, but ultimately they return little of value.
As the planning proceeded in the DPP, it became evident that the overall target was too ambitious—the level of benefit-risk was too high to be borne by the stakeholders. And, equally unattractive to many stakeholders; that the contribution made to the income from products and services that had previously not been sold by the company would be more important than had been thought. This needed to be factored into the planning and sequencing of delivery, and the profile of expenditure, because new products carry more risk when predicting future sales than established ones.
What senior management made very clear to the sponsor and project manager was that moving to a digital platform was a commercial rather than a strategic decision. Either the project ‘washed its face’ and came out clean, or it would be stopped. Coming up clean meant that the project remained financially viable, making an acceptable return on the investment.
So the budget for the project (program actually) was set and, as importantly, the governance process by which it could and would be altered, decided. This is an excellent example of where the cost was a genuine top-level constraint, but the amount changed in-flight. This has a much more benign impact on a project than when the type of constraint is changed. In this circumstance, the success criteria haven’t changed, just the boundary value.
So why is setting a cost constraint that flexes with the expected return so uncommon? One reason, as is so starkly shown by Tables 4.1 and 4.2 from Flyvbjerg (2003), is that so many business cases—and particularly the benefit cases—are barely worth the paper they are written on.
They often seem to be used to justify a decision already taken rather than as a decision making criterion. Perhaps, more constructively, it may be that it just proves too challenging to get reliable data, or the real value of the return is inadequately captured in purely financial terms.
Another possible reason we encounter frequently is that the concept of value (the price you are willing to pay) gets confused with cost (how much you have to pay). The two are related, but it is a mistake to substitute one for the other.
When It Is the Amount of Money that Matters
The project manager who said, “We have a target budget, but the client always seems able to find additional money” is relating an experience many project managers have had. The reality is that, despite all the rhetoric, budgets are often not the constraint—more an aspiration—certainly in government and the larger corporations. Nevertheless, there are some projects, and some environments, where this is most definitely not the case. There are projects where the absolute amount in the budget is a hard ceiling, and the project manager had better know how to deal with it.
The project manager who shared the following story had worked for many years as a program manager running high-spending projects for a large multi-national defense group. When he retired, he was asked to manage a UK lottery-funded project. It was here, for the first time, that he faced the reality of planning a project where the challenge of cost control was as complex as delivering the outputs. How do you plan and execute a project when working within a rigidly defined budget constraint?
The St Edburg’s church conservation work in Oxfordshire UK was a project to restore the Grade 1 listed building, parts of which date back 900 years, and was funded by the Heritage Lottery Fund.
The tender process is tightly controlled. A detailed cash flow projection for the project has to be produced, and there are specific criteria as to who can be involved in the budgetary process. For example, the chosen architect must be on the UK conservation register. Where the amounts come from must be documented, and must ‘make sense,’ and often give rise to complicated financial modeling.
As is standard practice among architects, the project architect’s fees were based upon a percentage of the final build price. When forecasting within such a constrained budget, considerations such as ‘should you calculate the architect’s fees before or after contingency is added to the tender price?’ can make the difference between a successful bid—and project failure.
The project went out to tender for the conservation work, knowing what their maximum spend could be. The architect managed the tricky business of advising the construction groups about the budget cap, without actually giving the target figure away. Even so, some of the responses came in at more than double the value of the funding from the Heritage Lottery Fund. Pricing variation like this, occurring in such specialized and tightly specified work, typically means that competition for the right resources is very keen. It is one of the reasons why small pieces of conservation work, such as at St Edburg’s, struggle.
The big budget items for the project were the construction fees, the architect’s fees, and contingency and management reserve.
Contingency reserves are the estimated costs, which are allocated for identified risks. They are associated with the known-unknowns. The contingency reserve may be a percentage or a fixed cost. They may be aggregated. As more information becomes available, the contingency reserve may be used, reduced, or eliminated. Management reserves are a specified amount of the project budget withheld for management control purposes and are reserved for unforeseen work. In construction, this figure is often a percentage of the total. Management reserves are intended to address the unknown-unknowns. |
On small-budget projects such as St Edburg’s, management reserves and contingency are often combined into one figure—in this case; it was set at 10 percent of total fees. There are some technical issues with this approach. For example, contingency is usually managed at the work package level. With a work package completed, any remaining funds should be released—either transferred to the management reserve or removed from the budget. This allows for greater accuracy in the monitoring of costs and cost risk. And there is another problem. Without proper evaluation of the known risk factors, how can you know that 10 percent is enough?
The project manager knew that getting the budget through the Heritage Lottery Funding process was going to be difficult. The supplier they had chosen was right at the top end of their price range, and if too much of the risk money were used, the budget would be exceeded. The request for funding would not be approved if it was even a penny over the target figure. This meant engaging with all the funding and resource groups to come up with an agreed approach:
This last point is significant. Grant money is released in three stages, with 50 percent upfront, 40 percent once the first half is completed, and a final 10 percent when all the work has been completed. As the project manager said: “It is very unwise to dismantle anything without being sure that the funds are available for completion, as there is no guarantee that follow-up funding will be made available.”
The St Edburg’s church restoration project was a success. Not because it did all of the things that had been envisaged in the original scope, but because what was delivered was tightly controlled against what could be afforded. At all times, the stakeholders were kept informed of what could be delivered and how. The focus on budget flavored every decision made by the project manager. “Each time I was asked about doing something better, or different, I had to weigh it against what I knew was left in the budget and what other risks I might need to allow for.”
The transparency around the budgetary process affected the behaviors and attitudes of the contractors and stakeholders. For example, the building contractor looked for ways to optimize the utilization of resources. “If we could work on two aspects on the project in parallel I can use some of my free resource time.” The stakeholders (the church) recognized the need on some occasions to relax less important constraints: “We will use a different church entrance just for this Sunday so that the project can exploit opportunities for cost containment.”
The project exemplifies the impact of an explicit cost constraint: ‘not a penny more!’ Every aspect of the planning and monitoring—and the decision making processes—were infused with the boundary condition set by the fact that there was no more money. Much like a haiku poem with its rigid limitation on the number of syllables, the immovable constraint led to innovative ways of achieving an outcome, not innovative ways of creating the outputs—that would be far too risky. The learning from this type of project is that constraints do not act to hinder you from achieving your objective, they work to shape the ways you go about achieving it. This case was originally published in the APM’s Project magazine (Worsley 2018).
In the case of cost constraints, the planning must enhance and simplify how to monitor expenditure on a day-by-day basis. The reporting must allow stakeholders to access the status of the project—how far away from the end-state the project is—so that they can engage in meaningful actions to support the success of the project, bringing it in within budget.
The Impact on the Planning Process
The two cases discussed earlier are examples of cost-constrained initiatives. In the DPP, what they are prepared to pay is set by what the financial return from the project is worth to the company. Spend beyond that, and the project is a failure. In St Edburg’s, the constraint is set externally and is immovable. Where the top most constraint is cost, the planning steps tightly iterate between the products, the processes, and the cost of the resources. The answer lies in circumscribing the scope—the set of products—that can be delivered within the constraint—the budget. This modifies the CPPRRSS model as shown in Figure 4.4.
Risk management will be mainly focused on events that might affect the budget. For DPP, benefit-risk and cost-risks had to be weighed together: “How do we make sure the target population can access the finance products without high-cost advertising or setting up help centers?”
For St Edburg’s the risks were about rework and unanticipated repairs creating unplanned cost: “Will we find that the footings need fixing when we take the wall down?”
The decisions and actions taken are conditioned by the impact on the remaining budget and different levels of reserves available. They are not necessarily the best possible decision or action, but the best allowed by the constraint.
Developing the Budget-Planning in Uncertainty
Absolute cost-constrained projects such as St Edburg’s are relatively rare in commercial environments. Much more common is the situation where a budgetary constraint is applied too early in the project lifecycle creating nugatory planning actions and generating unnecessary governance interventions as the costs escalate. Many project managers feel this pressure, observing, “If we mention a price or a date, then that immediately becomes the budget and the end-date.” In project language, the governance group was converting single figure estimates into constraints.
Given a single figure as an estimate, the best a sponsor or stakeholder can do is say it is “too high,” or maybe “sounds about right,” or “I’ll go with that.” All pretty unhelpful responses. Consider the difference when the stakeholder is presented with an estimate as a range. The conversation goes more like this. Project manager: “The costs lie between $15,000 and $20,000, and I think, given what we currently know, it is likely to be nearer $20,000.” Stakeholders: “Why such a big range?,” “Why are you not more certain?,” “How can I agree to that? What do we need to know before committing?”
This is a much healthier, much more constructive interaction. There is even a chance that the stakeholders will become engaged in the process.
The appropriate result of a conversation about cost-estimates between the sponsor and the project manager is an understanding about the significance of the difference between the project manager’s cost estimate and the sponsor’s budgetary limit (cost constraint). A good estimate must:
…while setting a constraint is merely a condition for the success of the project.
Presenting Uncertainty
So how can you avoid the trap set where the stakeholder won’t engage and insists on a single value estimate, which they will then hang you by?
This was the situation at Philby. Philby is a company supplying the construction industry with materials. It has a headquarters and some small offices/outlets around the country. Their practice when investing in internal IT projects was to set up fixed price contracts with suppliers, with severe penalty clauses for cost overruns and for failure to deliver the required outcomes. Suppliers were made aware of these conditions during the tendering process.
A Board-level decision was taken to upgrade the hardware and software platforms used by all management and administration staff in the company. The business case specifically recognized that the value from this investment would only be gained if all the managers and staff were made competent in the use of the new capabilities of the kit. This meant that the project would need to be responsible for the training too.
When estimating for planning purposes, the fundamental concern is to ensure that the inherent uncertainty due to the relative uniqueness of the product or the approach is understood and addressed. In this project, as with most projects, during the early stages, there was little detailed information on what the outputs would be, how many there would be, and in some cases how they would be created. In this situation, ranged estimates are necessary to reflect the levels of uncertainty. As time passed more knowledge was gained, the ranges were revised, becoming narrower, indicating higher confidence levels.
Table 4.3 shows an extract of an estimate from one of the bidders for the implementation of Philby’s new IT infrastructure. It does use a ranged approach based upon a two-point cost estimate: optimistic (low) and pessimistic (high).
Table 4.3 An estimation table
Number required |
Unit cost |
Totals |
||||
Products |
Low |
High |
Low |
High |
Low |
High |
Licensing costs |
2,400 |
2,400 |
$50 |
$50 |
$120,000 |
$120,000 |
Hardware upgrades |
400 |
550 |
$1,200 |
$1,200 |
$480,000 |
$660,000 |
Dept. servers |
5 |
7 |
$1,600 |
$4,000 |
$8,000 |
$28,000 |
Training-operators |
5 |
7 |
$400 |
$800 |
$2,000 |
$5,600 |
Training-staff |
2,000 |
2,400 |
$300 |
$1,000 |
$600,000 |
$2,400,000 |
$1,210,000 |
$3,213,600 |
Having a range is good, but the table is a confusing array of numerical data. Some may like it, but most managers would skip read it. Our project managers tell us that when presented with tables like this, many senior managers/sponsors move straight to the bottom line and ask, “Well, what is it, $1.2M or $3.2M?” (Sponsors usually round down!). The lack of precision (they want a single figure) is seen as poor management (poor estimating ability) on the part of the project manager. So less experienced project managers hide the uncertainty—because they confuse it with their own uncertainty—and the spiral into obfuscation and poor budgetary practices has begun.
If you focus on the last two columns, the meat of the table is there in a clear and emphatic way. There is no uncertainty about licensing costs, and apart from ‘Training-staff’ the variances are numerically driven, that is the value is dependent on the number of components affected and so are, in essence, controllable and contained. The ‘big ticket’ item, ‘Training-staff’ is different. We have no idea, nor any evidence as to how to control this cost. So, perhaps a sensible option here is to buy a little knowledge, maybe run an investigation.
A problem with two-point estimates is that it encourages an approach that has been heavily criticized, but which, nevertheless, remains common, and that is to take an average and use that as the constraint value. What are the implications for taking a mid-point as the ‘planned value’ (PV)? Have a look at Figure 4.5. Even if the estimate—the range—follows a normal distribution, which is unlikely (most estimates have a skewed distribution), taking the midpoint, the ‘most likely’ (ML) value, means that 50 percent of the time the project will come in above that budget figure. Does the project manager or the sponsor really want only a one in two chance of coming in on or under budget? Sounds like a poor bet if your reputation is riding on it.
The situation is even worse, of course, if the distribution is skewed as the ‘most likely’ point (ML) in this circumstance is often a lot less than 50 percent of the total possible values. When the distribution is skewed, the mode and the mean do not lie neatly together.
Barry Boehm (1981) in his early work on software cost estimation presented the case against taking the midpoint and argued for a third value—the planning value upon which to base your plan. He used this to develop his cone of uncertainty model (Figure 4.6), with the ‘cost at completion’ being the planning value.
The cone of uncertainty describes the reduction of the amount of uncertainty during the life of a project and reflects what every experienced project manager knows intuitively. The later you wait to confirm the budgetary figure the more likely you are to be right. In fact, unlike risk where there are five risk strategies, to manage budget uncertainty there are only three: buy information, make assumptions, or wait.
Boehm suggests that it is perfectly reasonable for a range of uncertainty to be as wide as +400 percent and –25 percent during the early stages of a project. (Most project managers are not that brave.) The asymmetry is explained by an effect called estimating-optimism bias. As commented by Steve McConnell (2006) in his comprehensive book on Software Estimation:
Considering that optimism is a near-universal fact of human nature, software estimates are somewhat undermined by what I think of as a Collusion of Optimists. Developers present estimates that are optimistic. Executives like them because they imply that desirable business targets are achievable. Managers like them because they show support for upper managements’ objectives. And so the software project is off and running with no one ever taking a critical look at whether the estimates were well founded.
Let’s get back to Philby’s project. Another supplier had a highly experienced project manager respond to the tender. She was aware of the procurement rules and the sensitivity of the company to cost overruns. She realized that by including the training, Philby’s had turned the engagement from a simple, low-risk rollout, to a more complex project. She also understood that she needed to engage the stakeholders in the right conversation—one that focused on the essential drivers of uncertainty. So, she developed the estimation table shown in Table 4.4.
Table 4.4 Presenting an estimate and the sources of uncertainty
Products |
Totals |
% variance line item |
% variance budget |
Uncertainty source |
|
Low |
High |
||||
Licensing costs |
$120,000 |
$120,000 |
0% |
0% |
None: fixed price |
Hardware upgrades |
$480,000 |
$660,000 |
38% |
5% |
Number of upgrades needed uncertain |
Dept. servers |
$8,000 |
$28,000 |
250% |
1% |
No agreement from Depts. on server upgrades |
Training-operators |
$2,000 |
$5,600 |
80% |
0% |
Unsure of the amount of training time |
Training-staff |
$600,000 |
$2,400,000 |
317% |
57% |
No agreement on training approach or how long it will take |
$1,210,000 |
$3,213,600 |
Firstly, her presentation was much less ‘noisy.’ She had only displayed the information the stakeholders needed to help focus their thinking. The table showed the sources and significance of the uncertainty in the estimation of costs for the project. The first thing to notice is that not all of the costs listed are estimates. For example, ‘Licensing costs’ are a fixed price and are entirely certain. This is important as it affects how the management reserve—how unknown-unknowns are dealt with. If the costing model is a mixture of fixed-price items and estimates, is it appropriate to apply a contingency charge to the whole amount? Should you not perhaps exclude the fixed-price items?
The real value of this table was of course that with the sources of uncertainty highlighted she could now have a genuine debate:
The most ingenious device she used was the ‘% variance budget column.’ No manager could overlook the fact that there was little point worrying about anything else if the ‘Training-staff’ issue was not resolved.
Her company’s bid won the contract—and no penalties were incurred. It was planned using the CPPRRSS model with the products (outputs) estimated in terms of numbers and size in narrowly defined ranges and costed processes tightly associated with each output, including the training approach.
She used one other important planning approach. One that is particularly sensible when cost is the primary constraint. With her need to stay within budget, and knowing the importance of the effectiveness of the training to the project success, the project manager knew this was not the time to adopt innovative solutions. Neither she, nor Philby’s, or indeed anyone she knew had previous experience of eLearning. She decided she would leave that as an opportunity for someone else on another project!
Drawing Upon Past Data
A few years back one of our MSc students focused her dissertation on the use of lessons learned in the planning of projects. She was working in the retail sector, and her initial findings were promising. In the presence of a strong central project office, almost 98 percent of projects, over a three-year period, had a documented lessons learned report approved and filed by the relevant governance group. However, then the research faltered. There was incontrovertible evidence that these reports had never been accessed by subsequent projects. Even the evidence of informal communication of learning from previous projects was at best circumstantial, more dependent upon the personalities involved than the process adopted.
The results were discussed with the project office manager, who was understandably disappointed. The actions they took as a consequence of this study are still in place today and are now an integral element of every project planned there. When the motivation for a project is presented, it must demonstrate that it can answer this question: “What previous or currently running project is this project similar to?” The project motivation documentation must show evidence that the experience gained by these projects, and any associated learning, has been taken into account. The critical questions from a budget perspective are:
The project manager when developing the plan and costing for the Philby’s project had drawn up a table in support of her estimates (Table 4.5). This highlighted the extent of previous experience of carrying out this type of activity in Philby’s and similar organizations. It makes clear to the steering group why the eLearning option estimating value correctly has such a wide range.
Table 4.5 Identifying the impact of previous experience on estimating
Products |
Totals |
Experience |
|
Low |
High |
||
1. Licensing costs |
$120,000 |
$120,000 |
Strategic supplier |
2. Hardware upgrades |
$480,000 |
$660,000 |
Twice in last 5 years |
3. Dept. servers |
$8,000 |
$28,000 |
Twice in last 5 years |
4. Training–operators |
$2,000 |
$5,600 |
Twice in last 5 years |
5. Training–staff |
$600,000 |
$2,400,000 |
Face-to-face training twice in the last five years Never set up online training before |
$1,210,000 |
$3,213,600 |
So how did she go about developing the total budget? A budget is not a number. It is a set of ‘line items,’ each associated with a cost. When developing the budget, particularly during the early stages when the level of uncertainty is high, it can be helpful to use a budget cube that integrates three perspectives:
Figure 4.7 shows the budget cube. To use it, you consider a ‘slice’ at a time, either horizontally or vertically and then stack them together. Its value comes from taking these different perspectives, which allows you to cross-validate, to pick up omissions and double counting that a single view might give rise to. It is also progressive in that if you are stalled looking at it one way, approaching from a different tack can unlock your thinking. All good planning tools should allow progress even when there is a lot of missing data.
When specific resource requirements are unclear, the categories of cost probably won’t be. Knowledge of the products to be produced suggests the types of resources, and the types of resources suggest the processes and therefore the categories of cost: labor, management, services, and so on, to consider, and so round we go.
Each perspective gives a different analysis, and each reveals different factors to be taken into consideration in the final budget. Many of the questions require consultation with stakeholders and policymakers; a project manager working alone cannot answer them. For example:
As an illustration of the use of the budget cube, let’s look at the figures from Philby’s project. In Figure 4.8, the initial position shows that the three perspectives give different totals. Which, if any, is correct? By allocating the money by using the combined views of sources of resource and costs, products and costs; and products and sources of resource, a clear picture emerges of what is giving rise to the cost, where omissions have been made, and thus how complete the budget analysis is.
Budgets for Control Versus Budgets for Planning
Table 4.6 shows the impact of various incentivization types on contractual behavior, specifically how often the project delivered within the budget. It supports the view that where a fixed-price or target-cost budget is agreed with a supplier, projects are less likely to overrun in terms of cost. When the incentivization is based on outcomes or activities (final-outcome and cost-plus-fees), the chance of coming in on budget is severely diminished—with around 80 percent of contracts examined being over budget.
Table 4.6 Impact of incentivization on budget performance
Fixed-price |
Target-cost |
Payment based on final-outcome |
Cost-plus-fee |
|
Under budget |
35% |
30% |
8% |
9% |
On budget |
35% |
24% |
17% |
9% |
Over budget |
30% |
46% |
75% |
82% |
Source: Meng and Gallagher (2012).
It’s no surprise that in contractual situations the budget is acting both as an agreement and as a way of setting the supplier goals. What is less certain is whether using this device to motivate project managers is as appropriate. When investigating how end-dates were set on projects (see ‘What do we mean by end-date?’ in Chapter 2) we found that artificially imposing a constraint rarely achieved its purpose, especially when issues remained unresolved, and often led to more stress and anxiety rather than improved performance within the project.
This effect of applying a constraint as a motivator has been analyzed on a number of occasions in the case of setting budgets. Two identical projects run by different project managers were set up, one with a budget of $1,000 and the other at $750. When completed, the actual expenditure was as shown in Table 4.7.
Table 4.7 Budget setting exercise
Expenses |
||
Budgeted amount |
Actual results |
|
Project 1 |
$1,000 |
$950 |
Project 2 |
$750 |
$850 |
Source: Churchill (1984).
Which is the better result? Project 1 because it delivered under budget? Or perhaps Project 2 because it delivered the same solution as Project 1 but at a lower cost? Or, is this the wrong question?
We ran a survey on a few project managers and asked: “Which of these two budgets would be best to use when seeking funding for the project?” And, “Which budget would you use to bring out the best in the team?” We’re sure you got the answers: to the first question, the answer was a unanimous vote for Project 1. No one wanted to go back and ask for more. The response to the second question wasn’t quite so consistent, but there was a large majority vote for Project 2.
The conclusion to be drawn is that budgets can be used for planning and incentivization, and the best budget for planning may not be the best budget for control. So, it is worthwhile making sure that these two uses do not get confused. We suspect that sponsors do just that. Best practice would be first to understand the planned budget, based upon adequate estimating before you start to get tricky and play around to create a control budget.
How tight you should set this control budget is also an interesting and important question. In some studies, the impact on spending under different regimes has shown that when the budget is regarded as being too tight the net effect is spectacular overspending.
The graph in Figure 4.9 shows the results of this research. When the budget is thought to be fair but tight, cost performance is good; however, when it is regarded as far too tight, cost control is lost. A lesson for many project sponsors to take to heart: and perhaps is why all the effort made in DPP to transparently link the cost cap to the benefit turned out so well.
Reflections
Budgets can be a trial to many project managers; so much admin, and so many hours of tedious work. But, planning a project without a budget is like driving a car with some of the controls missing: scary and a very uncomfortable ride for the passengers.
Brooks (1995) said it all in his seminal text ‘The Mythical Man Month’:
The budget… is not merely a constraint; the budget is one of the managers’ most useful documents. The existence of the budget forces technical decisions that otherwise would be voided; and, more important, it forces and clarifies policy and decision.
Here are some questions you might like to consider: