Chapter 6

Building Up a Blueprint

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.

Tying Up Blueprint and Vision

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 fact, the Blueprint contains even more than that. It features a ‘now’ model of the present and a ‘then’ model of the future. A properly developed Blueprint makes understanding the outcomes easier, which consequently helps you to identify the benefits; the benefits are how you'll measure, or assess the achievement of, those outcomes.

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.

Spend some time becoming familiar with these links between the key elements in MSP. Getting them clear in your mind is important, as is becoming comfortable with them.

Situating the Blueprint within the programme

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.

Formally, the purpose of the Blueprint is to maintain focus on delivering transformation and business change. It elaborates on the Vision of the programme and can also be known as the target operating model.

Therefore, the Blueprint is the destination. The Project Dossier and the Programme Plan describe your journey – how to get to that future state.

Entering the programme environment

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.

As the programme changes course at tranche boundaries, you may well require intermediate Blueprints that describe the point where your programme can consolidate and draw breath, before continuing on its long and winding road.

Vision becomes Blueprint

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.

Tranches and transition

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.

The straight vertical lines in Figure 6-2 are the tranche boundaries. The black swans at the top of each boundary symbolise unforeseen consequences. A black swan is something out of the ordinary, an event with the following attributes:

• An outlier (meaning it's outside the expected range)
• A rarity outside your regular expectations, because nothing in the past has suggested to you that it would happen
• An extreme impact

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.

The relevance of tranches, when looking at the Blueprint, is that you may well need an intermediate Blueprint for the end of each tranche.

Right projects (done) right

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.

Connecting the Blueprint and other themes

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.

Building a 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.

Defining a Blueprint

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.

A Blueprint is quantitative not qualitative – it contains numbers. You need to quantify the Blueprint by adding performance metrics to each of the sections. So, for example, in the organization section say exactly how many staff are at each grade, or in the tools section say how many giant dumper trucks the mine needs. Initially, these values are indicative, but with each refinement (each iteration) they need to become more precise.

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.

You iterate around all the different versions of the Blueprint to bring them into line.

Minding the gap: Current and future states

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.

1. Carry out sufficient analysis so that you understand the current (or ‘as is’) state.
2. Model the future or (‘to be’) state.
3. Perform a gap analysis, comparing the current and future states in order to understand that gap.
4. Plan and manage the journey from one state to the next.

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.

You only need to understand the current state in enough detail to inform the journey. Don't fall into the trap of becoming paralysed, analysing an illogical and ever-changing current state. Also remember that the more radical the transformation, the less the current state can inform the nature of the future state.

Defining tranches

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.

A tranche is:

• A step change in organizational capability. In other words, it's a major change in what the organization looks like, not something trivial.
• A distinct set of benefits

If tranche boundaries run across the full programme, you can carry out a strategic review to:

• Assess achievements to date
• Confirm necessary realignment of the programme

Therefore, projects are likely to run across tranche boundaries.

Creating the Blueprint for an Emergent Programme

The situation is slightly different for an Emergent Programme (which I introduce in Chapter 2). An Emergent Programme comes into being when the organization recognises that a number of existing projects are interrelated and would be better run as a programme.

In these circumstances the steps for creating the initial Blueprint are as follows:

1. Analyse existing projects:
   • Identify products and dependencies.
   • Step back to the underlying concept.
   • Create the inherent design.
2. Merge project designs into the Blueprint.
3. Check whether the future state remains cohesive.

These steps sound logical, if quite brief. In reality, however, you're likely to face a lot of politics and power plays as the sponsors of the individual projects become aligned with the reality of the Emergent Programme. You may need to use a great deal of tact as you pull together an Emergent Programme. Creating a Blueprint is one of the tools you can use to demonstrate how well, or how badly, the candidate projects fit together.

Helping Your Blueprint to Evolve

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.

Analysing your options

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:

• Balance in the Business Case
• Benefits
• Capability to manage work
• Need for funding
• Project and programme management capability
• Risks

Adopting existing projects

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:

• Proximity to delivery?
  • Perhaps adopt a project near to completion.
• Strategic fit?
  • Perhaps adopt projects that align with the Blueprint.
• Re-usability of delivered outputs?
  • Perhaps adopt parts of projects that can deliver outputs you want to re-use.

Setting up pilots

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:

• Pilot different delivery options
  • As early as possible
  • As cheaply as possible
• Have a plan for closing pilots when their feasibility is demonstrated

Refining your Blueprint

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:

• Revisit:
  • Definition
  • Scope
  • Delivery status
  • Expected benefits
• Carry out:
  • At tranche boundary
  • When a major change is proposed
• Before transition:
  • Check capability is ready for delivery
• After transition, test whether the capability:
  • Led to improvements
  • Resulted in benefits

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.

Knowing Who's Involved in the Blueprint: The Design Authority

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.

A good name for this group is the Design Authority. Typically it includes subject-matter experts from each of the relevant functional specializations such as IT, HR and finance. You also want people with expertise in designing things like organizational structures, IT systems or process modelling.

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.

Reeling off the Blueprint responsibilities

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.

Senior Responsible Owner

The SRO is that very senior individual who's accountable for the success of the programme and is responsible for:

• Providing strategic direction for the Blueprint design.
• Ensuring Sponsoring Group authorization and commitment to the ‘to-be’ state, demonstrated through active co-operation; for example, making appropriate resource available to assist with design.
• Ensuring that the Blueprint remains aligned with the strategic direction of the organization and promotes a coherent capability.
• Providing the link to the Sponsoring Group and other key stakeholders, maintaining their commitment.
• Providing advice and direction to the Programme Manager and Business Change Managers.
• Ensuring that the Programme Board assesses and understands the implications of the Blueprint and its delivery.

Programme Manager

The Programme Manager runs the programme day-to-day and is responsible for:

• Ensuring that the Blueprint is authored and assembled in collaboration with the Business Change Managers.
• Working closely with the Business Change Managers to ensure that the Blueprint, Programme Plan, Benefits Realization Plan and Benefit Profiles are consistent and able to deliver the Business Case.
• Ensuring that the programme has access to competent resources.
• Ensuring that appropriate options appraisals take place.
• Communicating Blueprint details to projects and other programmes.
• Ensuring that the project teams clearly understand the planned step changes in operational capability.
• Ensuring that uncertainties and ambiguities relating to the content of the Blueprint are identified and recorded as risks.
• Contributing to managing stakeholder expectations.

Business Change Manager

Each Business Change Manager beds down the changes in her part of the business and is responsible for:

• Leading the development of the content and taking responsibility for the delivery of the design into business operations.
• Consulting with and gaining support from senior business managers for the ‘to-be’ state.
• Ensuring that the planned step changes in operational capability are clearly understood by the operational areas.
• Providing and co-ordinating essential input to the Blueprint with the assistance of experienced operational staff and specialists, and (where appropriate) authoring parts of the Blueprint.
• Ensuring that ‘as-is’ and ‘to-be’ information from the Blueprint is used to construct the Benefits Profiles.
• Aligning the creation of the capability within the Blueprint with benefits realization through approval of project outputs.
• Ensuring that operational changes during the life of the programme are being reflected in the evolving ‘as-is’ state in the Blueprint.

Programme Office

The Programme Office looks after the administration of the programme and is responsible for:

• Providing or locating information and resources that can assist with the design of the Blueprint.
• Facilitating impact assessments of changes on the Blueprint.
• Maintaining configuration control of the Blueprint. That means keeping track of the versions and how they fit together.

Considering Blueprint responsibilities: A real-life example

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.

I was auditing a programme that had just started and was advising on how to set up the Programme Office. I'd already found evidence of a lack of co-ordination between different parts of the business (silos) when maintaining the Blueprint. This problem was caused by:

• Lack of explicit recognition of the need for Blueprint design and delivery
• Silo-based groups of projects
• Incompatible planning horizons for the different functions – some people were planning for the short-term; others were planning three years ahead.

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:

• The Blueprint was strictly hierarchical. Some silos were producing information at a lower level of detail than others. Adopting a hierarchical structure allowed us to make sense of these different levels of detail.
• The programme wasn't tightly controlled and we didn't have the power or the resources to take design functions from silos into the Programme Office. Therefore the Blueprint simply contained hyperlinks (links to where the information was really stored, like you find on a webpage, rather than a copy of the information) to the relevant information still being maintained within the silo-based work streams. The role of the Design Authority was to co-ordinate. This arrangement proved very successful.

For another illustrative example, read the nearby sidebar ‘Grinding out a Blueprint’.