Chapter 18

Managing a Tranche

In This Chapter

Understanding the purpose of tranches

Linking managing a tranche and the other processes that are going on within a tranche

Setting up a tranche

Taking care of a tranche

Crossing tranche boundaries

As I describe in Chapter 10, tranches are sections of the programme that deliver new capability to business as usual. You need to set up and manage each tranche at a high level. Now, I'm a bit of a Star Trek fan, so I make no apologies for describing this arrangement as you being Captain James T. Kirk on the bridge of the starship USS Enterprise:

• The captain is Managing the Tranche from an imposing leather chair.
• The bridge officers are Delivering the Capability.
• The away team is Realizing Benefits on the planet ‒ in other words, in business as usual (with those in red shirts looking around nervously as they suspect their time may soon be up).
• The crew members are working together on the same mission and to be successful, they have to maintain communications with each other.

In this chapter I look at what the captain (sorry, the Programme Manager) does while Managing a Tranche and break it into three simple sections: setting up a tranche; running a tranche; and handling a tranche boundary. I examine the activities that this person is responsible for in each section.

Thinking that the end of each tranche is a great opportunity to review the status of the programme is great, but you can also face unplanned tranche boundaries that make life a little more exciting. You have to be able to review really quickly sometimes.

Discovering Why You Manage the Tranches

When the wider authoring team of MSP changed it from a process model to a transformational flow one (check out Figure 1-3 in Chapter 1), we were very keen to get across that things don't happen in separate places (silos) or even in strict sequence in a programme. Instead, I like to think of a programme as being more like a stream bubbling across rocks: the different flows of water mix and separate and little eddies form where the water goes round and round in circles.

If that model lacks a little discipline for you, we also include distinct processes in the transformational flow. At the beginning and end of the programme the processes are sequential, but in the middle is an iteration (I explain iteration in Chapter 7. It just means you're going around in circles) of three processes during each tranche, as follows:

• Managing the Tranches: Which I describe in this section.
• Delivering the Capability: Which I cover in Chapter 19.
• Realizing the Benefits: Which I look at in Chapter 20.

Figure 18-1 illustrates the model for the Managing a Tranche process. (I know that a programme consists of a number of tranches, but I feel that you manage them one tranche at a time. So from now on I talk about managing a tranche.) You're working with the agreed documentation for the programme and the controls are related to governing rather than managing. The outputs are capabilities, outcomes and benefits, as well as updated documents. I look at the activities and who's involved in more detail in this chapter.

You're Managing a Tranche for the following three purposes:

• To implement programme governance. Reflecting on what you've learnt about governance is about more than just management. It concerns systems of direction and control and is about putting in place appropriate checks and balances.
• To ensure that the capability being delivered is aligned to strategic objectives. You can think of this purpose at a strategic level or at a more detailed one. What you're doing is aligning capability delivery with everything that's going on in business as usual.
• To realize benefits. In other words, to enable their release.

Establishing a Tranche

Setting up the tranche is the first activity in the Managing a Tranche process. This activity is very scalable (you can apply it to a big or a little programme). If you have a modestly sized programme or one that's been running for some time and is settled, establishing the tranche may be straightforward; indeed you may have almost nothing to do.

But if you have a very large programme (and in particular if you're at the beginning of it), establishing the tranche can be highly significant. You need to carry out the following tasks, roughly in this order:

1. Set up the organization that runs the tranche.
2. Appoint the Business Change Team in business as usual.
3. Create the Programme Office and get them up and running effectively.
4. Put in place all the structures that support governance.

   I often think of governance as being a set of committees (though perhaps that's a little bureaucratic). You're going to produce the paperwork for a committee so that it can meet regularly, process the decisions and move on. You may have a lot of structures to put in place.

5. Establish the whole communications network for the programme, from websites through to common data storage.
6. Think about your physical environment requirements:
   • Office space, facilities and services. The Resource Management Strategy may have defined some rules that help or you may have to crisis manage getting resources (a fancy way of saying you're running around doing one urgent task after another).
   • New intranets, extranets and websites.
   • New tools for planning, estimating or scheduling and for functions such as risk management, quality management, financial control or change control.
   • Documents or records management tools.
   • Specialist configuration management tools.

In one giant programme I worked on, setting up this physical environment was so large that it was itself treated as a programme. In your programme you need to plan how much effort goes into establishing the tranche.

Running a Tranche

This portion of Managing a Tranche covers several activities such as managing the programme. You need to repeat each of these activities frequently, so a lot of your effort inevitably goes into them.

Managing the programme

Be in no doubt; you have plenty to do when Managing a Tranche:

• Direct work. You're going to put in place the governance.
  • The detail is done in Delivering the Capability process, but you need to keep an eye on it here.
• Managing risks and issues. You need systems at the programme level.
• Delivering Communications. You're going to have a communications function at the programme level.
  • How are you going to control and deliver communications?
• Initiating audits and assurance reviews. You need to trigger lots of checks.

  You can think of these as being Captain Kirk asking various people to check downwards on what the rest of the crew (not to mention the bug-eyed aliens) are doing. The Programme Office commissions audits and reviews of projects and of transition in business as usual.

  But you also need to think of audits as operating sideways and upwards. Captain Kirk (no Captain Picard; Captain Kirk isn't smart enough to think of this sort of thing) may ask another starship captain to look over his plans or suggest to the Admiral the need to ask the Klingons to take an independent view of what's going on. Okay! Enough of the starship analogy. You have to commission audits and reviews of your performance on behalf of external stakeholders, the Sponsoring Group or other external agencies.

• Maintaining the Blueprint and a governance structure. You need to ensure that the Blueprint remains aligned with strategic objectives, so you have to set up communication channels. If the strategic objectives change, you may have to alter the Blueprint and that can have quite significant effects on the projects that you're in the middle of delivering.
• Ensuring information and asset integrity. This can be a very significant piece of work on a large programme.

You also have to manage people and resources and think about procurement and contracts functions as well.

Maintaining the flow of information

You need to get your information management system up and running.

Reporting must match the needs of the programme and show progress against the Programme Plan (which I discuss in Chapter 10). Information has to be flowing on subjects such as the following:

• The schedule, with particular emphasis on inter-project dependencies
• Financial reporting
• Resource use
• A benefits summary

Projects and business-as-usual activities have to provide the information and the Programme Office has to filter that information up to the Programme Manager and then out to the broader stakeholders.

Monitoring, reporting and controlling

The activity of monitoring, reporting and controlling can be a major job. You can sometimes feel as though most of your life in a programme is dominated by these tasks.

Don't let this activity take over your life. Just because you can report certain information doesn't mean that you should do so. Important stakeholders may not know what information they need and with the best possible intentions can enquire about all sorts of irrelevant detail. In particular, everyone thinks that delving down into what's happening in projects is a good thing.

Try and streamline reporting so that you can focus on answering questions such as:

• Are the Blueprint and the capabilities being delivered still coherent and consistent?
• Have the Senior Responsible Owner and the Programme Board the right amount of information for them to consider:
  • Major exceptions from projects
  • Outcome achievements
  • Benefits achievements
  • Benefits realization exceptions
  • Capability delivery escalations
  • Reviews

Transitioning and maintaining stable operations

This process is what the Star Trek away team are doing down on the planet. In other words, what the Business Change Managers are doing in business as usual, when running the Delivering the Capability process.

But you need a link back to the Enterprise's bridge, and that's why this activity is included in Managing a Tranche. Indeed, this activity is so important that probably the SRO authorises the beginning of transition. (I guess if the Programme Manager is the captain, the SRO must be an admiral visiting the ship.)

Transition, which ends up being a stable operation within business as usual, is absolutely vital to the programme. (A colleague of mine argues that this single topic is worthy of a whole course.) You may know examples of when transition stabilisation has gone well or gone badly.

Although from the bridge people keep an eye on these types of tasks, the Business Change Managers are responsible for this work:

• To implement those transition plans on which you've worked so carefully.
• To measure performance through transition using the new benefits measures that you've already tested and baselined.
• To continue measuring in a consistent way as operations stabilise.

You need reporting lines throughout the programme, but it's also very important for the benefits to be reported through the business as usual management structure.

You must also manage a whole series of downsides of these benefits:

• Disruption to operations because existing staff are moved to new ways of working, and because of a learning dip as people adjust to those new methods. (If somebody gives you a new tool to help you do your work, your performance drops as you learn how to use it. Eventually your performance improves.)
• Things don't settle as quickly as imagined, so the improvements don't flow as quickly as anticipated and benefits ramp-up is delayed.
• The natural tendency for people to revert to old ways of working. You need to put in place specific activities that help reinforce in the minds of staff that the new ways of working are the way things are now done round here.

The Business Change Managers also sustain existing business operations during the programme, looking at the following:

• Technical integrity of systems
• Transferring or replacing superseded ways of working
• Maintenance of continuous service
• Maintenance of morale

Take a look at Chapter 10 for more on transition and at Chapter 20 for details of realizing benefits through transition.

Dealing with a Tranche Boundary

When you grab a moment to drag yourself away from the endless cycle of monitoring and reporting and glance into the future, what do you see? The next tranche bearing down on you!

Many programmes simply don't have the capacity to organize the next tranche effectively: they're just too focused on the day-to-day effort of running the current tranche. I see this as another symptom of information overload.

Therefore, make sure to ask yourself whether you and your team have enough spare capacity to close down the current tranche properly and get ready for the next one.

When you get your head round the idea of a planned tranche boundary, which typically happens about once every six months in your programme, I predict that just over the horizon (say six to twelve months in the future) a dramatic and completely unexpected event will occur that fundamentally changes the nature of your programme.

Of course I don't know what that event is going to be for your particular programme, but it's in the nature of transformational change programmes: unexpected changes in direction happen surprisingly frequently. In other contexts these events are called black swans (explained in Chapter 6. The later sidebar ‘Calling all bird-spotters: The black swan’ relates an example).

The lesson for you in programme management is that as well as being ready for a planned tranche boundary, you need to expect the unexpected: you have to be prepared for an unexpected tranche boundary. Bear in mind these two ideas – the planned and the unplanned tranche boundary – as you read the next few sections.

Preparing for the next tranche

At the end of the current tranche you need to prepare for the next one. I describe the end-of-tranche review and closure activity in the next two sections, but for the moment I cover preparing for the next tranche. I want to raise two significant points that you need to consider:

• If you have a Programme Plan that's based on tranches, you need to have some resources available towards the end of each tranche to prepare for the next tranche.
• But if all your resources are devoted to managing the current tranche, where are you going to get the resources to prepare for the next tranche? And do you have a contingency plan for closing the current tranche if an unplanned tranche boundary arises?

Here are some things to do as you prepare for the next tranche:

• Learn from experience. Gather up the lessons you've acquired during this and previous tranches. Pull out what you can, study it and apply it as you go through your planning.
• Adapt your governance and organization structures, perhaps because of external factors or simply because the balance within the programme changes as it moves on.
• Consider altering your skills mix. You have to move people out of the programme and others into it. That may lead to changes to the physical environment for the next tranche.
• Review and refine the scope of the programme and of all the programme information.
• Manage and review your information baselines.
• Get approval to proceed.

As an example, if the programme moves the organization a substantial distance (say, several hundred miles), the Programme Office may need to move to the new location in the next tranche.

Moving towards tranche closure

For this stage, you need to commission an end of tranche review and arrange for the closure of the current tranche (I discuss tranche reviews in Chapter 14):

1. Update information.
2. Review the viability of the programme.
3. Assess benefits.
4. Evaluate benefits if the tranche was a pilot.

Reviewing benefits

Part of your end-of-tranche reviews is benefits reviews. You want to make sure that the reviewers are focusing on these sorts of questions:

• Were planned benefits realized or not? That is, were targets correct or too low?
  • If benefits weren't realized, why not? Can remedial action be taken?
• Does a pattern apply to the success/failure?
• Were the assumptions correct? If not, what was the effect?
• Have dis-benefits been managed and minimised?
• Did you experience any unexpected (dis-)benefits?
  • If so, can they now be maximised or minimised?
• Do any further potential benefits exist?
• Were measures correct?
  • If not, can they be refined? Was data collection effective?

Here are some typical objectives for an end-of-tranche review:

• To assess the achievements of the tranche
• To discover how far the programme is on the way to the Blueprint
• To see whether any corrective projects are needed.
• To find out whether any unexpected benefits are possible.

The end-of-tranche review can ultimately result in a go or no-go decision for the programme.

Allocating Responsibilities Across Tranche Management

Although usually the SRO is accountable for all the activities in the Managing a Tranche process, the Programme Manager is responsible for them. The exception is the transition and stable operations activity (check out the earlier section ‘Transitioning and maintaining stable operations’), for which the Business Change Managers are responsible. For activities such as communications, audits and Blueprint alignment, the Programme Manager and Business Change Managers share responsibility (‘Managing the programme’ earlier in this chapter has all the details on these aspects).