Benefits Realization: Demonstrating Initiatives’ Value

Debbie Crawford just taught a refreshed version of our Benefits Realization class. The topic is one that bedevils PMOs, largely because it takes a while to figure out that it’s not a closing phase task. In other words, it has to be planned, executed, monitored, controlled, and delivered…just like any other initiative deliverable. Below is an overview of the class:

Benefits are not just another dimension of portfolio management, but are the basic rationale for any investment of funds.  As such, benefits should drive those investment or change decisions from initiation through implementation and beyond. It is the methodology needed by any organization intent on effectively demonstrating that desired benefits are achieved in practice.

This course, built on a wealth of real world experience and lessons learned, will engage the participants in achieving:

  1. Increased organizational ability to forecast benefits which are complete, realizable, and represent real value for the money. In other words, we are investing in the right things and getting them done.
  2. Realize forecasted benefits in practice by ensuring the required enabling, business, and behavioral change takes place; ensuring that the performance of the benefit matches the business case promise.
  3. Realize benefits as early as possible and sustain that realization for as long as possible.
  4. Capture and leverage emergent or unplanned benefits (and minimize any dis-benefits) to optimize the benefits realized and the value for money is achieved.
  5. The organization’s ability to demonstrate the above – not just as part of the framework of accountability but also so that we learn what works as a basis for continuous improvement.

Where Did The Money Go? — Making Project Benefits Happen

OK, you saved your receipts. You may be able to show what you spent it on. But can you really show what you got for it? Not just some shiny new SAP modules, or a fancy app, but what higher margins, market share, or tangible benefits can you prove?

Benefits realization has been a theme of mine for years: here, here, and here. In fact, I’d move it to #1 in the list I gave to Michael Krigsman about the threat marketing IT poses to the CIO. If your PMO or function can’t show that it delivers value, then how can you expect it to be a strategic player? PM College just created a new course on benefits realization and the subtitle says it all: how to create tangible value against your business case.

The biggest misconception about benefit and value management is that the process happens after the project. That approach simply does not work. You can’t decide after the project: “gee, we need to show the boss the benefits…let’s figure out how to collect, measure, and present them.” As the course description says:

Benefits are not just another dimension of portfolio management, but are the basic rationale for any investment of funds.  As such, benefits should drive those investment or change decisions from initiation through implementation and beyond.

In other words, benefits realization has to embedded in the project plan from its very start…or you too will find yourself asking Hoyt Axton’s question: “Where did the money go?”

Why is “Dodge Caliber” my most popular search term?

The Ur-Caliber

The Ur-Caliber

The hottest Crossderry search term over the last few weeks has been “Dodge Caliber”, which brings folks to my “Benefits vs. Disbenefits” post. Probably not quite the take that most link followers expected, but the image does point them to Eric Beckinger’s cri de coeur.

I guess I should opine briefly on why I empathized w/ Eric’s rant: I had just rented a Dodge Caliber. The shape had intrigued me when I first saw it on the road. And though I had read a number of negative reviews, I was eager to give it a whirl once I saw it was my week’s rental.

Frankly, once you look past the profanity, Eric may be understanding the poverty of the Caliber driving experience. It wasn’t just bad, it was depressing. My mantra while driving it was “I’m so glad I didn’t get close to buying one of these.”

Oh, and I kept thinking back to the time I drove a Trabi…

Benefits vs. Disbenefits

Read Eric Beckingers post on why this car shouldnt exist...

Click to read Eric Beckinger's post on why this car shouldn't exist...

As we build the value management components of the next generation of SAP methodologies, I’ve dug in to the program management standards of PMI and OGC.  One of our first principles is to ensure alignment with industry standards; however, for programs and value management we’ll need to mix and match.

One example of a concept not in both standards is the idea of “disbenefits” in OGC’s Managing Successful Programmes (benefits profile outline here).  The concept is illustrated in my comment below about a Dodge Caliber rental…

I still can’t get over how bad the Dodge Caliber was to drive…however, a short test drive could fool the unwary.  Only a bean-counter would think it was a good idea to keep building Calibers. What is more valuable: the additional amortization of the Caliber tooling you get by selling more cars or the lasting emnity of the folks who buy them?

And that’s why considering disbenefits makes all the difference…

Making sure that your deliverables’ benefits are realized

With all my recent scope management posts lately, here’s a timely post on benefits realization (here) at John Gough’s iJourneys blog (here).  I like the theme of his post, that “…benefit realisation does not start when the project ends.”   I also second his point that IT sees itself as apart from the “business” and often has a leadership void at the top.  John puts it plainly:

Get Out of the Comfort Zone — There is a view…that the IT project manager delivers the project (i.e. the delivery of outcomes) but the business is responsible for building capability and realising benefits.  CIOs complain that they are too often sidelined by the business, but they do not always have the balls to … declare that: “we have taken the project this far, now give us responsibility for the business change”.

I’m not very comfortable, however, with his suggestion to:

Ditch the Business Case — The Business Case is designed to justify the project, but too often towards the end of the project, the dusty document is retrieved to “see what the benefits were”. The benefits are the project, and should guide the process from beginning to end, whereas the Business Case is just a means to an end.

My experience is that ditching the business case is what happens too often.  It should inform deliverable definition, the expected outcomes of those deliverables, the relative priority of proposed scope changes, and the benefits expected from the outcomes.  Instead, projects deliver “whatever,” the outcomes and benefits aren’t what were expected, and IT wonders why IT is “sidelined” by the business. 

Hat tip: Elizabeth at Girl’s Guide to Project Management (here)

%d bloggers like this: