Review of Managing Successful Programmes (MSP) 5th Edition

I’ve belatedly got to grips with Managing Successful Programmes (MSPⓇ) 5th Edition. I’m late to the party – my book was delivered several weeks late, thanks to Brexit.

The new MSP 5th Edition replaces the 2011 4th Edition, one of the most successful books produced by the team at OGC/Cabinet Office. The 4th Edition had its strengths and weaknesses, but overall was liked for its simplicity (not packed full of rules like Prince2) and utility (good practical guidance for Programme teams).

How does the 5th Edition stack up compared its predecessor?

First, the Good News

The new guide has some strong points, for example:

• The concept and application of VUCA (volatility, uncertainty, complexity and ambiguity)
• Design and planning are now separate activities (as I have espoused in my new book)
• Recognition that some projects will use Agile or Hybrid methods (read my book)
• Communities of Practice (read my recent blog)
• Use of Retrospectives (read my book)
• Some clarification of the role of Programme and Portfolio Offices
• Removal of some poor material (e.g. the weak material on Quality)

Additionally, there is continuity with many of the key documents previously used in previous versions, such as the Programme Brief, Vision Statement, Business Case, Benefits Map, etc.

The Themes are prisoner of the 777 gimmick

The new book has a structural problem, which seems to be self-imposed. It has adopted the infantile Prince2Ⓡ gimmick of having 7 principles, 7 themes and 7 processes.

The artificial limit of 7 themes has meant a savaging of the themes from the 4th Edition, with the disappearance of some key subjects of prime importance to programme teams.

If you ask a programme manager for his or her main areas of concern, you will probably get a list something like this:

• Benefits
• Stakeholder Engagement
• Risk / Issues
• Planning
• Business Case

In the new book, only two of these survive

• Business Case, which is renamed Justification (and is now overly focussed on financial benefits, to the exclusion of non-financial and intangible benefits)
• Planning, which is renamed Structure (a bizarre choice of name, which only serves to confuse).

The new themes of Design, Knowledge and Assurance make sense (unlike the new Decision theme, which is full of fine words about decision-making, but lacks practicality). What doesn’t make sense is the arbitrary limit of 7 themes. The authors are trapped in a prison of their own making.

The resulting 7 themes are overloaded, and the absence of key chapters such as Risk, Benefits and Stakeholder Management is a serious weakness. In previous versions of the book, several key concepts of Change Management were introduced in the chapter on Stakeholder Management – that chapter has now gone. The new book is weaker as a result.

In general, a programme team using the 5th Edition book as a resource during a programme will struggle to find the practical information they need.

The Processes are adrift

The new book starts with VUCA. It’s on the first page of the introduction: we are in a new world of volatility, uncertainty, complexity and ambiguity.

To respond, the new book has a new process model or Programme lifecycle, influenced by VUCA and inspired by Agile iterative delivery. The old approach of a master plan, carefully worked out in advance, then delivered in tranches has gone. In a VUCA world of volatility, there must be frequent assessment of new information and consequent redesign and replanning.

But the new process model has two major weaknesses

Weakness 1: The new process model is wrong

The new  process model is presented as an iterative loop.

This is highly misleading, as the first time round the loop, the Design and Plan processes are heavy – they initiate all sorts of work; whereas on subsequent iterations, these two processes are light – they revise existing documents.

So the model should be like this

Weakness 2: The gate process has gone

Since its inception in 1999, MSP has never used the word “gate”, but it has always been a gate process. (The same is true for Prince2.)

Gates are good for governance: In most cases, at the end of a tranche, there should be a go/no-go gate; by default, the gate is closed; when the gate is opened, the team can start the next tranche. If there is no clear gate, then the programme can too easily drift along from one tranche to another…

The new version is unclear about gates. Instead it has multiple “formal approval” points (five per tranche). This is not a basis for good governance.

Gates support Management by Exception: In a gate process, the gate meeting occurs to take a go/no-go decision and to delegate work to the programme team.

That’s a key element of Management by Exception

• Gate meetings are decision meetings
• Don’t have a meeting if there is nothing to decide

Management by Exception has disappeared from the new 5th Edition. That’s a mistake.

With no clarity on gates, and with 5 decision points per tranche, the 5th Edition process opens the door to Management by Meeting.

To sum up: the process model needs clear gates, possibly like this:

Will 12 approaches be used… or sidelined?

The new 5th Edition has 12 approaches. Unlike the themes which have been limited in number, the approaches have multiplied. The 8 strategies in the 2011 version have become 12 approaches in the new edition.

The previous 8 strategies were hard to digest. As a trainer, I too often saw blank incomprehension when I patiently explained the 8 strategies in the classroom. I always suspected that these strategies would be remembered in the exam room, then rapidly sidelined and forgotten.

In the new book, there are 12 approaches, scattered around the book in 7 themes, and not even collated together in the important appendix A, Programme Documentation. They remain important in the exam room, but will they be used in real-world programmes? I suspect not.

Tinkering but not adding value

Programme Management is about Change Management and adding value.

In this new book, there is a lot of low-level change which adds no clear value (“planning“ becomes “structure”, “strategy“ becomes “approach”, etc.)

And there’s a lot of new consultancy jargon using word-pairs which will confuse rather than clarify, especially for non-native speakers of English. (Note that only 2 of the following 9 words are in the glossary)

• affordability vs achievability

• pace vs velocity

• capacity vs capability (or ability)

• efficient vs effective

Worth the bother?

So, is the new MSP 5th Edition worth the bother? The book has been modernised, but has it been improved? Is this really the new best practice? As I wrote in an earlier blog, the term “Best Practice” has become very popular. Too often, it is overused. At worst, it is pure marketing-speak.

Axelos are a sales and marketing company (unlike their OGC/Cabinet Office predecessors who worked for the UK government). As ever, Axelos assure everyone that the new MSP 5th Edition is best practice. But that’s what they said about the old MSP. Yesterday’s best practice is suddenly declared to be obsolete. As the saying goes, Le Roi est mort, vive le Roi (the King is dead, long live the King!). And Axelos are the king makers.

The 4th Edition from 2011 was fairly easy to learn, and fairly easy to apply. It served as a practical reference guide. The new 5th Edition is harder to learn. It’s much more conceptual; and consequently less practical.

Indeed the guide has been modernised, but it has also been rewritten, not always successfully. And a good many changes are questionable. They add confusion, not value.

This is not a success in terms of Change Management. Any mixed teams, where some people use the 4th Edition and others the new 5th Edition will face issues. Corporate PMOs will also face issues. They might be reassured that most of the key documents are unchanged (the templates), but should be concerned about the gap between the two editions; and that the 5th Edition is less practical, harder to apply.

So if you already know MSP, don’t rush to migrate to the 5th Edition. It’s a big change, requiring too much effort, with not enough added value.

If you are new to MSP, then take the plunge. This new edition is not easy to digest, but MSP will inspire you and guide your programme management. At least that is unchanged.

___ 

Prince2Ⓡ and MSPⓇ are registered trademarks of Axelos Ltd

6 honest servants to build your Communications Plan

Do you know who said this?

"I had six honest serving men. They taught me all I knew.

Their names were: Where, What, When, Why, How and Who"?

You probably don't know - but you'll recognise his name. It's Rudyard Kipling, author of "The Jungle Book", now famous as a Disney film.

Rudyard Kipling's saying can help you in Project Management. His basic questions "What, When, Why, How and Who" can guide you though the tangled jungle of project management communications.

Communications are important in Project Management - they can be critical to project success. Various analysts have highlighted poor communications as a major source of project failure, from the Standish Report of 1996 to the 2007 survey by COMPTIA.

Why is it so important to communicate? Firstly because many projects are cross-functional. Most organisations are functionally based - they are a series of functional silos. Things may work well inside each silo, but projects need to work transversally, across the organisation (more than one silo) and they often need to work with partners outside of the organisation (more than one company). For a cross-functional project to succeed, you need rich, transversal communications.

Secondly, the project is a vehicle for change. People are naturally resistant to change; they are familiar with the current ways of working. Change is disruptive; there is resistance to change. For your project to deliver real change, you need to communicate to maximise buy-in and to minimise resistance.

As it is important to communicate, the project manager needs a communication plan. This is where Rudyard Kipling's saying comes in.

We need our own Six Honest Serving Men to create a communications plan.

·  To whom? The stakeholder group who receive the communication

·  What? The message to communicate

·  Why? The objective of the communication

·  By whom? Who will create and/or deliver the communication

·  When? What frequency, or what date, or during which stage of the project

·  How? What channel of communication (email, face to face, meeting, intranet...)

Example

To Whom?	What?	Why?	By whom?	When?	How?
Entire project team	Initial objectives	Get involvement	Project Manager	Start of project	Kick-off workshop
Order management team	Training schedule	Ensure availability for training	Order Admin Manager	Start of stage 2	During monthly team meetings
Sales Force	New bonus scheme	Motivation	Regional Sales Manager	At next Quarterly Meeting	Powerpoint with Q&A
Internal Audit	Process flowchart	Compliance	Process team lead	For each new version	Process workshop
etc...

Creating the communications plan is the first step. Once that's done, the next step is to put the plan into action - to use it to organise your communications, week-by-week, month-by-month.

For the project manager , creating a communication plan is useful investment of energy. It normally takes you only an hour or two to create an initial plan, and it will save you hours of sweat throughout the project. It helps identify your transversal stakeholders. And it helps you focus on areas of possible resistance, and how best to mimimise resistance.

A communications plan is a best practice approach. In the Prince2 project management method, it's the basis of the project's Communications Strategy.  In MSP, for programme management, there is a diverse toolkit, starting with a Stakeholder Engagement Strategy; passing by various Stakeholder Analyses; and finishing with a Communications Plan.

Whatever your method, get out of the jungle! Remember Kipling's six honest servants and create a communication plan for your project or programme.

Project management, change management are like apples and pears

Should a project manager be a change manager? The traditional answer was YES, a project manager should know how to manage change. Today the answer is more often NO, as there are new and better ways to manage change.

Change initiatives are increasingly using a new role of Business Change Manager to manage complex change. In such cases, the project manager is no longer a change manager. Apples are apples and pears are pears: project managers manage projects. And change managers manage change.

What is wrong with a project manager running change management? Why invent this new role of Business Change Manager?

If we understand the Customer - Supplier relationship in projects, we will understand why. A Customer - Supplier relationship underpins most change initiatives: the project teams are on the supplier side, delivering a solution. The business teams are on the customer side, using the solution.

This “customer - supplier” relationship is not a question of contracts or invoicing. This relationship exists even for internal project teams working inside one company - an internal supplier provides a solution to an internal customer

This is why the we have two distinct roles, the project manager role and change manager role. One role on the supplier side, a separate, distinct role on the customer side.  And this is a peer-to-peer relationship, where the two roles are equal, not hierarchical.

Programme management methods like MSP (Managing Successful Programmes) recognise this separation. MSP has two two key processes
    ❑    a supply side process, called “Delivering the Capability”, for building the solution in project mode 
    ❑    a change management process on the customer side, called “Realising the Benefits”, for transitioning to the new solution and measuring the success of the change.

This approach has many advantages. Notably, it recognises that the motivations of the Project Manager and the Business Change Manager are very different.

The Project Manager is often motivated by
    ❑    technology (performance, features, innovation)
    ❑    sign-off and approval
    ❑    project performance measures such as finishing OTOB (On-time and On-budget)
   
The Business Change Manager has different concerns
    ❑    reliability, stability
    ❑    ease of use, training, support
    ❑    good documentation
    ❑    long term benefits

The Business Change Manager role needs business skill, rather than project management skills. The Business Change Manager should be chosen from the business area that will use the new solution. Crucially, after the solution is implemented, the Business Change Manager will return to the day-to-day business, and will use the solution week-by-week, month-by-month.

This reveals another important difference in motivation between the two roles the Business Change Manager (and his or her colleagues) is going to use the new solution, whereas the Project Manager will probably never do so. That’s a big difference, and that’s another reason why we we need a dedicated Change Manager.

So for your next business change initiative, try not to mix apples and pears. Don’t confuse project teams (apples) and business teams (pears). Project managers should manage projects. And change managers should manage change. Keep those apples and pears apart.