Managing Successful Programmes

I’ve just heard that I have passed my PRINCE2 Practitioner qualification, thanks to the excellent help of Pearce Mayfield.

I’ve been “broadly familiar” with the PRINCE2 method for a number of years, but have resisted getting into it too deeply because of the bureaucratic nightmare I have seen many organisations make from it.

One of the best things I can say about the Pearce Mayfield training is that through it I have seen, by contrast,  how to make PRINCE2 a living and breathing approach to delivering a project.

Delivering successful IT-enabled business change (PDF), published by National Audit Office November 2006.

Summary

IT-enabled business change essential for reforming public services.

Many examples of failure, report examines 24 examples of success to draw out key factors, projects from £k20 to £M800+.

For the critical success factors identifies key questions to assess likelihood of success.

Critical Success Factors (and related questions)

Ensuring senior level engagement

• Is the board able to make informed judgements about the department’s capacity to manage change?
• Does the department have in place a decision making structure that will ensure strong and effective leadership of the IT-enabled business change?
• What incentives exist to drive performance?

Acting as an intelligent client

• Does the department have the necessary programme management skills?
• What is the natural division of duties between the Programme and Project Management Centre of Excellence and the Chief Information Officer?
• How will the department establish and promote an open and constructive relationship with suppliers?
• How clear is the department about the business process that it is seeking to change or develop?
• Does the technology exist to deliver the change?

Realising the benefits of change

• Beyond immediate technical success, how will wider benefits be secured?

I spent half a day earlier this week at the Best Practice User Group Congress. BPUG is concerned with the application and use of OGC products such as Prince2, MSP and MoR. As you might expect therefore there was little mention of alternative methods such as Agile.

I didn’t have time to attend the conference sessions, so this is somewhat less than a full review: I did however take part in one round-table session and had a chance to speak to a number of vendors at the exhibition.

“Simple, not Easy”, hosted by Adrian Dooley from The Projects Group was advertised as seeking “… to identify the fundamentals behind the evermore contrived solutions for consistently delivering successful projects”.

I’m not sure we achieved that in 90 minutes, crammed into a room that showed an artful ability on behalf of the hotel to turn a fire escape corridor into a meeting space (!!), but there was some entertaining discussion, capped by Adrian’s takeaway – “Practice what you preach” – i.e. as professionals in achieving business change it’s down to all of us to address the business changes needed to make project management more effective in the organisations we work with.

There was a small exhibition area with a number of vendors of software, consultancy and training. Ones which caught my eye were:

• Change Director
• PAT from NinthWave
• RiskAid from Risk Reasoning

I’d have liked to take a look at Simply Project Office from Mundane Software, but sadly they seemed to suffer from the mundane problem of having no-one on the stand when I looked!

I’m planning to attend Agile Approaches for Delivering Business Value next week.

It looks like an interesting set of sessions, and although I doubt I’ll be liveblogging, I aim to post some notes here as soon afterwards as I can.

I’m particularly interested in two of the talks on the second day:

“A Square Peg in a Round Hole: Agile and fixed-price contracts” by Duncan Pierce;

“When XP Met Outsourcing” by Angela Martin.

In my current environment almost all our systems development is carried out by suppliers in various contractual models, and I’ve hit some frustrations in getting acceptance of Agile methods. I’m keen to learn how others may have constructed a “win-win” in this sort of situation.

(cross-posted on main blog)

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.

I’ve just got my hands on Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change by Gerald Bradley.

I’ll blog key notes here as I dissect the book.

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