Benefit Identification

One of the murkier areas of Benefits Realisation Management (BRM) is the process of actually identifying benefits to be able to create benefit maps.  It is clear that people know how to do this, and in fact that people are doing it.  Opening Gerald Bradleys practical guide "Benefit Realisation Management" and turning to 9.3 Benefit Identification doesn't really give a process to follow other than by discussing with stakeholders then using techniques to vet those benefits.  John Thorpe in The Information Paradox suggests you keep asking "so what", and then benefits are defined.

I'm not suggesting that there is anything wrong with either of these books, however for a beginner working with benefits it is very difficult to simply walk into a workshop with relevant stakeholders and identify benefits on the fly.  Simply identifying the relevant stakeholders and getting them all together is enough of a challenge, doing that and then having a productive workshop cold is no easy task.  Also lets remember that the stakeholder sessions aren't just about benefit identification, we're also using BRM to try to answer (and get agreement on) some important questions:

1. What does measurable success look like for the programme (i.e. what is it trying to achieve)?
2. What activities will the programme conduct, what will those activities cost and how will they each contribute to success?
3. How will the programme measure success through-life, spot problems and act to ensure success?

For us prior to stakeholder workshops, the process that we use involves deconstructing any documentation that can be found and using this to build a "straw man" model to take apart in the stakeholder sessions.  An explanation of this process can be found in Jennys blog. 

The strength of this process if done well is that:

1. you begin your workshops with a map people can immediately engage with and correct, rather than having to try to explain benefits and create something to discuss during the session. 
2. the map shows where weaknesses lie in the documentation and currently written expectations (benefits with nothing to create or sustain them etc.).
3. You can reference the benefits, outcomes, strategic objectives (insert terminology of choice) against the strategic documentation to show where you "created" them from.

The process also gives a lot more than just benefit identification, it gives a linked, supportable, in context view of the entire programme.  To help you get started with identifying benefits BRM Fusion have produced OutcomeJogger, which is free to download.  You can also use Realisor to create your maps and hold information against the benefits / outcomes.