CHAPTER 4

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

When Cost Is Set by the Value

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.1 Benefits mapping process—step one

Figure 4.2 Impacts to sub-impacts to products—step two

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.

Figure 4.3 Profiles of benefits and impacts over time

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:

• The construction group would not include a contingency in their bid—this would reduce their total fees, and the ­architect’s fees.
• The church funding would provide a management reserve—this had to be agreed with the Heritage Lottery Fund group, who typically expect the sponsors to use their funds before getting any lottery money.
• A staged commitment to work was drawn up with the contractor, based on a revised scope. The initial tender had been for three work packages: replacing and repairing damaged stone on the tower; repairs to the north porch; and renewing drainage. It was decided to defer the last work package to another project. It was further agreed that the work on the north porch would only be started once it was clear that sufficient funds remained.

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.

Figure 4.4 Planning sequence in a cost-constrained project

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:

• Appropriately reflect the level of uncertainty
• Identify the drivers of uncertainty
• Reflect current experience based on history and trends

…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.

Figure 4.5 Plotting an estimate

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.

Figure 4.6 The cone of uncertainty

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:

1. Software costs: Why this supplier? Are you sure they provide the best deal?
2. Hardware upgrades: Should we spend time establishing the exact number of systems that need upgrading before confirming the ­budget? A simple inventory question.
3. Dept. servers: What can the steering group members do to reduce the uncertainty around participation by recalcitrant departments?
4. Training-operators: Should we dry run the training to find out how much time the training will take?
5. Training staff: What approach is preferred for the training? Who will decide this? Should the project be initiated until this issue is resolved given the centrality of the competency requirement in the business case?

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:

• What was the initial and final budget?
• What factors influenced the final budget figure?
• How is this new project different?

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

Introducing the Budget Cube

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:

• Organizational breakdown structure (OBS): The sources of resource for the project;
• Product breakdown structure (PBS): The set of products to be delivered by the project;
• Cost breakdown structure (CBS): The categories of cost over the project’s life.

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.

Figure 4.7 The budget cube (Adapted from Turner 2014)

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:

• The CBS identifies the need for an allowance for expenses. These costs can be easily missed if a PBS or resource only view is taken. Should these costs be included in the budget?
• The effort costs associated with implementation are higher in the PBS than the OBS. This is a common problem. The PBS assumes a particular effort for each deliverable produced, but there are often opportunities for savings in time and effort achieved through the rationalization of processes.
• The CBS identifies the potential for increased license fees and the possibility of tax being payable. Are these costs ­attributable to the budget for this project?
• The CBS distinguishes between costings for internal staff and contractors. Are only direct costs included or are fully burdened costs to be used?
• In the OBS it is clear that there are other parts of the organization that need to be involved in this project, for ­example procurement and office services. Should their costs be included in the budget?
• The OBS also identifies the time that will be spent by the staff (users) in being trained. Should their time be taken into account in the budget?

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.

Figure 4.8 Constructing the budget for Philby’s IT project

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.

Figure 4.9 Impact over over-tight constraint on overall cost performance

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:

1. If you do not account for all the costs of your project how is control exercised on those items not included? How does that affect your planning and management?
2. What techniques do you use to handle and convey uncertainty when developing, reviewing, or providing estimates? Could the approaches discussed in the Philby’s case be adapted for use in your situation?
3. Have you made use of lessons learned from other projects when planning or discussing your project with stakeholders? Would the deliberate use of comparisons with previous projects help when developing business cases and project plans in your organization?
4. What techniques do you use to develop a project budget? Could the budget cube help when discussing costs with your stakeholders?
5. Do you exercise cost monitoring or cost control? How well would your current approach deal with a tightly cost-constrained project?