Delivery of a project is not the only measure of success that has to be met. There are three different but complementary measures of success — and all three must be met for a project to be deemed fully successful. This triangle of success measures can be illustrated as follows:

The Project team’s measures of success relate to the successful delivery of its agreed business outcomes, benefits and value within the time, cost and resource constraints defined.

Too often project managers want to be only measured on ‘on time/budget and to specification’ measures. This is inadequate. Projects don’t exist to just be delivered, they exist to deliver business outcomes that have benefits and value. While some of the business value will be realized after the project has finished, there is always some value that can be realized as part of the project’s activities.

Therefore, ‘on time/budget and to specification’ become the constraint measures on the project, not its measures of success, per se. Success is measured in terms of the project’s delivery of the level of business outcomes specified for the project.

But, even this will not be sufficient to be considered a ‘success’ without the other two sets of measures.

The Business’ measures of success often relate to the project’s impacts on business-as-usual and operational performance. Are the new roles meaningful? Do the staff have a career path? Is the workload too onerous? Was the transition too disjointed and mismanaged causing a loss in productivity?

Business management are concerned with the ongoing delivery of their business processes and outputs. Projects should improve these but can, if their detailed operational requirements are not considered, reduce the business’ ability to deliver. This is what the business is watching for and is wary of.

Therefore, to be considered a ‘success’ in business terms, the project must deliver outcomes that improve operational performance on all dimensions. This is an aspect of project planning that is rarely considered. “What will life be like after this project has been implemented?” It is often useful to develop indicative “days in the life of …” scenarios to focus the project team on the detailed aspects of the “life” they are creating.

The Governance team’s measures of success revolve around the delivery and realization of the project’s value — the reason why the project was commissioned. If the project does not improve the organization in some measurable way, then it is a failure. Realizing the expected business outcomes, benefits and value in full and delivering the expected return on investment is the key governance measures of success.

This entails taking the project’s outcomes and then working with the business to deliver the final business outcomes and all of their associated benefits and value. So the governance team’s measures of success go beyond the project into the post-project timeframe when many of the benefits will be realized or optimised.

Hence ‘the success triangle’ — and the need to meet all three sets of ‘success measures’ for a project to be deemed fully successful. However, when we review most projects only a subset of the project measures of success have usually been defined. This is not good enough — all three measures of success are required.

Do you know all of the components of your three sets of success measures? Go to valuedeliverymanagement.com for our new “Understanding Project Success” Guide.

Every project is a change project. Even the replacement of your IT infrastructure is a change project.

One of the major shifts in thinking the Governance team should bring to a project is that it is a change project. That it is not, say, a systems project with change management helping with the implementation; but a change project with the system’s implementation helping realize the business value.

The Change Planning Framework helps make this change by making change planning simple.

It starts with the ‘desired business outcomes’ — where the organization wants to end up at and after the end of this project. So it starts with the end to be achieved.

Then it looks at the current state — where are we today? What works, what doesn’t, what do we have, what are we missing?

What is not known about the current or future states is identified in the “Clarify” column — what do we need to know, what do we need to find out before we go too far? Do we know how many suppliers will be impacted, what other competitors have done, what history we have on the system? This is an essential step and one that is often neglected as it is not seen as a change activity but then comes up later, delaying subsequent steps.

This Change Planning Framework breaks the change delivery activities into two types — Preparation that gets the change ready for implementation and Migration that actually makes the change within and across the organization. This split allows the range of change activities to be segmented by their impacts and allow project readiness for implementation to be evaluated (“Have we completed all of the preparation activities?”).

The final “Sustain” column locks in the value. Change is not a one-way street. Change that has been made does not automatically stay, you need to put in place activities to ensure the change and associated value is sustained. Without these sustain activities old processes reappear, new staff learn the wrong processes and gradually (and often quite quickly) the value gained seeps away.

This Change Planning Framework can be used to identify the major changes required to achieve the project’s ‘desired business outcomes’, and then re-applied to each change activity to identify the tasks to achieve each activity, and then to each task to identify the steps required to deliver each task. So the framework provides a common way of thinking about and planning for change that all staff can use to determine what needs to be done.

Importantly, it requires every change to have a clear, measurable ‘desired business outcome’ — a very clear end state to be achieved. Too many change activities have vague ‘objectives’ to be achieved and, therefore, cannot be easily measured as successful or not.

We also recommend this Framework is used for risk and issue management. “What is the risk outcome desired? Where are we today? What don’t we know? What do we need to do prepare for the risk? What do we need to do to manage the risk? What do we need to do to sustain the low/no risk situation?

This simple Change Planning Framework allows everyone to easily participate in change planning.

Further information and tools on change management are arriving soon at valuedeliverymanagement.com

When seeking to improve their project delivery capability many organizations focus on their project management skills. This is a business capability maturity level-1 approach — get a better quality ‘hero’ (project manager).

Project managers have a specific organizing, conducting, facilitating and controlling role to play on projects. But project management is only one of five such roles or components required for success.

The five Value Delivery components can be illustrated as follows:

The Project Governance level creates the environment for projects to succeed in the business. This is where business leadership is applied to ensure the project portfolio takes the organization where it wants to go.

The Portfolio Management level manages the inter-relationships between the projects and seeks to increase the overall value of the portfolio by optimising all of the resources.

The Project Management level plans and manages the workload and resources on the project. This is where the standard project management methodologies and bodies of knowledge are applied.

The Outcomes/Value Delivery Management level delivers the value. The definition of the scope, requirements coupled with effective value and change management enables the value to be delivered into the business. NB this stream does not include the technology or systems.

The Technical Delivery Management level supplies the engineering, technology, systems, technical skills and resources to the outcomes/value delivery level to enable the results to be delivered.

The implication of this model is that

• all five components are required to be effective for each project and the portfolio to successfully deliver the value expected
• just focusing on one component — eg project management, technical delivery or alike — will only have a marginal impact
• all five components need to be at the same level of maturity to generate the best results; shortfalls in any one component of project delivery will reduce the value of the rest
• the business cannot abdicate project delivery capability improvement to the project or IT fraternity as they themselves have an important role to play in governance and supporting the portfolio and solution delivery streams.
• When governing a project you need to ensure all five components are present, working well and aligned to delivering the expected value. You need all five components for you to succeed.

To better understand Project Governance, purchase “Understanding Project Governance” — a simple, clear guide to the 24 dimensions of project governance — what they are, why they are important, and the impacts of failure in each dimension (available from valuedeliverymanagement.com)

A common misconception is that projects rotate around the Project Manager. This is not so. They really rotate around the Project Sponsor.

The Sponsor is the person with the connections to the Executive Committee, his or her peers, the Steering Committee, key resources and others. It is the Sponsor who can make things happen.

The Project Manager can make things happen only within their sphere of influence, which is limited.

The relative roles and relationships between the Project Sponsor and Project Manager are illustrated in the following Project Governance Structure model:

[View enlarged image]

This Framework should be read carefully as there is a lot of information in the connections between the parties.

The Project Governance Structure Framework makes clear the interrelationships across the project and into both the business and IT. The core team (in burgundy) need the support of the other entities to be successful.

As a member of the Governance team, you need to understand and ensure all of these relationships are known, acknowledged and being managed effectively.

Support for Project Sponsors in their role is provided a beingaprojectsponsor.com, and for project managers at beingaprojectmanager.com

When life was simpler, projects could be assessed on their claimed return on investment (ROI). If the project was financially worthwhile (at the time of approval) and supported by some executive, it would be approved.

Projects tended to be approved in isolation creating problems at the portfolio level clashes and when they came to be implemented.

So the evaluation of projects has become more sophisticated. Or has it? A recent analysis of eight major approved projects found that seven should not have been approved in their current form. One was solving a non-problem, one was delivering a solution that was incompatible with the organization’s future direction, one was a project that was already off-the-rails! And so on.

Yet each of these projects had been evaluated by their divisional investment committees as well as the enterprise investment committee. The problem was that this (and most) organization did not have a clear and effective evaluation model.

The following evaluation model makes the bases for evaluating projects clear:

(Targetting Investments)

The first question is, “What’s the project’s value?” — why are we considering doing this project, what will we get from it? Obviously if you fail on this test, you don’t go any further.

Then the question is, “Will we get the value?” — is the project too risky, too complex, too vague or mismanaged to deliver the value promised? The value proposition is only as good as its ability to be delivered.

The next question is from the corporate perspective, “Does it advance our strategy?” — is it relevant to what we’re trying to do, the problems we are addressing, the direction we’re taking? If not, why are we doing it?

The fourth question looks at the organization’s capability to deliver the project “Can we deliver this type of project successfully?”

The reaction to many a failed project is to start it again with a new team, but sometimes the reason for the failure is that the project is beyond the capability of the organization to deliver. If you don’t know your organization’s project delivery capability you can be wasting large sums of money on projects you’re just not able to deliver.

The next perspective is whether we have the capacity to do this project — do we have the resources to deliver it, can the business absorb it effectively? Too much concurrent change reduces the actual value delivered as the staff become change-weary. Also, too many concurrent projects spreads people’s attention and commitment to thin. Can we do this project well? is the key question.

Then the portfolio perspective is applied. “Does it fit in with our existing portfolio?” — does it support other projects, can we accommodate it and implement it when due? A high-risk project by itself is not necessarily a concern, the fourth concurrent high-risk project is a concern. So how this project fits with what is already in-flight is important.

The final question, “Is this something we should do now?” — is it the most important, the most valuable project on offer? Is it worth the effort? What will happen if we defer or even stop it? This question needs to be asked whenever the project is being re-evaluated for continued funding. Just continuing to do a project because you’ve started it is no basis at all, it is better to cut your losses and reapply the remaining funds to a higher priority project.

Accompanied with a thorough evaluation process, this process culls irrelevant projects, projects you cannot do, projects that overload the organization and refocuses your investment funds onto the projects with the most value and likelihood of success.

Our Guide, “Understanding Prioritisation” will be available shortly — more details to follow soon

Why is it that two organizations implementing the same technical solution (hardware and software) can generate very different results? One implementation may be a disaster and threaten the existence of the organization, while the other generates massive, positive returns.

When we[1] found this discrepancy in business results from common technology in 1993-96[2] we went back to see why this was occurring. What we found was that different organizations had different approaches to implementing projects in general, and systems projects in particular, and that there was a direct correlation between these approaches and the results consistently obtained.

Through further work we identified five measurable levels of ‘business project delivery capability maturity’.

Now maturity models abound in and around IT — the SEI and COBIT maturity models are the most well known. However, these maturity models seek to improve the same processes until they are ‘optimized’.

The business capability maturity model found that there was a break point between maturity levels three and four where the whole foundations and thinking about projects changed. And the results changed too, increasing exponentially.

At maturity level-1 there are few repeatable project delivery processes. The organization relies on ‘heroes’ to bring the projects in. Therefore there are some successes (where the stars line up) and many non-successes, to varying degrees. Over time, the nett return on investment, once you’ve taken into account the ongoing operating and support costs, is negative.

Level-2 brings formality. Fed up with the hit and miss approach of level-1, organizations install methodologies, governance and approval processes. These processes are rigorously enforced, almost making following the process an end itself. The results improve generating a break-even investment return. Many organizations are still struggling to get to and sustain this level today.

Level-3 adapts the rigour and processes of level-2 to get even better results — a return of 1.3 to 1.5:1 on funds invested. Good, but not great. The highest IT maturity levels of SEI and COBIT will, by themselves, only allow you to get to this level. At least the returns are positive, but they can be doubled by level-4[3].

At level-4 the whole approach to projects switches from IT, project or quality-improvement delivery to strategy and value delivery. The returns double from level-3 (to 3:1), the time taken to do projects reduces and the time and effort wasted is minimized. Organizations at level-4 can generate two to three times the returns from the same level of investment as their peers — a sustainable cost advantage.

If your organization is not at level-4[4] you’re giving away significant value on each and every project and leaving the potential for a competitive advantage to your competitors. For most organizations, level-4 is the target level of maturity.

Level-5 is when the disciplines and approaches of level-4 are embedded in how the organization does business, competes and makes money — it is in its DNA. The returns increase exponentially again.

The other significance of the business capability maturity model is that it determines what types of projects you can successfully complete. Large-scale, complex, innovative projects require more mature delivery ‘capability’ than smaller, simpler projects. Taking on projects beyond your capability to deliver is a frequent reason why so many large projects fail in organizations.

So, you need to understand your level of capability, the level of capability your project demands and check that you do have the wherewithal in capability terms to deliver and realize the value. If not, don’t start.

For a complete description of the Business Project Delivery Capability Maturity Model, read “Project Delivery Capability — the next competitive battleground” available from www.project-sponsor.com.

[3] Level-4 can give you a cost advantage as you can halve your investment levels and still get the same results!

[4] Usually over 50% of the potential value on most projects!

If you’re asked to estimate the time it will take you get from somewhere you’ve never been to another place you’ve never been either, how accurate would your estimate be? So it is with many project estimates – they’re based on too little knowledge and too much uncertainty.

Any later adjustments to your estimate would be as you increase your knowledge of the challenge you’ve been asked – they would not be testaments to your estimating incompetence!

Estimates are dependent on the ‘Uncertainty principle’ that illustrates why initial estimates tend to be inaccurate and only become more accurate as the project progresses

Failure to recognise the Uncertainty Principle leads to a lot of misunderstanding about estimates (and therefore budgets and timescales). The Uncertainty Principle makes sense of a perplexing subject – estimating.

Uncertainty Principle

How long does it take you to get to work? Let’s say it’s 40 minutes.

So, most days it’s 40 minutes give or take a few minutes. Some days it is quicker – nearer 30 minutes – other days it takes longer, say over 50 minutes. On a few occasions it can take 90 or so minutes due to accidents, road-works and alike.

So tomorrow you have an important meeting with ‘the big boss’ at 8am. What time will you leave home – 7.20? Unlikely. There is enough uncertainty in your journey time for you to ‘allow’ for delays, bad weather, etc. You’d probably leave at, say, 7am. This is a 50% allowance for ‘uncertainty’.

The ‘uncertainty principle’ is the level of uncertainty that exists when making an estimate – the level of unknowns.

To illustrate. Take a journey between two point you’ve never been to. How would you estimate that journey time? To do this you’d have to seek out as much information about the journey, roads, form of transport, likely impediments, weather conditions, etc.

As you get more information you’ll be able to give a better estimate of the journey time. The earlier you’re asked for a ‘final’ estimate the more woolly and inaccurate it will be, as your level of uncertainty (unknowns) will be high.

So it is with project estimating. The more unknowns, the more the uncertainty, the less accurate the estimates. As you progress through the project the more the unknowns will become knowns and the more accurate the estimates will be.

By the end of the project’s solution-design stage the estimates should be fairly robust. But before that any estimates range from wild guesstimates to only partly-informed estimates.

However, when do most organizations expect a business case with fixed cost and time estimates? Often before even the requirements have been done! IE when the level of uncertainty is still very high.

No wonder these estimates are so often wrong.

“But,” you may ask, “why are estimates always ‘under estimated’ even when contingency and ‘padding’ is included?” There are three principal answers to this question.

When estimates are under-estimated this means they’ll be surplus funds. Now, rather than return the funds or deliver early, what tends to happen is that work expands to the funds available. A key governance team accountability is to see the funds allocated to the project as the maximum to be spent, not the target to be spent

Then there’s people’s optimism. Most people naturally under-estimate. They identify the obvious activities but usually don’t foresee all of the glitches, problems, delays or special events that will occur. To illustrate this, I have found that a carefully compiled workload estimate, including contingency allowances for things going wrong, delays, etc, must still be multiplied by FOUR to be accurate!

Management cannot take the answer. The team works out the estimates and finds the true total estimate to be an answer that is too high, one that the management won’t accept. So, rather than present the true total figure, the team presents a reduced estimate so as to get the project approved. Then, as the project progresses, the estimate is ‘adjusted’ to the full figure.

One Project Investment Committee member recently observed that he automatically doubled the costs and halved the benefits on any proposal presented. (Unfortunately, in his organization, this was usually very accurate.) Although extreme, he was in effect applying ‘the uncertainty principle’ to project estimates. However, there is a better way.

When estimates are uncertain, three different estimates should be given – best case, worst case and most likely. The range between these three figures should narrow as the project progresses and the level of uncertainty is reduced.

What these three estimates are saying is, “If you are not willing the spend the best case estimate, don’t start. However, the project should never exceed the worst-case estimate. At this time our most likely estimate is this”

However, the ‘uncertainty principle’ dictates that the earlier you ask for estimates, the less reliable they are. So if you go to your investment committee with a funding request based on highly uncertain estimates (that you’ve demanded from your project team) you’ve only got yourself to blame for any subsequent increase in the estimates.

In the physical world it is easy to see and be wary of a ‘gap’.

However, in the project world the ‘gap’ that exists between what projects deliver and what is required to realize the benefits and value is most often neither seen nor acknowledged.

Hence the continuing frustration with the lack of value generated from projects.

This VDM article discussed the issue and the need to recognize and plan to cover the ‘gap’ and realize the value expected. The result is often a significant increase in value delivered.

The Value Gap

It may seem to be a stupid statement, but it is true, that projects are not set up to deliver the benefits expected.

“But there’s a business case promising specific value in return for the investment in the project” you might object. True, but the business case glosses over the ‘value gap’.

The Value Gap is the workload left between where the project ends and the benefits are realized.

In the interests of simplicity (and benign acceptance) executives tend to accept that the project outcomes will deliver the benefits. They may accept that some benefits are realized after the project, but the ‘value gap’ is neither acknowledged nor recognised.

A project can only go so far. The project team does not run the business. They cannot directly alter how people change on the job to ensure the benefits and value are realized. Only the business can achieve and then sustain business value.

The problems are

they often don’t realize delivering the business outcomes, benefits and value is their role
they usually don’t know how to do it.

So the first step is the recognize the existence of the ‘value gap’ – that the implementation of the project won’t automatically deliver the value.

Impact on Scope

Recognition of the ‘value gap’ gives a new perspective on scope definition (and scope reduction). Any move to constrain/reduce the scope leaves a bigger gap between the project’s outcomes and the value. A gap that either has to filled by business-as-usual or the value will be reduced or foregone.

Impact on change

The ‘value gap’ consists of change activities that need to be done. So if it is agreed the necessary change activities are not going to be actioned by the project team, they need to be actioned by the business.

So, these activities need to be identified, organized and planned for execution. But these activities should not be left to business staff’s ingenuity, but should be planned jointly by the project and business teams so that the change plans are understood and owned by the business.

Impact on project completion

No project should be considered finished if plans to deliver each of the business outcomes and benefits do not exist. However, the plans need to be able to be executable by the business.

This ongoing execution of change activities continues on AFTER the end of the project as the strategic intent of the project – delivery of the value – has not yet been delivered.

Impact on governance

Therefore the Sponsor needs to continue to chair Steering Committee meetings monthly, receive reports from the business areas on their measured progress in delivering the business outcomes and value for some time after the project has been closed down.

When the bulk of the activities shift from delivering outcomes to progressively realizing value (eg releasing staff as the workload drops), the governance team can agree with the business that any remaining change activities are now fully the accountability of ‘business-as-usual’.

Impact on Sponsorship

The reason why projects are invested in is to realize the value. This is the ‘contract’ the Sponsor enters into with the business.

The Sponsors should, therefore, report back to their investment committee on their value-delivery performance. How did they do? What value did they realize and for what cost?

A simple step that focuses each Sponsor on their project’s value.

As we say, “Focus wins, It’s that simple.”

Benefits management is still a ‘hoped for’ element on most projects. Recent research found less than 30% of companies actually try to measure their projects’ benefits (yet getting the benefits is why projects are commissioned in the first place)

One major reason for this is the lack of a clear visible link between what the project delivers and the desired project benefits and value. This gap is bridged by “The Value Equation”™ a simple model that allows each element of the value delivery process – from project activities to value realization and measurement – measurable and manageable.

The Value Equation™ makes benefits and value management effective and easy.

But it changes how you do projects!

The objective of a project is to deliver value to the organization. This simple basic concept is too often lost in the hustle and bustle of project delivery. The focus on value is too often lost because it is not clear how value is generated, delivered or realized.

The Value Equation™ makes clear how value is generated, and in doing so introduces some key concepts critical to project success and value management.

Desired business outcomes (O)

The most critical concept is that of ‘desired business outcomes’. These are the business end states that are required to enable and deliver the benefits and value. This is where the business wants and needs to get to for the project to be a success.

Few projects currently define their ‘desired business outcomes’. What they usually have are unmeasurable objectives, project outputs and deliverables and a lot of assumptions buried in their documentation.

One key dimension of ‘desired business outcomes’ is that they are measurable by a true/false question – Do we or don’t we? Can we or can’t we? Have we or haven’t we?

Another key dimension is that they define the true end states to be realized. Too often projects head off towards some interim goal that won’t actually enable the delivery of the benefits. Implementation of a system is a common example. No organization exits to run a system; the implementation of a system is a step along the way towards the true end state, which might be, for example, “We have a clear 12-month forward projection of our key customers’ planned ordering requirements”. This 12-month plan end state is quite different to, say, the existence of an installed CRM system.

So the first critical consequence of the Value Equation™ is the need for your project to define its true ‘desired business outcomes’.

Project activities (A)

The project’s progress towards and contribution to these desired business outcomes can then be tracked. Every project activity should be able to be aligned to the outcome(s) it is delivering.

Again, these project activities should be measurable so that their completion can be tracked and measured (and quality controlled). You can then measure progress towards the delivery of each and every Outcome. This give a much clearer focus for project activities from a business point of view.

Benefits (B)

Benefits are different to the desired business outcomes/end states and the quantified value. The benefits spell out in measurable terms the non-quantified nature of the value.

Benefits are delivered or enabled by Outcomes. No Outcomes, no benefits.

But, importantly, realization of the benefits can be measured separately from the realization of the value. So, if your benefit is, say, ‘Products are delivered to market in half the current time’ this can be measured as achieved or not (are they or aren’t they?). The dollar value of this benefit is a separate measure. This is important if the dollar value changes substantially – Did we achieve the benefit? is one question. Did we realize the value? is another. They need to be defined and measured separately.

Value (V) and Value drivers (D)

The dollar (or other measure) value of a benefit is the most unstable element of the value equation as external events can impact and change the value drivers and, therefore, change the benefit’s value.

For example, a value computed with an exchange rate of 1-2 dollars will be different if the dollar is devalued and results in an exchange rate of 1-2.2. No one in the business can control the exchange rate but it would, in this case, impact the realisable value of the benefit.

However, both the value and changes to the value drivers are still able to be measured. Variances due to external events can be tracked and explained. So, while, in our example, the exchange rate may have changed the value of the benefit, this value change can be tracked and explained. This ensures your project’s value is managed from all dimensions.

Understanding The Value Equation™ allows the Governance Team to track and measure the delivery of the project’s value from the project’s activities through the delivery of the Outcomes and on to any external impacts.

Management to The Value Equation overrides management to the project plans for the Governance Team.

Happy new year to all our VDM readers.

We start this year with a series on “10 Critical Models for Governance Teams” – 10 key project dimensions you need to understand to be effective.

We start with “The Infernal Triangle” – the key levers you may need to adjust to deliver your project and the ramifications of each.

The Project triangle is actually four dimensional – scope, cost, time and quality.

QUALITY is a critical component because, as Gerry Weinberg observes, “If quality is an option all else is possible!” (You may just need to think about that one.)

So, as a member of the Governance team you must always be focused on the project’s quality – is this solution and its outcomes fit for purpose and to the agreed quality standards?

Make sure you personally look at the quality of some of the project’s physical outputs and review the effectiveness of the quality management steps – testing, user evaluation, etc.

So quality is the given. What about the other three?

SCOPE controls the value. Increases in scope must be assessed in terms of their impact on the project’s value. No increase in value, no scope increase should be the rule.

Scope reductions must also be assessed in terms of their impact on value. Any scope reductions that reduce the project’s value attack the very raison d’etre of the project – the delivery of the business outcomes, benefits and value.

On one recent project, the Steering Committee had agreed to drop a component that was seen as peripheral to the main focus of the project. But then our value engineering process showed this component delivered 80% of the business value. It was restored.

So, scope is a critical governance lever to control and protect the project’s value. No proposed scope changes should escape a rigorous value-impact challenge.

COST is a dimension that has high visibility outside the project. You’re allocated a certain amount of funds and if you go ‘over budget’ you have to go, cap in hand, to a management body and ask for (and justify) more funds. Very visible and very embarrassing. Few executives want to do this.

In the 1990s budget overruns were the norm. “We did well,” said one Sponsor in 1999, “we came in only 70% over budget.”

In the 2000s most organizations have clamped down on budget overruns. But in doing so, they have often ensured that their projects’ long term value is foregone to meet short-term budget constraints.

The problem is often that the ‘budget’ is set too early when there are too many unknowns. So the budget is, too often, by definition wrong.

(Where projects are over-estimated they rarely come in under budget. Instead they tend to finesse the project to consume the funds available.)

However, if you’re faced with a decision to, say, forego $2m in ongoing benefits for the want of $1m in additional one-time expenditure, you’re not doing your organization any favours in cutting scope to ‘make budget’.

Always remember Tom Peter’s comment, “The worst thing a manager can have on his tombstone is ‘made budget’.”

To realize the value you may have to go over budget; it’s a value trade-off. (Sounds of CFOs fainting in horror.)

TIME drives more than costs, it also reduces value through delaying the realization of benefits and, therefore, their lifetime value.

So time has a double impact – on both costs and value. You need to know your project’s cash ‘burn rate’ to understand the cost impact of any time increase.

You also need to know your value realization rate to understand the value impact of any project delivery delay (often this is greater in the long run than the cost impact because it is ongoing).

Each of the “infernal project pyramid’s” dimensions has an impact on the project value. So, if you, as the governance team, have to compromise, the rule of thumb is to go over budget before you go over time (which you’d do before you change scope or, lastly, compromise quality).

Ideally, of course, you’ll deliver all of the value on time, budget and to specification.

But no one said it was easy.