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

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

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

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

Collaborative Design in Lean Manufacturing

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

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

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

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

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

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

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

Collaborative Design drives project success. The authors quote some figures:

• cheaper: a nearly two-to-one reduction in effort
• faster: a saving of one-third in time

Collaborative Design in Project Management

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

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

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

Read the rest of the article here

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

Use recipes to bake better projects

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

Better cakes, better projects

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

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

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

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

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

click here to continue reading about 

• Donald J. Wheeler's Four States of Control

• W. Edwards Deming's SDCA cycle

• My recipe for baking better projects

When standard Project Management life-cycles are surprising

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

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

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

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

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

A mixture of good and bad ideas

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

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

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

When standards become a problem not a solution.

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

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

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

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

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

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

How to ensure that standards are good news

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

But standardisation must recognise that each project is different:

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

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

Delivery needs to be designed (not standardised)

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

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

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

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

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

A sandwich of standardisation

The resulting standard project management life-cycle is a sandwich

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

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

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

Traps to avoid

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

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

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

Build the Project Factory

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

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

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

Why Lean PMOs use CoPs not policemen

How do you improve project management in an organisation? The "classical" solution was to create a PMO (a project management office). The PMO published standards, then told everyone to use their new standards.

That approach often failed for two reasons. Firstly, the standards were heavy and impractical, written by PMO "experts". And secondly, the PMO became the enforcer of standards. They became the Project Police.

There is a Lean alternative. The way forward is to use CoPs, not policemen.

A CoP is a community of practice

A CoP is a community of practice. It brings together practitioners to share knowledge, problems and ideas. Many organisations in various areas (government, education, web content, ...) have started to use communities of practice. They recognise that more and more people are knowledge workers; and that sharing knowledge adds value.

Knowledge is not centralised. It is spread around the organisation. Many people have knowledge, not just the "experts". The community of practice brings together practitioners to harvest knowledge. The CoP is linked to a domain (such as Project Management). For example, at Stanford University, there are about 50 CoPs, each working on one domain.

Feedback from practitioners is new knowledge

The old top-down model for project management assumed that the PMO were the "experts". The experts had a monopoly of knowledge, so they published the standards. In practice, the standards weren't always great - they were too complex, and heavy to use in practice.

An organisation that values its knowledge workers uses a different approach. It uses a collaborative model, rather than a top-down model.

The CoP is the heart of this collaborative model. It creates a feedback loop on project management standards. The practitioners who work in real-world projects provide feedback (what works? what needs improvement?) Their feedback creates new knowledge. And when that knowledge is used to improve the standards, it adds value. The CoP becomes part of a value chain.

Iterate to improve

The modern organisation wants to be more agile. People now recognise that project management is a complex problem. Faced with such complexity, the agile approach is to discover the solution over a period of time, iteratively. There is no perfect solution that an expert can specify at their desk.

Finding a solution requires feedback: the early solution is tested in use, and then refined. The solution emerges iteratively, over a period of time.

The community of practice is the perfect tool for getting feedback. The CoP provides the feedback from project managers who are trying to use the standards.

In this context, the Lean PMO has a new role to play. They are no longer the "experts". The PMO may propose some standards (draft versions or prototypes). But their key role is to stimulate iterative improvement, driven by the community. This results in practical, workable standards that project teams will use.

Create a community of practice (CoP) to drive improvements

The CoP must be focussed. It's not a talking shop, to swap stories or moan about problems. The CoP engages project managers in the creation and evolution of standards. This ensures that the standards are practical and applicable to real-world projects.

The focus is on continuous improvement:

• what works?
• what is broken?
• how can we improve things?

Here are some examples

• A template that is too complex and hard to use
• A reporting requirement that generates hours of work each week
• A procedure that no longer works
• A great new tool for tracking issues

To maintain focus, the PMO commits to listening to the CoP, and taking on board their ideas. It's the feedback from the community of practice that drives the new versions of the standards and adds value.

How does the Lean PMO set up a community of practice?

• Define your starting point. Pull together your current good practice into one place. Collate everything into a document or a website (your procedures, processes, tools, templates, etc.). This is your draft standard, version 0.1.
• Find some good people. Find project management practitioners who want to get things done better.
• Get your CoP moving. Set up a simple, light process for discussing and sharing. Add a simple tool (e.g. Slack or a micro-website).
• Keep the CoP focussed. The focus is continual improvement. Keep things light and lean. Avoid long meetings - project managers are busy people.
• Add value. Use the feedback from the CoP to improve your standards. Publish new versions of standards (templates version 2.0, procedures version 1.1, and so on).
• Communicate. Tell everyone how that the CoP is driving improvement, and how the process is adding value.
• Iterate. Keep going. Improvement is an ongoing, long-term process.

Other benefits of CoPs in the Project Management domain

The community of practice is especially useful in the project management domain

• Many projects span organisational and geographic boundaries. In the same way, the CoP goes beyond the silo organisation. It is a community of project managers, regardless of organisational and geographic boundaries.
• Many project managers start their careers as subject matter experts. As the years go by, they become project management experts. The CoP helps this transition. It boosts the visibility of the project management domain. Thereby, it helps professionalise project management.

Read more about CoPs here

CoPs not police

The bottom line is that if you are a PMO struggling to impose your standards, then stop trying to be a policeman. Think CoPs not police.

This blog is part of a series about the Lean PMO, which will form the basis of a new Lean3 book. Find out more at LeanPub

Lessons from the Bushfires: understand stakeholders to communicate better

Lessons from the Bushfires

Communication is a critical success factor in project and programme management. To communicate successfully, you must analyse your stakeholders correctly.

Australia has suffered horrendous fires in the past few months. The authorities evacuated tens of thousands of people from their houses.

That required a lot of organisation and a lot of communication.

The public authorities struggled to communicate effectively. How to give the right advice to people? How to get them to listen? How to ensure householders react correctly?

For the authorities, there were two types of householders - those who will evacuate; and those who won't.

But that was too simple.

Analyse your Stakeholders

An Australian researcher, Dr Ken Stahan, has come up with 7 types of householder

• Threat Denier: they deny that a threat exists
• Responsibility Denier: they do not believe that they are responsible for themselves
• Dependent Evacuator: they are unable to take responsibility for their safe evacuation
• Considered Evacuator: they are determined to safely evacuate
• Community Guided: they look to advice and guidance from their community
• Worried Waverers: they want to remain. They worry that they lack the experience to remain successfully
• Experienced Independents: they are experienced with bushfires and are self-reliant and well prepared. They are committed to remaining but in unfavourable circumstances may evacuate.

(You can listen to Ken Stahan talking about his 7 types on Australian RN radio here)

Once you know there are seven types of stakeholder, you can communicate so much better. For each category, there can be a tailored communication - the channel, the timings, the content.

The next step in Australia is to get this working. Ken Stahan's idea is to use questionnaires, to better understand householders. To categorise stakeholders correctly.

That's the key: understand your stakeholders before you communicate.

Toyota is not just a car maker. Are you just a project manager?

Toyota is the home of Lean Manufacturing. In the 50's, Toyota developed the Toyota Production System, which became Lean Manufacturing. All world-class manufacturing today uses Lean.

There's a classic article by Charles Fishman in Fast Company, published in 2006. It analyses continuous improvement at Toyota’s factory in Georgetown, USA.

Lean means Continuous Improvement

The author argues that Toyota is not just a car maker.

Here's the key quote

Toyota’s Georgetown factory only looks like a car factory. It’s really a big brain–a kind of laboratory focused on a single mission: not how to make cars, but how to make cars better.
The work is threefold: making cars, making cars better, and teaching everyone how to make cars better.
At its best, Toyota adds one more level: It is always looking to improve the process by which it improves all the other processes.

Project Management needs Continuous Improvement, too

Are you just a project manager?
Or are you a Lean Project Manager with a focus on Continuous Improvement
To qualify as a Lean Project Manager, your work would be threefold

1. Running projects
2. Improving your project management process
3. Teaching everyone how to improve your project management process

And are you at your best - do you add one more level? Are you always looking to improve the process by which you improve your project management process?

From Lean Manufacturing to Lean3 Project Management

Toyota makes it appear easy, by building continuous improvement into their culture. Read the Fast Company article to find out how they do it.
You can do the same for your projects. You can build continuous improvement into your Project Management. Read my new book Lean3 Project Management to find out how you can do it.

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.

PM2 : Government isn't a community

PM2: Government isn't a community

In January, the European Commission published PM2. This is yet another Project Management framework created by yet another government body. This is the wrong initiative, done in the wrong way.

The world doesn't need another top-down government-inspired initiative. More so-called "best practice". We already have the PMI from the US, Prince2 from the UK, and several others. PM2 adds nothing new, it just reassembles the existing pieces in a different way.

A new set of rules

Government-driven methods attempt to codify "best practice" in a book. This "bible" is a static set of rules which is defined to be "best practice". It becomes the basis for compliance and creates an ever-growing training and certification industry. Henceforth, every CV must include certification. Everyone who wants funding must follow the rules.

PM2 follows this pattern. It is driven by a set of rules, not a community of practice. Maybe it's called Open PM2, but there are no clear feedback mechanisms to ensure that "best practice" does actually work. There is a network around PM2 (PSN), but the focus is implementing the method, and especially on training and certification. This will surely become a community of compliance rather than a community of practice.

Need a new approach

Agile has shown the way. There is a real, innovative community around Scrum, sharing good practice. Good practice evolves, bottom-up, driven by community feedback. SAFE explicitly promotes communities of practice (SAFE is a scaled approach to Scrum).

Beyond Agile, the wider Project Management world also needs to move to communities of practice. We don't need yet another top-down method like PM2. We need a bottom-up approach, based on  communities of practice. Each community will identify good practice, proven in day-by-day use. Ideas will be shared using modern social networking techniques.

This is the forward-looking approach proposed by Lean3. Sadly, PM2 is not forward-looking, it's just a rehash of old ideas, just another set of rules.

Why I stopped blogging (and why I'm starting again)

I stopped writing this blog in May 2015 

I stopped because it was time to be less evangelical about Prince2. It was time to start facing up to the truth.

My blogs were "explaining" Best Practice, as defined by Prince2. They were broadly uncritical. I assumed that Prince2 was "Best Practice", and explained how to get it to work.

For example, I explained how to analyse risk. I knew that,  until you simplify the Prince2 risk approach, it's not usable. I knew that no-one uses the Prince2 "Best Practice".

Same with communications. I wrote a blog on communications. Prince2 has an unusable "Communications Strategy". No-one uses the four strategies in Prince2. Again, I was blogging to explain how to convert  so-called "Best Practice" into real workable practice.

This incessant need for simplification told me that Prince2 is not "Best Practice"...  It was time to wake up.

In 2015, I faced up to the facts: the term "Best Practice" is now meaningless. So I stopped writing this blog.

Since then, things have got worse

Prince2-Agile was a car crash

In June 2015, Axelos launched Prince2-Agile, a new companion guide to Prince2. This guide purports to explain how to combine Prince2 with Agile.

But it was a car crash. All of Prince2 meets all of Agile in a mammoth mash-up. The premise of the book is to use Prince2 in its entirety (all 7 processes and all 7 themes), then to add Agile. The resulting behemoth (P2 + P2A = 700 pages and 2kg of paper) is hard to explain, let alone to defend.

 Even the most evangelical supporters of Prince2 struggle with this. This is not "Best Practice". No one introduces Agile into projects like this. I know how people blend Prince2 and Agile, and it's not like this.

Prince2 needed a diet, got a sugar rush

In 2017, Axelos updated Prince2. Prince2 was aging. It was fat and bloated, full of junk that no-one uses. Put instead of sending Prince2 to a health farm, to lose weight, Axelos added more fat. More bloat.  Prince2 grew to over 400 pages.
The new book now wants the Project Manager to become a methods expert, and to tailor Prince2 for each project. That's not Best Practice. In most well-organised companies using Prince2, the corporate PMO downsizes Prince2 massively. Once.

I'm starting blogging again

I'm starting to blog again. I'm starting to blog about Lean3, a new approach to Project Management.
I've not given up on Prince2. It's a tool we can still use, but it's fossilised and we need to plan for the future. Prince2 is our past.

Lean3 rejects the idea of frozen "Best Practice", written by a guru and published in an expensive book. Lean3 will have strong feedback from the community, using social media techniques.

Lean3 argues that each community of practice should define its own good practice. Good practice which is used and proven in practice.

Read more about Lean3 at www.lean3.com

Ignore the fashionistas: you still need Prince2 in an Agile world

Fashions come and fashions go. For fashionistas, yesterday’s fashions are history. 

In the world of project management, Agile is the current fashion, particularly the Scrum variant of Agile. If you browse many project management websites, you'd think Scrum has become the only way to run projects.  Some Agile fashionistas even suggest that everybody is moving to Scrum, and that “traditional” methods like Prince2 are history.

What should project managers do? Should you follow the current fashions? Or is there still life in older methods like Prince2?

A success story…

There’s a good reason why Scrum is fashionable - for many teams, it's a success story. But if we pause to understand the roots of that success, then we will find that not everyone can go with the crowd and follow the latest fashion.
The popularity of methods like Scrum is driven by two waves of innovation

❑  the rapid, unrelenting growth of the Internet
❑  the increasing incorporation of software in products

For project teams working in one of these areas, Scrum can boost project success rates.

Using Scrum, a dedicated, motivated, self-organising team can work in “discovery” mode,. They don’t start with a detailed specification (or with any specification at all, in some cases). The team works iteratively, in discovery mode, converging to a solution. Using sprints, they manage their time constraints - each sprint delivers on time.  For many software development teams, Scrum is a good choice.

… with limitations

However, success using Scrum is based on two key assumptions

❑ the project can use discovery methods, starting with little or no specifications
❑ a dedicated, self-organising team can be put into place

In many companies and in many projects, these assumptions are simply not valid.

If you look at the context of your project, you may find that it is very different from the world that the Scrum fashionistas inhabit

SPECIFICATION DRIVEN: Your project may need to start with specifications, for one or more  reasons, for example:
- a detailed design is highly desirable (e.g. for a construction project or an IT infrastructure project)
- a specification of the final solution is needed in order to get budget approval
- a specification must be created as the basis for a contract with one of the project’s suppliers

SILO BASED ORGANISATION: Your project may not have a dedicated team, for example:
- some team members perform both project work and day-to-day support work
- some team members work on multiple projects
- your silo culture is stronger than your project culture (so each team member reports to their line manager not to your project)

As a project manager, you need to understand your project constraints. Your project method must align to your constraints. If you use Scrum in the wrong context, you will have a square peg in a round hole, and your project will suffer.

So how to run your project in these cases? The traditional methods such as Prince2 are still there to help you. They are not history, Prince2 remains valid

    ❑    Prince2 is a general purpose method (not just for software projects or internet projects)
    ❑    Prince2 can create well-structured specifications using product based planning and product descriptions
    ❑    Prince2 uses a team based approach, able to cope with the traditional silo organisation and with non-dedicated teams.
   
Additionally, Prince2 is a full-strength project management method, covering essentials such as budgets, business case, risk management; most of which is absent from Scrum, which is a delivery team approach rather than a project framework.

It’s not always a binary choice for every project. It’s not simply Prince2 or Scrum. If necessary, you can blend the two. Inside a Prince2 project, you can have teams using Scrum; or you could run one project stage as a timebox. For example, inside a product development project using Prince2, you may have a dedicated team working on the software, using Scrum to ensure on-time delivery of a high quality software solution. (There”s a recently launched Prince2 add-on called Prince2-Agile which explains how to blend the two)

So be careful with your next project. Don't simply go with the crowd, don't be a blind follower of fashion. To ensure project success, you need to understand your project constraints rather than listen to the fashionistas.

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.

Need inspiration on project quality? Look at your car!

If you are a project manager and you need to deliver quality, then go look at your car for inspiration. Your car is a high quality product which should inspire you in your project management...

A modern car is long-lasting and useful. It's high quality. The car manufacturers (Toyota, Renault, Ford, etc.) have worked hard to improve quality over many decades. Consider the last 50 years. If you compare the quality of two cars from 1964 and 2014, the difference is huge. The 1960's car had an limited lifespan, typically less than 10 years - its body would rust away year by year, its engine would wear out; whereas today's car should run for several hundred thousand kilometres and remain largely rust free for all its long life. Additionally, that 1960's car was basic - no radio, no heater, no seatbelts. That's very low quality in today's terms. Today, all that comes as standard.

So when you look at your car, you should admire a high quality product, and ask what the project manager can learn from car manufacturers.

In manufacturing, quality is defined in two ways: "Meets specification" and "Fit for use"

The manufacturer has delivered both in your 21st century car

- manufacturing specifications have vastly improved (better paint, more robust engines, etc.).

- customer satisfaction has vastly increased (the car is more "fit for use" - temperature control, audio, safety...)

Both of these definitions come from the world of manufacturing, but both can be applied to projects.

•  In automobile manufacturing, the car is the product. Toyota, Renault and Ford focus on delivering a high quality car
• In project management, your project has a "product" - this is your deliverable or your solution. This is where your quality focus should be.

We have two definitions of quality, so there are two ways to focus on quality in products.

1.  Using the approach of "meet specification", the starting point is to define (i.e. write down and describe) your final product, then to break it down into sub-products. To document that breakdown, you can draw a simple diagram called a "Product breakdown structure", which shows the 15 or 20 deliverables that make up your final product. You can then focus on each of these deliverables - particularly, on how to deliver quality for each deliverable, one by one. If each deliverable is high quality, then your final product will be high quality
2. Using the approach of "fit for purpose", you start with a less defined final product, typically a list of user needs or functionalities. (Sometimes these are expressed as "user stories"). You then work iteratively, trying to converge towards a solution that meets user needs. Each iteration is a better approximation to the final product, and where possible, is a partial working solution. Throughout the process, you work closely with your user or customer, showing them each iteration to get their feedback, so they can check that it's fit for purpose. Iteratively, you converge towards a high quality solution.  

These two approaches correspond to two Project Management methods

•         Prince2: The specification-driven approach is the way that the Prince2 project management method addresses quality. Prince2 has a "path to quality".
•         AgilePM: The iterative approach is an Agile way of working, supported by methods like DSDM (which is the basis for the AgilePM certification). DSDM says "never compromise quality"

Whatever your method, it's time to take action on Project Management quality.

One of the famous books on manufacturing quality is called “Quality is Free”. The book says that addressing quality correctly doesn’t cost you time and money, it saves time and money.

If you don’t use a robust approach to quality, you’ll probably waste time. You’ll discover the defects downstream. You’ll find out the customer’s quality expectations when you deliver. And you’ll probably fix any problems. But fixing quality defaults once the product is delivered can be very time consuming. You may end up doing the work twice… once to make the product, and a second time to fix it.

So addressing quality saves you time, keeps your customer happy, and delivers added value. Free of charge.

So maybe it's time to go admire your car... and to get inspiration for your next project.

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.