Monday 29 March 2021

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.

programme lifecycle

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
programme lifecycle spiral

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:

programme gated lifecycle

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


Friday 12 March 2021

Learn from Lean: use Collaborative Design for faster and cheaper projects

 When should a project manager plan to use the project budget? Should you keep a lot of budget in reserve for the last part of the project, to fire-fight problems? Intuitively, the answer is YES.

But the answer from Lean is NO. You should invest up-front in Collaborative Design. You will have fewer fires to fight. This article explains why.

Collaborative Design in Lean Manufacturing

Lean Project Management is based on Lean Manufacturing. Lean Manufacturing was pioneered in Japan by Toyota and Honda. Collaborative design was an integral part of the success of Lean Manufacturing.

It’s often hard to transfer concepts from Lean Manufacturing to Lean Project Manufacturing. But in this case it’s easy, because Collaborative Design comes from Lean’s new product introduction: for automobile manufacturers, introducing a new car is a project. Toyota and Honda pioneered Collaborative Design to optimise their project success.

It’s explained in the excellent book The Machine that Changed the World : the Story of Lean Production by James Womack et al.

In the best lean projects, the numbers of people involved are highest at the very outset. All the relevant specialities are present, and the project manager’s job is to force the group to confront all the difficult trade-offs they’ll have to make to agree on the project. As development proceeds, the number of people involved drops…

In many mass production design exercises, the number of people involved is very small at the outset but grows to a peak very close to time of launch… to resolve problems that should have been cleared up in the beginning.

The budget is spent very differently in Lean: it’s spent upfront. Whereas in Mass Production, it’s saved for downstream trouble-shooting.

Let’s draw this as a graph. Let’s compare two projects which have the same budget in man-days (effort). We see that the two graphs of effort against time are very different.

Collaborative design in lean manufacturing

Collaborative Design drives project success. The authors quote some figures:
  • cheaper: a nearly two-to-one reduction in effort
  • faster: a saving of one-third in time

Collaborative Design in Project Management

Let’s bring this back from automobiles to project management.

A lot of projects follow the same curve as Mass Production. Planning is largely a solitary activity, mostly done by the project manager. Resources are added down-stream to firefight problems late in the project.

Collaborative Design brings together the key stakeholders (such as work package owners, subject matter experts and users) ...

Read the rest of the article here

  •  to see other comparative graphs 
  •  understand the three features of Collaborative Design

Thursday 4 March 2021

Use recipes to bake better projects

Are your projects unpredictable? Maybe they are a bit like my mother’s cakes!

Better cakes, better projects

My mother wasn’t a great fan of recipes. She had some cookery books, but didn’t always use them. She often baked a cake without using a recipe. Consequently, our family had some great cakes, but also a lot of middling cakes, and a few disasters. Unpredictable.

Does that sound familiar to project managers? Your projects may be a similar mix - few great projects, a lot of middling projects and some disasters.

If your baking was unpredictable, how would you improve it? You would need to start using recipes. And start taking notes on each recipe: “the oven should be at 200°C not 180°C”; or, “this recipe would be better with two eggs". Those notes help you tweak the recipe to improve the result. So next time you bake, try using two eggs. Or try baking at 200°C

To improve your projects, you need the same approach. But we’ll talk about processes instead of cake recipes. And we’ll need continuous improvement, instead of tweaks.

The objective is to get your projects under control. You need defined project management processes (your recipes), and you need feedback from real-world projects (that’s your notes suggesting tweaks). Then test out the revised processes in the next projects. That’s a cycle of continuous improvement.

click here to continue reading about 

  • Donald J. Wheeler's Four States of Control

  • W. Edwards Deming's SDCA cycle

  • My recipe for baking better projects