Managing Successful Programmes

I’ve clarified the process I have in mind, based on the previous two posts:

In Programme Procurement Strategy - 1 I briefly reviewed the approach from the OGC Risk Allocation Model for Project Strategy and Procurement.

Thinking about how to apply that approach to my own programme, I quickly realised that the range of changes we are seeking to deliver (across technology services, business processes and management capabilities) does not easily sit into a single risk assessment.

So I’m still attracted to the risk-based approach, but it is going to need substantial de-composition of the programme to apply it meaningfully.

I’m going to start with the Blueprint, since that is where our final outcomes are defined. For each area of the Blueprint I will examine each outcome, and analyse against the risk framework from the OGC guide.

I need to put together an analysis of procurement options for the programme I am shaping, as first steps in devising a procurement strategy.

The main online reference I have found so far is the OGC’s Risk Allocation Model for Project Strategy and Procurement (pdf).

The first part of that document examines the suitability of different contract types in relation to the nature of the organisation and the programme goal:

• Understand overall programme goal
• Think about life-cycle of that goal, and of the sponsoring organisation – i.e. Volatility
• Understand the difference between Inputs, Outputs and Outcomes
• The more volatile the goal or the organisation, the less likely that you will be able to successfully procure for Outcomes, or possibly even for Outputs.

The document then goes on to consider the risks related to organisational capabilities. The earlier in the value chain Inputs-Outputs-Outcomes, the more skills are required within the organisation for integration and change management, and the more vulnerable you are to opposition from within.

The last area of consideration is the ability of the market to supply a particular  service.

Once all three areas have been analysed, it’s likely that further iteration will be required to converge the  solution.

Further reference to the MSP manual (p77, 2003 version) identifies three areas of programme activities where quality management is involved:

1. Quality management of the governance arrangements – this corresponds to the top level “Governance Reviews” in post 3 of this series.
2. Quality assurance and review of project outputs – this corresponds to the lower three levels in post 3 of this series.
3. Configuration Management of key programme documentation.

Drawing on this we need to add an area to our Quality Management Strategy (item 3 above).

I’m puzzled that the section on Quality Management makes no reference to Benefits Reviews (they appear in the chapter on Benefits Management), but as I’ve noted, they are critical to ensuring the delivery of Value, so in my opinion they should be integrated into this strategy.

Earlier posts in the series:

• Quality Management Strategies - 1
• Quality Management Strategies - 2
• Quality Management Strategies - 3
• Quality Management Strategies - 4

At some point we will have to identify the who of Quality Management – who will carry out all of the activities.

Looking at the last post it occurred to me that a useful simplifying assumption would be to divide the processes into three levels:

The activities in the first section are the responsibility of the SRO / Programme Director, often with external help such as audit.

The activities in the second section are the responsibility of the Programme Manager, assisted by the Programme Office

The activities in the third second section are likely to be the responsibility of the individual Project Managers, often assisted by the Programme Office

Earlier posts in this series

• Quality Management Strategies - 1
• Quality Management Strategies - 2
• Quality Management Strategies - 3

In the last two posts of this series I have started down the line of understanding the value chain of a programme, and therefore what it is we need to quality assure.

This post steps back for a moment to think about the sort of process we need to design in our Quality Management Strategy – the how of quality assurance.

One of the major differences between a programme and a project is the very much higher likelihood of change in a programme than in a project:

• Firstly, the programme itself may change direction over its lifetime, reflecting changes in the surrounding environment;
• Secondly, the precise makeup of the project portfolio may change to deal with new opportunities and threats, or to accommodate changes in programme direction;
• Thirdly are the inherent changes within each project in the portfolio.

So the process(es) we invent and document in a Quality Management Strategy must be designed from the start to accommodate change in any of the inputs. That implies ongoing review at a number of nested levels.

Earlier posts in this series

• Quality Management Strategies - 1
• Quality Management Strategies - 2

Why do we need a Quality Management Strategy?

In an earlier post I wrote about my confusion when starting to think about how to create a quality management strategy for my programme.

Let’s go back to basics – why do we need a Quality Management Strategy?

Fundamentally it’s about ensuring (to an acceptable level of certainty) that the Programme will deliver what it sets out to deliver.

And that is about Value.

A Programme delivers Value through achieving Outcomes which deliver Benefits.

So the starting point for a Quality Management Strategy has to be around the shaping and validation of Outcomes, and the identification of Benefits.

Shaping of Outcomes is essentially a political process – framing the programme so that it meets the perceived needs of the sponsoring group.

Linking of Outcomes to measurable Benefits is a critical part of defining the Programme, and includes the identification of Benefits, devising a Benefits Management Strategy and validating the Benefits Realisation Plan.

So the first step in our Quality Management Strategy must be the processes around Planning and Realising Benefits.

That’s why Benefit Reviews are important.

I’ve been thinking about how to put together a Quality Management Strategy for the programme I am shaping. Question is, where to start…

The MSP Manual says:

[…] used to define and establish the activities for managing quality across the programme

which sounds tautologous to me.

In Chapter 9 on Quality Management, a bit more detail appears:

The Quality Management Strategy defines what criteria will be used to assess quality, what quality activities will be incorporated into the management and delivery of the programme, who will be responsible for carrying out these activities, and how the programme will meet required audit and organisational standards for quality assurance and quality control.

In Appendix B there is more specific guidance on the contents:

Description of the quality assurance, review and control processes for the programme, covering:

• What will be subject to quality assurance, review and control, and the quality criteria to be applied.
• Who will undertake quality assurance, review and control activities
• What will trigger those activities (time-based, event-based or associated with risk occurrence)
• What actions will be taken depending on the results of quality checks
• Configuration management and change control procedures
• Defined responsibilities for quality management
• Information requirements to support quality management
• Procedures for use of support tools for quality management activities e.g. change control software
• Resource requirements for quality management

All of which will be very useful to describe the headings, but which doesn’t ask the fundamental question – why are we doing this? A later post…

The UK Department for Education and Skills are major users of Programme and Project Management. To aid programme startup, they have an approach known as The 22 Questions.

As an aid to meeting facilitation, here are the 22 questions as a MindManager mindmap.

I had a good example the other day of the potential of the Stakeholder Power/Impact Matrix .

I was discussing with a colleague the framing of another potential programme, and quite informally drew a rough matrix in front of him. I explained the meaning of the two axes and then with him discussed our first impressions of who should appear on the chart, and where they should be placed.

We found the exercise illuminating, not least because the small discipline of deciding where each person or group should go triggered us to articulate some deep-seated and potentially difficult issues around certain individuals.