The (late) Steve Jobs said that if you believed something was ‘simple’ you obviously did not understand it. The challenge, he said, was to thoroughly understand the complexity so that you can then simplify it. His products are testaments to his success — highly sophisticated items of technology with one or two buttons only, for example. Apparently he and a small team spent their evenings for weeks and weeks simplifying the original iPod interface.

Yet in our time-pressured working environments, increasingly there is a desire for the simplistic.

A classic example of this is the approach of locking business case defined benefits into future operating budgets so as to ‘ensure their realization’. This is simplistic thinking – and illustrates the value-destroying properties of such simple thinking.

Locking benefits into future budgets:

1. Reduces the value of benefits as managers seek to minimize their future exposure by defining only enough benefits to get their business cases approved (not a good start).
2. Is irrelevant to the many managers who do not expect to be in the same position by the time the benefits are being expected (not a behaviour changing solution).
3. Fails to recognize reality – that during the course of the project and beyond the financial value of benefits can legitimately change significantly due to factors outside the project and governance teams’ control – eg interest rate changes. Any increase or decrease in value is ignored by this simplistic approach.
4. Doesn’t even measure benefits realization only budget achievement. If other events have allowed the future budget to be met, the benefits from the project may not be realized at all as they are not needed (to make budget) or measured (as benefits).

And we could go on. But this example illustrates the dangers of simplistic thinking.

Simplified thinking, however, is quite different.

If you want to measure benefits realization you need to measure the inputs – the ‘stepping stones’ along the way to full benefits realization. You need to measure the progressive delivery of the:

• project outcomes,
• business outcomes,
• associated benefits
• and then their value,
• while tracking any changes to the value drivers.

This ‘input’ approach to benefits realization management and measurement is simple to set up, embeds benefits realization into projects, and actually increases the value of benefits realized. Their value is tracked and measured independently of any other events or financial changes so you know what the project has and has not delivered.

When people just ask, “Just tell me what to do,” they are looking for simplistic answers. They don’t want to ‘think’ – they just want to ‘do’. In these cases you can be assured that their outcomes will be simplistic, poor and compromised.

What people should ask for is “Tell me how to think about this. How should I approach it? How do I define what I’m trying to achieve?” When you then provide them with simplified but highly effective solutions, you’re on your way to a simplified and highly successful result.

© Totally Optimized Projects Pty Ltd, 2011

Featured publication: Solving the Benefits Puzzle



Solving the benefits puzzle is a story of how an organization, frustrated with its inability to track and measure benefits, moved towards adopting a benefits realization TOPology.

This short, entertaining book spells out the problems and the solution. It is intended as means of getting people to understand benefits delivery management when their level of interest is likely to be low. More information | Download sample pages

Only $29.95
Get your copy today

……………………………………………………………………………………………………………………………………………………………….

A tool gaining popularity is Rob Thomsett’s sliders.

The idea is simple: there are six sliders/options that measure project success with a scale of 1 (low) to 5 (high). At the outset of the project the business is asked to rate the relative importance of each of the six options with the caveat being that any movement up on one option must be met by a corresponding movement down on another.

The six sliders cover

• Stakeholder satisfaction Do you want to be satisfied with the outcomes of the project?
• Deliver on time Do you want to receive the project to schedule?
• Deliver on budget Do you want to receive the project at the agreed cost?
• Deliver planned scope Do you want to receive all that you said you wanted?
• Meet quality requirements Do you want it to perform/work?
• Team satisfaction Will you feel warm and fuzzy if the project team are happy at the end?

Now remember, any movement towards “Yes” must be countered by a corresponding movement towards “No”.

This is surely the ultimate substitution for project performance!

“Mr/Ms Business, we are about to take your $x and in return we want you to commit to being happy with a poor quality result that you agreed to be dissatisfied with, but know in return that the project team had a great time.”

Interestingly, project practitioners welcome this model but complain that only dimension reflects the project team (team satisfaction). Within bounds, the business is not interested in ‘team satisfaction’. Did the team have a good time? Is not a business measure of success. (This is not to say that managing team morale and productivity is not important.)

This model seems to me to be evidence of how far away we are getting from what projects are all about — delivering business outcomes and their benefits.

The measure of success is “Did the project deliver the agreed (hopefully optimized) business outcomes so as to enable the full realization of the associated benefits?” There is no sliding away from this measure.

Certainly there will need to be compromises at times — but these should be trade-offs in relation to the value the project is to deliver.

A time overrun impacts when benefits will be realized – that’s the trade-off.

A cost overrun impacts the net value of the benefits – that’s the trade-off.

A quality or scope compromise will reduce the ability to realize the benefits in full – that’s the trade-off.

A stakeholder satisfaction compromise may again impact the level of benefits realized.

Insofar as these decisions are necessary they need to be made with quantified numbers that spell out the value impacts and alternative options. These six sliders are not alternatives, which is the fundamental problem with the model. Rather than compromise at the outset, let’s focus on delivering success and the realization of the business benefits.

Featured publication: Understanding Project Success (only $9.95)




The most common measures of project success – on time/on budget – are deficient. Indeed, many organization’s project measurement processes penalize attempts at success.

This Guide provides a thorough discussion of what is (and isn’t) ‘success’ across three dimensions – all of which have to be met for the project to be considered a total success. Yet, too often, only one is used. Agreement as to the true measures of project success can have a major impact on your future project results. More information

……………………………………………………………………………………………………………………………………………………………….

Two things happened recently on the same day in the same organization.

The first was I received a copy of a post implementation review report that basically said “We don’t know if we got the benefits from this project as the KPIs and other benefit measures were largely vague, unmeasurable or irrelevant.” Overall, the conclusion was that the project had ‘failed’ to deliver the results and benefits expected.

Not altogether surprising when you have ‘vague, unmeasurable and irrelevant’ goals. As the Cheshire Cat said to Alice in Wonderland, “If you don’t know where you’re going, any road will take you there!”

As frequent readers of my blog will know if there is one thing I hammer as vital to project success is the need to spend the time clearly and thoroughly define your desired business outcomes in clear, measurable terms; and then focus your whole project on their realization.

But many people don’t get it.

The second was a workshop with some quite senior management. We’re developing a business case for this client and defining their value proposition in clear, measurable terms. Their reaction was …

1. “Too many benefits” I wonder how many times they’ve said that of a project!
2. “Too ambitious” We might actually deal with the root problems if we take this approach. Can’t we just deal with the easy symptoms and look like we’re doing something?
3. “Yeah, but what does the software do?” Thinking is hard, can’t we just adopt the software?

I was pleased to see that even the software expert said, “If there is anything I’ve learned from installing systems over the past 10 years it is that unless the business knows exactly what it is trying to achieve the software installation will be a failure.”

What this experience makes clear is that software and demos are being used as a replacement for thinking. And this is the nub of the problem — that people need help to think and that so many of the problems we have are as a result of a reluctance or inability to think.

How do you address this problem? Post your comments below.

Our consulting company, Capability Management International, is 15 years old this year. So we start the year with 15 of our most critical insights.

“We do projects to realize the associated benefits”

Benefits realization is not peripheral or consequential to projects but central. Benefits realization should not, therefore, be ‘hoped for’ or ‘someone else’s responsibility’ but the main focus and intent of all projects.

We do projects to move from our current state to some future state because we believe that this future state will be more beneficial than the status quo (ie doing nothing). “More beneficial” can be lower cost, increased revenue, more compliant, more competitive, or whatever.

However, if we don’t get these benefits, we’re worse off. We’ve incurred the time, effort and cost (and distraction) of the project without the payoff — the benefits. All pain, no (or insufficient) gain.

Benefits management is not, therefore, ‘extra work’ but replaces project management as the overall driving force and success measure.

The business case needs to move from being a means to justify the cost and get funding to being the statement of the project’s ‘value proposition’ that the project then goes on to deliver. The ‘cost’ is then only one of the resources required to deliver the value.

We need to shift our perspective from ‘delivering projects’ to ‘realizing benefits’. We need to view each and every aspect of the project through the ‘benefits and value lens’. Not because this is an advanced or ‘better’ way of approaching projects, but because that why we do projects.

Let’s put ‘benefits realization’ center-stage. Then we’ll start consistently delivering real value. Now there’s an idea!

What’s stopping us?  Please post your comments below.

A complete ‘benefits management program’ from outcomes and benefits identification to full realization is available from valuedeliverymanagement.com.

© Jed Simms, Australia 2009.

“If we don’t do this project, we’ll lose market share/customers/opportunities and that’ll be worth $XXm in lost revenue/profit!”

I’ve seen a number of projects justified with ‘avoidance of loss’ cited as the major (sometimes only) benefit.

The argument can be quite genuine. If the Blackberry did not respond to the iPhone, it would potentially lose significant market share. If your competitors are offering a sought after facility in the market and you don’t provide it, you’ll potentially lose market share, revenue and profit.

That’s all okay but is this avoidance of loss a ‘benefit’?

The answer is ‘No’ because it fails one of the fundamental requirements of a benefit — that it’s realization is measurable.

You must be able to determine if the benefit has been realized/delivered at (or after) the end of the project.

By definition, if you do the project you avoid the loss and therefore cannot measure it. Trying to claim “We would have lost $400m if we had not done the project, but we didn’t, so we just saved $400m” is an unverifiable benefits claim.

Having no loss is not a measure as there is no guarantee that you would incur the loss without the project due to customer loyalty, other features you offer, the cost of transfer, or whatever. Notice above I always said “potential loss” as I’ve seen projects refused, that claimed the end of the world as we know it if they were not done, and nothing significant happened.

A genuine potential avoidance of loss is a legitimate reason for doing the project, a ‘risk’ if we don’t do the project, but is not a benefit of doing the project.

As an executive you’d be foolish to ignore such a reason for doing the project; but you should not put this in the ‘benefits’ column. It fits under the “Risks of not doing this project” heading.

However, when you have such a claim and it is a big number there is a tendency to not look for other benefits. In a recent case, where the Board refused to sanction a project whose only benefit was a $400m avoidance of loss, we found $40m of realizable benefits and that the potential loss was actually nearer $700m! Both very good reasons for doing the project, but only the $40m was a real benefit.

This benefit and the extra value loss potential were discovered in just two weeks using our Benefits Management Program.

What do you think?

How to Identify and How to Quantify your benefits are both available from valuedeliverymanagement.com.

© Jed Simms valuedeliverymanagement.com, 2008

When recently reviewing a project that had a projected benefits value of $32m we found that the true available value was over $100m.

So, if the project delivered the $32m is this true success? Or, is it a failure for failing to realize the other $70+m?

One of our surprising findings when we conducted our worldwide research into where the value went on projects was that the business case was the greatest single destroyer of value. Most business cases left vast amounts of money ‘on the table’ unidentified.

How business cases are generated, their myopic focus on dollar benefits that actually reduces the value identified, and their inability to compute benefits in ways that could be tracked throughout the project, all contributed to the loss of value.

Missing 25% of the available value was common. Many, as in the case above, missed more than they found.

As business case generation is part of the project, surely inadequacies in this area are a ‘failure’ of the project. And, if you don’t identify the benefits you’re unlikely to realize them. So, the full available value goes unrecognised, untargeted and unrealized.

NB Most projects still struggle to realize the value they target, so this is a double loss — some value is missed and of the remainder some is lost or destroyed.

So when I class projects like the example above as having ‘failed’ on at least one dimension (full realization of the available benefits) is this fair or being unreasonable?

What do you think?
© Jed Simms, Australia 2008

Initially the focus was on successfully completing projects. “Successful” often meant ‘finish’ hopefully within sight of the original budget and timeframe. This was called “Doing projects right”.

Then the focus came onto selecting the right projects. “Right” often meant ‘financially positive’ with some cognisance of the risks involved. This was called “Doing the right projects”.

This is where most organizations are today — trying to do the right projects right.

But there is a third dimension — delivering the right value.

Unfortunately along the way the whole purpose of projects — delivering benefits and value — has been forgotten. It has been ‘assumed’ (or ‘hoped’) that benefits will flow from what the project delivers. But as businesses around the globe can attest, “that ain’t necessarily so!”

This illustrates a mindset that is wrong — that there are projects and then there are benefits, and one follows the other.

When you take a Value Delivery Management approach to projects you see the two — the projects and benefits — as inextricably intertwined.

Projects should (and can) deliver benefits throughout their lifecycle.

In a large utility, we defined the new ways of working in 14 weeks. This work specified what we wanted the systems to do and also identified the many changes required in the business for them to adapt and get the value from the systems.

The system was scheduled to be delivered in 15 months time. We weren’t going to wait 15 or so months for benefits so we started on benefits delivery at once.

In the first six months we realized 28% of the available benefits. In the first year this rose to 43%.

Delivering benefits early and progressively

• reduced the net cost of the project to the organization (we came in 10% under budget)
• improved the organization’s performance as the project progressed
• proved to any non-committed staff that this project was successful and could (and did) deliver results — and that they needed to get on board
• isolated the project from any scope reductions, culling, cancelling, delaying or any other externally imposed constraint — everyone was on board to ensure its success
• its proven history meant it got top billing when it came to allocating resources; “This projects works, lets get on it” was the belief generated.

This early and continuous delivery approach to projects also reinforced people’s ‘backbone’ when it came to dealing with the (big 4) systems implementer — they could confidently knock-back their recommendations knowing that their own plan was delivering results and value.

Overall, the project came in on time, under budget and realized every benefit proposed! And this from a project that was business-led, by people who had never directed a project before.

(Simultaneously, the same SI implemented different modules of the same software in the same organization interstate and came in 8 and 10 months over time and more than 100% over budget — so they weren’t the difference.)

When you add the essential ‘third dimension’ you are beginning to focus on value delivery management.

Your comments?

© JED SIMMS — the creator and founder of project-sponsor.com and valuedeliverymanagement.com is also Executive Chairman of Capability Management — a value delivery management consultancy.

Feel free to publish this article but please retain acknowledgement of source, authorship and copyright.

Some of the larger projects around town are appointing a ‘Benefits Delivery Manager’ who is given accountability for ensuring the delivery of the benefits.

This is a typical structural knee-jerk reaction to a process problem — appoint a person and give them accountability (regardless of whether the role is doable).

These people are on a hiding-to-nothing! They don’t control the project and they don’t control the business and so are not well placed to deliver anything. Worse, they’ll be seen as ‘the person accountable for benefits’ letting the lazier business manager off the hook.

But my objection is less that it is an unviable role without the authority to do the job expected than it perpetuates the myth that benefits are something that happens at the end of or after the project’s completion.

Most of the value lost in projects is lost well before the project gets to implementation. Indeed, by then most of the damage is done. Even with the best will in the world you often can no longer realize many of the benefits even if you were the most capable Benefits Delivery Manager in the world. They don’t exist as possibilities any more. They’ve been destroyed by how the project has been managed and governed to date.
Of more value would be a “Value Delivery Manager” who works with the project and governance teams to ensure the value is correctly and comprehensively identified, planned for, protected throughout the project and beyond, and realized progressively.

The Value Delivery Manager needs to have the authority to question proposed decisions, have poor decisions reviewed and report to the Project Investment Committee on where and how value was lost on any project.

NB This value loss may occur due to business (in)activity rather than be the fault of the project.

The Value Delivery Manager in effect provides a value-focused QA role on the project. Does the business case capture all of the available value? Do the plans target the realization of the value? Are the decisions being made enhancing or protecting the value? Are the outside environment or business conditions impacting the potential value? And so on.

It is not their role to make the final decision but to have the power and authority to question what is going on with, a bit like auditors, access to the Project Investment Committee that requires the project, governance and business teams to justify their actions when they go against the recommendations of the Value Delivery Manager.

Now, their not accountable for the delivery of the value (which they can’t do anyway), but they are accountable for maximizing the potential, planned and realized value of the project and explaining why, where and how any potential value was lost.

They are the guardians of value for the project who keeps everyone else focused on delivering the value.

Which role would you rather have?

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

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