Stakeholder Value-Delivery Matrix

Primary stakeholder in the 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
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.


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?

gain from processes

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?

stakeholder pain matrix

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:

pain vs gain graph

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

utility curve 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.

stakeholder matrix utility curves

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.

highest priority processes

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

prioritizing stage 2

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.


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.

Post to Twitter Post to Facebook

This article was published on Thursday, October 25th, 2007 at 1:01 am and is filed under Business Analysis, Prioritization, Requirements.
You can leave a comment on this post


  1. As stated in the review this is an excellent twist to the old Stakeholder Process matrix. Amazing how we can miss such a simple concept but that is what makes Roger the BPM master that he is.

  2. Wow, what a great idea. Thanks to Roger and you for sharing. Great article.

  3. Thanks for sharing this tool.

One Trackback

  1. By Scott Sehlhorst on April 20, 2009 at 9:55 pm

    @onpm “tight coupling” with stakeholders – utility, pain, gain, and goals #prodmgmt

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>