The Essentials of Managing Programmes

John Bartlett

• Publisher: Routledge
• Year: 2017
• Print ISBN: 9781138288294
• eBook ISBN: 9781351974769
• Topic: Business
• Subtopic: Business General
• Index: Business

The Essentials of Managing Programmes is an indispensable, applied guide to success in realising the benefits associated with delivering business strategy and change.

John Bartlett opens with the purpose and application of programme management in the context of the business or organization. He explains how to organise for programmes, including the roles of the key players involved; how to design and establish a programme office. Three chapters cover the core elements of risk, benefits and governance.

To help you think strategically, the author builds on soft systems thinking (Peter Checkland 1981) to visualise and communicate the dynamic nature of change and encourage employee involvement.

Pick up and use this concise, intensely practical guide to develop a shared understanding, shared language and shared purpose in all your programmes; across project managers, sponsors, programme board members and all those involved in or affected by organizational transformation.

1 Introduction

Programme management is now an important and recognised management technique in the world of business change. Since the publication of the first serious book on programme management by the UK government in 1994 (A Guide to Programme Management, CCTA, UK), interest in the subject has burgeoned. Subsequent editions of this book, published as Managing Successful Programmes, have maintained the demand for further knowledge.

During the 1990s government organisations needed to respond to National Audit Office concerns over the failure of several high-profile change projects, whilst the need to have a structured approach in order to manage business change became an increasing requirement of blue chip enterprises. The 1990s also saw mergers and acquisitions on an unprecedented scale, and businesses had to embark on holistic restructuring following the world-wide recessions of the early part of the decade. Holistic change has continued into the 21st century with further large-scale mergers, acquisitions and business recessions. To manage change of this magnitude, programme management has become the de facto approach, even though, in its embryonic state, debate continues over its essential elements. The main principles, however, are fairly well established, and debate over the next few years will surely centre on pinning down the terminology and fine-tuning its approach.

A key area of debate has been the differences between programme management and project management. This is where many people find difficulty, particularly in making the important decision whether a desired business change should be structured as a programme or a project. The definitions given later in this chapter set out the essential differences, and should leave the reader in no doubt about how to make the right decision.

It is ironic that the first real test of programme management in recent years came not from the influences mentioned earlier but from a decision made years ago by computer programmers to code years using only two digits. This Year 2000 problem, or the failure of many computers and computer programs to properly recognise dates in the year 2000 and beyond, had major implications for business and government. The test was significant for programme management because the problem affected every part of a company’s organisation, and enormous resources had to be marshalled to tackle it. Programme management was recognised as a key approach for solving this problem, and year 2000 programmes were implemented on an unprecedented scale world-wide. There are many who would decry the enormous cost and effort involved in solving the year 2000 problem, but millions of lines of code were changed, and the fact that the millennium passed without any serious computing incident bears testimony to the effort and cost expended.

The lessons learned from the year 2000 have had to be applied with equal vigour to other examples of whole-company change, such as the preparation for the euro, customer relationship management (CRM) programmes, e-commerce programmes, mergers and acquisitions, and enterprise resource management (ERM) programmes. Whilst the year 2000 programmes were driven from technical problems, these later programmes were undertaken for business or legislative reasons, and reflect the diverse changes now regularly occurring world-wide. Electronic commerce, for example, challenges the way companies trade and operate. Much of this change can only be tackled at a programme level.

Undoubtedly, the first decades of the new millennium will see further large-scale business change, as companies fight for product and service supremacy, increased market share and increased profitability. Programme management will have to become a much more sophisticated discipline in order to tackle the complexities of this accelerating change. Forces such as the Internet, e-commerce, social networking and digital money will significantly change working habits and patterns, and management techniques will have to cater for these revolutionary changes.

Programme management is not a methodology in the way that project management can be. It is rather a framework that acts as guidance for good practice. This book is one of these. Its guidance is taken from tough practice, and there is nothing mentioned in terms of technique that has not been tried successfully, and on some large and complex programmes.

What defines a programme?

Several definitions of a programme exist currently, each offering a differing perspective on a similar theme, i.e. that a programme is a collection of vehicles for change, designed to achieve a strategic objective. Programme management is the approach taken to manage a programme, which may comprise the employment of a management method or selection of appropriate management techniques.

In many definitions, vehicles for change is often substituted by projects, but in the author’s experience, projects are not the only change vehicles. Incremental and operational change can be accomplished that does not require the discipline of a project to carry out the change. These can still be validly part of a programme, particularly if undertaken as preparatory measures, like an investigation, study or questionnaire survey.

The word collection is important, since in a programme the vehicles for change are often not physically related to each other, unlike sub-projects within a project. For example, a project to fit out a new warehouse and an investigation into the number of customers with an “A” credit rating are not obviously related vehicles for change, but they could be parts of an overall business programme to diversify product supply. Thus, although each vehicle may be physically different, it relates to the programme through its contribution to the overall strategic objective. Also, projects within a programme often depend on synergy. One project might only be successful if other projects are completed in a certain way. A programme is an ideal vehicle for the management of such synergy.

In a project, sub-projects are traditionally formed from discrete pieces of work from a work breakdown structure. They are typically related to the design, development and implementation phases of a project and not just the end objective. Thus, a project to fit out a new warehouse may contain sub-projects such as trunking and cabling, fitments construction, warehouse operations and goods inwards handling. These are clearly related to each other throughout various phases of the project’s lifespan. The warehouse fit-out project is not related in the same way to other projects or change vehicles in the product supply programme, such as a project to implement an ordering process via the Internet. However, both projects, if implemented, would contribute to the overall programme’s strategic objective.

Most definitions agree on the business objective goal, whether the actual words used are strategic business objective, strategy, goal or aim. Programme management is at a state currently where definitions are still somewhat fluid. This is no surprise, as even a more mature discipline such as project management may have many definitions.

Programmes exhibit certain characteristics, which some people like to include as part of the definition. These relate often to the longevity of programmes or their position within a company. It is true that programmes tend to be longer in duration than projects, and may, in fact, be self-perpetuating or ongoing. Certainly, they tend to have higher focus within a company because they are strategic, and are usually applicable to not lower than departmental level. It is the author’s opinion, however, that any definition of programme should be kept as simple as possible, and favours the definition of a business programme as a collection of vehicles for change, designed to achieve a strategic business objective.

Table 1.1 summarises the main differences between a project and a programme, which are covered in detail under the relevant chapters in this book.

Table 1.1 Main differences between a project and a programme

Project	Programme	Chapter
Focus is on a single objective, usually non-strategic	Focus is on a business strategy, always strategic	1, 2
The change that a project seeks to bring about is narrow	The change that a programme seeks to bring about is wide ranging	1, 2
Benefits are delivered through a single undertaking and accrue usually only after its completion	Benefits are delivered incrementally by projects and other change vehicles during the lifespan of the programme	7
Main deliverables tend to be few	Main deliverables tend to be many	3
Timescale is usually rigidly defined	Timescale is loosely defined, with some exceptions	2, 3
Scope changes are managed as exceptional events	A programme is designed for scope changes	1, 2
Sub-projects are related to project outcome and to themselves	Projects and other change vehicles are related to programme outcome, but may be otherwise unrelated	1
A project is organised usually into sponsor, project manager, sub-project managers and team	A programme is organised usually into programme manager, executive team and project managers	4

Whereas projects tend to have a singular focus and deliver to specific objectives, programmes tend to take a wider view and deliver a multiplicity of objectives towards the achievement of a business strategy. The construction of the Channel Tunnel, linking England to France, for example, might have been conceived by some as a large project, but in reality it was a major programme of change. The act of digging the tunnel was just one major project within this programme. Whereas this project’s objective was to dig the tunnel, the programme supported the strategic objective of providing a fast and continuous rail link from the UK to the Continent. Other projects within the programme included the UK high-speed rail link, the construction of the international terminals at Ashford and Ebbsfleet, marketing, ticketing, support operations, customs changes and French link-ups to major European rail routes. The tunnel has been operational for several years and many of the projects have been completed, but the original programme was only completed with the opening of the high-speed line from St Pancras Station. Had the strategy been conceived originally as a programme and not just as individual projects, the important sponsorship, funding and economies of scale might have been better achieved. A programme could also have stayed in place to accommodate further enhancements in an evolving strategy. Piecemeal development is always more costly in the long term.

In another example, the hosting of the London 2012 Olympic Games was deliberately established as a programme from the outset and closely followed the UK government’s Managing Successful Programmes (MSP)¹ framework. Within the programme were several major construction projects, not least the clearing of the existing industrial site and construction of the Olympic Park. However, the scope of the programme not only included the ability to host a successful Olympic Games but also the renovation of the site for future housing and parkland. In typical programme format, contracts for various construction projects were only issued by the programme when ready. This enabled appropriate phasing to be accomplished and to incorporate lessons learned along the way.

Another key difference between a project and a programme relates to the achievement of benefits. Benefits are achieved during the life of a programme, as completing projects are decommissioned and new ones commissioned. In a project, benefits only usually accrue once the project has been completed, and after the project team has been disbanded few organisations seriously put into practice a benefits management regime. A programme, however, is an ideal vehicle for monitoring the achievement of benefits. If a particular completed project did not achieve its desired outcome after a period of time, the programme can commission another project to take corrective action.

Scope changes are exceptional events in projects, the scope having been agreed, signed off and frozen for development; but a programme should be designed for change – its longevity makes scope changes both inevitable and desirable. The ability to turn a programme around and change direction is a master stroke of management, and is facilitated through a flexible organisation structure. Thus, the organisation of a programme is different from a project, reflecting the different perspectives of the strategic business objective and the singular objective, and the level at which programmes and projects tend to sit within a company structure.

Throughout the following chapters these key differences between project and programme will be exemplified. However, understanding the differences is one thing. Being able to decide whether a piece of change should be executed via a project or a programme is another! The next section deals with this decision problem.

Project or programme?

Identifying whether a particular idea for change is a project or programme is an important undertaking, since the right management approach needs to be adopted to ensure the change has a good chance of success. Sometimes it is glaringly obvious, other times more complex. There are no hard and fast rules for every business situation, but some good general guidelines can be compiled. Normally, difficulty will only be encountered with large pieces of change, where the choice is between commissioning a large, complex project or a programme.

Figure 1.1 shows some examples of business change, categorised as projects or programmes. Those shown as projects could either stand alone or be part of a programme. Local conditions of scope and scale will dictate which of these undertakings are projects or programmes, though size is not the key criterion. A large project could be larger than a programme in terms of resources, cost or scope, but a programme has the characteristics of being complex and multidisciplinary rather than large in size. The choice of project or programme becomes greyer towards the centre of the diagram, and some could equally be both. The problem is that all the projects shown could also be part of a larger programme anyway, so the choice must always be made by asking the question: What is the strategy? The answer to this question will decide whether a piece of change should be truly stand-alone or fit within an overriding strategic direction, and so be better managed as part of the strategic direction.

Figure 1.1 Graduated examples of business projects and programmes

Some believe that the decision whether to manage change by project or programme is easier for more physical undertakings, such as building a bridge, than for managing business-related change. A bridge is a good example where thinking has to be applied beyond the main construction element. On the surface, building a bridge seems like a major c...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• List of illustrations
• Preface
• 1. Introduction
• 2. Applicability to business
• 3. Moving from Business Strategy to Programme Design
• 4. Organising a programme
• 5. Supporting the programme
• 6. Managing risk
• 7. Benefits management
• 8. Using soft systems thinking in programme management
• 9. Programme governance
• 10. Communication management
• Bibliography
• Index