Stakeholder Value-Delivery Matrix

Roger Burlton, of the Process Renewal Group, gave an excellent presentation Monday morning at the 10th annual International Business Rules Group: Developing a Business Process Architecture and Program of Change. A lot of good stuff about how to define, develop, and manage processes. One idea in his presentation was particularly compelling – that of driving process improvement strategy based on stakeholders. This approach looks at how much benefit the stakeholders can get from the improvement, and how much pain the current process causes them. A very compelling strategic prioritization tool.

Thanks Roger Burlton!

Thanks Roger, both for sharing your thoughts with us at the IBRF conference, and for giving me permission to write about this technique. We’ve adapted it a little bit. You can see a pure example from one of Roger’s presentations online (slides 15 – 17). Click on the “Other Resources” link from the Process Renewal Group’s main page, and select Implementation: The Payoff from Architecture and Program Management. If you would like to follow up with Roger about this or any of his other works, he’s asked me to share his email address here rburlton@processrenewal.com.
We’ve simplified the example grids to show fewer processes, written out an explanation built from Roger’s (verbal) presentation, and introduced the notion of utility as a means to prioritize. The base idea comes entirely from Roger.

Stakeholders

Roger’s technique is a straightforward one – like all good ideas, it is obvious in a “I can’t believe I didn’t think of it” way. In short, you find the processes that are the most valuable to the most influential stakeholders – and you improve those processes first.

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Determining Value

Value, in this analysis, is a combination of pain and gain. To begin this analysis, you have to define the processes under consideration. You should have already done this as part of defining the scope of the project – and Roger showed us some compelling techniques for defining and managing the scope of the project. For each process, you perform two analyses.

• How much gain does each stakeholder stand to get from improvement of the current process?

For each process, for each stakeholder, identify if the gain from the proposed process improvements would be small (1), medium (2), or large (3). Use whatever normalizing scale you like – the key is to be simple, consistent, and directionally correct. You don’t need to have a detailed benefit analysis for each process.

You’re trying to prioritize, early on, which processes to work on.

• How much pain does each stakeholder feel due to the shortcomings of the current process?

Perform another analysis for each process and each stakeholder. This time identify the relative level of pain felt by each stakeholder, due to the inadequacies of the process. Use the same numbering scheme: low (1), medium (2), and high (3). The key is to be relatively consistent in your approach to assessing pain. It does not need to be an econometric assessment of risks and penalties, or a detailed model of lost opportunity and revenue. The goal is to approximate “how bad is it?”

Note that the “Combined Gain” and “Combined Pain” rows show the (stakeholder) weight-adjusted sums of the relative gain and pain levels. Each process then gets a ranking on the “most potential gain” and “most induced pain” scales. When you have a tie, remember to skip the next number when calculating rank. (e.g. if two processes in the example above had a combined pain score of 5, then they would both have a rank of 3 – and process #1 would have a rank of 5).

Pain Meets Gain

Next, create a graph with pain ranking along the vertical axis, and gain ranking along the horizontal axis. Plot each process on the graph. The processes in this example would look like the following:

There is a reasonable distribution of potential value for this example. Value is a proxy for utility when viewing this graph.

Intro To Utility Curves

If you were to overlay utility curves on the diagram, you would see that some processes are more valuable than others.

These utility curves also help us visualize the discontinuities in the diagram. Processes 2, 5, and 1 are more valuable than processes 3 and 4, which are more valuable than processes 6, 7, and 8 (not shown in the grids above).

Prioritizing Processes

Given the relative values of each process, as demonstrated with the utility curves, we can break up the staging – or prioritization – of the work to clearly convey which processes should be improved first.

And then we can also see which processes to prioritize for the second iteration.

As we complete the first set of processes, we should re-prioritize. Like all projects, we are aiming at moving targets. The second phase may not include processes 3 and 4. Our improvements to processes 1, 2, and 5 may not have been very effective – there may still be a lot of pain and gain to justify refactoring them again. However, there is value in communicating our plan as we know it today to the executives.

Processes 6, 7, and 8 may never get re-engineered. Since there is relatively little pain (impetus for change) or gain (value available from known changes), there may always be a better way to invest our resources.

Conclusion

Getting agreement from executives about what to do, or more practically, what to do first can be very difficult. By presenting a view like this to executives, you make it very easy for them to make decisions. And following Roger’s lead – you have the opportunity to convince them that it was their idea all along, and you only facilitated the plan.