Chapter 19

Managing Projects within a Programme: Delivering Capability

In This Chapter

Examining the role of your programme people in projects

Helping to start projects

Monitoring existing projects

Closing projects smoothly

Programme management makes project management more efficient by helping to kick-off individual or groups of projects, providing a helpful environment around projects while they're running and assisting closure.

In this chapter I continue my Star Trek analogy from Chapter 18 (hurrah!), but switch focus from the captain's chair to all those keen young people who're controlling the Starship Enterprise. To be more prosaic, you're leaving your cubicle (co-located with the Programme Office), where you've been chatting with the SRO and some Business Change Managers, and having a look at what your staff members in the Programme Office are doing. Some of them are helping projects to deliver capability.

I look at how you in the programme can help projects to deliver: how you can turn your programme into a project factory where project outputs slip easily off the production line. I cover what the programme can do when starting projects, running projects and closing projects

For those of you from project management, this is reasonably familiar territory. If you're the sort of project manager who likes to operate on your own, however, you may feel uncomfortable with the way the programme tries to help, even control, what you're doing.

Understanding the Purpose of Delivering the Capability

The purpose of the Delivering the Capability process is to co-ordinate and manage project delivery according to the Programme Plan (which I describe in Chapter 10).

Figure 19-1 illustrates the process to help you visualise it. You're working with the agreed documentation for the programme and the principal controls are those you use to monitor and govern projects. The outputs from this process are the routine and non-routine reports coming out of the projects and of course the project outputs themselves. I look at the activities and who's involved in more detail throughout the rest of this chapter.

Delivery from projects provides outputs that enable the new capabilities to be put in place as described in the Blueprint. Also, bear in mind that Delivering the Capability is repeated for each tranche (flip to Chapters 10 and 18 for more on tranches).

Check carefully that your programme people are helping others to deliver their projects and not, accidentally, taking over, duplicating or even undermining the management of the projects. In Chapter 3, I introduce the idea of your programme being right not necessarily tight as regards control. Tightness of control may be most apparent around the relationship between the programme and its projects:

• In an extremely tightly controlled programme, the Programme Manager may well be a sort of super project manager.
• In a very loosely controlled programme, the Programme Office simply gets progress reports from projects that are otherwise being independently directed.

Neither loose nor tight control is wrong; it depends on the nature of your programme and the culture of the organizations involved. I describe a middle ground where the programme has considerable influence over projects, but they're still being run with a fair degree of delegated authority.

Starting a Group of Projects

The activities for the programme to undertake in connection with starting one or more projects are quite straightforward:

1. Start projects.
2. Engage stakeholders.
3. Align projects with benefits realization.
4. Align projects with programme objectives.
5. Manage and control delivery using the defined governance structures.
6. Manage risks and resolve issues.
7. Close the projects.

Clarifying the connection between projects and benefits

A good starting point is to recap the relationship between projects and benefits, as shown in Figure 19-2. This list can even be basis of the briefing you give to new project managers:

1. Identify projects started by the programme.
2. Confirm how these projects fit into the big picture by referring, for example, to strategies.
3. Make sure that the projects are aware of and understand the interdependencies with other projects.
4. Explain how the project outputs are going to be used, if necessary, perhaps combined with the outputs from other projects, to enable transition, to provide capabilities that lead to outcomes and ultimately to realize benefits.
5. Use the information from the Defining a Programme stage, as detailed in Chapter 7, to provide projects with guidance on quality, reporting, exceptions and escalations.

The emphasis here is on doing the things that the projects can't do themselves. They need to focus on project management ‒ delivering capability ‒ while you focus on the aspects of programme management that co-ordinate, focus and direct projects.

Delineating a project in a tranche

Having worked closely with the MSP reference group and authoring teams for many years, I'm a great fan of MSP: it's a pretty robust set of advice. But I do think that it's a little vague about where the detailed planning for a tranche is carried out. The high-level elements are certainly part of preparing for the next tranche, which I mention in Chapter 18, but behind the explicit activities in this process the people in the Programme Office, who are particularly focusing on projects, have some work to do as well.

The Programme Office need to carry out some detailed work to bed down a new tranche. Here's the list that I personally use:

• Scope and define projects in dossier
• Existing projects:
  • Review their status and progress
  • Re-align as necessary
  • Minimize overlapping project territories
  • Simplify inter-project dependencies
  • Consider organizational power structures
  • Develop dependency network

Another piece of preparation I suggest is to have a thorough look at the scheduling of the projects. Again, here's my personal checklist:

• Scheduling (planning) projects:
  • Look for early wins – but optimize overall benefits
  • Schedule benefit review(s)
  • Schedule the end-of-tranche review
• Refine the Programme Plan:
  • With deliverables dependencies
  • With resource dependencies
  • With tolerances
  • By updating the transition plan

Clarifying start-up responsibilities

During project start-up you want to be quite clear about who does what:

• The Programme Manager is responsible for:
  • Ensuring that Project Board appointments are appropriate.
  • Appointing the Project Executive, and maybe the Project Board, in a tighter-controlled programme.
  • Providing the project brief (including the outline business case for the project).
  • Discussing the project brief with the project management team.
  • Agreeing the project plan and tolerance in the project initiation documentation.
  • Agreeing product delivery times for products with inter-project dependencies.
• The Programme Office helps with planning.

Depending on how tightly or loosely your programme is controlled, you may want to check a brief drafted by a project manager or draft the brief and give it to the project manager. I like to make sure that the following items, from big picture stuff down into a bit of detail, go into each project brief:

• Project definition
• Business case
• Target delivery date
• Quality expectations and acceptance criteria
• Programme risks
• Project dependencies

Keeping an Eye on Existing Projects

While the projects are in flight, the programme needs to monitor progress and intervene when things go off-track: for example, if issues and risks need to be escalated.

The simplest way to make this work with the right balance between delegation and control is to ensure that everyone understands and is using tolerance and management by exception. These ideas are well described in PRINCE2 (get hold of PRINCE2 For Dummies by Nick Graham, Wiley), and they really make your life straightforward in a programme.

Management by exception means that instead of saying that a project manager must deliver the project on time, they must deliver the project within plus or minus one week of the target (the tolerance). When reporting, for example, you just want to know if the project manager is on schedule to within plus or minus a week. So management by exception simplifies reporting, while maintaining clear control.

Monitoring progress

When you're monitoring progress across a series of projects you can all too easily find yourself drowning in data. Therefore I suggest that you present only certain key information from projects to the programme and in a summary form.

Here's what I consider the minimum information:

• Outputs.
• Timely completion or progress against schedule.
• Risks, issues and assumptions that may need to be escalated.
• Changes to estimates, again within the granularity (level of detail) that needs to be escalated to the programme level. (I don't want to know all the trivia about the project; I just want to know the things that matter to me at programme level. This links very closely with the tolerance I've delegated to the project manager.)
• Costs and benefits that are relevant to the programme.
• Resources, particularly those being managed at programme level.
• Fundamental changes to the scope of the project.

Overseeing progress

Overseeing means just a little bit more than monitoring; it also includes taking actions, perhaps outside the project environment, and linking what's happening in the project to the bigger picture of what's happening in the programme. Here are some things you need to do when you oversee progress:

• Review progress in order to make essential interventions. This isn't second-guessing your project managers. You have project managers in order for them to manage projects. The interventions you're going to make from the programme level are those that only make sense when considered from a programme perspective.

  The project reports from the project perspective; you intervene from the programme perspective.

• Deal with escalations and exceptions. One of the things you need to think about here is the level of management by exception you use when dealing with projects. To some extent I'm assuming that you've put in some form of management by exception, because you need to deal with escalations from projects and exceptions within projects. Again, you can't do so unless you previously defined tolerance or something similar.

  In essence you have to agree the delegated authority of the project. Beyond that tolerance, the project has to escalate to the programme.

• Manage dependencies. I look at three classes of dependencies in Chapter 10. You need to manage the dependencies that can't be managed within projects.
• Check and maintain alignment with the Blueprint. The Blueprint is an evolving document, because you put more effort into it as time goes by and because of changes in external circumstances. You need to keep an eye on projects and their alignment with the Blueprint.
• Maintain some oversight of quality. I look at quality in Chapters 13 and 14. Remember that the quality environment within a project may be unique to that project and focused on project outputs. You need a quality management environment that fits the whole programme and takes a wider view of the quality of what's coming out of the projects.

Deciding when to escalate risks and issues

The systems you have in place need to ensure that risks are escalated to the programme in the right circumstances, such as when:

• Other projects or programmes are impacted.
• The project doesn't have authority to resolve the risk or issue (that is, the action may exceed the project tolerance).
• The project lacks the skills or experience.

Managing conflict

You may have to become an expert on conflict management because of conflict between the narrow project needs and the wider programme needs.

The SRO has the ultimate responsibility to resolve the conflicts, but you don't want these things escalating to the SRO very often. Sometimes all that you need is to communicate effectively the effect on the programme of project issues. But sometimes the differences in viewpoint between project and programme level are more deep-seated. You may find that your soft skills, such as communication, are very useful when trying to soothe your project people. In particular, you need to think about your internal communication in Delivering the Capability. Take a look at Figure 19-3 for an illustration.

You may find that focusing on topics only apparent from a programme perspective is useful, including:

• Interdependencies between projects. For example, one project may think it can delay delivering an output, but that output's timely delivery is essential to another project.
• Design compliance. The people in a project think it is a good idea to use a different logo, but the design authority wants everybody to use the same logo.
• Resource management across shared resources. You've only got one specialist in using the phaser (oops, I'm back to Star Trek again), but two projects want to use him or her at the same time.
• Co-ordination between project implementation and business-as-usual transition. The project intends to deliver the new accounting system just before the end of the accounting year – bad move!

I'm a pilot, and if things are going wrong when you're flying you don't want to be playing around with all the knobs and dials – you need your head up, looking out of the window. The same thing applies in a programme when you're monitoring and overseeing delivery of the capability (your people). You need to stay out of the detail and focus on what's important:

• Manage inter-project products:
  • Quality check product descriptions and designs
  • Accept completed products
  • Control changes to products
• Analyse project issues for their programme impact
• Carry out programme quality assurance
• Communicate between projects

Closing Projects

As each project approaches its end, you want to make the closure as smooth as possible by ensuring that the following tasks take place:

• Supporting the closure process.
• Confirming the transfer of outputs to the Business Change Managers and business as usual so that they can trigger transition and ultimately benefits.
• Assigning incomplete actions from the projects to someone outside the projects and making sure that the actions are accepted.
• Making sure that lessons are recorded and passed on.
• Scheduling post-project reviews.

Allocating Responsibilities across Capability Delivery

The Programme Manager is responsible for all the activities I describe in this chapter, although the Business Change Managers help to ensure that projects are linked with benefits realization.

The Programme Office supports you, and, of course, the SRO has the overall accountability.