Chapter 4

Focusing on the Principles of Programme Management

In This Chapter

Defining programme principles

Encouraging the necessary principles

Making sure that your programme improves

This chapter covers the principles of programme management – those universal, proved-through-experience, empowering concepts that underpin the whole of programme management. I describe what you can do to ensure that the crucial programme principles exist: aligning with corporate strategy, leading effectively, seeing and conveying a better future, achieving – and protecting – benefits, creating value and delivering a coherent capability. In addition, I point out that the programme needs to develop, adjust and improve throughout its life.

I cover powerful ideas in this chapter, some of which may seem a little daunting to achieve. But I hope that the discussions and examples in this chapter help you to see that living by these programme principles is entirely practical, thus encouraging you to apply the principles of programme management to your own programme.

No hard and fast rules apply to the principles. You just need to reflect on how you're going to utilise them in your programme.

Considering the Characteristics of Principles

When you come to set up a programme, you need to ask yourself a central question: what does a successful programme look like? Fortunately, the answer is fairly straightforward. You consider the principles that reflect the characteristics of a successful programme: the common factors that underpin the success of any programme of transformational change.

I worked with the authors of MSP to identify the principles that underpin programme management. We asked ourselves what differentiated principles from any other aspect of programme management. We came up with three conclusions that are in themselves useful if you're setting up and running a programme:

• Universal. Principles apply to every programme you come across, no matter how big or small, no matter what its impact. Principles have to be genuinely universal. They aren't aspirations to strive for, which some programmes may achieve but not others: they're the basics.
• Self-validating. Principles are proved in practice. They're not bits of theory picked up from a quick Internet search. Experts have observed these aspects of programme management in the real world and found that they really do work.
• Empowering. Principles give practitioners added ability or power to influence and shape transformational change. In other words, they aren't constraining. They don't tell you what you must do and limit your flexibility. Instead, they open up an area for you to think about and encourage you to be innovative in the way you align with the principles in your programme.

Ensuring that Your Programme is Principled

You need to make sure that your programme contains, provides and encourages a set of essential principles. In this section, I discuss six important features of all successful programmes. They:

• Tie up with your organization's overall strategy
• Display effective leadership
• Supply solid, lasting transformational change
• Bring benefits
• Deliver value
• Maintain a coherent direction

Keeping aligned with corporate strategy

Programmes can deliver outcomes and benefits of strategic significance for your organization. As a result, most programmes (though not all) are large and involve significant investment by the organization. Consequently, you're going to (and indeed should) face constant pressure to justify the programme. After all, if it's going to cost a lot of money, senior management may want to consider stopping it.

The best way to safeguard your programme is to demonstrate not only that the programme is aligned with corporate strategy, but also that it's essential if the organization is going to achieve its strategy.

Staying focused

Aligning a programme with corporate strategy isn't as simple as when you're running a project. Projects are relatively short and consequently relatively inflexible. In a project, you start out with an idea or perhaps even a design or a specification. You may identify options towards the beginning of the project, but then you build what you have designed so that it meets the specification or fulfils the idea.

I don't want to make project management seem easy – I know from experience that often it's not – but the nature of project management is that (unlike with most programmes) you're trying to build something that you already have reasonable understanding of. Even with a high-level programme Vision, some uncertainty is likely to exist about how you achieve that Vision. You'll probably require a considerable amount of time before you successfully complete the Vision. (I cover creating the Vision in more detail in Chapter 5.)

You hope that the Vision is fairly static, but the journey to achieve it may have many twists and turns. Furthermore, your organization's strategy may well change over the course of the programme. Consequently, you may have to confirm regularly and frequently that the programme, as it's currently understood, is indeed aligned with the organization's ever-changing strategic objectives. This confirmation of alignment is an on-going task.

Making a strategic contribution

If your programme remains aligned with corporate strategy, you can contribute to that strategy in several ways:

• Make a contribution towards achieving corporate performance targets.

  Different organizations operate performance management in different ways. Typically an organization has some high-level, strategic performance indicators – perhaps known as key performance indicators (KPIs). You may then have a hierarchy of lower-level performance indicators.

  A reasonably sized programme can't justify itself by making minor contributions to a series of low-level performance indicators. A substantial programme needs to make a difference to one or more strategic performance indicators.

  Therefore, you and the programme management team need to engage with the performance management function within your organization as follows:

  • Endeavour to understand the nature of the current strategic performance indicators.
  • Enter into a dialogue with the performance management team to agree the contribution your programme can make and how to measure it.
  • Consider talking with others who see their primary job as being to achieve the identified performance indicators. If a senior line manager's role is to contribute to a particular performance indicator, that person may not be willing to share achievement of that performance with a new programme.

    Additionally, even though discussions may have taken place in the Sponsoring Group when your programme was identified, at a working level you may need to be diplomatic. Don't try to tell senior line managers, who have an established position in the organization, that the programme is now in charge. Negotiate with them to understand their views and persuade them of the value of the programme.

  • Remember that this exercise isn't a one-off: you may need to maintain these links over a prolonged period.
  • Prove or disprove strategic ideas.

  For example, put in place a pilot of new ways of working. If it works, great! Roll out the new way of working across the organization. But if the pilot's unsuccessful, the programme has still made a valuable strategic contribution, because it's prevented the organization reorganizing into a structure that wouldn't have worked.

  Plus, the organization is sure to have certain strategic drivers, the things the business wants and needs to do with the highest level; for example, generating more business from the web. You can make sure that these drivers are extended to and understood in projects and business change activities.

An organization's strategy changes over time and therefore the programme must create a robust but flexible working environment. You need to establish what I think of as a porous programme boundary. The boundary is the limit of the effect of a programme; it needs to be porous so that ideas and scope can move in and out of the programme as the strategic environment changes (check out the later section ‘Seeing a different picture of benefits’ for more details).

Leading change

For an organization to undergo strategic change, it needs more than just management. Leaders in the programme need to lead that change actively. Here are just a few examples of the sort of leadership that your programme requires:

• Leaders need to give clear direction on where the programme is going. In other words, they must champion the agreed Vision.
• Leaders need to make sure that they're trusted. They do so in the dynamic and fast-moving world of the programme by behaving consistently and encouraging transparency. Discussing issues freely and evaluating risks openly requires courage, but such behaviour reinforces trust and demonstrates strong leadership.
• Leaders need to engage honestly with stakeholders. Which means talking to them and listening to them. People used to talk about stakeholder management, but today the preferred term is stakeholder engagement. From a leadership point of view you have to engage actively with stakeholders, listening to and valuing their perceptions of what's going on. A programme often focuses more on people than is the case if you're just running a project.
• Leaders need to accept that the programme is going to change significantly over time. They must appoint the right people to the team at the beginning of the programme. Programmes often need a rare mix of skills and abilities. You need to get that team in place while you're Defining the Programme, but you also have to adjust the composition of that team as the programme evolves.
• Leaders need to be comfortable with uncertainty. You can't run a programme using a Gantt chart (one of those diagrams showing when activities will occur that you often see around projects). Fundamental uncertainties exist within any major programme.

  If you're trying to transform your organization profoundly, you can't follow a predefined life-cycle based on a series of templates. The leaders need to be comfortable with the complexity and ambiguity in the early parts of a programme and make others in the programme team equally comfortable with uncertainty.

• Leaders need to understand that they can't know everything. Problems come thick and fast in a typical programme, appearing from all sorts of different directions within the programme – internal, external, from projects, from business as usual and from the design area. Leaders need the mental agility and sheer resilience to cope with and resolve an endless stream of problems.
• Leaders need to appreciate that business as usual has to undergo the painful activity of transition to new ways of working. They must understand the pain of this transition and support it.

  Never neglect or underestimate the amount of work that needs to be done to take the outputs from projects and embed them in business as usual.

I look in more detail at leadership within a programme in Chapter 17.

Envisioning and communicating a better future

Here's a useful way of looking at your programme's goal: if the new world isn't better than the old world, why are you going there?

Leaders need to envision and communicate a better future. So they need to describe a clear Vision of that future – what the world will be like when you arrive in the future state. But here I ask you to consider why you need to focus so much on the Vision – the better future.

Purpose of programme management

You can use much of MSP if you're managing a large specification-led change initiative. In that case, the emphasis is much more on a network of projects and subprojects. Programme management can do much more than that, however. Over the years the team of people who came together to create MSP have created a tool to allow you to achieve genuine transformational change.

Transformational change isn't about doing the same thing slightly better. It is, fundamentally, about doing something different. And I don't mean a couple of people in an organization taking on a new role; I mean hundreds or thousands of people doing different roles, in different places for different purposes. Programme management really does change the business. (I don't want to come across as a zealot – but then again I'm not sorry if I'm showing a real enthusiasm for the subject!)

Programme management is the best tool for achieving transformational change. No amount of project management or even portfolio management can help your organization become radically different. Only programme management contains, assembled from a wide range of sources, the tricks and techniques you need to change fundamentally your organization.

A better way of delivering change

In the preceding section I want to communicate how programme management can give you a better future, if you're involved in change delivery. I hope my passion and enthusiasm goes some way towards doing that.

In your programme, the leaders of the programme need to show similar passion and enthusiasm for the new future that you're all working so hard to achieve.

Doing so involves more than simply describing the future verbally. The leaders of the programme need to:

1. Record the better future.
2. Distribute it.
3. Listen carefully to the concerns of the wide range of stakeholders in the programme about that future.
4. Respond to those concerns by working with individual stakeholders and stakeholder groups, if necessary by altering the boundary of the programme to accommodate those concerns.
5. Ensure that the Vision is communicated clearly and consistently within all levels of the programme.
6. Keep the Vision current. Hopefully that means just making minor changes to the Vision to keep it fresh. If the Vision changes fundamentally, you need to reconsider whether the programme can still continue in its current form.

Communicating a better future is a challenge when you're trying to deal with stakeholders who may be nervous about the new future, but ultimately they'll see that the new future is indeed in their own interests. An even greater challenge, however, is communicating a new future with stakeholders who may be disadvantaged in the new world, or indeed may not even be part of it. Not everyone can be a winner in a transformational change programme.

Real leadership involves supporting such people as they come to terms with no longer being part of an organization's new world or must accept that the power they held in the old world is going to be diminished.

Programme leaders have to take the time to help people on the road to their new world.

Focusing on the benefits and threats to them

Programmes are about creating benefits. Therefore your programme needs to maintain a focus on the benefits and an awareness of what threatens them.

Seeing a different picture of benefits

Before I go on to talk about those threats (in the later section ‘Focusing on threats to the benefits’), I want to ask you to look at benefits in a different way. Benefits are one of the new ideas in programme management, and they're extremely important. You may not have dealt with benefits realization before or have a great deal of experience of managing change in a structured way, as happens when you do benefits management.

I cover benefits a little in Chapter 2 and a lot in Chapters 15 and 16. In Chapter 2, I show you the full version of the Ferguson Factory, but Figure 4-1 features a simple version of the model focusing on benefits that many of my clients find helpful.

Figure 4-1: Exploiting project capability.

The model shows a single project that delivers a capability. Capability is exploited in business as usual in order to achieve an outcome – the effect of change. You measure the effect of the change (that is, the outcome) via benefits.

In other words, a programme isn't about a predefined dossier of projects, the capabilities identified in the Blueprint or even a set of outcomes. A programme is about achieving a set of benefits.

As I describe in the earlier section ‘Making a strategic contribution’, the programme has a boundary. Within the boundary are the outcomes, capabilities, outputs and activities you have to deal with in order to achieve the benefits. The programme boundary is porous and may well change, in order to ensure optimum realization of benefits.

Areas of work move in and out of the programme as certain areas display opportunities for significant benefit realization. Remember that the ultimate success of the programme is determined by the ability of the programme to realize the benefits. Furthermore, those benefits need to continue to be relevant to the organization and align strategically.

Focusing on threats to the benefits

The programme needs to focus on benefits and threats to them such as late delivery of outputs, difficulty in implementing capabilities in business as usual or changing strategic priorities.

One way of doing so is to put benefits as an early agenda item for each Programme Board (whose role I describe in Chapter 9). If you do that you probably need to have benefits on the agenda of lower-level bodies in the programme and business as usual. In this way you can feed progress on benefits up through the programme to the highest level.

Adding value

If a programme doesn't add value over and above the individual projects, it doesn't justify its existence. Indeed at programme reviews, if you can't demonstrate additional value, people can see a reason for closing the programme.

But when your programme offers benefits over and above those from projects, you have programme benefits: ones that can't be claimed by individual projects but only by the programme.

Therefore, your programme has to manage the complete set of benefits being delivered, which also helps the programme to prevent double counting of benefits by projects.

I expand on this concept a little more here, by considering a number of standalone, but related, projects. Each of those projects has a project business case (which is different from the programme Business Case that I describe in Chapter 8; what difference a couple of capital letters make!) where the benefits associated with the project are described. (The benefits are expressed sufficiently rigorously so that they're not only claimed in the business case, but also demonstrated in business as usual after the project delivers its outputs.)

If you now group the projects into a programme you can add up the benefits from each of the projects and claim them as the benefits of the programme. At least, that's one approach.

But costs are associated with running programme management over and above project management. The programme needs to demonstrate that it can deliver additional benefits that more than outweigh these additional costs.

Here are some examples of the ways in which programme management can add value:

• The programme can make projects more efficient by:
  • Rapidly sharing lessons between similar projects
  • Centrally managing resources shared across the projects
  • Building once products that several projects can use
• The programme can make projects more effective by managing their scope more tightly. It can ensure that the projects only build capabilities that are essential for achieving the Blueprint.
• The programme can simplify the management of issues and risks that inevitably arise between closely related projects. I discuss these subjects in Chapters 11 and 12.
• The programme can centralise and streamline the planning of projects and also provide an effective route for reporting across multiple, related projects. I look at these subjects in more detail in Chapter 10.
• The programme can ensure that quality is achieved appropriately and consistently across the projects. This prevents some projects paying insufficient attention to quality management, perhaps because staff in the project aren't familiar with the concepts. The programme can also ensure that other projects don't gold plate their outputs by over-engineering outputs or putting too much emphasis on quality. I cover quality in Chapter 13.
• The programme can speed benefits realization by providing a focal point for managing benefits. In the Programme Office you may want to appoint a benefits co-ordinator. This person builds up experience of techniques associated with benefits management such as benefits modelling and reporting, which helps the Benefits Owners spread through business as usual to accelerate achievement of the benefits. Flip to Chapter 9 for more on programme roles.
• The programme can ease handover between projects and business as usual by putting in place a structure: the Programme Board where the Programme Manager and Project Executives can meet regularly with Business Change Managers to sort out the details of the handover from projects to business as usual and to build trust between those two communities.
• The programme can provide more effective engagement with stakeholders, particularly where they have an interest in more than one project, by providing centralised or co-ordinated stakeholder engagement. I provide more on this subject in Chapter 14.

You may be daunted by the prospect of having to demonstrate objectively the value that programme management brings over and above the value of project management. But I hope that this list helps you to feel more comfortable about identifying value from programme management.

Designing and delivering a coherent capability

With everything that's going on in a programme you can all too easily find different elements of the programme pointing in different directions. Therefore, the programme must design and deliver a coherent capability. You define that capability in the Blueprint, from where you can work out the scope of projects and the outputs to be produced.

The programme doesn't operate solely at the level of the individual projects; it needs to focus on the bigger picture. Nevertheless, it must also give clear direction to projects.

The Blueprint evolves over time and the programme must ensure that it delivers the current version of the Blueprint. If strategy changes to the extent that the capability described in the Blueprint is no longer coherent, or even no longer relevant, the programme may need to be stopped.

I cover the mechanics of designing and delivering a Blueprint in Chapter 6. But the principles apply across the full breadth of programme management, not to one particular theme. Therefore, in this section I explore some of the softer aspects of maintaining coherence.

A coherent Vision

At the risk of stating the obvious, everyone needs to be working towards the same Vision. But I take the risk because achieving this aim in practice is often a lot more difficult than it seems. I regularly come across programmes that lack a Vision, feature a poorly communicated Vision or even have several different Visions.

For many people a programme Vision is an alien concept. Business as usual may recognise the mission of the organization, but that may be significantly different from the Vision of one particular programme. Plus, projects often have nothing as inspirational as a Vision.

The programme management team needs to get across to the people working in and around the programme that the Vision is important and is something they need to think about and understand if the programme is going to create that coherent capability.

Coherent stakeholder engagement

Organizations are becoming more familiar with stakeholder engagement, from the point of view of business as usual and from within projects. Sometimes, the different groups within a programme can feel (wrongly) that they're engaging effectively with their stakeholders by communicating a local message. They communicate their understanding of the programme from the perspective of their project or business unit.

The problem is that this local message may be distinctly different from the overall coherent messages that the programme wants to communicate. I pass on two anecdotes, one good and one bad, which help you appreciate the significance of stakeholder engagement when establishing a coherent capability.

The first example concerns a programme that was operating on two sites a few hundred miles apart. One site contained the Programme Office and the other site had a small public relations (PR) team carrying out stakeholder engagement. The latter team was dedicated to the programme, but when I visited a beautifully designed and professionally executed road show that it was delivering, I was astonished to see that the PR team simply didn't understand the broader messages the Programme Office was trying to push out from the programme centre.

Two breakdowns in coherence were at work:

• The people at the centre assumed that the PR team understood what the Programme Office was about. The latter failed to recognise that it needed to treat PR staff as stakeholders and engage with them if they were to understand the breadth and detail of the programme.
• The PR team was communicating the wrong messages to all the stakeholders they came into contact with. The more enthusiastically the staff members worked to engage with stakeholders, the less coherent the messages became!

My second example involves a programme with many external stakeholders. Other organizations were interested in the programme, as well as local, national and international regulators looking at different specialist aspects of the programme.

The programme had put in place a system whereby one person was nominated as the point of contact for each stakeholder group. The programme made sure that each point of contact understood what the programme was about and consequently that person was able to maintain a link with the external stakeholders. As a result, the programme maintained coherence.

Learning from Experience

In this section I look at a programme principle that's slightly different to the six I lay out in the earlier section ‘Ensuring that Your Programme is Principled’, but is no less important. Instead of being a corporate aim that the programme needs to achieve – alignment, leadership, a better future, benefits, value or coherence – this principle is something less tangible that the programme has to do. Your programme (and indeed you) must learn from experience to produce a learning organization.

You need to adjust the programme's approach to each individual theme based on previous experience, building into its review mechanisms opportunities to reflect on experience.

Demonstrating maturity

The ability to learn from experience often reflects the maturity of programme management. Programme and project management maturity considers the way in which the organization is structured to do the right things repeatedly and reliably.

You may already be familiar with the idea of maturity from some of the processes that take place around you. When you go to the supermarket you expect to find the same products to the same quality standard being stocked in the same place in the supermarket whether you visit on a Monday morning, Friday afternoon or in the middle of the night.

Process maturity is fundamental to business as usual. But in the modern world of delivering change, people often put much less emphasis on process maturity. One person may argue that her programme may be so fundamentally different from another programme running in the same organization that very little good practice can be transferred from one programme to the other. Thinking about common ideas for running both programmes is known as programme management maturity.

But within a programme, undertaking a series of similar or related projects is fairly common. Therefore, your aim is to run those projects in similar, more mature ways. You want to change your culture from one that's populated by individual projects doing their own thing, to a culture where you have a project factory slickly and efficiently turning out project outputs for the good of the programme.

In this context, the programme needs to discover what works and what doesn't in order to increase the maturity of what you're doing within the programme.

Logging and reviewing

Put in place opportunities at all levels for people to record their experiences within the programme.

In projects, this requirement may mean setting up lessons logs (sometimes called lessons learned logs). Because simply recording something in a log doesn't necessarily mean that the lesson has been disseminated to people and learnt by them, I also like to set up discrete opportunities for actually learning the lessons.

If you're carrying out transition within business as usual on a number of different occasions, and at a number of different locations during the programme, you may also want to put in place opportunities to capture the lessons that you want to learn from each little transition event.

Of course, logs aren't the only way in which you can capture lessons. Sometimes a better approach is to get groups of people together to have a meeting to review and capture what they've learnt. The lessons that have been captured can then be put into an end-of-project, or end-of-transition, report.

You have to consolidate the acquired learning in some way, and a great opportunity to do so is through the formal reviews that are carried out at various points through the programme. The programme needs to define the different types of internal and independent review that occur before, during and after structured initiatives (such as projects) and less structured work (transition).

This subject is substantial and hugely important. I cover governance and assurance of quality in Chapters 13 and 14.

Training and educating

When you gather together all the learned lessons, you have to communicate them to people working in the programme and those about to join it.

For a large programme, you may need to set up induction training and regular retraining for people working within the programme.

I recall one programme where I was proudly told about a pack of PowerPoint slides, which explained the programme to new arrivals. Sadly when I talked to new arrivals, none of them had seen the slides! Make sure that people have the opportunity to look at the lessons recorded and apply them to behaviour in the programme in future.