Chapter 1

Introducing Programme Management: Projects, Programmes and MSP

In This Chapter

Thinking about the differences between projects and programmes

Discovering the key programme management terms

Uncovering the structure of MSP

The term programme can have lots of different meanings in business and within organizations. Perhaps you think of a programme as a schedule in the heart of a project. Be careful if that's what your colleagues think ‒ they may consider Managing Successful Programmes (MSP) a scheduling tool! Or it can mean a set of projects, which is fine because you can use parts of MSP successfully to look after such a set. Let's call that multi-project management.

In this chapter, I explore the nature of programme management. I look at projects and programmes, building on the idea of a project to introduce the concept of a programme. I also share with you a few terms used frequently in programme management, to help you develop that all-important common vocabulary, and I have a quick look at the programme management structure as it's used in MSP.

If you already have a fair amount of programme experience and are reading MSP For Dummies to discover additional details of good practice in managing transformational change programmes, by all means skim rapidly through this chapter.

But more than likely you're newly arrived at the programme management station and want to orientate yourself. Well if any of the following applies to you, you're in the right place:

• Your project is getting a little complicated and someone at work mentions programme management (perhaps at the coffee machine while you're waiting for a so-called espresso that in fact looks more like washing-up water when it's dispensed).
• You're looking after a number of projects and really want to tie them together a little more tightly (as much as you really want a caffeine boost ‒ right now).
• You know that your business has to change and your gut feeling is that putting a few people to one side to deliver a technical solution from a project isn't going to suffice (just like that machine-produced cup of joe won't do).

Understanding Projects and Programmes

Whatever your level of programme management experience, no doubt you already have some ideas on the following:

• What a project is
• What a programme is
• What the difference is between a project and a programme

As you read through this book, I share some new ideas with you, and so I want you to be clear in your own mind about genuinely new ideas or ones you have some previous experience of.

Start by folding a piece of paper in half. Label one half ‘project’ and the other half ‘programme’. Then write down a characteristic of a project and the equivalent characteristic of a programme. Repeat this exercise until you've identified six to twelve sets of characteristics.

Take your time with this important exercise; perhaps leave the list on your bedside table.I bet you wake up in the middle of the night (especially if you read the list before trying to sleep) and think of another pair of characteristics.

Whatever you write on your comparison list is fine; this is your starting point, so there are no wrong answers.

Don't send me your lists (please don't!). I've done this exercise with thousands of people all over the world, so I'm getting pretty good at guessing what gets written on these pieces of paper.

Checking on the characteristics of projects

Here's a fairly typical set of project characteristics:

• Projects are finite; they have a defined start and finish.
• Projects deliver a predetermined product, service or output.
• Projects have a clear development path.
• Project benefits accrue at the end of the project or afterwards.
• Projects have a shorter timescale than programmes.

You can have, and I frequently do, a debate about each of these characteristics; they aren't set in tablets of stone. This list serves my purpose for now by giving us a point of comparison for the characteristics of programmes (look at the later section ‘Working out programmes’ characteristics’).

Definition of a project

Your programme contains one or more projects, and so you may as well have a definition of a project to hand.

A project is a temporary organization created for delivering one or more business outputs according to a specified business case.

Note that the word ‘business’ appears twice in the definition: you only do projects because they make business sense.

Project constraints

When discussing project characteristics, people often mention that a project is time-constrained, temporary or has a start and end; perhaps even that a project is fundamentally defined by time. Let me put that another way: whenever someone mentions the scope for a project, do you tend to come up with an inevitable and reasonably fixed timescale?

This is the way many people see projects, but I like to think about them in a different way. I consider project constraints as performance targets.

I suggest that a number of different elements of a project exist that can be constrained and which the project manager may have to manage. I show the project constraints in Figure 1-1, and discuss them below:

• Time. The obvious one as just mentioned.
• Scope. The need to deliver a certain amount of functionality, for example, adding an online store to a company website.
• Quality. The fitness for purpose of deliverables or perhaps even the rigour with which fitness for purpose is demonstrated.
• Benefits associated with the deliverables. They may be defined quite rigorously so that you have to achieve a certain amount of saving, for example, or may be quite vague, for example, if you're putting in place a new marketing image.
• Resources. To put it narrowly, the costs available to carry out the project.
• Risk. You may have to reduce the risk and the project or taking some risks may be acceptable.

You can put these constraints in some sort of order, because certain constraints are more constraining and others less so, which increases the amount of flexibility when a project is executed. (The question of how a programme constrains projects is discussed in Chapter 10.)

Working out a programme's characteristics

Here's a typical list of the characteristics of a programme:

• A programme is bigger than a project; people use terms like strategic when talking about programmes. Bigger change initiatives are more likely to affect the whole organization and its future direction. That's the sort of thing people mean when they talk about something being strategic.
• A programme has a vision of an end state.
• A programme's end state may be some distance in the future and therefore it involves uncertainty: no path is defined to that end state.
• A programme can involve changing culture, working practices, business operations and services as well as delivering outputs.
• A programme needs to co-ordinate the output delivery from a number of projects so that benefits can be realized during the programme and afterwards.
• A programme may give you an opportunity to include infrastructure projects that don't directly deliver benefits.
• A programme's timescale is longer, possibly much longer, than a project's.

Check out Chapter 2 for loads more info on what a programme is.

Definition of a programme

A programme is a temporary, flexible organization structure created to co-ordinate, direct and oversee the implementation of a set of related projects and transformational activities. Its aim is to deliver outcomes and benefits related to the organization's strategic objectives.

Now that's a pretty long definition, so I break it down into chunks to understand what it's about:

• A programme contains a set of projects and so is liable to be large. Therefore, you're talking about something that relates to strategic objectives.
• A programme is an implementation of a set of related projects and transformational activities to co-ordinate in business as usual. Doing one or more projects may not be enough. Projects give businesses the outputs; the ammunition if you like. Business then has to fire the gun; it has to transform or, to put it simply, to change. You do all this to deliver outcomes and benefits (defined in the later section ‘Being Clear about the Four Central Terms’).
• Despite being large, the programme is still a temporary organization. It needs to evolve over time as its goals change and as the organization changes.
• The programme has to manage. In other words, it must co-ordinate, direct and oversee the work to deliver the projects and to do that transformation in business as usual.

Nature of a programme

You can start to see that a programme covers a much wider range of issues than a project.

A programme isn't just a big project.

I discuss this wider range of issues throughout this book, but some of these aspects of programme management may already be occurring to you. If so, tick them off against this checklist:

• Focus on strategy
• Vision and Blueprint within a tranche boundary
• Timescales loosely defined
• Risk management focuses on risk aggregation
• Issue management being orientated towards inter-project and benefits- related issues
• Planning to deliver outcomes through tranches
• Benefits delivery
• Governance through strategies and standards
• Wide stakeholder engagement
• Quality management spreading out to look at processes
• Business Case focused on benefits

Don't spend too much time yet on the checklist, because it contains lots of terms and subjects that I explain later in the book. As you move on through the chapters, you may like to come back to this list to see whether you're building up a picture of what a transformational change programme can be.

Being Clear about the Four Central Terms

Four terms are crucial to understanding programme management:

• Output. An output is simply something that is made or produced. It's also sometimes called a project deliverable or just a product. This term will be familiar if you've worked in a project environment.
• Capability. A capability is a complete set of outputs. If outputs are a project view of what's made in a project, you can think of the capabilities as being the business-as-usual view of a collection of those outputs.
• Outcome. A new operational state (some people define it as the effect of change). Outcomes are vitally important within programme management. They're the result of change normally affecting real-world behaviour and/or circumstances. They're a manifestation of part or all of a new state conceived in a programme's Blueprint.
• Benefit. A measurable improvement resulting from an outcome perceived to be advantageous by some stakeholders and which contributes to organizational objectives.

Following the projects-to-benefits-delivery sequence

The delivery sequence, shown in Figure 1-2, adds gloss and context to the terms:

1. You deliver outputs from projects. Output is a term relevant in the world of the project. While it's still relevant in programmes, it isn't the be-all and end-all. After you've got the outputs from the projects, you're about halfway through the heavy lifting.
2. You produce capabilities, which are one or more outputs from the point of view of your business as usual.
3. You exploit capabilities so that they become outcomes. (Outcomes are significantly different from outputs).
4. You measure the achievement of outcomes as something quite specific: benefits.

The last two activities take place within business as usual and not within a project.

Programme management is project delivery plus capability exploitation to achieve outcomes and benefits.

Comparing outputs, capabilities, outcomes and benefits

Take a good look at Table 1-1, which is really useful in enabling you to think about the differences between outputs, capabilities, outcomes and benefits.

Study the table and then try completing a similar one for your initiative, identifying the outputs, capabilities, outcomes and benefits for your programme.

Seeing the Structure of MSP

In this book I don't just talk about programme management in general; I look particularly at programme management as it's described in Managing Successful Programmes (MSP).

The MSP framework ‒ the method if you prefer ‒ consists of three concepts or elements:

• Principles. The common, universal and high-level factors that underpin success. They guide the organization on what to aim for.
• Governance themes. Help an organization put in place the right aspects of programme management. They include aspects such as organization and planning and control.
• Transformational flow. Provides a route through the life-cycle of a programme, from conception to delivery and closure.

Discerning the factors for success: Principles

MSP covers some pretty big ideas, which are universal, self-validating and empowering. These principles emerged as people like you learnt from their experience of managing programmes.

I look in depth at the MSP principles in Chapter 4.

Creating the right aspects: Governance themes

Governance is the control framework through which programmes deliver change objectives and demonstrate to the corporate level of the organization that they're under control. You have to negotiate and manage resources and deliver outcomes and benefits in a changing environment. You do so by using the governance themes:

• Business Case. The vital test of the viability of the programme.
• Benefits management. Benefits of a measurable improvement resulting from an outcome at the heart of the programme.
• Blueprint, design and delivery. The Blueprint is a description of the future state and expansion of the Vision.

  Be careful that the Blueprint isn't a plan for reaching that future state.

• Leadership and stakeholder engagement. Stakeholders can affect or be affected by a programme. They even include people who simply perceive that the programme affects them. Engaging with stakeholders links to achieving the Vision, leading through transition, achieving benefits and using resources (see Chapter 14 for more on stakeholders and Chapter 17 for leading people through change).
• Planning and control. Key to the success of any programme, at the beginning and as it progresses (I discuss planning and control more in Chapter 10).
• Programme organization. Involves defined roles, clear accountabilities and responsibilities, management structures and reporting arrangements.
• Quality and assurance management. Ensures that the programme is working appropriately and stays on target to achieve its objectives.
• Risk and issue management. Uncertain events (risks) and unplanned events that have happened (issues) can affect the direction of the programme and you need to manage and resolve them.
• Vision. A picture of a better future; it's the basis of the outcomes and benefits of the programme.

Tracing a route through the programme life-cycle: Transformational flow

As illustrated in Figure 1-3, you can represent a programme as a set of processes:

• Realizing the Benefits. Where transformation or transition takes place.
• Delivering the Capability. From where projects are delivered.
• Identifying a Programme. Where the business decides to take a programme approach to an initiative.
• Defining a Programme. Where you set up the governance for the programme.
• Closing a Programme. Where you wind down that governance.
• Managing the Tranches. Where you look after each chunk of a programme. A tranche delivers a step change in capability.