CHAPTER 13

Design the outcomes

13 Design the outcomes

Figure 13.1 illustrates the design the outcomes process within the MSP framework.

13.1 Purpose

The purpose of the design the outcomes process is to establish solid foundations for the programme. This means enabling the organizations involved to understand the programme vision, benefits, risks, and the target operating model, including the gap between the current and future states, before starting to plan the programme in detail. This process is where the detailed definition and design work for the programme is undertaken. It is revisited at the start of each tranche to either validate the outputs or adapt them to new information.

13.2 Objectives

The objectives of the design the outcomes process are to ensure that:

• there is a clear and compelling vision for the programme, set out in the vision statement

• the benefits and dis-benefits of the programme are understood and documented

• the design approach has been decided upon and documented

• the risks to the programme have been captured in a risk register and analysed

• the target operating model (along with performance measures) is in place for processes, culture, organization, technology, infrastructure, knowledge and learning, and information and data

• the gap between the current state and the target operating model is understood and clearly documented.

13.3 Context

The design the outcomes process refines the initial vision statement, which is in the programme brief, and expands it into two things: a detailed future state comprising the target operating model, and a set of benefits to be realized. Each benefit is described in a detailed benefit profile. The links between benefits and project outputs, capabilities, outcomes, and organizational strategic objectives are shown in benefits maps. At this stage, risks will be identified and prioritized in the programme risk register. This is also the correct point in the process for learning from previous programmes, projects, and other work to be acknowledged and incorporated into the programme.

Throughout this process, the programme strategy and programme plans are likely to be updated. The programme brief is used as input to the business case.

Table 13.1 shows the inputs, activities, and outputs for the process.

13.4 Activities

13.4.1 Identify previous learning

The programme manager and programme team spend time identifying learning from previous programmes, projects, and other work to apply on this programme before proceeding.

13.4.2 Appoint the programme roles

In this process, the programme team will need to expand beyond the initial team which produced the programme brief. Specialist skills will be required, such as business analysts and benefits specialists, to help with the construction of the target operating model, analysis of benefits, and options analysis going forward. Skills which are unavailable locally will be brought in using temporary specialists. It is important to set up an infrastructure to support them to work effectively. This means organizing items, from office accommodation to office equipment and computers, and from software tools to configuration management solutions. In this process, the amount of information will grow significantly and the documents produced will depend on the contents of others. Version control will help to keep everything in sync so that people are working with up-to-date information.

13.4.3 Develop the vision statement

The vision statement builds from the initial vision in the programme brief. One way of developing this vision is to hold a vision workshop for the representatives of different stakeholder groups to explore the potential end-state of the programme. The outputs of this workshop should be validated before being included in the vision statement.

13.4.4 Identify and validate benefits

The vision statement, along with the initial benefits identified in the programme brief, guides the programme team to develop the benefits of the programme. A benefits map will show the links between outputs, capability, benefits, and strategic objectives so that these relationships are clearly understood before the benefits are validated. Creating a benefit profile for each benefit will develop and validate the benefit further.

13.4.5 Identify and prioritize risks

The programme team creates and maintains a risk register to capture those uncertain events that would affect one or more outcomes of benefit. The risk register is also used to keep a record of the risk exposure of each of those events and the responses planned. Risks identified in earlier processes are included if they are still valid.

To prioritize risks consider, as a minimum, an assessment of the likelihood of the risk occurring and an estimate of the size of impact on one or more outcomes of benefit.

13.4.6 Develop the target operating model

This step takes the vision statement and expands it into a detailed target operating model. This requires focus on several different aspects: processes, culture, organization, technology, infrastructure, information and data, and knowledge and learning. The work is likely to bring in a much wider range of people, from specialists in business analysis and architecture, to process analysts, organization designers, technology specialists, and data analysts.

13.4.7 Develop the programme strategy

Building on the initial work in the previous process (identify the programme), aspects of the programme strategy will be developed here, including the approaches to:

• governance

• stakeholder engagement

• design

• funding

• delivery

• resourcing

• information

• knowledge and learning

• assurance

• decision-making

• issue resolution

• risk response.

The programme strategy is developed in this process but is not completed, amended, or (re)approved until the plan progressive delivery process.

13.4.8 Develop the programme plans

During this process, the team will understand much more about the programme, including the vision, the target operating model, and its benefits and risks. This means that programme plans can be started during this process, although they will not be completed, amended, or (re)approved until the plan progressive delivery process.

13.4.9 Develop the business case

Building from the programme brief, the team will gather information about benefits, costs, and risks, and potentially reconsider some of the options explored when developing the programme brief. All of this information is important input to the business case which will be completed, amended, or (re)approved in the next process.

13.4.10 Prepare for the next process

The next process is a complex one where the overall programme is planned, and the first tranche is planned in detail. Programme justification also occurs in the next process. It makes sense to plan for the progressive delivery process here.

13.4.11 Agree to proceed (or close)

Formal approval to proceed means that:

• the sponsoring group approves the outputs from the process

• the sponsoring group authorizes and commits to resource the next process

• the SRO confirms that the vision statement correctly reflects the desired end-state of the programme

• the sponsoring group commits to supporting the next process in the programme lifecycle

• if formal approval cannot be given, the programme will close.

13.5 Responsibilities

Table 13.2 shows a RACI chart for the activities in the process, split between the core MSP governance boards, supporting offices, and individual roles.

13.6 Application of the themes in this process

Table 13.3 shows how the themes apply to the design the outcomes process.