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.

No news is good news: Management by Exception

Are you fed up with boring Project Management meetings? Are you in an interminable cycle of weekly meetings? Are you overdosed by tedious Powerpoints?

It could be that you are suffering from “management by meeting”. If the only way that your company can manage a project is to hold weekly meetings with everyone round the table, then they are doing management by meeting.  Another day, another meeting.

There is an alternative. There is a way to reduce the number of boring meetings. It’s called Management by Exception.

Management by Exception is based on constrained delegation. Delegation with limits. When the delegation is in place, then you apply the old saying “no news is good news”. If there’s nothing exceptional going on, then you probably won’t have a meeting.

Here’s how it works:
    •    you propose a plan with some defined constraints
    •    when the plan is agreed, your manager delegates
    •    during the period of the plan, the delegation is in place…
    •    … unless something “exceptional” happens, notably if you exceed any defined constraint

So you only need a meeting if something exceptional happens. You don’t need management by meeting!

Let’s look at an example. Let’s imagine a project to install some packaged software.
    1.    You divide the project into stages. Let’s say that one of them is the software selection stage
    2.    You write a short document with your criteria for software selection; you create a work-plan for the software selection stage, with two constraints
    ⁃    The software is supposed to cost 30k€, plus or minus a tolerance of 10k€
    ⁃    The stage is supposed to take 2 months, plus or minus 2 weeks tolerance
    3.    This plan, including the constraints, is approved by your project board, so you start work. They know what you are doing, and when you plan to do it, so delegation is in place. Limited delegation - you can’t exceed your tolerances!
    4.    You send a regular weekly report to the board, showing your progress.

Let’s now see why it’s called Management by Exception, by looking at two scenarios, the best case scenarios and the worst case scenario.

Best case: For this stage of the project, you are broadly on time and on budget. Nothing exceptional takes place. You find the software and finish this stage of the project. No weekly meetings are required during the stage.

Worst case:  For this stage of the project, things are difficult. Let’s imagine some possible exceptional events
    1.    You can’t find suitable software
    2.    You can’t find anything under 50k€
    3.    You will need 3 months to evaluate and select the software
If any one of these exceptions occurs, then you need to get back ASAP to your board. You are outside of the delegation limits, so you do need a meeting.

So we only have meetings when they are useful. That’s why Management by Exception has big benefits
    •    It saves management time - it limits the time wasted in meetings
    •    It lets the PM manage, and helps avoids micro-management by top managers

Let’s be clear, Management by Exception doesn’t means laxity and absence of control. It is a practical approach, it is is not an idealistic “zero meetings” dream.

Some meetings are needed - for example:  
    •    at the start of the stage to agree the plan
    •    at the end of the stage to review the stage, and to plan the next stage
    •    if anything exceptional happens

It’s a best practice approach. It’s a cornerstone of the Prince2 family of methods. Prince2, the Project Management method uses management by exception. It is also used in MSP (Programme Management), MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices).

So if you are fed up with boring Project Management meetings, then bring in a best practice alternative. Stop wasting time, week after week after week. Move to Management by Exception.

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.

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”.

Aim high to build a high performance team

In today’s fast moving world, most organisations have a large change agenda. Do you have more projects to run than people to run them? Are you forced to use inexperienced staff to run key projects?

One response to this challenge is to look at best-practice frameworks like Prince2 for Project Management, or MSP for Programme Management. But it’s important to set the right goal.

When you start to deploy a best practice framework like Prince2 or MSP for your team or company, you should set the goal high. You want a high performance team, not just a few star performers. If you create team-wide strength in project management, you can really start to deliver your organisation’s change agenda.

Some organisations hesitate to standardise on a framework like Prince2; perhaps they train a few people, but they don’t roll it out to everyone.

They are missing the benefits of a generalised solution. The way to get full benefit from a framework like Prince2 is to generalise its use.

There are three reasons why you should widen the rollout of a framework like Prince2 or MSP:
1) each framework is relatively simple to learn so training is short and relatively cost effective
2) a framework provides a single point of truth to unite the team
3) a framework helps your organisation to improve and innovate.

Let’s look at those points

1) Speed: Learn in a week

All the best practice frameworks  from OGC (Prince2, MSP, MoP, P3O, etc) are reasonably simple to understand. With a week’s training, you can understand the key concepts, pass an exam and get a basic understanding of how to use the framework.

At the team or enterprise level, this means that all your team can learn your method. You can train them all. This is a key to success.

2) Single point of truth

If your organisation uses a framework such as Prince2, you have an external reference.

There are thousands and thousands of books on Project Management. Every author has his or her own ideas. If you don’t have some reference point for your organisation, every Project Manager will have his or her own ideas.

Prince2 has condensed a huge diversity of opinion into one book, which covers a major part of Project Management. That means that an organisation which adopts Prince2 has started to simplify its Project Management problem. With Prince2, you start to introduce a single vocabulary, a single point of view, a single intellectual framework. That’s significant added value, and a second key to success.

3) Improve and innovate

Don’t be worried by Prince2’s apparent complexity. Treat it like a supermarket which stocks 10,000 items, but you only need a week’s groceries. It up to you to choose. You can adapt Prince2 to your needs. This is what Prince2 calls “tailoring”.

If you tailor Prince2 with intelligence, it becomes a springboard to innovation. It becomes easier to implement, easier to use, and easier to adapt to your business needs.

You should start with the standard framework of Prince2, then simplify in order to implement it. If you hit barriers to implementation, then simplify it further. (That’s quite normal - the first simplification is never quite enough!). This simple core is your starting point. It’s your foundation for building team-wide high performance.

As you continue, you can build on this foundation. You have focussed on the essentials of your project management problem. You have  a basis for continuous improvement, for further innovation. And that’s your third key to success.


That’s three keys to success to building in-depth strength, and a high performance team. You need to aim high to increase your project capacity, and to meet the challenge of delivering an ambitious change agenda. Aim high, deliver high performance.

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.