Now that the concept has been described (section 4), it’s worth introducing some practical tools.

The basic questions that we’re going to answer with Benefits Management are based around Return on Investment, whether that Return on Investment is in the form of better care, better patient or service user experience, or any of the other portfolio benefits listed for Apperta in section 4.10:

• What are the benefits? (of your project)
• What can you evidence and how can you present it?
• What do you need? (i.e. more funding, a test bed, tech support…)
• Who can help? (Commissioners, funding bodies, research teams, peer projects)
• What will tick their boxes / benefits will they value the most what language do they speak? (How can you best frame what you have to get what you need?)

A useful tool to use with a group of people, either together in a workshop or remotely, is Mentimeter (www.mentimeter.com).  The Benefits Manager will need to set this up with the right questions:

1)     Have a group identify the stakeholders, and rank their importance.  Mentimeter 2D scoring can be used on a voting basis to identify the stakeholders who are most relevant for the next stage

2)     Involve the stakeholders in identifying the benefits, both the ones most relevant to themselves and benefits of the project

3)     Involve the stakeholders in monitoring progress on realising those benefits

Most projects, whether ICT or otherwise, work by affecting people.  They may change the behaviours of care givers or care receivers, provide tools to help deliver care more effectively, or they may affect the health of the whole of a population.  The people affected are termed “Stakeholders”, and Stakeholders can refer to individual people, groups of people, or organisations.

The obvious stakeholders for all projects are: those whose behaviour is changed; those who make the change; and those who fund it.  But there may be many more, and it’s worth getting some definition on exactly which cohort, which subset of the population, fit into each subset.

Once you’ve identified the stakeholders, record how they are affected, how much, what they care about and will need to be informed about as the project progresses, and how they want to be communicated with. Managing a project is like walking a tight rope between the competing demands of the stakeholders, balancing up what you want to do (for end users such as staff and patients) against the limited resources you have (finite funding).  You can’t satisfy everyone.  But if you have a Stakeholder Register then at least you can make a conscious decision about the path that you are going to walk with your project.

Stakeholders can be identified individually, however it’s often easier and more productive to identify groups with the same interest as a group, and keep a separate communications group file (eg list of email addresses) so that the benefits expected can be updated without getting out of synchronisation (ie some of a group updated and others not).

The Stakeholder register needs to record how each stakeholder expects the project to impact them (column “Benefits/ disbenefits expected” for description, column “Stakeholder +/-“ for how much effect they expect).

The Stakeholder register also needs to record how much impact a stakeholder can have, since this will tell you how much you will have to respond to their demands (it’s a fact of life – someone will always want you to do it their way, and when you do it that way, someone else will complain.  You need to work out which battles to fight and which champions to back or you will wear yourself out and make no progress).  A very powerful stakeholder (column “Formal power in system”) can usually influence enough other people to get their way, if they have an “Interest” to do so, even if theoretically don’t have a direct “influence on the project”.  So the negative influence of to community pharmacy groups will probably not tip the balance in the end, because of their low influence both within the project and in the system.  Whereas it’s worth communicating closely with “Prof Greening, cabinet member for health” and ensuring that her concerns are addressed and she becomes  a supporter, because in spite of having other priorities (“interest” rated at not high), if she did take an interest she could reverse it with “influence” = high and “formal power” = high.

OpenStrategies approach

OpenStrategies is designed specifically for strategic planning in a multi-stakeholder environment, and offers an effective method of improving collaboration, reducing duplication of effort, engaging stakeholders, and delivering outcomes were facilitated bottom-up approach to strategic planning..

Open strategies based on the following principles, and incorporate them into the open strategies system:

• Communities are intelligently complex, not chaotic. They don’t require top-down management, and (given the right tools) can develop their own future in a collaborative, transparent, and strategic manner
• But planning needs to be open – to new ideas, new people, to time, space, growth, and of course to change
• The community will need to develop a common system and language
• The community needs an effective plan – one that will move them through actions and is results oriented
• Communities and groups of individuals can successfully collaborate on large-scale projects, including the diverse drivers, motivations and aims (explicit, implicit and hidden), and social signals, and collaboratively review and select which resources to work on, for which projects, and with which collaborators

More information can be found on www.openstrategies.com

Communication is vital with all stakeholders, especially the stakeholders directly impacted by the project and especially those with the most influence and formal power.  “Perception is reality” (Gomes & Romão, 2016), so it falls on the Benefits Sponsor (and therefore the Benefits Manager) to prepare communications and deploy them to manage perception. 

Newsletters

Newsletters, especially a number of different newsletters tailored to different groups, may seem to be time-consuming, but they are a lot less time-consuming than working on a project for years to have it cancelled by someone who didn’t understand it.  But be careful that the newsletters are consistent, and preferably there are no more than two (one for professionals, one for the general public) because people get suspicious if they think you are giving different messages to different people.

Structured interviews

It’s often helpful to hold semi-structured interviews with people to understand how the project is progressing, and whether the benefits are being realised.  The questions you are going to ask will enable you to update the entries for that stakeholder in the Stakeholder Register, in other words, whether they are being communicated with in the way that suits them (often enough, too often), what benefits they expect to achieve (compare what they say with what is recorded in the register), and any comments or suggestions they want to make about the progress towards delivering benefits, or decisions made about the direction and progress of the project.

The timing of these interviews and who you ask will depend on the likely impact that each interviewee could have on the project.

PRUB thinking

The PRUB process (Project, Result, Use, Benefit) is an effective way of mapping what’s going on within the community of stakeholders, and how the activities contribute to benefits (Seath, 2009).

PRUB is a simple way to engage the stakeholders and to present “one version of the truth” – all the projects, all the benefits, how they link.  It enables the project team and sponsors to work out which are the critical projects and benefits, plus how to understand what will make the most difference and determine investment on this basis.

PRUB is based on there being two “agents for action and change”: organisations, and the community.

Organisations do Projects, which are activities such as a gateway to health records, and produce Results, such as access to the health record.

The Community, Citizens or Customers then Use the results created by the organisation, for example read the information in the health record or record their own treatment actions, and achieve Benefits in the form of better patient/ service user experience, faster and safer care, reduced costs.

The diagram above shows that almost without exception, Benefits are not delivered by organisations. Benefits can only occur when citizens or clients engage with Results by using them. This means that two of the most important questions that should be asked when starting a project are ‘Who is going to use the result of this project?’ and ‘What evidence exists that this result will be used?’

One of the core strengths of PRUB is its ability to audit a single project or set of projects to ensure that it can be logically determined that the Results of Projects will be used and that therefore they will contribute to the desired benefits.

A quick Benefits Pathway

a quick way to understand the linkage between the initiatives in the benefits is to use a four-column map such as the one available in Amplify!’s benefit pathway.

In the example given below, the benefits of the portfolio already placed in the right hand [Benefit] column. In the left-hand column, the benefits manager can list problems that are brought about the need for these projects. With the start point and end point defined, what has to change and what has to be stopped can be added in a workshop environment. This can include a virtual workshop environment, as Amplify! Is cloud-based.

A full Benefits dependency network

The BDN describes explicitly the linkage between investment objectives and the related benefits (the ends), business transformation necessary to deliver the expected benefits and IS/IT capabilities (the ways), and the facilities that enhance the changes (the means). (Gomes & Romão, 2016; Gomes et al., 2013)

The components in each column can be described in detail according to the Infrastructure and Projects Authority

Or more simply using the Universities and Colleges Information Systems Association model and way of working up the map:

Once you have identified what the benefits are, you should create a Benefits Log.  This documents, for each Benefit, how it’s going to come about and what it depends on/ what depends on it.  This is vital for clarity (so you know how the benefit is going to happen), and also makes the benefit much more achievable (IPA, 2017 p.48).

The Benefits Register is just a compilation of all of the Benefits Profiles.

The most common entries in a Benefits Profile include:

1. Reference Number – needed when referring to Benefits in other Project documentation
2. Name – something descriptive which allows everyone to recognise the benefit without having to remember the reference number, a summary of the description
3. Description – a short description of the Benefit
4. Benefit Owner – this is the person or entity that has been given the authority to manage a particular Benefit and is accountable for doing so
5. Business Area – where the benefit will be realised, or the Business As Usual part of the organisation where the benefit will be realised and needs to be measured
6. Assumptions - Any assumptions made in estimates of cost or value, design of change required or availability of resources
7. Dependencies - Benefits usually depend upon outputs and therefore the projects that produce them.  A benefit may depend upon multiple outputs or even products and events external to the current project or programme. All such dependencies should be documented here.  Some benefits may also be required to achieve other benefits and any benefits or Organisation KPIs that depend on this benefit should also be listed
8. Costs – should be described to avoid double-counting in complex circumstances.  Ideally it should be possible to perform a value for money calculation, but if the relationship between the benefit and the project is complex then this may be more difficult.  Disbenefits (unavoidable negative consequences of change) don’t have costs to make them happen, but may have a cost for the mitigation
9. Measures/ Performance indicators – How will we measure the extent to which the benefits are being realised? This can be more opaque in health and care where benefits cannot necessarily be linked directly to financial gain.  Baselines and which way the difference is (eg is the improvement to reduce waiting times, or to increase the number of appointments) should also be recorded.
10. Value or Target – what is the aim or intention for this benefit?  This will be updated with actuals as the project proceeds.  This also highlights how the measures will be used.
11. Cross references and any supporting documentation – benefits are often designed at Business Case stage and realised months or even years later, by a different team.  It’s worth documenting supporting information so the rationale can be understood
12. Project Board Decision – a description of the action or comment from the Project Board concerning whether the Benefit is agreed upon, and/or has been delivered

 (Praxis Framework, 2015a; UCISA, 2016, p. 7)

A comprehensive Benefits Profile could also include: Stakeholders impacted; Enablers required; Outcomes displayed; Target Date; Current Baseline.  Note that gathering the data is often complex.  A MS Word document is useful to capture the text, but sometimes even a spreadsheet will struggle with the capture and recording of different measures and specialist Benefits Profile software is recommended.

1.1.1      Benefits Register

A benefits register is where you would put all of your Benefits Profiles.  It’s often convenient to use a spreadsheet for this, but a spreadsheet won’t easily take the amount of information that’s captured in a full Benefits Profile, and in any case a lot of the information is text-based and Excel (and other spreadsheets) doesn’t do paragraphs well.

If you aren’t using a specialist cloud solution for your Benefits Management, then the Benefits Register should contain a subset of the information in the profile, and if possible, a link to the profile. 

The following are suggested:

The Benefits Realisation Plan is essentially the sum total of the components listed above: Stakeholder Management; Benefits Map; Benefits Profiles.  The actions that are needed to keep the Benefits Realisation Plan current and effective are to: Measure, Monitor & Control, Evaluate, and Handover to the business.

Measuring benefits and compiling them into a Portfolio

Most Benefits Managers work on the benefits of a single project, or on the benefits of projects independently of any other.

The Portfolio Benefits Manager (see Section4.1.1 Project, Programme, Portfolio) has a requirement to compile the Benefits of many projects and programme and understand their contribution to the KPIs of the organisation and the overall benefits wanted. 

Many project managers and project boards want a dashboard to present the progress and achievement of benefits on a single page, perhaps using straightforward charts.  This can be done relatively easily in Microsoft Excel.

However if you want to do this across a whole portfolio, it does get more complicated.  This is where the power of a tool such as Amplify! (www.amplify-now.com) is very useful.  As well as the dashboards for individual projects, Amplify! will combine the results of multiple projects and display a dashboard of the whole portfolio along with the ability to drill down and follow through on, for example, the project falling the most behind on performance in a particular area.

Two of the features of open source is that information can be kept by the owner, and that APIs allow access to information in a documented manner. With appropriate access, information entered into the system by one organisation can be made available for reuse in a different context by other organisations – write once, read many.

If a specific cloud-based solution is used for benefits management for each individual project, it would be feasible for the Apperta foundation to combine the benefits from all of the projects and all of the information that it funds, into a number of high level KPIs which confirm or justify the funding that Apperta receives and distributes.  This would satisfy the Portfolio requirement.