Chapter 2

Understanding What's Involved in a Programme

In This Chapter

Recognizing the reasons for programme management

Managing benefits within the programme

Thinking about documenting your programme

Describing the programme's end state

Choosing the sort of programme that's right for you

Most likely you haven't come across programmes before (as I define them in Chapter 1). Or perhaps transformational change in your organization has been run using a series of projects, with the change in business as usual taking place in a less controlled way. Understanding the differences between programmes and projects is crucial to successfully understanding programmes, so if you are uncertain about these differences, I suggest taking a look at Chapter 1 before reading this chapter.

In the sections that follow I give you a simple picture of what a programme is like and introduce you to some of these new ideas. I provide a helpful model for picturing a programme and discuss the benefits, documentation and various types of programme available.

Using the Ferguson Factory Model: What a Programme Looks Like

I want to share with you a model that I draw up for my clients when they ask me: ‘what's different in a programme?’ or ‘what do we have to do within the programme?’

I've evolved this Ferguson factory model over 15 years to help people understand the nature of programmes. But a word of warning! This isn't a simple little diagram. It almost certainly contains a whole heap of new ideas for you. Even if you've considered some of these ideas previously, you're likely to be unfamiliar with them all.

Entering the Ferguson factory

Figure 2-1 illustrates the Ferguson factory model. Come on in! I explain what each of the symbols means in the next section.

Exploiting capability

A programme starts with the Vision ‒ a high-level picture of the future.

The Vision is complemented by a Blueprint, which contains more detail.

This detail means that the Blueprint has to be created over time, so you're going to have incremental versions of it.

The dotted lines in Figure 2-1 mark the boundary between project world below the line (that is, the environment in which you're undertaking one or many projects) and business as usual above it (that is, the existing, everyday business environment).In project world you have a series of projects, which come together in something known as a tranche.

A tranche is followed by a second tranche and a third one.

Each tranche delivers capabilities.

Capabilities are exploited in business as usual to become outcomes.

The achievement of outcomes is measured as a benefit.

In order to achieve those outcomes, you're going to need to carry out transition (the planned activities that you can undertake to help people change from an old to a new way of working) within business as usual.

You then have another capability: more outcomes, more benefits management and more transition. All these elements are happening in business as usual.

Just a couple more elements. The Blueprint evolves over time and therefore you have early and intermediate Blueprints, the latter describing intermediate states as different outcomes are achieved.

Some projects don't deliver capability ‒ they deliver part of the Blueprint: if you like, it's a design project.

Only one more element to go.

Another little project or activity in business as usual delivers some early benefits perhaps even before you deliver capabilities.

This diagram may take a few hours to come to terms with, but if you understand even a little of what I'm discussing here, you're well on your way to grasping programme management.

Appreciating the Benefits

The trigger for any change initiative is that you want to create benefits – some value.

I use the term change initiative at the moment, because in the very early stages you may not know whether it's going to be managed as a project or a programme (flip to Chapter 1 for the distinctions between projects and programmes).

Understanding the central role of benefits

Benefits are a result of change; they don't occur in the case of the status quo, where nothing changes for years and everyone repeats the same process again and again, like the aptly named rock band. (In Chapter 15, I look at how you can make sure that your benefits are measuring change and not the status quo.) Therefore, benefits are the fundamental reason for a programme's existence.

Of course, benefits can be the trigger for any initiative, but the real test is whether the organization wants to manage benefits in a structured way, co-ordinated with structured management of the capability-delivering projects.

Take a second to read that short but rather involved paragraph again, because it contains some pretty important ideas. If the organization wants to manage benefits and projects within the same environment, you probably want to take a benefits- or outcome-driven approach to planning. In fact, you can say that the main focus needs to be on achieving change and that only a benefits- or outcome-related view can help you understand and manage change.

Now, of course, some organizations stick resolutely to a project view of the world. They think that a project's role is to build something and that exploitation of that something is someone else's responsibility. If that's the case, you aren't going to be able to deploy all of programme management. Sometimes an organization's culture is just too strong and rejects the idea that you can manage project delivery and achieve change in business as usual as part of the same initiative.

But I want to assume that the culture is going to accept co-ordination of the two sides of transformational change – projects delivering outputs on the one hand and those outputs being exploited in a managed way to result in benefits realization on the other – and have a look at what that means.

The key points are that:

• Change results in outcomes, because outcomes are defined as being a result of change.
• Benefits are how you count those outcomes.

For now all you need to do is to grasp these two ideas.

Programmes are about:

• Co-ordinating delivery from a set of projects.
• Integrating the outputs into a capability.
• Delivering the realization of a set of benefits.

Achieving benefits

You need to manage the achievement of the benefits, as opposed to simply waiting for them to happen.

To manage benefits, identify them fairly early in the programme, before change starts to happen. Then you may have to take a baseline measure of the benefits, using any new measurement methods you need to introduce. Consequently, as you go through the programme, you can measure the benefits in a consistent way, as follows:

• Change produces outcomes
• Measurable improvements are called benefits
• Programme needs active benefits management, which involves:
  • Identification of benefits
  • Baselining of benefits
  • Measurement of benefits

Avoiding the mistakes of others: Why change initiatives go wrong

Ask yourself why some organizations fail to deliver change and so fail to achieve the desired benefits. After you've listed your own reasons, take a look at the following list of why organizations fail to deliver change:

• Culture not being changed
• Insufficient board-level support
• Insufficient focus on benefits
• No widely understood picture of future capability ‒ no Blueprint
• Poor Vision
• Stakeholders aren't engaged
• Unrealistic expectations of organizational capacity and capability
• Weak leadership

Turn this list round: instead of seeing these problems as obstacles, view them as opportunities to fix problems and so achieve benefits. Programme management encourages you to focus on precisely these sorts of thing.

Documenting Your Programme

I can hear you stifle a yawn from here. Yes, I know that documentation sounds dull, but please don't skip hurriedly passed this section. Documentation isn't about bureaucracy: it's about sharing an explicit understanding of your programme with possibly a very wide readership.

Document only the things that you really need to record – information that you want to share with others. And don't record things twice. Record information once and, where necessary, link to that single source of information.

I'm not going to get hung up on the format of documentation (I talk much more about documenting your programme in Chapter 7). Very few people keep paper records these days, though it may be appropriate in certain circumstances. More likely, you carry out some form of information management from within a document or information management system. Just use an appropriate format given the size of your programme. (I cover information management in more detail in Chapter 13.)

I do, however, want to mention two useful documents to give you a feel for the type of documentation you create in a programme.

Planning for the upside: The Benefits Realization Plan

In a Benefits Realization Plan you record your plan for realizing benefits. Who said programme management was hard!

Figure 2-2 is a simple diagram representing a Benefits Realization Plan. A real plan is clearly more complex, but I hope that the figure illustrates how the benefits need to come together into a single co-ordinated plan that includes dates.

You describe each significant benefit in a Benefit Profile. (I cover the detail that goes into a Benefit Profile in Chapter 15.) You take all the Benefit Profiles, integrate them, remove the anomalies and double counting, and plot the benefits on one or more schedules in the plan. So, for example, if one benefit profile said you need 4,000 staff and another benefit profile said you need 5,000, you have an anomaly. Or if two different benefits link to a five per cent increase in turnover, is that a total ten per cent increase or are they both claiming the same five per cent? As you assemble your Benefits Realization Plan you resolve these sorts of anomalies.

Figure 2-2 shows costs. Strictly speaking, that's moving towards an investment appraisal in a Business Case, so people debate whether costs should be shown on the Benefits Realization Plan. On the other hand, the Benefits Realization Plan may need to show net benefits and hence, by implication, costs. This argument is really a technical point. You may find that you simply have to conform to the accounting rules of your organization.

Some experts say that the items marked below the line in Figure 2-2 are in fact dis-benefits. What's a dis-benefit? Well, usually benefits are how you measure an outcome that's perceived to be an advantage by a stakeholder. But other stakeholders may perceive some outcomes to be a disadvantage. For example, the Finance Director may be highly pleased with a benefit called reduced staff costs, whereas the staff would regard the resulting reduced pay as a dis-benefit.

Do you really want dis-benefits appearing so early in a programme? It depends on the programme. One thing's certain: if benefits and costs are being shown on a single graph (as in Figure 2-2), the vertical axis must be financial. Therefore, all these benefits are financial benefits.

Organizations often debate whether softer, intangible, indirect benefits can indeed be expressed financially, but the answer's usually decided by the culture of the organization in question. I can't give you hard and fast rules (sorry!).

You may want to note in your Benefits Realization Plan when programme closure happens. Benefits and dis-benefits continue to flow after the end of the programme.

Anticipating advantages: Benefits Management Strategy

The Benefits Management Strategy is one of the set of strategies you create during the Defining a Programme process (check out Chapter 7 for more on Defining a Programme). It documents your approach to realizing benefits and is the framework within which benefits are to be realized.

In broad terms, you may want to cover the following:

• Do you want benefits as early as possible, no matter what sort of disruption that causes?
• Or do you want to minimise organizational disturbance, even though that delays the realization of benefits?
• Does an overriding necessity exist to maintain services while you're putting in place the new world?
• What's the situation regarding existing projects? If you're running an emergent programme, you may have to cover this aspect in the Benefits Management Strategy.
• What sort of approach are you going to take to early benefits possibly being delivered even before you have delivered any capabilities (which I describe in the earlier section ‘Exploiting capability’)? Check out Chapter 15 for discussions around this idea.

Reaching towards the Destination: Vision and Blueprint

Figure 2-3 describes the programme environment rather neatly. Take a look first at the external environment (at the top) where political, economic, sociological, technological, legal or environmental drivers are causing your organization to function in a particular way. Working down the figure, these external drivers cause your organization to adopt certain strategies and policies and, more importantly, to change the strategic direction of the organization. That strategic change gives rise to one or more programmes.

The programmes, along with any standalone projects, are called the portfolio. A single programme has certain characteristics. It contains projects and has an effect on business operations. In addition, because the programme is long, you need to have a high-level Vision of the desired end state. That Vision may be supported by a more detailed description of the end state: a Blueprint.

I discuss the Vision in Chapter 5 and look in detail at the Blueprint in Chapter 6. You start to create the Vision right at the beginning of the programme when the most senior people in your organization decide to use programme management for a change initiative (check out Chapter 3 for more). You put the detail on the Blueprint when you're fleshing out the programme, which I cover in Chapter 7.

I give you a few more details on the Vision and Blueprint in the later sections ‘Viewing the Vision Statement’ and ‘Considering the purpose of the Blueprint’, but in the next section I want to examine briefly the context for a programme.

Aligning with organizational elements

Sometimes people talk about how a programme aligns with various organizational elements, which unfortunately is a pretty dry and abstract way of thinking about how the programme fits in with some of the critical aspects of the culture within the business.

Programme management aligns with three critical organizational elements: corporate strategy; the mechanism used to deliver change; and the environment in business as usual.

Corporate strategy

All organizations have an approach they want to take to moving the business forward in the future; simply put, this may be growth or expansion. Most organizations also have a more detailed set of corporate strategies. Each programme needs to align with corporate strategy: after all, programmes are about strategic change.

Delivery mechanisms for change

Each organization achieves change in different ways. The most familiar way of doing so is project management, even though many argue that project management is not, in itself, a particularly good tool for achieving change.

A whole range of less structured mechanisms exist for achieving change. Well-known methods include quality circles, lean and kaizen (continuous improvement).

As a programme manager you want to be aware of the mechanisms that are used in business as usual to achieve change, and then choose to fit in with those approaches or deliberately select a different approach. Whatever you do, you don't want to be ignorant of the way that change happens in business as usual.

Business as usual environment

Business as usual is focused on exactly that ‒ keeping day-to-day business going. Therefore, it looks at the efficiency and effectiveness of existing processes. The aim is to do the same thing again and again but increasingly well.

The programme needs to fit in with this environment while aiming for transformational change.

Role of programme management

Programme management balances the tension between running the business and changing the business, as well as managing the transition of outputs delivered by projects into the organization. It does so by breaking effort into manageable chunks (tranches).

Programme management also provides a framework for reconciling competing demands for resources.

Viewing the Vision Statement

The Vision and the Vision Statement are similar things: the Vision Statement is the document in which the Vision is recorded.

Purpose

The purpose of the Vision Statement is to communicate the end goal to all stakeholders. So it needs to be written in customer-facing terms ‒ by which I mean it needs to be understandable to ordinary people. (If you want an example of something that isn't written in customer-facing terms, just look at the terms and conditions of a piece of software – they're usually incomprehensible!) Think of it as an artist's impression of the future state.

Here's an example of the challenge of writing a Vision in the right way. Imagine that you need to compose a Vision about reducing the number of staff in the company in a way that's acceptable to the firm's staff. The answer may be to include something in the Vision about having to achieve levels of productivity that match the best in the industry. If productivity in the organization is currently lower than the benchmark and no hope exists of increasing market share in a flat market, staff numbers have to reduce as productivity is improved.

Composition

The composition of the Vision is pretty straightforward, partly because it has to be very brief: it's a clear statement of the end goal of the programme ‒ something short and memorable.

Perhaps you need to include any imposed constraints on the programme ‒ the situation in which the programme is being undertaken. You can expand on this external view by setting the context for the programme and project teams. Maybe you also require relevant information to help set expectations. You're trying to put the context of the programme into the broader business context.

Consider including information to support the justification for change, for example, a clear description of the unsustainable current reality.

Considering the purpose of the Blueprint

Formally the purpose of the Blueprint is to maintain focus on delivering transformation and business change. It elaborates on the Vision of the programme and may also be known as the target-operating model. Figure 2-4 illustrates the Blueprint.

Here's the dilemma. If the Vision is going to engage stakeholders, it needs to be short and memorable. As a result, it also has the added advantage of being more likely to remain stable. The disadvantage of a short Vision is that it lacks detail.

Therefore, you create and hold the detail in the Blueprint. At the beginning of the programme, you have very little detail in the Blueprint: it's just a simple amplification of the Vision. But over time, as additional work is done to understand the future state, more and more detail goes into the Blueprint. By the end of the programme, the Blueprint is a comprehensive description of the future state.

Moving towards drivers for change

Drivers for change isn't a motorist action group, but is about identifying the external factors that are pushing your organization to do things differently. A change initiative rarely affects only a single part of a business ‒ more likely you experience a string of knock-on effects. In Figure 2-5, I list the typical areas affected by a strategic transformational (in other words, big) change.

Identifying the drivers for change in your own organization is extremely useful and makes future changes less unexpected. Figure 2-5 contains a generic list of drivers for change, which you can use when you can't brainstorm your particular drivers.

Deciding on the Type of Programme

One of the difficult things to get your mind around is the sheer diversity of available programmes. Some are like projects (in that they mostly deliver outputs, but are so big that you break that output delivery into a number of projects and you need something sitting above the projects, which you call a programme). Others focus on changing society, with almost no project-like delivery of outputs. Some programmes are clearly defined at the beginning, whereas others only become clear partway through as the situation becomes better understood and pilot studies show what does and doesn't work.

Using the Programme Impact Matrix

When looking at the diversity of programmes, you may sometimes hear people talking about programme impact. Figure 2-6 show the range of impacts a programme can have.

Impact is related to the focus of the change and the predictability of outcome:

• Focus of change: This focus may be narrow, such as implementation of a technological solution, through to wide, such as affecting part of society.
• Predictability of outcome: This may vary between low, where a proven approach is being taken, to high, where complex, innovative or unpredictable outcomes are sought:
  • Specification led: Where the change is based on making and delivering something, you have low levels of ambiguity about what's being delivered. Nevertheless, complexity and risk still exist in the delivery.

    You may then want to use a scaled-down version of programme management in this situation.

  • Business transformation: Where the change is focused on changing business functions, the programme is Vision-led. Some ambiguity exists around the impact of the changes ‒ the greater the impact on customers, the greater the ambiguity and risk.

    MSP is designed for this type of programme.

  • Political and societal changes: Where the change is focused on improvements in society, predictability is reduced because of uncontrollable external factors. The scope may need to be adjusted as ambiguities are resolved.

    Programme management is extremely suitable for such high levels of complexity, ambiguity and risk.

Exploring programme types

Some programmes come about because you know what you want – you have a Vision. But other types of programmes exist; for example, a number of projects are bumping into each other, or several organizations have to work together. I explore these different types of programmes along with a few others here.

Vision-led programme

A Vision-led programme comes into existence when you have a clear Vision. Consequently, the programme is likely to be defined from the top of the organization and include the work of a number of different functional specializations; for example IT, HR and facilities management. In the private sector, it's linked to innovation, for example, new products and services. In the public sector, a Vision-led programme is probably triggered by political priorities necessitating the delivery of change to a population.

Emergent programme

An emergent programme comes into being whenever you recognise that a group of existing projects would be better managed together. In other words, an emergent programme evolves from concurrent projects. For example, you may recognise that in order to achieve change and deliver benefits a co-ordinated programme approach is more useful. By its nature, an emergent programme is transitory. Initially it pulls together a group of projects, but when stable it becomes just another programme.

Compliance programme

A compliance programme is often known as a must-do programme. It arises because the organization has no choice but to change as a result of an external factor such as new legislation. The benefits associated with a compliance programme are factors such as compliance with legislation or even the avoidance of an undesirable consequence, such as a fine.

Multi-organization partnerships

A multi-organization partnership isn't a separate category of programme, but programme management is often used when a number of organizations need to co-ordinate. These organizations share a Vision for the outcome of the programme, but each participating organization has its own business objectives to achieve. These objectives are complementary to the overall Vision, but may not encompass all that Vision.

Checking out the characteristics of a programme

This section describes briefly some of the key characteristics of a programme.

Consider having a look at the change initiatives that are going on around you and check how many of these characteristics each one has. I bet that many of the change initiatives that are called projects now feel much more like programmes.

A programme has the following characteristics (I expand on each of these items throughout this book):

• Focus on strategy
• Vision and Blueprint within a boundary
• Governance through strategies and standards
• Business case focused on benefits
• Timescales loosely defined
• Risk management focused on risk aggregation
• Issue management focused on inter-project issues and benefits
• Planning to deliver outcomes through tranches
• Quality focused on processes
• Stakeholder engagement is wide
• Benefits delivery

Linking programmes, projects and business as usual

Figure 2-7 shows another view of a programme, to help you understand how the elements in your programme fit together. Changes at the corporate level trigger a programme. Within the programme you have a variety of projects going on. Those projects deliver products, outputs or deliverables.

But you know (from the earlier section ‘Exploiting capability’) that you want to achieve outcomes, and outcomes appear not in project world but in the real-world operational environment. In more detail, you need to achieve outcomes, but those outcomes come into place when you exploit capabilities. That exploitation of capabilities happens in business as usual. But the exploitation of capabilities also happens within the programme.

Business Change Managers carry out the business change and exploit the capability in order to achieve the outcome. Therefore, the Business Change Managers need to work in project world and in business as usual, and consequently the programme management happens in project world and in business as usual.

Now try it for yourself:

1. Describe the context of your programme. You can do a PESTLE (political, economic, social and technological, legislative and environmental) analysis or a SWOT (strengths, weaknesses, opportunities and threats) analysis if you're familiar with these.
2. Identify the drivers for change for your programme.
3. Identify the areas of the business that are going to be affected.
4. Decide what type of programme it's likely to be and its impact.