Chapter 23

Ten Reasons to Run an Initiative as a Programme

In This Chapter

Employing parts of programme management

Recognising when to start an emergent programme

Using programme management to deal with risk and uncertainty

In Chapter 22, I provide three tests to help you decide whether to treat a change initiative as a project or a programme. But sometimes the world isn't that clear; you may not have a sufficiently broad perspective on your change initiative to make an easy and absolute one-thing-or-the-other decision.

So in this chapter, I provide ten symptoms that, if you spot them in your change initiative, suggest you need to think seriously about running it as a programme. I also include a number of illustrative examples from the real world to help clarify the situations. Frequently, the result is an emergent programme (one that evolves from concurrent projects; see Chapter 2 for details).

You can use these indicators to consider employing certain elements of programme management to help you run a change initiative. You don't have to use all programme management to add value to your initiative (I discuss the principle of adding value in Chapter 4).

Co-ordinating Complex Activities

Although the basic programme management organizational structure looks simple, it gives plenty of scope for setting up additional governance structures and for creating posts, particularly in the Programme Office, to carry out extra work on behalf of the programme. None of this gets in the way of projects building their outputs.

So if you're running a change initiative as a project and you find that the project team is being distracted from creating outputs because of the number of related and important activities they end up co-ordinating, use some of the programme organizational structure to help you out.

For example, if you're running a project that includes training some users and you discover project team members setting up committees to talk to the various users and understand their training needs, take a lesson from programme management and create a design authority or create a post called training co-ordinator in your Project/Programme Office. I describe such additional roles in Chapter 9.

Organizing Scarce Resources

Resources are always finite ‒ and that's a fact. When several projects are competing for the same resource, you probably need to use some programme management.

I recall a time when I was working in an IT area that delivered lots of projects. I was one of the line managers overseeing a dozen or so projects in different parts of the business. It wasn't really a programme due to very little overlap among the projects, except in one particular area. We were very short of one resource: database administrators. My project managers were always fighting for the resource and complaining that their projects were being delayed because they couldn't get those staff.

So I set up a resource co-ordinator to work for me and allocate scarce resources among my projects.

Harmonising Design Interfaces Among Projects

It's pretty normal for one project to negotiate with other projects about some design details. You don't need programme management to allow a couple of project managers to get together and come to an agreement.

But if a project needs a large number of other projects to agree on a design interface, the situation is different. (A design interface is just how something is passed from one place to another. When you send enclosures with emails you're using a common design interface for the format of the enclosure. It works most of the time, but occasionally you can't open a document.)

Some organizations print a lot of documents, often for legal reasons, and doing this centrally can still make sense. I had a project running to upgrade the central print function. The print jobs came from lots of different business lines and, if those lines had been stable, the upgrade would've been straightforward. But many of those business lines were changing what they wanted printing (each of those changes was run as a project). My guys in the print project were unable to find out what they needed to print.

The solution was to use programme management to co-ordinate the design interfaces among all these projects. In effect, I was putting in place a Blueprint similar to the ones I describe in Chapter 6.

Dealing with Economies of Scale Among Projects

Sometimes you face a situation where a series of projects are running that aren't very closely linked. Perhaps they all need to use similar functions but in different ways. In that case, giving the building of that function to a separate project may be more efficient. The project team's task is then to create a generic module to be reused across multiple projects. (If you're from an IT background, this idea is similar to object orientation.)

A simple example I recall, again involving IT, was when several projects wanted to put in place an online security function. I preferred using a separate project to build the security module. That meant I had to put in place the sort of communication among projects normally called programme management.

Creating a Framework in an Uncertain Environment

Of course, business rarely runs smoothly; you always face challenges. But sometimes the going is particularly rough, and seeing into the future becomes difficult. For example, perhaps external regulators are about to introduce a whole series of new rules, or technological innovation may disrupt the market. In such uncertain times, creating a programme can be helpful.

When describing most programmes, you think about creating a Vision that's stable from very early on in the programme. When creating a programme to help steer you through uncertainty, however, you may find that you set up the programme structure and co-ordinate the change initiatives some time before the situation is clear enough to describe a well-defined Vision. In this situation, the programme structures can provide reassurance for stakeholders in uncertain times.

Handling High Risk across Multi-Projects

Spotting a risk not in your area but in someone else's is fairly common. I talk about stakeholders being good at identifying risks in Chapter 11. If project people from a group of projects keep spotting risks that can only be handled elsewhere, in other projects or centrally, then that's another clue that you may need a bit of programme management.

I was working with the risk co-ordinator in a business while his workload increased. Projects were identifying risks that only other apparently unrelated projects could mitigate. These risks being bounced among projects made us think about creating a programme to cover all those projects. After we formed the programme, unsurprisingly one of the key posts in the Programme Office was a risk co-ordinator dedicated to the programme. In Chapter 11, I examine more closely how this arrangement can work.

Coping with a Contracting Universe

Finding yourself in a situation where your business universe is shrinking can mean that you need to use programme management.

I was working with a retail business that was contracting rapidly. The situation wasn't pretty, but the reality was that our market was shrinking and we had to do something about it. After operating for several years in different national markets, we now focused on the UK. So, for example, we combined separate German and French divisions into an international division. As our business universe shrank, projects or different parts of business as usual that had experienced little interaction now became increasingly connected. This spurred us into creating an emergent programme to co-ordinate all these connections.

When a business is contracting, for whatever reason, projects and pieces of business as usual that were distinct and separate often move closer together. As a result, you may need to bundle its change initiatives into programmes.

Ordering Change in Business as Usual

Sometimes the trigger for creating a programme sits within business as usual, where a particular part can develop lots of ideas for new change initiatives that may take place in the same part of the business. But if they all happen in an unco-ordinated way, business as usual faces change overload.

You can avoid this danger by creating a programme structure that focuses on sequencing the change in business as usual at a more manageable pace.

Managing Multiple Stakeholder Groups

Project management works well when you can identify a single stakeholder group that will be the users. But sometimes even a modest change initiative may affect lots of different stakeholder groups with competing interests. In these circumstances you may need to pick up on some programme management ideas around stakeholder engagement, the programme organization, the Vision and Blueprint.

For example, if different organizations are providing medical services and social care to a community, bed blocking can result. People with chronic illnesses, usually older people, aren't released into social care smoothly. Consequently they remain in hospitals, blocking valuable beds, when they really need a much less intensive level of medical support.

On a number of occasions, even when working in quite small communities, I've used an element of programme management to help deal with this situation. Where a large number of stakeholder groups from different professions and charities existed, I needed more sophisticated stakeholder engagement to bring them all on message, even though the size of the initiative was small. Chapter 14 is particularly relevant in this situation.

Funding a Busy Business Case

Thinking of a Business Case being funded by a single body sounds great, but often the world isn't that simple. If you have a change initiative where funding originates from multiple sources, managing the Business Case can become complex.

Use programme management ideas around the Business Case and the relationship to benefits to help build an alliance that funds the initiative. Chapters 8 and 15 are useful in this context.