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

When standard Project Management life-cycles are surprising

A few years ago, I created a project management software package called TrioProject. The package was quite good, but it had a major flaw. It used a Gate process approach, which was good. But it standardised the Gate processes… and to my great surprise, that proved to be a weakness. The standardised life-cycle was the flaw.

It came as a surprise to me, because I've been working on project management standards for decades. It was clear to me that, to improve project management, you need standards. But you have to standardise the right thing. If you over-standardise life-cycles, you are in trouble. I was in trouble.

I'm not the only person to make this mistake. Often, when I talk to PMOs, I discover that they've made the same mistake. I learn that they have a standard life-cycle such as 

• Charter
• Initiate
• Build
• Test
• Deliver and Deploy
• Close

So let's unravel this problem. Where did I go wrong?

A mixture of good and bad ideas

My first good idea was to use a Gate process. The Project is structured as a series of Stages, each separated by a Gate. This is a proven way of working. It splits the project into manageable chunks of work (stages). It allows the project board to control progress (gates).

My second good idea was to standardise the process. In this way, all projects follow the same path. This standardisation enables repetition, which is the basis for continuous improvement.

The flaw - my bad idea - was to over-standardise the process. Every project is different. So a standard life-cycle is overkill. It's a bad idea. The diversity of projects is enormous. In reality, many projects cannot and should not follow a standard process.

When standards become a problem not a solution.

Once you start down the wrong path, standards become a problem not the solution. If every project has to use a standard process then people hit problems:

• The process doesn't fit the project (square peg in a round hole)
• The project manager applies the process blindly, without enough thought

Some companies address these problems by multiplying the number of standards.

• One company used different life-cycles for different sized projects (small, medium, large).
• A building company used 3 standard processes, for construction, renovation and maintenance projects.

But multiple standards only complicate the problem, they don't solve the problem.

Faced with these problems, other companies give up on standard life-cycles.

How to ensure that standards are good news

The answer is not to reject standardisation. Standardisation is the foundation of continuous improvement and better project management.

But standardisation must recognise that each project is different:

• Yes, it's a good idea is to use a Gate process.
• Yes, it's a good idea to standardise the OVERALL process
• BUT it's vital to understand that each project is DIFFERENT

The way to achieve this is to use project design. For each project, the delivery must be designed, not standardised.

Delivery needs to be designed (not standardised)

Each project is different, and each project needs to be designed.

Project design is an early project activity which works out how to deliver the project. The project team works out how many stages are needed, and what those stages are.

That's the big challenge: every project must deliver differently.

During project design, the project team analyses project delivery and structures it appropriately. They understand their unique challenge, and design their unique solution.

So that's the source of the flaw in TrioProject. It was a mistake to over-standardise project delivery. You cannot decide in advance. Delivery should be DESIGNED and NOT STANDARDISED.

A sandwich of standardisation

The resulting standard project management life-cycle is a sandwich

• standardise the early parts of the project
• design delivery (recognising that each project is different)
• standardise the final parts of the project

This still provides the basis for a repeatable life-cycle. It allows for enough standardisation to enable continuous improvement.

Read my recent book to find out more about Project Design; and learn how to design your next project.

Traps to avoid

Before we finish, here is a reminder of the traps to avoid:

• don't standardise the number of delivery stages (for example 3 delivery stages)
• don't standardise the names of delivery stages (for example analysis, build, deployment)

A small project might need only one delivery stage. A larger project might need five delivery stages. A second large project might need five completely different delivery stages.

Build the Project Factory

To sum up, we standardise project management to give a basis of repetition. Standards provide the foundation for continuous improvement and for building a project factory.

But we also recognise that each project is different. We need to reconcile standards and flexibility.

In a forthcoming blog, I'll say more about the Project Factory. Watch this space.

Open the gate to more effective project management

For a team manager, one of the simplest and most effective ways to structure your team’s project management effort is to introduce gate-process methods. They are not rocket science, they are not state-of-the-art, but they work. If are manage a group of projects, and you want long-lasting improvements  in project management, then you should be looking at  gate-process methods. 

Gate process methods break a project into stages and gates:
    •    A stage is a block of work in a project (sometimes called a phase). It’s run by the project manager, and typically will be several weeks long, sometimes several months long.
    •    A gate is a decision point. The board makes a go / no-go decision, based on the work done in the current stage, the plan for the next stage and the overall viability of the project. It’s called a gate for a reason: if no-one opens it,  then it stays shut. That’s important. If the board don’t take a explicit decision to proceed, then the gate stays shut and no more resources should be used on the project. The project must stop.

Many best practice project management methods are gate processes. For example, Prince2 is built around stages, but Prince2 is flexible - it  allows for a variable number of stages. Prince2 doesn’t use the word “gate”, but it has end-of-stage decision points which are gates -  the project board must explicitly approved the next stage plan. Gated methods also are a part of best practice portfolio management guidance. In the same family as Prince2, the MoP guide (Management of Portfolios) highlights the importance of gated methods, saying that “quick wins can demonstrate the value of a portfolio management approach. The first steps commonly include applying staged release of funding so that investment of resources is associated with confidence in successful delivery. Also pay particular attention to a rigorous start gate…” 

Prince2 is a generic gate process method, applicable to any type of project. There are other gate process methods which are specific to various industries and project types.

    ❑    One of the most developed stage gate methods is PetroGate, a method used in the oil and chemical industries. For example, a major chemicals company starts all major investment projects with up to four stages and gates. Gate four is the key decision point - at this gate, the investment budget is approved.

    ❑    In IT, various IT methods for solution development such the v-model have been translated into stage-gate project management methods. For example, the IT project teams in a major bank used a stage-and-gate method to boost the reliability of the handover to operations at the end of the project. The final gates checked that the right work had been done prior the hand over to the support teams and the project closedown.

    ❑    In New Product Development, many companies implement a funnel approach to product development using stages and gates. They generate hundred of ideas and start lots of projects. Weak ideas or unprofitable products  fail to get beyond gate 1 or gate 2. If a hundred projects are started, perhaps only 20 or 30 get into prototyping and development and under 10 get though the final gate which approves the product launch in the marketplace.

    ❑    In the construction industry, gated methods are used. As construction projects can be long, some industry methods can have many stages (ten or more). But if it’s a renovation project, there may be fewer stages, and if it’s a demolition project, there may be only one or two stages.
   
Be careful when you deploy gate-process methods. Avoid the traps
    •    Each project is unique, you should not  force all projects into a rigid structure. 80% of your projects may follow your standard method, but 20% of your projects should definitely not (but could still use a generic gate-process approach such as Prince2)
    •    Understand overlaps. Stages are sequential, but some teams need overlapping “phases”. (Prince2 explains how to handle this, although in the current 2009 version the vocabulary it uses is confusing)

So if you are a team manager looking to boost project management efficiency, check out gate-process methods. One good starting point is Prince2, because it is a general purpose gate-process method, which you can tailor to your company or industry needs.  Take a look … open the gate to more effective project management.