Chapter 7

Details, Details: Honing Your Programme

In This Chapter

Understanding the aims of Defining a Programme

Following the process

Linking benefits and projects

Planning your programme

This chapter covers the second process within the MSP transformational flow, Defining a Programme, which follows on from Chapter 3's Identifying a Programme. The Defining a Programme process is, broadly speaking, where you carry out the detailed work to plan the programme. I lead you step-by-step through deciding the programme's aims, understanding its various processes and planning it.

More is involved than simply planning an initiative. After all, the programme is going to involve a transformational change in the way your organization runs, so the programme itself may well need altered governance structures, a subject I also discuss in this chapter.

Figure 7-1 shows a process model. At first sight the diagram is a bit daunting. Don't worry about the activities or roles; I cover them all as you work through this chapter. The inputs are straightforward as well: they're just what comes out of Identifying a Programme. The controls are simply about getting approval for your programme. Finally I explain the outputs later in the chapter when I look at programme information.

Understanding Your Goals when Defining a Programme

At the end of the Identifying a Programme process, the Sponsoring Group has approved the Programme Brief and the Programme Preparation Plan (I explain that process in Chapter 3). The next step in the transformational flow is Defining the Programme.

Considering the purpose of Defining a Programme

The Defining a Programme process aims to:

• Provide the basis for deciding whether to proceed or not
• Explain the following:
  • What the programme is going to do
  • How it's going to do it
  • Who's involved
  • How it's going to be controlled
  • Why going ahead is justified

Using the Programme Definition Document

In order to justify the programme, you're going to consider the inevitable trade-off between resources, costs, quality, timings and benefits. Look at Figure 7-2 for a representation. You then present that balance to the Sponsoring Group and it represents the Group's contract with the Senior Responsible Owner (SRO; I cover these roles and others in Chapter 9).

The document that summarises the programme so that the Sponsoring Group can give a formal go-ahead is called the Programme Definition Document. This document involves more than a Business Case, which only shows that the programme is justified. The Programme Definition Document is more comprehensive, but still summarised, and also explains how the programme is to be executed.

Some organizations require a great deal of information to be presented to senior managers whereas others are happy with a summary. While some organizations put this information out for independent review and analysis, in others the senior managers want to look at it themselves.

If your organization's culture does want to see such a summary document, MSP defines it for you. The Programme Definition Document consolidates or summarises the information used to define a programme. The sequence of information shown below usually goes down pretty well with the Sponsoring Group, but it's not set in stone; feel free to alter this composition or sequence depending on how the definition of your programme goes:

• Objectives for the programme
• Executive summary
• Justification and context for the programme
• Criteria against which it can be measured
• Vision Statement
• Blueprint summary
• Programme roles and responsibilities
• Governance principles that have been applied
• Summary of the current state
• Explanation of tranche structure
• Description of outcomes
• Summary of risks
• Summary of Project Dossier (see the later section ‘Designing the Project Dossier’)
• Stakeholder summary
• Benefits Map
• Timescales, milestones and tranches
• Information baselines, status and content

Phew, that's quite a list! All these items seem relevant, but with so many topics to cover I'm often asked: ‘How on earth do we pull all this information together in a logical and structured way?’

The answer is that others and I have done this process before, and we've worked out a sequence that works pretty well: it's the activities in Defining a Programme. Of course you need to move backwards and forwards in sequence as you gather more information, but you can take my word that this sequence works.

I'm in preparation for running a couple of workshops for the senior management team of a company that's being spun off from a larger parent. The managers recognise that setting up their new company is a programme. I'm going to work through the activities in Defining a Programme with them.

When I briefed them on what I was going to do, and the sequence, they could see the underlying logic and were pretty impressed that I managed to come up with such a brilliant agenda. I didn't tell them that I'd worked it out by writing MSP For Dummies!

When you're defining your programme, use the sequence in the process model: it's a great starter for ten, but feel free to repeat the process, oriterate in MSP speak, if you feel you've learnt something new and need to modify some of your earlier models.

Gathering together programme documents and information

In this section, I lay out the full range of documents and information that you may gather as you run a programme. Understanding these documents and their interrelationships is useful before you embark on the sequence of steps or activities in Defining a Programme.

Take a look at Figure 7-3, which shows how all the documents that you use to manage the programme fit together. It's a complex but powerful illustration of your documentation and is worth becoming familiar with.

You can see that I split the diagram between Identifying a Programme (at the top) and Defining a Programme.

In the identification process, you look at the business strategy that leads to the Programme Mandate. You evolve the Mandate into a Brief in Identifying a Programme (as I cover in Chapter 3).

The programme is executed against a backdrop of corporate policies and corporate capabilities. In Defining a Programme, I break the documentation into three areas:

• Business design: What the business will look like in the future. The documents in this section include the:
  • Vision Statement.
  • Blueprint.
  • Benefit Profiles. These are key documents. The rest of the detail about the programme may be very fluid, but the Benefit Profiles – the benefits you'll achieve over time – need to be pretty static.

  The MSP boundary (the extent of the programme) goes a little further than just the business design to include:

  • The Mandate and the Brief.
  • A few composite documents such as the Business Case, Project Dossier, Benefits Map (a summary of the benefits) and Programme Definition Document.
• Governance area: Where you keep the strategies. Looking at the issue simplistically, you have one strategy for each governance theme. Although things aren't quite as straightforward as that, it's a good way of approaching this topic. The strategies are:
  • Stakeholder Engagement Strategy
  • Issue Management Strategy
  • Monitoring and Control Strategy
  • Information Management Strategy
  • Quality and Assurance Strategy
  • Organization Structure (for the programme, not the ‘to be’ state)
  • Benefits Management Strategy
  • Risk Management Strategy
  • Resource Management Strategy

  Just remember that sometimes one theme has two strategies, such as a risk strategy and an issue strategy, and sometimes a theme doesn't have a strategy: the vision theme for example.

• Management area: Every strategy has a plan. So you have:
  • Quality and Assurance Plan
  • Information Management Plan
  • Resource Management Plan
  • Programme Preparation Plan
  • Programme Communications Plan
  • Risk Register (in this case you've moved from a plan to a register). A Register is just the document where you record some information and keep it up-to-date. Your Risk Register is probably a spread sheet telling you a little bit about each of your current risks and what you're doing about them.
  • Issue Register (another register)
  • Benefits Realization Plan
  • Stakeholder Profiles (okay, these aren't called plans, but they're still details about stakeholders)

  All these items come together and feed into the Programme Plan.

Investigating the infrastructure for Defining a Programme

I cover the step-by-step activities to create the initial versions of these documents during Defining a Programme in the later section ‘Carrying Out the Defining a Programme Sequence’. Here I look at setting up the process (to discover wrapping it up, check out the later section ‘Getting approval to proceed’).

Generally, Defining a (major) Programme may take half a dozen people six months. You'll find that you can survive hand-to-mouth during this period, begging, borrowing and stealing resources in order to complete programme definition.

But the most efficient approach is to seek agreement when drafting the Programme Definition Plan to get resources such as:

• Computers and other office equipment
• Configuration management
• Definition team
• Offices
• Software

For an insight into the importance of getting a programme's infrastructure sorted, read the nearby sidebar ‘The importance of infrastructure’.

Knowing who does what

When describing each of the activities in Defining a Programme, I refer frequently to ‘you’, the reader. But when you start to form a small team, you need to know who does which activities and takes which responsibilities. Here's a brief introduction (I describe these roles in more detail in Chapter 9):

• The SRO is accountable for everything.
• The Programme Manager is responsible for everything (with a few exceptions).
• The Business Change Managers are responsible for the benefits-related activities.
• When the Programme Manager is responsible, the Business Change Managers are consulted and vice versa.
• The Programme Office mostly supplies support.

Carrying Out the Defining a Programme Sequence

The heart of Defining a Programme is to amplify the Vision into the Blueprint and then identify the projects needed to provide the capabilities that are missing from the ‘to be’ state the Blueprint describes. In parallel, you can also work out the benefits associated with the ‘to be’ state.

You can then balance the programme costs, the majority of which come from the projects, and the benefits in the Business Case.

Identifying the stakeholders

The first step is to do a little more to identify and analyse the programme stakeholders (following on from your initial work with stakeholders when Identifying the Programme in Chapter 3). You need to build on that initial stakeholder engagement work with the programme team to carry out a more rigorous stakeholder analysis. You can find more on stakeholders in Chapter 14.

This is an iterative process. Iteration means that you jump right in and have a quick go at getting an answer that's good enough. After you've done that you'll know more. You may have to do a bit more detailed work – another iteration. Or your initial attempt may be good enough. Do your initial stakeholder analysis with the core programme team. If you identify stakeholder groups with high interest in and influence on the programme, invite them along to carry out further stakeholder analysis with you. Doing so reinforces your communication links with them and shows that you respect their importance.

Refining the Vision Statement

As you go through the Defining a Programme steps, you can expect the Vision to change – not in overall concept, but in the detail.

Therefore, look out for opportunities to:

• Refine the outline Vision Statement contained in the Programme Brief
• Focus on the beneficial future state

Developing the Blueprint

I look at Blueprint design and delivery in detail in Chapter 6. Here, I concentrate on the sequence of actions you may want to take, because my focus in this chapter is the process.

I recommend building on your Stakeholder information (see the earlier section ‘Identifying the stakeholders’) to put together a Blueprint workshop. The initial workshop can be quite short. Sometimes a few hours is enough for you to brainstorm the top-level future state Blueprint: processes, organization, tools (technologies if you prefer) and information. You can even simplify things further and produce just an outcomes model at the top level.

If this workshop is a success, attendees are going to be willing to come along to subsequent workshops to put more detail on the Blueprint in parallel with the work you'll be doing on benefits and projects. In this way you develop increasing levels of detail – you iterate.

Modelling the benefits and Benefits Profiles

I tend to find that more senior stakeholders are willing to participate in the Blueprint workshops I describe in the preceding section. On the other hand, slightly more junior stakeholders are likely to come along to the parallel series of workshops on benefits.

In Chapter 15 I look at the modelling techniques you use, but here I'm looking at the sequence. This process involves another series of iterative workshops that put on increasing levels of detail.

I prefer to plan half-day workshops. Anything longer and attendees have to work too hard.

Here's the sequence:

1. Create a benefits breakdown structure at the top-level benefits workshop and turn its top level into a Benefits Map.
2. Your benefits expert, which may just be you at the moment, needs to review the logic in the benefits model before the next workshop and circulate it to the workshop attendees for approval.
3. Conduct a series of benefits modelling workshops going down into increasing levels of detail.

The benefits breakdown structure helps you to be clear on what these levels of detail are. At each level, you can create a Benefits Map. In a simple programme, you may be able to get away with a single Benefits Map, but in my experience more complex programmes need a series of maps: some at a high level for sharing with more senior stakeholders, others in more detail to get to grips seriously with what's going on.

During the mapping workshops, take note of who's expressing most interest in each benefit. They're potentially the benefit owners. Your next step is to set up a series of workshops with the owners of each of the high-level benefits to create one Benefit Profile for each benefit at each workshop.

When validating the benefits:

• Ensure that each benefit represents an aspect of a desired outcome.
• Bear in mind that non-strategic benefits may divert the programme.
• Assess the trade-off between the cost of realizing and measuring the benefit versus the value of having the benefit.

Designing the Project Dossier

The Project Dossier is where you go to find an authoritative list of the current projects in your programme so that, for example, you know what you intend to kick off in the immediate future. The Project Dossier is the next item to create, after modelling the benefits (in the preceding section).

From the Blueprint you can identify capabilities, required in the future state but not present in the current state. You can cross-check that these capabilities are essential if you're to realize particular benefits, identified by stakeholders as being in the Benefits Model.

Capabilities go into a big pot (a metaphorical one of course, otherwise it may get knocked over – think of the mess!). Then you break them down into outputs and put those outputs together again into candidate projects. Next you can run a little gentle scheduling to see whether:

• The timings of the projects are achievable from the project perspective within the constraints of budget, resource risk and so on.
• The capabilities are available in business as usual in time to allow the benefits to be realized quickly enough and also to fit in with any business constraints.

I look at how you plan the Project Dossier in Chapter 10. To round off this activity, however, I run through its purpose and composition.

Purpose of the Project Dossier

The purpose of the Project Dossier is really pretty straightforward: it's a list of projects required to deliver the Blueprint with high-level information and estimates.

Composition of the Project Dossier

Experience shows that recording slightly more than a list of projects in the Project Dossier is useful. Therefore, the composition is as follows:

• List of projects.
• Outputs and resources (at least an outline).
• Timescales and dependencies. Again I'm talking here about critical timescales and dependencies when viewed from the programme level.
• Initial requirements for each project, from the Blueprint.
• High-level budgets.
• Contribution that the projects make to outcomes and benefits – usually some sort of matrix that maps project outputs onto outcomes and then onto benefits.
• Issues and risks, but again high-level programme level issues and risks.

Identifying tranches

Carrying on along the same lines as when grouping outputs into projects (see the preceding section), you next need to group projects into tranches. I cover tranches in much more detail in Chapter 10. The capabilities delivered from early tranches can usefully be pilots that help explore, prove or disprove particular approaches to achieving the Vision.

A tranche delivers a step change in capability into business as usual.

Deciding on the Programme Organization and Governance

Your programme definition is progressing well when you reach the point where you're:

• Fleshing out the Vision of the end state in the Blueprint.
• Expanding the benefits model into Benefit Profiles
• Putting together the Project Dossier and seeing the tranches emerge

In this section I cover the next few steps of compiling the programme organization and how you plan to run the programme, which means producing the governance strategies that relate to each of the themes.

Designing the programme organization

Figure 7-4 shows an extremely simple model of a programme's organization.

This highly simplified diagram hides a wide variety of sins. Although I have seen a simple programme for a charity being run by a few part-timers, I've also been involved in programmes with many hundreds of people working in the central programme structure. Take a look at Chapter 9 for more details on the additional posts you may need to start defining.

Developing the Programme Governance

You have to decide how your programme's going to be run in practice – and, indeed, how you're going to explain to people how the programme is to be run.

To do so you document your approach, your strategy, for each of the different aspects of the programme. In order to maintain alignment with existing corporate strategies, you may simply be saying how those strategies are to be applied in the particular circumstances of the programme. But if you're programme is more radical, you need to explain how the approach in the programme differs from the familiar approach in the ‘as is’ state.

You need to create strategies – that is, explain how you plan to manage each of these aspects of the programme:

• Benefits management
• Information management
• Monitoring and control
• Quality and assurance management
• Resource management
• Risk and issue management
• Stakeholder engagement

Strategies aren't abstract theoretical documents – though I was once given an assignment to write a set of theoretical strategies for a programme that, not surprisingly, was rapidly abandoned. In a successful programme, you need to document the results of your negotiations with experts in each field on the approach you're adopting; these are your strategies.

I discuss each strategy further in the chapter on the related theme, but as I don't cover the Resource Management Strategy elsewhere, I look at it briefly here.

The Resource Management Strategy covers how the programme is to acquire resources. The more you can agree in this document, the less tactical scavenging for resources you'll do later in the programme:

• Assets required
• Cost and expenditure profile
• Dispute resolution
• Funding requirements
• How resourcing is to be achieved
• Human resource management
• Internal/external mix
• Procurement approach
• Resource profile
• Skills and knowledge transfer
• Subject matter experts required
• Technology and services required

Planning, Planning, Planning!

As you near the end of the Defining a Programme process, you need to pull together the various plans for moving on.

Developing the Programme Plan

The Programme Plan is the detailed, central plan that you probably expect to see in a programme.

Here's the purpose and composition of the Programme Plan:

• Purpose: Controls and tracks progress and delivery of the programme and the outcomes.
• Composition:
  • Programme schedule
  • Dependency network
  • Cross reference to the Risk Register
  • An explanation of project grouping
  • Transition plan
  • Monitoring and control activities
  • Programme tranches
  • Effort and cost
  • How the plan is to be deployed

Notice the transition plan, which describes how transition is to be carried out in business as usual. Consequently, the Programme Plan covers both the project area and business as usual.

Confirming the Business Case

This section focuses on pulling together the Business Case, which I discuss in more detail in Chapter 8.

You may well find that, on the first pass, the Business Case doesn't quite work and you have to return to the activities I discuss throughout this chapter. Figure 7-5 shows what you may need to do.

You start with the Vision, which is amplified into the Blueprint. From the picture of the future state, you can create Benefits Maps and Profiles and iterate them back into the Blueprint. Then you can put the Maps and Profiles together into the Benefits Realization Plan.

From the gaps identified within the Blueprint you can create a Project Dossier, which is integrated with the Programme Plan. You can now iterate between the Benefits Realization Plan and the Programme Plan to see whether you have a viable Business Case.

If you aren't getting a viable Business Case, you have a few options:

• Be less ambitious and design a Blueprint with smaller gaps between ‘as is’ and ‘to be’ states.
• Find a different approach that meets the constraints: more quickly, less cost, fewer threats, more innovation and you hope greater benefits.
• Iterate round, going back on the benefits and projects sides in the diagram back into the Blueprint until you achieve a viable Business Case or if necessary you can close the programme. This repeating loop is a useful one to bear in mind.

Preparing for the first tranche

Just before you leave the Defining a Programme stage, you need to prepare for the first tranche, which involves:

• Preparing to establish the programme governance and organization
• Acquiring the infrastructure for the next tranche
• Developing plans for:
  • Communications
  • Benefits realization
  • Overall programme
  • Resources
  • Quality

Getting approval to proceed

The final step in Defining a Programme is to get approval to proceed. In this section I propose a possible four-step process.

You may expect me to say that you need to get approval in accordance with your culture. Instead I'm going to say something different: you need to get approval to proceed in accordance with the governance strategies you create during the Defining a Programme process (see the earlier section ‘Developing the Programme Governance’).

Every organization gives approval to proceed in its own way, but experience shows that the following four-step approach is useful:

1. SRO and Programme Board (which comprises key managers within the programme) approve
2. Sponsoring Group endorses
3. Independent review
4. Sponsoring Group authorises

The first approval from the SRO and Programme Board is simply agreeing that the Programme Definition can be put to the Sponsoring Group for them to endorse it.

Endorsement doesn't mean approval – merely the Sponsoring Group saying that it's comfortable that the Programme Definition can go forward for an independent review to make whatever recommendations are appropriate. These recommendations are considered when the Sponsoring Group finally authorises further work on the programme.

You can see that the suggestion is for the documentation to go twice to the Sponsoring Group. You may find this approach useful, or you may discover that it doesn't fit with your organization's culture. But including independent review at such an early stage is a good idea.

At this stage, it really feels as though you've got your programme up and running!

See whether you can arrange the information about your programme into the documents I discuss in this chapter. If you spot any gaps, consider what activities you'd want to plan.