Chapter 6
In This Chapter
Linking your Blueprint to your Vision
Establishing your Blueprint
Evolving your Blueprint
Getting the right people involved in your Blueprint
Like all For Dummies books, I design this one for you to dip into and out of at your leisure. Having said that, however, people tend to create programmes in a particular order: when you come to produce your Blueprint you're likely to have received the sign-off from the Sponsoring Group at the end of the Identifying a Programme stage. You also have an outline Vision, which is a pivotal document within your programme as I discuss in Chapter 5.
In this chapter I consider the relationship between the Blueprint and the Vision. The Vision is a high-level picture and therefore needs to be complemented with a more detailed model of the programme's desired future state. This Blueprint is a comprehensive document, or set of information, covering the processes, organization, tools (and technologies) and information that exist in the desired future state.
I also talk your through creating your Blueprint, how it needs to develop and the best people to help you with it.
Take a look at Figure 6-1, which is a simple but powerful diagram depicting the relationship between the Blueprint and some of the other key elements within a programme.
You start with the Vision, which I like to see as your postcard from the future (‘the weather's great – glad you're not here, ha ha!’). Using the same analogy, you can consider the Blueprint as a detailed report from the future.
In addition, when the Blueprint contains those outcomes, you can identify which projects you need. The projects lead to the outputs and then the capabilities, and when the capabilities are exploited they become the outcomes.
The Vision is an early customer-focused description of outcomes, which is at a summary level so that you can retain the interest of all the stakeholders. In contrast, the Blueprint is a detailed description of the changed organization, often called the to-be or future state.
Therefore, the Blueprint is the destination. The Project Dossier and the Programme Plan describe your journey – how to get to that future state.
In Chapter 2, I include a model of what I call the Ferguson Factory. Well, Figure 6-2 shows an expansion of that factory. Before reading on, work through the diagram and see how many symbols you recognise.
My intention in this section is to describe a more complex, volatile and unpredictable programme environment, which is the reality in most, if not all, the programmes on which I've worked. In such circumstances, you need a Blueprint even more to allow you to focus on the destination.
A transformational change programme needs a Vision that can be expanded into a Blueprint. Both of those items describe business as usual – the area above the horizontal dashed line in Figure 6-2. The area below the line is the project environment.
Each oval indicates a tranche (a set of projects that provides a change in capability) with, not surprisingly, a number of projects in it. I show three tranches. The left hand tranche in Figure 6-2 delivers some outputs that are seen in business as usual to be a capability. When the capability has been exploited it becomes an outcome – the effect of change. You use benefits management to monitor achievement of those outcomes.
The three linked horizontal arrows represent the transition activities (pre-transition, transition and post-transition) that need to take place in business as usual in order to exploit capabilities properly. Transition occurs in each tranche. So the sequence in subsequent tranches is again: capabilities, outcomes, benefits, transition.
Figure 6-2 contains a couple of intermediate Blueprints (they look a bit like windowpanes, to signify the four elements in a Blueprint): descriptions of future states, but at different times in the future. Each of those Blueprints also goes through a series of iterations (basically MSP-speak for revisions), when more and more detail is put onto the Blueprint.
The dotted project in the first tranche is a design project – one that creates or refines part of a Blueprint rather than delivering an output that is part of a capability.
The striped project, which may just be some activities in business as usual, gives rise to early benefits. Some people call these ‘quick wins’, but often this term is misused. Early benefits excite stakeholders and early outputs on their own are insufficient. I like the term quick wins, but you have to be careful to stop people claiming quick wins when they haven't actually delivered any benefits.
Yet in spite of its outlier status, when you think about the black swan after the event, it's explainable and has retrospective predictability.
(The term black swan comes from the excellent book of the same name by Nassim Nicholas Taleb, The Black Swan. It refers to the fact that before Europeans went to Australia, they thought that all swans were white. In Australia they discovered that some swans were black.)
Black swans are relevant in a programme, because you may think of a tranche boundary as being a planned, predictable event in the future. Sometimes a tranche boundary is just that, but quite often in a programme a tranche boundary is triggered by a black swan – an extreme and unpredictable event that was inevitable with hindsight.
I expand on planning tranches in Chapter 10 and managing planned and unplanned tranches boundaries in Chapter 18.
As you move down the diagonal plan line, you want to do the right projects as well as do projects right. Doing projects right is project management, while doing the right projects is part of planning within the programme environment. So when you do your planning you want to make sure that you place sufficient emphasis on doing the right projects, and then some emphasis on doing projects right.
The same balance is relevant when reporting on the programme (see the upwards diagonal line). Of course you need to report that you're doing projects right (you need project reporting), but you must also have programme reporting to continue to confirm that you're doing the right projects. This means linking your achievement of outputs from projects back to benefits, outcomes and ultimately to the Blueprint.
Take look at Chapter 10 for loads more on planning and control.
Figure 6-3 shows the broader set of relationships between the Blueprint and the other themes in MSP. The diagram is self-explanatory, but just to illustrate how it works, you can see that the Blueprint informs the Business Case and the Business Case justifies the Blueprint.
In this section, I describe the steps you need to take as you and your team build a Blueprint. I begin with a basic description of a Blueprint, which I illustrate in Figure 6-4, so you can see what you're aiming to create.
In essence, a Blueprint is a model of an organization. MSP recommends breaking a Blueprint into four parts – processes, organization, tools (and techniques) and information (or POTI, which is best not pronounced ‘potty’!). If the relevant experts in your programme want to break the Blueprint down in a different way, however, that's absolutely fine too – whatever works for you.
For example, in the first iteration of the Blueprint you may decide that you need about 4,000 staff. In iteration 2, you refine that figure to 4,215. In iteration 3, you work out that 1,484 are Grade 1, 233 are Grade 2 and so on.
When you look at the Tranche 1 Blueprint, you decide to put in place 742 Grade 1 and 195 Grade 2 staff in that tranche. Tranche 2 may be 355 Grade 1 and 46 Grade 2 staff. When you review the final figures during Tranche 2, the total may change to 3,958 staff.
Don't check my figures too closely! I just want to illustrate that the numbers become more detailed as time goes on, but also vary as you learn more about the future state.
As you put more detail on your Blueprint, you'll find a whole series of gaps between what you have in the current state and what you need in the future state. Identifying how to practically fill each of those gaps gives you a really good indication of what each of your tranches should be. These gaps are illustrated in Figure 6-5.
Wherever you discover a gap in outcomes, fill it with capabilities. Aiming to provide those capabilities triggers you to plan the projects that deliver outputs to fill the capability gaps.
After you carry out the gap analysis in the preceding section and start to put together a Project Dossier, you can start to define your tranches. I give a brief description here but discuss tranches in more detail in Chapter 10.
If tranche boundaries run across the full programme, you can carry out a strategic review to:
Therefore, projects are likely to run across tranche boundaries.
In these circumstances the steps for creating the initial Blueprint are as follows:
The initial Blueprint you create isn't the first version. You go through several iterations of the Blueprint during the Defining a Programme process (which I cover in Chapter 7).
In this section, I provide some checklists concerning what to consider as you create the later versions of the Blueprint in the Defining a Programme process or when updating the Blueprint later on in the programme.
Each time you put more detail in the Blueprint, you may need to look at the options, perhaps adjusting the scheduling and scope to cater for the following:
Even if your programme isn't classified officially as being an Emergent Programme (see the earlier section ‘Creating the Blueprint for an Emergent Programme’), from time to time you may want to consider adopting existing projects. Here are some factors to consider:
With this heading, I don't mean framing aviators for a crime they didn't commit (groan at the poor pun!). I mean that when you're running a large programme, you're unlikely to be able to go from the current ‘as is’ state straight to a final design for the ‘to be’ state. You may have to set up some pilot schemes to test which new business models are feasible:
You revisit the Blueprint frequently and are certain to carry out fairly formal updating of the Blueprint at each tranche boundary (Chapter 18 describes this process). But you also need to update the Blueprint regularly and frequently in the middle of tranches. Here are a few items to consider:
Figure 6-6 shows you how you may end up with two intermediate Blueprints and the final Blueprint. The diagram shows how different pieces of work contribute to capabilities that can be exploited into outputs.
Although the Programme Manager may do most of the work in designing the Blueprint in a very small programme, in a programme of any size you form a group to design the Blueprint initially.
Initially this group may create a strategic architecture covering each of the areas of the Blueprint and add sufficient detail to define performance levels. As the programme proceeds that role can change. The group may become the Business Design Authority, which provides assurance that the integrity of the Blueprint is being maintained as projects come up with local designs for outputs. Figure 6-7 illustrates maintaining Blueprint integrity. I talk about this more in Chapter 13.
Here's a list of how each member of the programme management team may contribute to or use the Blueprint. You can find more on roles in Chapter 9.
The SRO is that very senior individual who's accountable for the success of the programme and is responsible for:
The Programme Manager runs the programme day-to-day and is responsible for:
Each Business Change Manager beds down the changes in her part of the business and is responsible for:
The Programme Office looks after the administration of the programme and is responsible for:
Here's an anecdote from my own experience that shows the importance of a Design Authority in connection with Blueprints. I hope that it helps you to see how you can use the Blueprint to bring together the different players in the programme.
As a result, the technology partner had very long lead times for ordering niche technology equipment while the creative business units were focused only on artistic output for the next season.
I was unsuccessful in making the intellectual argument for Blueprint management with the Programme Director who came from the creative, front-line part of the business. She saw it as a bureaucratic overhead. However, I did uncover a bottom-up eagerness to resolve Blueprint alignment issues.
So I asked a colleague to chair a series of informal meetings across silos. Over time these meetings became the Blueprint Design Authority. This person also looked after information management and as a result he was able to put in place a Blueprint, which had several interesting characteristics:
For another illustrative example, read the nearby sidebar ‘Grinding out a Blueprint’.
18.189.170.134