We do projects to meet needs.  In “Don’t Give Me What I Asked For, Give Me What I Need” (July 3, 2012) I described an example of how a client can ask for something specific, but not have a good understanding of how that will meet their underlying needs.  I think that happens a lot:

• I need a break, let’s go on a trip (will that meet our need to relax?)
• This house is just too small, let’s buy a bigger one (will that make us more comfortable?)
• I can’t get the information I need to control costs, we need a new system (will the new system control costs?)

I’ve found that my clients are better off if they stay focused on the outcomes or benefits they want when they make an investment in a change.  But, this is hard to do.  We quickly jump from the need to the solution.  The need and the solution can become disconnected.  How can we keep them together?  Is there a way to create a map between where we are now and realizing the benefits we need?  There is.

John Thorp wrote a book in 1998 titled “The Information Paradox – Realizing the Business Benefits of Information Technology.”   As a leader in a top tier international consulting firm, Thorp found a common problem.  Information technology investments were not delivering the value promised.  It wasn’t that new systems were not getting built; it was that the organizations building them hadn’t taken the time to map out all the work that needed to be done to realize the benefits.  The IT projects that under delivered were about completing scope, not delivering benefits.  Thorp suggests in his book that “benefits realization” – a set of principles and practices – can be applied to projects, programs, and organizational culture to ensure that IT investments are selected and delivered in a way that contributes the needed business outcomes and benefits.

This book is a fairly easy read with lots of real life business cases and specific tools and techniques.  While the benefits realization approach involves fundamental shifts in how an organization manages its programs, I think that as project managers can apply some of the tools and techniques right away on our projects.  Advocating for fundamental change in our organizations will take a little longer.  So, I’ll apologize to Mr. Thorp now for any shortcuts I take in describing his Benefits Realization Approach more as a micro-view than a macro-view.  It’s all good.

The Benefits Realization Approach to a project would recognize that the project may be a program with many technology and non-technology oriented changes required to achieve the desired outcomes and benefits.  To achieve the outcomes and benefits, we need to avoid four “blind spots:”

• Linkage – not understanding all the work that links the investment in change to the expected business benefits.
• Reach – not understanding the impact the change has on other organizational and stakeholder systems and processes.
• People – not understanding the people impacted by the change and their current culture, environment, and capacity or readiness for the change.
• Time – not understanding the time realistically required to make the change fully and effectively.  The other three blind spots affect this one.

A technique pioneered by Thorp and his colleagues to shed light on the blind spots is Results Chain Modeling.  It creates a “road map” of the steps required to ensure that an investment in change leads to the desired business benefits.  The steps may be IT systems, process changes, people changes, or communication with stakeholders to change their behavior or attitude.  The components of a results chain map include:

• Outcomes – ultimate or intermediate business results (circles on the map)
• Initiatives – actions that contribute to the outcomes (squares on the map)
• Contributions – how the initiatives and outcomes impact one another (arrows on the map)
• Assumptions – expectations, conditions, or risks over which the project has little control (hexagons on the map – not shown in the example)

Here’s an example of a results chain from a 2007 article by Thorp in the Information Systems Control Journal found at www.isaca.org.

This simple example identifies initiatives and outcomes that have to be done in addition to the new information system to deliver on the ultimate outcomes of decreased operations costs, maintained customer base, and increased sales of new products.

I can think of a number of examples of projects that would have been more successful if a results chain map had been completed early in the project.  “Don’t Give Me What I Asked For, Give Me What I Need” was just one example.  Thorp describes this as “silver bullet thinking” in which a business need is followed by a quick jump to an information technology solution as the way to meet the need.  The Lone Ranger needed more than silver bullets to save the day.  He needed his horse, Silver, his sidekick, Tonto, inspiring music, a good plan, and sometimes running fast and hitting hard.  But, silver bullet thinking is a tough thing to break out of.  We liked it when the Lone Ranger fired those silver shots at the pivotal moment.  We forgot about the other stuff.  The other stuff was harder and more boring.  It took more time.  I’ve had several conversations on past projects about creating benefits baselines and linking them to the scope of work that have been met with stares of frustration or worse.  (Where’s the Lone Ranger when you need him?)  Thorp warns us that the move to a benefits realization approach is more than techniques, is not easy to implement, and is a long term proposition.  He’s right.  But, I think his ideas can be useful from the bottom up – one project at a time.

On our projects, we can start by defining the outcomes and benefits expected and use benefits chain modeling to depict all the possible steps that could be taken to bring them about.  Then we pick the steps what have the greatest impact on the outcomes and benefits and refine the map so that the required steps create a complete and logical path to the benefits.  This gives us a map of the whole journey we need to take.

Benefits realization struck a chord for me because it recognizes that finding what can go right on our projects starts with understanding the benefits expected.  What is that perfect outcome we hope to achieve to make our organization better?  We get into trouble when we define a project too narrowly.  We have to avoid the blind spots by thinking about all the ways our project affects the organization, its stakeholders, and the people on or connected to the project.  We have to give ourselves enough time, based on the changes we really need to make, to realize the results and benefits we seek.  Having a map can help.

Thanks for reading.

Copyright Glenn Briskin and “The Other Side of Risk” 2012