Chapter 20

All Change: Realizing the Benefits through Transition

In This Chapter

Considering the purpose of Realizing the Benefits

Understanding the process for managing transition

Sharing responsibilities for Realizing the Benefits

In many ways this chapter is the big one, because it concerns the ultimate aim of all programmes: achieving outcomes and realizing benefits! More specifically, I show you how you can put that final work in business as usual into an orderly process. For ease of use, I split the process into pre-transition, transition and post-transition.

I address much of the information in this book at the Programme Manager (who, as I describe in Chapter 9, undertakes the day-to-day programme management), but this chapter mostly concerns the duties and responsibilities of the Business Change Managers.

Appreciating the Purpose of Realizing the Benefits

Realizing the Benefits is a little broader than you may at first imagine. Its purpose is to manage benefits from initial identification through to successful realization. Realizing the Benefits therefore starts as soon as you finish Defining the Programme, which I discuss in Chapter 7.

MSP uses an extremely useful and straightforward description of how to make the best use of project outputs in business as usual. As the process model in Figure 20-1 shows, the Realizing the Benefits process is broken into three simple steps:

1. Pre-transition. Business Change Managers make their preparations before they receive the outputs from projects.
2. Transition. Business Change Managers help make the changes happen.
3. Post-transition. Business Change Managers settle everything down again in business as usual and revert to being line managers.

This structure means that the process model is pretty straightforward. You take the project outputs, and of course all the information you have in your documentation, run through the three-stage process model and the benefits realized from your new outcomes emerge. Furthermore, you create stability too, because old ways of working have been removed and the new operations are stable.

The controls listed in Figure 20-1 are much more focused on the performance of business as usual and the benefits being achieved: virtually nothing to do with projects is shown.

You do need to monitor the progress of projects though, to ensure that the outputs are fit for purpose (that is, fit for benefit realization) and that you can integrate those outputs into operations. You also need to plan and manage the transition from old world to new world, which is a hugely important activity for any programme. To put it another way, you need to achieve outcomes while simultaneously maintaining business as usual.

So you require a level of operational stability as you move from old to new, and you also need to maintain operational performance. You have a massive amount of work to do.

Achieving the Blueprint

You can think of Realizing the Benefits as achieving the Blueprint (Figure 20-2 sums it up nicely):

• The Blueprint expresses the Vision as follows:
  • Process
  • Organization
  • Tools and technology
  • Information

  All this material is stated in objective terms, that is, with performance indicators such as costs and service levels.

• The benefits documentation describes how you can measure achievement of the Blueprint objectively:
  • Benefits Profiles
  • Benefits Realization Plan
  • Benefits Management Strategy

In Realizing the Benefits, the outcomes described in the Blueprint come to life, and you demonstrate objectively that you've achieved those outcomes by showing that you've realized the benefits.

Looking at the activities

In this section I put a little flesh on the bones of the activities in Realizing the Benefits (you may like to check out Chapter 17 and Figure 17-3, which is a diagram of transition).

You start with pre-transition, which is what you do in business as usual before you receive the capabilities that you can exploit; then comes transition and finally tidying up post-transition.

I look in detail at each of the activities in subsequent sections. But in the list below I summarise the activities in order to give you a feel for the types of things you need to do:

1. Manage pre-transition:
   • Analysis
   • Preparation in business as usual
   • Planning of transition
2. Manage the transition:
   • Deliver benefits
   • Support changes
3. Post-transition:
   • Review progress
   • Measure performance
   • Adapt to the change

Pre-Transition: Getting Ready

In this section, I look at each of the pre-transition activities in turn.

Establishing benefits measurement

The first pre-transition activity you look at is establishing benefits measurements:

1. Collect the data defined in each Benefits Profile using new or modified ways of measuring benefits if necessary.
2. Find that data and set up reporting. Watch out for the following series of potential pitfalls:
   • Is the data current?
   • Is it accurate?
   • Is it relevant?
3. Create a baseline of the performance when you have valid benefits measurement or, to be specific, create a baseline of the benefit using the new, modified or existing measurement mechanism.

Don't underestimate how difficult this process can be in the real world. I've seen this work take many months to get a valid baseline using a new measurement mechanism.

Of course you need some reporting via the programme, but eventually reporting has to go via business as usual, and your best bet is to start with parallel reporting to the programme and via business as usual.

If anything, make a point of ensuring that business-as-usual reporting is slightly ahead of reporting via the programme. Doing so encourages business as usual to take ownership. Business-as-usual reporting can also give you significant difficulties, so this step isn't one to underestimate.

Monitoring benefits realization

The second pre-transition activity is to monitor benefits realization and compare benefits with relevant parts of the following:

• Business Case
• Programme Plan
• Benefits Realization Plan
• Blueprint

Sometimes a debate arises as to whether to record benefits in the Programme Plan or the Benefits Realization Plan. I'm relaxed about where you record them. Just make sure that everyone who needs to know understands what you're doing in your programme.

Avoid recording the benefits in two separate places because inevitably that results in one set of data being different from the other set. If you must report benefits in two places, nominate one report as the master data and link to that data in the other report.

You're going to need to make adjustments if, for example:

• Outputs are unstable.
• The plan isn't realistic.
• External circumstances have changed.
• Programme objectives have changed.

By monitoring benefits realization you can have a benefit-focused dialogue with projects. Talking with projects isn't just about project progress; it's about whether projects are releasing outputs that ultimately allow you to realize benefits.

Planning transition: Factors to consider

The third pre-transition activity is to plan transition. Here's a brief list of factors to consider:

• Staffing levels and working practices
• Information and technology
• Creation of temporary facilities
• Cultural and infrastructural migration
• Integration with the Programme Plan
• Maintaining business operations
• Back-out arrangements (that is, arrangements for going back to the old-world state if moving to the new world state isn't successful.)

Don't underestimate what's involved in planning transition. You may need to trigger some very serious discussions in the business about how to keep it going during transition.

Communicating the changes

Programmes have a tendency to communicate a great deal at the beginning (during the Defining a Programme process), and then the communication tails off as the programme proceeds.

In this fourth activity in pre-transition I suggest you do the opposite:

• While the projects are creating outputs, you may have very limited need for communication with business as usual.
• As the time for the outputs to be delivered approaches, raise the profile of the programme in business as usual:
  • Communicate the changes that are going to take place soon.
  • Communicate widely.
  • Engage and involve stakeholders and don't simply pass them bland information.

If you have a Programme Communications Plan that lays out how this process is going to happen, you need to use it.

Take a realistic view of the time needed to overcome resistance. Also, raise the profile of communication early enough to be able to overcome sensibly that resistance to change.

Assessing readiness for change

The fifth pre-transition activity is to assess readiness for change. Here's a helpful little checklist of what to consider before you say ‘yes, we're ready to move into transition’. The sequence enables you to consider readiness from a more distant, historical perspective then move up to transition and finally look beyond transition at how things will settle down the future:

• Business as usual's track record in successfully delivering change.
• Individuals and the organization's experience of the type of change you're going to undertake.
• Capacity and capability of the resources in business as usual to accommodate change.
• Fit of the change with the existing culture:
  • Is it merely a mechanistic change or do you also need cultural change?
• Effectiveness of the support systems that have been put in place.
• Mobility, that is the flexibility, of the workforce.
• Current performance of business as usual.
• Performance of third parties and their alignment with the old world and the changes you're putting in place.
• Capability of service management to cope with change.

This list is comprehensive. Don't be surprised if it starts some pretty serious discussions in business as usual as to whether you really are ready for transition.

Transition: Embedding Change

Compared with the effort you put into pre-transition, the transition process itself can be something of an anti-climax. Indeed, the better you prepared during pre-transition, the more straightforward transition is going to be.

I can give you only a headline list of the activities in transition. You create a much more comprehensive list as you're going through your pre-transition planning.

For transition, you need to carry out the following:

1. Initiate transition, also considering whether the outputs are going to be ready from projects and whether you have your plans in place.
2. Activate support arrangements for the new ways of working.
3. Enact the transition.
4. Review whether transition is being successful.
5. Focus seriously on the achievement of the outcomes.

Actually do transition only when:

• Outputs are complete, ready and fit for purpose.
• Staff are trained and briefed.
• Outstanding risks and issues are owned by operations.
• Contingency arrangements are in place.
• Transition managements are in place.
• Senior Responsible Owner (with the Programme Board) has approved the start of transition.

Post-Transition: Stabilising the New Ways of Working

Here's a brief look at the post-transition activities. Although these are in sequence, they'll also overlap:

1. Continue measuring benefits through transition and post-transition. You made a start in pre-transition; hopefully the measurement mechanisms from the earlier section ‘Establishing benefits measurement’ are working.
2. Remove access to old world working practices and systems, so that people find using new working practices and systems easier than trying to revert to old ways of working. This can mean revoking access to old IT systems, physically removing old records or even stopping entry to old working areas!
3. Respond to changes in requirements (because the world isn't static).
4. Monitor and report benefits continually to the programme and through business as usual management.

Allocating Responsibilities Across Benefits Realization

As you may expect, the pattern of typical responsibilities for realizing benefits is pretty clear. The SRO is still accountable, and of course an interesting relationship exists between this person, colleagues on the Sponsoring Group and line managers of business as usual where these benefits are being realized.

Business Change Managers and the Business Change Teams are responsible for realizing benefits, so the Programme Manager reverts to being consulted or supporting. In the main the Programme Office is also consulted or supports: although on some occasions it's merely informed of what's happening in business as usual.