Chapter 10

Planning and Controlling Your Programme

In This Chapter

Moving step-by-step through the planning process

Slicing your programme into tranches

Taking control

Working with planning documents

I can hear some of you thinking (yes, your thoughts are that loud): ‘Hey, I'm a project manager. I've been planning and controlling projects for years, and a programme is just a big project. Surely this chapter can't show me much I don't already know.’ Well, read on because I think you're going to find plenty of useful new stuff. And those of you who aren't familiar with project planning, don't worry; you don't need any prior knowledge to read this chapter.

In this chapter, I take a look at the difference between programme and project planning. I talk about how you develop the Programme Plan, how you control your programme against the Plan and how you split it into tranches(sections that can deliver a new capability to business as usual). I also discuss who deals with each of the documents associated with programme planning and control.

Contrasting Programme and Project Planning and Control

You have to plan your programme and then control it against the Plan. A programme covers transformational change in business as usual, so Programme Plans are much more comprehensive than project plans.

Covering the basic differences

The fact is that programme planning is different from other planning you may be familiar with, for example, project-level planning. Here are some reasons why:

• You have to process very large amounts of information; consequently programme planning isn't just a matter of gathering information from projects and publishing a vast amount of data.
• The large number of stakeholders within a programme means that extensive consultation is required.
• The Plan needs to be built carefully to ensure that it encapsulates all the key information without overloading people with data.
• During the early versions of the Programme Plan you may discover a high level of ambiguity within the Plan ‒ don't worry, this is quite normal.

Controlling a programme also involves more than controlling a big project. To see how they differ from each other, ask yourself, ‘Why are we controlling the programme?’ Simply and endlessly exerting control against detailed plans is a trap that's all too easy to fall into, and it doesn't necessarily allow you to deliver the programme effectively.

You carry out programme control in order to:

• Refine and improve delivery
• Minimise ambiguity
• Bring certainty wherever possible
• Justify the continuation of the programme

Planning your programme

In this section I ask you to think about the relationships between the Programme Plan and other documents and themes to help you understand how planning sits at the heart of the programme. See Figure 10-1 for an illustration. I provide cross-references to the chapters where I discuss the related themes where appropriate:

• Vision Statement. Look at the Vision Statement and make sure that you have a clear understanding of the objectives of the programme. The Programme Plan has to deliver against the Vision. (Flip to Chapter 5 for more about the Vision Statement.)
• Blueprint. Ensure that you look in detail at whether or not the outputs and capabilities that you're planning to create will result in the outcomes described in the Blueprint. Are you focusing on the right things? (Check out Chapter 6 for information on the Blueprint.)
• Benefits. Link benefits to projects. You also need to consider the timescale of benefits when putting together the tranches. (Benefits are covered in more detail in Chapter 15.)
• Projects. In an Emergent Programme a number of projects are already running and have their own stakeholder groups and supporters. But even a Vision-led Programme has projects that are running as you re-plan. Think vigorously about these projects and make sure that they're contributing outputs that lead eventually to achieving benefits. Indeed, examine projects more carefully than that: make sure that all the outputs being produced by projects ultimately contribute to benefits. (See Chapter 6 for more about Emergent and Vision-led Programmes.)
• Resources. Think carefully about the resources available and needed ‒ the phrase capacity and capability is useful in this context. Capacities mean that you have enough resources and capabilities means that people have the right skills.

  I've known many programmes that were limited simply because they tried to use all the available capacity and had no way of generating any more.

• Stakeholder needs. Go back to the Stakeholder Map and Stakeholder Profiles (possibly to the Stakeholder Register) to think about the requirements of the stakeholders. You want to share with them the right level of information to keep them properly engaged. One size doesn't fit all; you may need to have several different types of progress reporting. (Chapter 14 covers Stakeholders in more depth.)
• Risks and Issues. Be clear on responsibilities for taking action on risks and issues. They can arise at project level and be dealt with there. They can arise at project level and be escalated to the programme, or they can be identified at programme level and then delegated down for the projects to resolve. (I look at Risks and Issues in Chapters 11 and 12.)
• Timetable. All the information in the Programme Plan has to be scheduled, so produce a timetable based on the dependencies between different types of things, for example, outputs from projects and transition activities. Also, give due weight to interfaces; for example, if you're training people and introducing new procedures, what's the exact relationship between those two sets of activities?
• Progress monitoring. Too much information can be as much of a problem as too little when monitoring progress. Identify milestones that are truly significant to the programme. The detailed information can be monitored elsewhere.
• Transition. Capture transition activities in the Programme Plan. Transition is never as easy as you anticipate, so make sure that you consider things such as the cultural aspects of transition. Are staff prepared to alter their working practices? Something may seem like a wonderful idea to senior managers, but staff may be much more reluctant. Also consider what needs to happen for products to be truly accepted within business as usual. Make sure that you reflect all these aspects in the Programme Plan. (Transition is covered in Chapter 20.)

Pondering the Planning Process

At the very highest level the planning process is quite straightforward:

1. Construct a schedule of projects that allows you to achieve benefits.
2. Integrate project plans as they're refined.
   • Consider existing risks and the new risks from linking projects.
3. Respond to project exceptions.
   • An exception is basically when something goes wrong – big time. ‘Houston, we have a problem,’ was Apollo 13 reporting an exception.
4. Monitor progress.
   • Anticipate risks.
5. Consider deadlines and constraints.

The difficult part is in the first step: constructing a schedule based on benefits. I give you some useful ideas in this chapter, but you may like to look at the sequence I describe in Chapter 7 to see how each of the activities fit together.

Developing the Programme Plan

Simply taking all the project plans and publishing them together is too easy and just results in information overload. You require the level of detail necessary to provide progress information to allow you to identify pressure points and issues. You don't need any more information than that.

When you think about the tools you're going to use to monitor and maintain your plans, you have to:

• Present the Programme Plan information to stakeholders in a variety of different ways.
• Distribute the Programme Plan to various people, again in different formats.
• Think about how you're going to integrate project-level information.

Prioritising activities

Focus on activities that are critical to the programme. These activities can be projects, such as procurement, that are prerequisites for other projects, or they may be activities that involve scarce resources.

Also give priority to early benefits realization, which provides funding and fosters commitment and enthusiasm.

Coupling and creating cohesion

When I'm planning the next tranche, I bear in mind a couple of ideas:

• Coupling: The overlap between projects.
• Cohesion: The way the elements in a project fit together.

In Figure 10-2, each circle is a project and the thin lines represent dependencies within the project. This is the cohesion within this project. The thick line is the coupling between two projects.

The project environment is designed to deal with dependencies. So some cohesion within projects is entirely reasonable.

But when you have a lot of coupling between projects, issues and risks are constantly elevated from project level to programme level, which simply increases the workload at programme level.

Your aim when reviewing the relationship between outputs and projects is to allow cohesion within projects in order to minimise coupling between projects.

Designing projects

If you have the power to change the scope of the projects in your Project Dossier, take the opportunity at a tranche boundary to slice and dice your projects. Here are some factors to consider:

• Create smaller projects if the task is big or complex.
• Combine small packages of work into a single project.
• Consider the availability of skills.
• Maintain existing team working arrangements (or perhaps even disrupt them).
• Make use of geography and the culture of teams by co-locating a project team or using an existing team to carry out a new project.
• Encourage management by exception (delegating an agreed tolerance and then reporting based on how close the project is to that predetermined tolerance level).

Reading about resources

A resource is any input required by a project or by the programme, including people, assets, materials, funding and services. You want to focus on shared resources: plan and manage shared resources at the programme level. You can delegate the management of other resources to projects or business as usual. Organizations tend to overestimate their capacity, and therefore you can end up with an unrealistic Programme Plan.

When you're setting about your planning activities, carry out assurance reviews and perhaps even maturity assessment (explained in Chapter 14) in order to understand the true capacity of the organization.

Here are the types of shared resource to consider:

• Facilities: Offices can be shared.
• Information: Projects update a shared repository. (In the old days, that was the office filing cabinet. Today it's some fancy cloud-based storage system.)
• Staff: Can work part-time on several projects.
• Third-party services: Several projects can use the same service provider.

When resourcing the plan, be realistic and bear in mind that:

• Resources have finite availability.
• Availability and capability limit pace.

Home, Home on the Tranche!

You need to organize the work going on within your programme into tranches, a key element in programme planning and control.

Arranging work into tranches

A tranche (the French word for slice) is one or more projects and related transformational activities. The key characteristic of the tranche is that it delivers a step change in capability; in other words, something that is really noticeable in business as usual. It has to include the transition activities to achieve outcomes and provides an extremely useful control point for the whole programme.

A tranche ends when the transition stage of the Realizing the Benefits process is completed. In other words, outcomes are achieved and assurance reviews have been carried out, including reviews of the benefits realized to date. I describe that process in Chapter 20. However further benefits are realized in the post-transition phase, and that may happen in a subsequent tranche.

This is a very precise definition of the end of a tranche. In the real world your tranche boundaries may be more blurred. Be pragmatic when defining your tranches in order to keep stakeholders comfortable and create meaningful control points. I cover the detail of the process in Chapter 18.

Sometimes splitting complex work, for example, long projects, is useful so that they don't run across tranches. Or you may want to combine small pieces of work to make management and reporting more straightforward.

Working with workstreams

MSP doesn't put a lot of emphasis on workstreams, although the term is used commonly in complex change initiatives. A workstream is a logical grouping of projects and activities to enable effective management. They can delineate projects against a whole variety of different criteria.

Although a reasonable description of a workstream, it doesn't really bring it to life. Quite often workstreams run the length of the programme, so if you're looking at a picture of a programme, the tranches are vertical slices and the workstreams are horizontal streams.

The simplest example of a workstream is just the grouping of projects with some natural interrelationship. Most frequently this grouping is by function. You may find an IT workstream with perhaps half-a-dozen projects all with an IT theme. You can also expect to find a human resources workstream and a facilities workstream.

Yes, I know IT projects should rightly be called business projects with a large IT content. But that's not the term used in the real world. The problem with just calling them IT projects is that you might group under an IT manager. It's the interaction with the business that's important from the perspective of the programme and therefore you may want to group those projects in a different way, perhaps by business unit.

Seeing tranches in a programme schedule

Tranches really only make sense when you can see a picture. Figure 10-3 features a simple schedule for a programme showing three tranches:

• Tranche 1: Includes projects A, B and C. Benefits are realized after the transition, and benefit reviews may happen sometime after the end of the tranche. But the tranche itself ends soon after transition, which is when any end-of-tranche review has to take place. I discuss reviews more in Chapter 14.
• Tranche 2: Includes projects D and F. You can see that project D starts during tranche 1 but logically is part of tranche 2.
• Tranche 3: Includes projects E, F and G. Project E has been running during tranches 1 and 2. Although acceptable, I sound a word of caution. In my experience a tranche lasts about six months, perhaps a little longer. That means that project E runs for well over a year. As a general rule, I become concerned when the duration of a project gets up to about one year. My preference, if at all possible, is to break it into a series of shorter projects, but that's a generalisation. In some industries the average duration of a project is much longer.

Given this schedule as a draft, I'd do my very best to break project E into two or even three smaller projects. I'd look in detail at the dependency network to see whether those smaller projects can be run in parallel as part of tranche 3, or if some of them can be moved to tranche 2 or even tranche 1.

Tales of the unexpected: Tranche boundaries

At each tranche boundary you hope to have a clear view of the Vision, or, to be more precise, a clear view of how you may get to the Vision. But if I can use a geographical analogy, you won't be able to see hidden valleys along the way. Figure 10-4 illustrates visibility across the tranches. At each subsequent tranche boundary you may get a clearer view ‒ that is, see into more hidden valleys.

Figure 10-4 is a pretty little way of visualising tranches and getting a better appreciation of how much or how little detail you need in the Plan for the next and subsequent tranches. Notice the hidden valley to the right of the third peak. You can't see into that valley until you get to the beginning of the third tranche.

As a mountaineer on a mountaintop, with a number of hills and valleys between you and that Vision, what can you see? Well, if you look down into the second and third valleys, you can't see the valley floors; some detail is hidden from your view. So you can't plan how you going to cross those second and third valleys.

What you can do is plan how you cross the first valley. You can plan the tranche that's immediately in front of you. When you've done the first tranche and you look across valleys two and three, you still can't see enough detail in valley three, so you can plan only valley two. You know a lot more about valley two than you did at the beginning of the previous tranche, so you can now make a plan for the second tranche. Only when you reach the third peak can you see the third valley and plan the third tranche.

The lesson is not to plan too far ahead.

Grouping projects

When you group projects together, the obvious solution is to group by discipline. Programmes tend to be multidisciplinary, but grouping projects by discipline feels natural. For example, you can group IT projects together and HR projects together. The difficulty is that the most difficult dependencies tend to arise between functions, so you may prefer to have cross-functional projects.

You can group projects by location if you have a multi-site programme.

An excellent approach is to group projects by deliverables, and so create some sort of logic network or precedence diagram of the deliverables from the projects (just a diagram linking things up with arrows). Look at the dependencies between the deliverables. Then create projects where deliverables are clustered and group projects again where dependencies exist.

In short, do whatever you can to try and avoid competition for resources and to minimise resource bottlenecks. I can give you only so much advice on how to do this, and it requires pragmatism. In the end you want to have a logic or precedence diagram that avoids tangles of inter-project dependencies; you want flexibility at the programme level.

Figure 10-5 shows a simple example. The five products are grouped into three projects. In the first option, all three projects have to communicate with each of the other two projects. As a result, six lines of communication operate. By regrouping the products, projects 1 and 3 have to communicate only with project 2. So the number of communication channels is reduced to four, without increasing the size of any projects.

Controlling Your Programme

As I discuss in the earlier section ‘Contrasting Programme and Project Planning and Control’, these planning tasks differ in a number of ways. The same is true of programme control.

Here are some typical questions you may ask when controlling a programme that you probably wouldn't ask when controlling a project:

• How will outputs enable change?
• What benefits will follow on?
• What enabling capabilities are also needed?
• On what projects are you dependent?
• What other projects depend on you?
• What's the state of these projects?

Programme control is quite different from project control. In a programme you want to be monitoring, reporting and controlling in order to achieve the Vision, Blueprint, outcomes benefits – that sort of stuff.

Overseeing a programme

Based on my personal experience, here are the aspects that you need to consider when you're overseeing progress at the programme level:

• Review progress in order to make essential interventions. You aren't second-guessing your project managers. Their job is to manage their projects and they report from the project perspective. Intervene when only you can see something because you have a programme perspective.
• Use management by exception when dealing with projects. Put in place some limits for each project (a tolerance). Deal only with individual issues that are escalated to you by the project manager because, for whatever reason, they feel they can't cope, or when the project exceeds the overall limit (known as an exception).
• Manage dependencies that can't be managed within projects.
• Check and maintain alignment with the Blueprint. The Blueprint is an evolving document both because the team puts more detail into it and due to changes in external circumstances.
• Oversee quality. I talk more about quality in Chapter 13.

Monitoring a programme's progress

When you're monitoring the progress of a series of projects, you can easily begin to drown in data. So cut back on what project information is reported to you. Ask for reports with less detail to make them clearer.

Let me put that another way. If I'm a project manager and you ask me if I'm happy with my progress I can answer yes or no. You're then quite clear if I'm happy or not. Or I can write a 3,000-word report that includes lots of ifs and buts and maybes and explanations. When you read the report, you may know more detail, but I doubt if the status of my project would be any clearer to you.

That said, projects must present certain key information in a summary form. The following aspects are crucial, starting with outputs being fit for purpose, then using whatever sequence makes sense for your programme:

• Outputs
• Timely completion against the agreed project plan
• Project risks, issues and assumptions
• Estimates
• Costs and benefits
• Resources
• Scope

Dealing with the Planning Documents

Programme planning and control involves a number of documents and someone has to deal with them. In this section I consider the purpose of each of the relevant documents, look at the composition of two key ones and discuss the areas of focus of each of the key players.

Discussing the purpose of the documents

Here are the purposes of a whole raft of strategies and plans:

• Monitoring and Control Strategy. Good Programme Managers know that they have to set up some form of internal control. Often they're quite charismatic characters (ha ha) and have a very clear way of doing things, such as holding a progress meeting every Wednesday morning in a particular room ‒ that sort of thing.

  You let people know that these meetings are going to happen by publishing a Monitoring and Control Strategy, which records how the programme is to apply internal controls.

• Programme Plan. A comprehensive document used to control progress and track delivery of the programme and outcomes. Occasionally you may hear the word programme used to mean schedule and that's the case here.
• Projects Dossier. In contrast to the Programme Plan, the Project Dossier is a high-level document ‒ a list of projects required to deliver the Blueprint with high-level information and estimates.
• Resource Management Strategy. Identifies how the programme is to acquire and manage resources needed to achieve business change. For example, you can negotiate with the finance director about how the programme can access funding ‒ that goes into the Resource Management Strategy. Or you may have contracts with external companies that provide different types of resources.

  The more topics you can tackle proactively and record in the Resource Management Strategy, the less reactive resource management you have to do.

• Resource Management Plan. The arrangements for implementing the Resource Management Strategy. You can run the programme using crisis management ‒ begging, borrowing and stealing resources when you need them. But the process is much more efficient if you've already negotiated ways of getting hold of resources and you have a plan for doing so.

Looking inside two documents

I look only at the composition of the Programme Plan and the Project Dossier. These two documents are central to your planning, while the composition of the other two documents (the Resource Management Strategy and Resource Management Plan) can vary quite widely.

Programme Plan

This list shows what the Programme Plan contains, but it gives no indication of its size or complexity, because that depends on the programme:

• Programme schedule
• Dependency network
• Cross-reference to the Risk Register
• Explanation of project grouping
• Transition plan
• Monitoring and control activities
• Programme tranches
• Effort and cost

Project Dossier

A useful idea is to record slightly more than a list of projects in the Project Dossier:

• List of projects
• Outline of outputs and resources
• Timescales and programme level dependencies
• Initial requirements from the Blueprint
• High-level budgets
• Contributions to outcomes and benefits
• Issues and risks

I often include a matrix that maps project outputs onto outcomes and then onto benefits.

Clarifying the planning areas of focus

This section covers the areas of focus for key roles in terms of planning and control. Flip to Chapter 9 for detailed descriptions of these roles and check out the earlier section ‘Discussing the purpose of the documents’ for more on the documents.

The Senior Responsible Owner focuses on the following:

• Consulting the Sponsoring Group and other key stakeholders and maintaining their buy-in, especially in preparing for and carrying out transition.
• Leading the on-going monitoring and review activities of the programme in mid-tranche and at end-of-tranche, including commissioning formal reviews such as audits or health checks, if required.
• Monitoring progress and direction of the programme at a strategic level and initiating management interventions where necessary.
• Authorising the Resource Management Strategy and the Monitoring and Control Strategy.
• Ensuring that adequate assurance is designed into the control mechanisms.
• Authorising the Projects Dossier, Programme Plan and the required monitoring and control activities.

The Programme Manager focuses on:

• Designing the Projects Dossier, Resource Management Strategy, Monitoring and Control Strategy and the required assurance activities.
• Designing of the Programme Plan.
• Ensuring that the Blueprint, Programme Plan, Benefits Realization Plan and Benefit Profiles are consistent and able to deliver the Business Case and remain aligned.
• Developing the Resource Management Strategy and deployment of the Plan.
• Developing and deploying the Monitoring and Control Strategy.
• Establishing and managing the appropriate governance arrangements for the programme and its projects.
• Ensuring that key programme documentation is current.
• Creating and issuing Project Briefs.
• Identifying and managing programme dependencies.
• Progress-reporting to the Senior Responsible Owner and the Programme Board on projects, Business Case, Programme Plan and Blueprint achievement.
• Adjusting the Projects Dossier, Blueprint and Plans to get the best flow of benefits.
• Managing stakeholder expectations and participating in communications activities to inform stakeholders of progress and issues.

The Business Change Manager has plenty to do in connection with planning and control, a lot of it focused around transition in business as usual:

• Consulting with the Programme Manager on designing the Project Dossier and scheduling the tranches and constituent projects to ensure that the transition aligns with the required benefits realization.
• Ensuring that changes are implemented in the business.
• Ensuring that the business continues to co-operate effectively during the period of change.
• Providing adequate and appropriate business and operational resources to the programme and its projects to ensure that outputs are designed, developed and assured to give them the best chance of enabling the scale of improvement required.
• Making sure that the operational functions are adequately prepared and ready to change when transition starts.
• Ensuring that plans are in place to maintain business operations during the change process until transition and handover are complete; also providing input to the reviews.
• Planning the transition within operational areas and accommodating requirements to maintain business operations.
• Ensuring that when transition is completed, the focus remains to establish the new ways of working and ensure that old practices do not creep back in (like an unpleasant insect you throw out the bedroom window during the night!).

The Programme Office is the information hub and involves:

• Supporting the development of planning, control and information management arrangements.
• Gathering information and presenting progress reports on projects.
• Supporting the Programme Manager in the development of reports.
• Providing the programme teams with information and resources that can assist with the design of documentation.
• Establishing and operating the programme's information and configuration management systems, procedures and standards.
• Collecting, monitoring and measuring data and keeping the information up to date.
• Collecting and presenting information on business performance.
• Ensuring that coherent and common project-level standards are in place for all document management arrangements for the programme.