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

Brexit joins the hall of infamy of Programme Management

Brexit: a case study of MSP worst practice

A year ago, I wrote that Brexit was heading for failure. I compared the Brexit programme to a rudderless ship, lost at sea.

Brexit is a huge programme run by the UK government. The UK government is the home of "best practice" methods like Prince2 and MSP. So it's appropriate to judge Brexit using the MSP method for programme management.

A year ago, I said Brexit breaks all the rules for MSP Programme Management. The Brexit Programme uses worst practice, not best practice. It's not driven by a strategy, there's no attempt to create a common vision and there's no blueprint. It was clear a year ago that the Programme was like a rudderless ship. Now, one year later, the ship is heading onto the rocks.

Brexit is entering into new waters

This week, Brexit has moved to a new phase. In MSP terms, it's now in transition. For MSP, the transition should only start when everything is ready. When all the new capabilities are ready, and it's time to go live. MSP says that transition is not driven by a date, it's driven by readiness. It's supposed to be a well-prepared transition from the old (the current state) to the new (the future state). The future state is described in a blueprint.

Ships heading into the unknown

Brexit has entered transition. On the 29th March, the UK leaves the UK. But from this week, in mid February, the transition starts. Any ship leaving a UK port today, heading to a distant port may not arrive until after the 29th March. When the ship arrives at its destination port, it might be facing new rules (the future state). Scotch Whisky going to South Korea might face a 20% tariff if the ship carrying it arrives after 29th March. Who knows?

So the transition has started, and it's unplanned and unprepared. The future state is unknown.

So Brexit has entered its transition, and all the MSP best practice, has been ignored:    
    •    the future state blueprint is not defined (deal? or no-deal?)    
    •    the capabilities are not in place. For example, 11 new laws are still missing (they are very slowly going through the UK parliament). And only 7 trade deals have been secured out of the 69 new trade deals needed.    
    •    there is no transition plan (plan for a deal? plan for no-deal?)    
    •    the go-live date is not determined by readiness, but is an arbitrary date fixed by the UK Government

A special place for Brexit

Brexit has now earned its place in the pantheon of bad practice. It joins other infamous programmes, in the hall of infamy of Programme Management. It joins the Bradley Fighting Vehicle programme, immortalised in the splendid film The Pentagon Wars. And the 2004 Greek Olympics, immortalised by abandoned sports venues and an abandoned airport.

Donald Tusk, the president of the European Council, warned of "a special place in hell" for "those who promoted Brexit without even a sketch of a plan". There is a special place reserved for Brexit in the hall of infamy of Programme Management. Brexit is on the podium, it’s number one. It's a perfect case study of programme failure. Pure hell.

Brexit is failing to apply the basics of MSP programme management

Brexit is failing to apply the basics of MSP programme management

Brexit is heading for failure. This major programme is dominating British political and economic life and will continue to do so the several years. The British government gave us MSP (Managing Successful Programmes) but it is failing to apply MSP basics to the Brexit programme. As a programme, Brexit is failing.

Brexit is a major transformation programme. Some early estimates said there were over 500 government projects working on Brexit. One academic argues that the Brexit programme is more complex than the US moon landing programme in the 1960s.

Brexit is clearly a programme. And it's clearly transformational. It will have a huge impact on British law, trade, immigration, culture and much, much more. MSP is designed for such major transformation programmes. But the British government is not using own toolkit. Their failure to use their own proven method is driving Brexit towards failure.

No clear strategy

The first problem for this programme is the lack of strategy. MSP insists that a programme can and should support one or more high-level strategic objectives.

The problem here is that Brexit is not part of any strategy. The referendum was called for tactical reasons (to silence critics in and around the ruling Conservative Party). The decision to leave Europe was not part of any strategy; and since the referendum, the government has not developed any visible strategy. Is the strategy to stay close to the EU? Or to go for worldwide trade deals? Or deals with the British Commonwealth? No-one knows.

No shared vision

The second problem for this programme is the lack of vision.

MSP recognises that it may be hard to create a shared vision but underlines the importance of building a shared vision. The vision explains the destination of the programme. This provides a cornerstone of a successful programme, on which so much is built.

Again, the government has not developed any shared vision - each minister has their own vision. One vision is to be like Norway, another vision is to be like Canada. Others mention Switzerland or Singapore. There is no attempt to create any shared vision. This has crippled the Brexit programme.

No blueprint

The third problem of this program is the lack of a future state blueprint.

MSP says you should model the future state, which is the situation in place at the end of the programme. This model is called the "blueprint" in MSP. The difference between the current state and the future state is called the "gap". You fill the gap with project work.

Until recently, we all believed that the government had 50 impact assessments, sector by sector. We are told these existed in "excruciating detail". This seemed to be a sort of gap analysis. This suggested there was indeed a final blueprint. But the 50 impact assessments have proved to be a fiction. They don't exist. There is no blueprint, there is no gap analysis.

The most glaring omission concerns Northern Ireland where Brexit generates multiple constraints. A blueprint for Northern Ireland which resolves those constraints is possible, but is not part of Government thinking. MSP provides the tools, but the government doesn't use them. Without a blueprint, the contradictions rest unresolved.

Until you have a future state blueprint, you don't know the gap, and you don't know what projects to run. Because there's no Brexit blueprint, those 500 projects don't know what they have to achieve. A project with unclear goals cannot succeed.

Heading for failure

The Brexit programme is like a rudderless ship. The strategy is unclear, there is no vision, the programme is lost at sea. Work has started on 500 projects, but to do what?

In most organisations, such drift would not be tolerated. The programme would be cancelled. Brexit needs to be rescued or cancelled. Sadly for Britain, neither option seems likely today.

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.

P3M3: behind the acronym is an important tool

Project Management is full of acronyms. PID, WBS, ROI… there are hundreds. Some of them help us, some of them confuse us.

P3M3 is a troublesome acronym that’s been around for a few years. Some people like it, some hate it, some don’t understand it. P3M3 is certainly not a good acronym, but don’t be put off. Take the time to understand it, and you will discover a useful tool-set that can help any organisation to measure its progress in Project Management and related areas.

Firstly, let’s decode the troublesome acronym. It’s a confusing acronym, because the acronym is not the sum of P3 + M3, as you might expect. No, P3M3 is the fusion of two other concepts, MM + P3M (but neither concept actually exists as a stand-alone acronym)

    1.    MM is about Maturity Models
    2.    P3M is  Project Management, Programme Management and Portfolio Management

So P3M3 is about measuring your team’s maturity to manage projects, programmes and portfolios. 

P3M3 comes from the UK, and belongs to same family as Prince2, MSP, MoP and P3O. If you are using one or more of these methods, then it will directly help your team to measure your progress; if you are not, then don’t worry, they are designed to be general purpose models, and you can still use these tools.

Let’s deal with the two parts separately

1) MM = Maturity models.

P3M3 is based on models, which help us to measure maturity. Each model tries to express one aspect of maturity. 

A maturity model attempts to measure your team’s maturity, on a scale from 1 to 5, based on defined best practice. It’s not just an arbitrary measurement, it’s a well designed model based on a set of criteria founded in proven best practice.

For example, P3M3 contains a maturity model for project management (called PjM3). This is based on a 360° set of measurements of project management maturity, using 7 dimensions such as financial management, risk management and resource management. This can be used by any team, whether it is using Prince2 or not. For the Prince2 community, there is dedicated model to measure the team’s ability to run better projects using Prince2. (This version is called P2MM).

2) P3M = the management of change initiatives (projects, programmes and portfolios)

P3 is a useful little acronym. It stands for Projects, Programmes and Portfolios. These are increasingly called “Change Initiatives”. They are three different ways of managing change.

Project Management has been around for years, and many organisations have reasonable maturity in project management. Programme Management is more recent, and Portfolio Management is the new arrival. All three are tools for change, to help the organisation to manage change efficiently and effectively.

So P3M is about management of change, and P3M3 is about measuring your organisation maturity to manage change.

Some organisations manage change well. They implement a strategy which changes the organisation. They innovate, adapt and survive. Their change management is effective.  When they invest in a project (or a programme or a portfolio), they can expect a good return on that investment.

So that is why P3M3 is so important. It measures your organisation’s ability to change. To innovate. To adapt. To survive.

Concretely, P3M3 drives improvement. It helps you to assess your maturity, objectively and with a structured 360° view. When you know your strengths and weaknesses, you can improve. If you know that, for example, your project financial management is fairly strong (say, level 3), but your project risk management is weak (level 1), you can launch some targeted improvements in risk management.

That’s a fast track to improvement. A fast track to better management of your projects, programmes and portfolios. Which means more efficient and more effective change management for your organisation.

That’s why P3M3 is so useful.

Size matters: when should big projects become programmes

Some project managers still like to use the old “rule of thumb” that a project shouldn’t last more than 9 months. This is project management folklore. If a project is longer than 9 months, says the old folklore, then it is likely to fail. So best split it into pieces.

As with much folklore, this “rule of thumb” contains some wisdom, but it’s not rigorous and proven. Methods like Prince2 help to show that project length is only one factor likely to cause project failure. A 9 month project can fail for many, many reasons (as can a 3 or 6 month project);  whereas a  2 year project which is correctly managed can succeed (and many do)

More importantly, the old rule ignores the emergence over the last 20 years of programme management. Programmes are used for handing major initiatives and business changes, and typically take years rather than months.

Does the old rule of thumb maybe need to be rewritten? Should it say “if your project will take more than 9 months, then run it as a programme”?

Let’s consider some of the main differences between a project and a programme
    ❑    A project focuses on deliverables, and is generally shorter and more structured
    ⁃    When the deliverables are in place, the project is finished.

    ❑    A programme is a longer initiative, which often more flexible
    ⁃    delivers one or more strategic objectives
    ⁃    focusses on delivering change - when the benefits from the change are in place, the programme is finished

This tells us that the differences are not due to the length of the project or programme. More important is what it delivers: the vital difference between programmes and projects relate to the nature of the change, not to the duration of the change initiative


One simple way to understand whether to use project management or programme management is consider the nature of the change
    ❑    Project management is good if you are changing things (or making new things)
    ⁃    software and web sites
    ⁃    new or improved products
    ⁃    new IT infrastructure
    ⁃    buildings, roads

    ❑    Programme management is better if you are changing people (or their way of working)
    ⁃    restructuring, reorganisation
    ⁃    new processes
    ⁃    better ways of working
    ⁃    globalisation
    ⁃    expanding, downsizing, outsourcing, off-shoring


So that old “Rule of thumb” is a nice proverb. Like all proverbs, it seems right at times, but often it’s wrong and misleading. Better in today’s world to use another rule of thumb: “If your project will take more than 9 months, attend a course on programme management”.

How MSP helped a tiny organisation... to survive

There is a growing understanding that Programme management is vital for big organisations. Methods like MSP are increasingly used by big organisations for major transformational programmes like
    •    company mergers
    •    business reengineering (e.g. ERP or CRM rollout)
    •    launch of new products, services or markets
    •    public sector reorganisation
    •    major sporting events which help regenerate run down urban areas

But it’s less well understood how a method like MSP can help small organisations or small teams.

Small organisations can face for the same need for transformational change as big organisations.

So let’s look at how very small voluntary sector organisation has benefited from MSP over the last few years. The organisation is indeed small, with only 5 staff. But from 2005, it identified some big problems… which could have threatened its very existence.

It’s a publicly funded organisation, and the management team saw that it was not delivering value for money to the funding bodies. It was time for change, time for transformational change, time to apply some MSP best practice. Otherwise, in today’s difficult times, the funding would have been cut, and the very future of the organisation put at peril.

Here’s three of the ways that MSP helped this tiny organisation to re-invent itself... and survive!

1) Develop a vision to drive the change: since end 2008 a vision statement has been in place. The organisation must change over the coming years. It must reinvent itself.

The vision statement explains where things are heading and helps to guide the change. At various annual meetings (AGM, board of control), the vision has been explained and agreed. This is the MSP way - build consensus for change, starting with a vision.

2) Analyse the stakeholders: from 2005, the organisation started to look at the funding bodies as stakeholders, not just as sources of income. MSP helps you to get a 360° vision, to view your situation from the point of view of the stakeholder. With MSP you seek to understand their interests, and to work out how to engage with each stakeholder.

3) Build a project dossier, run the next tranche: In 2010, by looking the stakeholder interests of the major funding body, the organisation identified several options to provide stakeholders with better value for money. One was an outreach project, providing services in a wider geographical area. Another project was educational, targeting 11-15 year-old school kids.

In MSP terms, this was a part of the project dossier, to be rolled out in the next tranche of the programme. Once the tranche plan was agreed, the projects were launched. Soon the outreach solution went live, and by 2011, the benefits were clear and measurable. The outreach was working in 12 towns. Equally, the educational project as fine - the schools were happy.

This tranche delivered clear benefits to a key stakeholder. The story continues today - additional opportunities, follow-up projects in more schools, new projects in the 12 towns… the new tranche is under way.

So we have seen three of the ways that MSP has helped a tiny organisation to reinvent itself. MSP can help your small business or your small team. It’s not just for the big guys!

MSP: the 'Do Nothing' vision

What is a ‘do-nothing vision’ in MSP?

Managing Successful Programmes suggests that a programme team should elaborate a vision of the future. This is an agreed and communicated vision of the desired future. As a contrast to this desirable future vision, it can be useful to analyse the "do nothing" option.

Your change programme may encounter resistance. Both the future vision and the "do nothing" vision are useful to overcome resistance and to help motivate people to support the proposed changes.

In Nokia, the new boss, Stephen Elop came in from Microsoft with a new strategy. He wanted Nokia to work with Microsoft, and to put Windows on their smartphones. That meant abandoning Symbian and Meego, two existing Nokia operating systems.

He used the "burning deck" scenario to drive the change. This scenario said that "do nothing" was impossible. We - the Nokia team - are on a burning deck, and if we do nothing we will burn. We have a choice to jump off the deck, into the cold black sea below. This is a risk, but a risk that we must take. Doing nothing is certain death, whereas we might survive in the sea...

For Nokia, the do-nothing option was clear... uncompetitive products, declining market share, increasing irrelevance in the global marketplace. So Nokia took the risk, and jumped off the burning desk. They closed their Symbian and Meego teams and went for the Windows option.

Sometimes, doing nothing might appear to be a good choice.

Hewlett Packard have just voted for the "do nothing" choice. They were thinking of selling their PC business. They decided against it. They compared the option of floating off the PC unit with the option of doing nothing, and choose to do nothing.

Some say that, in the long running Euro-crisis, Angela Merkel is failing to provide leadership, and very often favours the "do nothing" option (or at least, do too little, too late)...

London 2012 Olympic Games

Lessons for MSP Programme Managers

For several years, the 2012 games have been criticised because their costs were constantly rising. Now, a different type of criticism is appearing, saying that some of the promised benefits will be hard to deliver.

This article reviews the London Olympics using the perspective of MSP (Managing Successful Programmes). As a major UK government initiative, this is reasonable - the Olympic Games programme should use MSP, which is the approved UK government Programme Management method

London 2012 Olympic Games - Tranches and Blueprints

If we analyse the 2012 Olympics as an MSP programme, then – here I simplify things – there are two main tranches. Tranche 1 is to prepare the games and run the event; Tranche 2 is to deliver the legacy. In this case, the programme will have two main Blueprints – an Intermediate Blueprint for the summer games in 2012, and a Final Blueprint that specifies the long-term outcome, where the stadium, the aquatic centre, etc. are handed over to the local community.

London 2012 Olympic Games – Initial Business Case

The London bid for the Olympics, as presented in Singapore in 2004, was full of promise. The list of benefits included

• 20,000 local construction jobs
• Boost to Tourism during the Games
• Legacy sporting venues (Stadium, Aquatic centre)
• A boost to Sport in UK
• Rejuvenation of East London
• New transport infrastructure

This gave a positive business case. For £2.3 billion of costs, the benefits would be high. An easy-to-justify Business Case.

London 2012 Olympic Games – Updated Business Case

Now, seven years later, the picture has changed. The preparation for the 2012 London Olympic Games is advancing. The major building works are done, and preparations for the summer games are well advanced.

The costs have risen, and keep rising. Some benefits are fragile or negative.

The cost estimates have grown and grown. The budget has grown from £2.3 billion to £9.3 billion. This cost growth has been widely documented, so I won’t discuss it here. The most recent cost expansion, identified this week, concerns security staff. The original plan (on the Intermediate Blueprint, i.e. for the 2012 Games period) included a major element for event security, with 10,000 security staff. This has been found to be insufficient, and 20,000 security staff will be needed, at considerable additional cost.

London 2012 Olympic Games – A benefits review

The benefits forecast has come under more recent scrutiny. Two major sporting venues will be created for the Games, the Aquatic centre and the Olympic stadium. Both have serious problems with their benefit realisation, but the problems with benefits are wider:

• 20,000 local jobs – The massive building programme created tens of thousands of construction industry jobs. On a recent BBC radio programme “File on Four”, local politicians explained that only a few hundred local residents got jobs. The benefit has not been delivered. In MSP terms, this benefit is badly profiled. A benefit profile must pass the DOAM test (Describable, Observable, Attributable, Measurable). The authorities can track the jobs and the workers, but there is no way to trace whether the workers are local people. Many building workers came from outside London, but now have London addresses while they are working on there. They are not local people, they are temporary residents. So this benefit profile fails the DOAM test – not observable and/or not measurable – and is therefore hard to claim as a benefit for the programme. This benefit should therefore be removed from the Benefit Map and the Business Case.
• Boost to Tourism - Many politicians are still talking of increased tourism due to the Games. This is a just a dream. The politicians need to learn from the past. As a recent article in “The Economist” explains “Since the 1992 Barcelona games, hosts have seen a fall in foreign guests during each Olympics, as well as in the months before and after”. This supposed benefit is therefore actually a dis-benefit, because there will be fewer tourists in 2012 than in a normal year. Indeed some West End theatre owners fear they will have to close their shows next summer due to lack of customers. This dis-benefit makes the already bad programme Business Case even worse.
• Legacy – the Aquatic Centre. The Final Blueprint for the programme specifies that the aquatic centre will be a community leisure pool, with slides and toboggans. Have fun, bring the kids! However the intermediate blueprint for the aquatic centre is not aligned to this need. The aquatic centre has now been built – it’s a large, iconic architectural masterpiece, probably good for the summer Olympics. But it has low roof, which cannot be converted to give room for the future slides and toboggans, which will attract families with kids. Additionally, the large prestigious building will be expensive to run and maintain (perhaps £2m per year). So the benefit delivery from the aquatic centre may be bad, with high costs and low income. The cashable value of the benefit will go down, and the programme Business Case gets worse.
• Legacy – the Stadium. The second legacy venue is the stadium. The initial benefit realisation plan for the Olympics proposed the sale of the stadium, but this has hit major problems. The expected sale to either Tottenham or West Ham football clubs hit legal issues, and the stadium will now be rented, not sold, which directly hits the benefits stream and the programme Business Case. No rental contract has been signed, so a large cash benefit has been replaced by a possible long-term rental income. Worse, the new rental tenant may ask for building work as a condition for rental, which would add to programme costs.
• Regeneration of East London – the Village – The Olympic village will be built for the Games, and then converted into housing, at a cost of £1.1billion. This seems to have been sold to developers for £825million. While some politicians dispute the figures, it seems to that the regeneration (an intangible benefit) must be balanced by a significant cost or dis-benefit (the £275 million loss on the sale of the Village).
• Regeneration of East London – the Media Centre. A huge building has been built for the media, to support 20,000 journalists and TV crews during the games, at a cost of a third of a billion pounds. However, there is no decision, and no clear plan about the legacy use of the Media Centre. The Final Blueprint is unclear, after 7 years!

London 2012 Olympic Games – Not a viable programme?

For any normal Programme, the Business Case is regularly reviewed. A golden rule of MSP is that if the Business Case is bad, the programme should be halted. The Business Case of the 2012 Games looks very bad, with high costs and low benefits. Additionally, the Business Case has been artificially lightened by hiding many costs, such as infrastructure improvements (£6.5 billion) and counterterrorism (£1 billion)

However, this programme is a political programme, with the UK prestige at stake. In reality, the programme will not be halted. This once-justifiable programme seems to have become an expensive folly.

London 2012 Olympic Games – Lessons for MSP Programme Managers

The lesson for Rio 2016 and for future Olympic Games? In the recent BBC radio programme “File on Four”, the final comment from a London politician gives us a key lesson about Stakeholder Engagement – “Make sure that the people who are responsible for your legacy are there at the start; don’t plan an Olympic Games where everybody is in there just for the purposes of delivering an Olympic Games”. A good lesson for Rio and a good lesson for all Programme Managers.

© Copyright Triotime 2011

Four profiles of programme management actors

Win-win with MSP in Madrid

I’ve spent the week in Madrid training people from a telecoms company on Programme Management.

The company has four types of people it needs to train.

The training is based on MSP, the Programme Management framework from OGC. In broad terms, MSP targets transformational programmes. These deliver change. They change the way an organisation works, or deliver change in a social or public service environment.

The first profile at the training was the programme manager, running internal transformation programmes. That’s the “typical” MSP programme, an internal transformation programme which drives business change inside an organisation.

The second profile is an upcoming role, namely people from the Programme Office. The company has a permanent programme office, to support the internal transformation work. I trained the Programme Office manager and a team member. They will help roll out and sustain MSP for the internal transformation programmes, for example by providing templates and guidance. And also more actively, they should play the Programme Office role within the programmes, to facilitate monitoring and control, and to act as the Programme information hub.

The third profile and fourth profiles take MSP into the client – supplier world. The company provides complex business solutions to its customers. While these are broadly technical – for example, providing a major upgrade to the client’s telephone system – there are benefits from using MSP to widen the focus from “simple” technical deliverable to the wider added-value outcome.

So the third profile is the Programme Manager of the client-facing programme. S/he benefits from MSP training by managing programmes differently. This will come from understanding the difference between technical outputs (e.g. the new proxy server) and the client’s business benefits (e.g. improved telecoms, enhanced videoconferencing, lower telecoms costs). With MSP, you recognise the overall value proposition in the programme, not just the technical deliverables.

The fourth profile is perhaps the most interesting, as it’s the client support role. Today this role takes over where the projects finish, to make sure that the client can use what the projects have delivered. Using an MSP approach, this role becomes the BCM (business change manager) and works actively with the project teams to ensure they think beyond technical deliverables. As BCM, s/he will prepare for business change and then drive it through; and work proactively with the client to ensure benefit realisation.

These latter two roles focus on the overall value chain. That includes client benefits, not just supplier profitability. That’s a change of mindset. And it’s not at the expense of the supplier business case – using an MSP approach, the Programme manager will get visibility of all the supplier work within the wider programme, and can also see the customer value proposition. This is a “win-win” approach, to replace the current “lose-lose” solution where the supplier projects seem profitable, but the profits disappear in costly post-project support to resolve customer issues (and a dissatisfied customer is often a lost customer).

To sum up: looking at the overall value proposition of the programme generates both supplier profits and customer satisfaction. Win-win with MSP.

Focus on transformation not PMOs

How a focus on business transformation programme gave the right PMO solution

I recently spent a couple of days with a fast growing hi-tech company in snowy Stockholm.
I was invited to help them with their PMO deployment, but it soon became clear that their urgent needs were based on an upcoming business change. They needed to shift focus.

They were looking at their PMO needs because their business is growing FAST and they are running more and more projects, so they had identified the need for a PMO solution. However, the company founder has recently announced a new organisation structure. The business is expanding worldwide, and the company needs regional operations. It can’t operate only out of Stockholm any more.

We started out as planned, working on the PMO agenda. I took the team through the basic P3O guidance. P3O is the OGC guidance about Projects, Programmes and Portfolios (that’s the P3); and specifically, on the “Office” structure needed to support the P3. Just to be clear, “P3” plus “O” gives P3O. The offices are commonly called PMOs, but the guidance is called P3O.

During day one, the picture became clear. The new organisation chart announced by the boss was going to transform their portfolio structure. So indeed P3O could help. However, faced with business transformation, P3O is not enough.

The P3O guidance does explain that a transformation programme based on MSP is a good way to roll out your new PMO solution. However, in the context of imminent business change, what’s the way forward?

According to the P3O best practice, the best way to add a PMO solution to your existing business is by running a transformation programme. So it became clear to me that the way forward was to wrap the two initiatives together, both the business reorganisation AND the PMO solution, all in one transformation programme. The programme should address the immediate business reorganisation first; and postpone some of the less urgent PMO work to later.

So here is what we did in the remaining time. We covered a lot of ground!

Step 1: Make sure everyone understands the basics of Portfolio Management as the business reorganisation will create new portfolios. For this, I used the new Management of Portfolios guidance from OGC, which is called MoP

Step 2: Focus on the business transformation programme. As a meeting room exercise, we drafted some of the key documents of the early MSP processes, notably
- Vision statement
- Blueprint after business transformation, including some basic PMO elements

Step 3: Focus on the final goal, including additional PMO elements. We drafted more MSP documents
- Final blueprint
- Project dossier
- Risks

This leads to a two-tranche programme which should deliver short and medium term solutions. Tranche 1 is business reorganisation, supported by the basic PMO structure; tranche 2 adds a full-strength PMO solution.

This has to be two tranches. The major change of reorganisation will be a big effort for this company. The second tranche will consolidate the work of the first tranche; and drive out more benefits.

So the lesson is this. Don’t focus on PMOs when you need wider business change. The business change is the priority, and your PMO structure should come out of that change programme.