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

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

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

Four ways to build value in Portfolio Management

Getting started with Portfolio Management is typically quite easy. Essentially it’s all about reporting. But once this is in place, what next? It’s easy to lose momentum and get trapped in a weekly cycle of reporting.

To make sustainable progress on Portfolio Management you need identify how to add additional value from Portfolio Management. This way, you can make sustainable progress. You won’t lose momentum.

The first step in Portfolio Management is reporting. You gather all the various project, programmes and change initiatives together. This may take time, but it’s reasonably easy. If you are working at the enterprise level, your enterprise portfolio is the sum of all the approved, active change initiatives in your company. If there are a lot of initiatives,  focus on the bigger ones. If you are working in a department such as I.T., your I.T. portfolio is the sum of all your approved, active I.T. initiatives, including those which support other departments.

This first step is typically fruitful, as it invites answers to several pertinent questions:
- what projects and programmes have been approved? 
- are project and programmes well defined (are there overlapping projects? are some projects part of bigger programmes?)
- do you have wildcat projects?(unofficial, i.e. active but not actually approved)
- do you have zombie projects? (dormant, i.e. approved but not active)
- do you have straggler projects? (the project should have closed, but instead has drifted into maintenance or support work)

Reporting is the first step. What comes next? How to sustain momentum and avoid the trap of low-value repetitive reporting?

The way forward is to identify where your company needs to add value with Portfolio Management.

There are basically four ways to add extra value

1) Target the right projects, to generate value
    ❑    You choose to focus on the project approval process. You start to build a project prioritisation model, which is a decision support tool for choosing which projects to run. The model will help to build a balanced, achievable portfolio, aligned to your strategy
2) Help projects to deliver, to protect the value-adding process
    ❑    You choose to focus on tracking and monitoring projects. You ensure project inter-dependencies are managed. You work on resource bottlenecks. You highlight problems and push forward issue resolution.
3) Push for better performance, so more projects deliver well
    ❑    You choose to focus on project performance. You monitor actual performance against plan (on time? on budget? how good are the estimates?); and whether projects following your expected ways of working. Then you feed back lessons and drive improvements.
4) Follow up on business cases, to ensure real long-term value-for-money
    ❑    You focus on delivering value. You ensure all projects have a solid business case, which is reviewed before work starts, at key milestones, at closure - and most importantly in the weeks and months after closure, to ensure benefits are really sustained.

When you can identify where to add value, you have a goal. A destination. Once you understand your destination, you can plot the journey: your next next steps become clear.

An invaluable next step is to benefit from other people’s experience to guide your journey. For Portfolio Management, you now have guidance in the form of the MoP framework (Management of Portfolios) and the P3O guide (Portfolio, Programme and Project Offices). For example, the MoP guidance explains how to build a portfolio prioritisation model, while the P3O guidance explains how to to build a value proposition.They are interlinked - MoP helps you to define your destination, while P3O helps plan out the journey.

When you know your destination, when you have a plan for the journey, taking the next steps is easier…

Mapping the future, mapping the past

 This is about understanding the past. It’s a case study, but it’s more than that. It’s about how we can better understand the past if we have a frame of reference.

The case study explains how a large company improved its project & portfolio management.

This multi-national organisation was structured as 7 business units. They had an ambitious change agenda. To deliver this huge amount of change, they needed to improve their project management.

They ran a 3-phase improvement initiative to improve project management
    ❑    Phase 1 introduced Prince2 project management, supported by heavy-duty EPM tools (Enterprise Project Management software)
    ❑    Phase 2 measured regularly the improving maturity, by measuring the use of Prince2-based methods and the tools. With these measures, they found the weak spots, and took corrective action
    ❑    Phase 3 introduced portfolio reporting. It started once the level of maturity of Project Management was acceptable - it needed good quality project data as the starting point for consolidated portfolio reporting.

We can understand this case study in terms of P3O. That will be our frame of reference. P3O  provides organisations with a top-down approach for improving their P3 (P3 stands for projects, programmes and portfolios). The O stands for Offices, so P3 + O gives P3O.

So let’s use the P3O framework.  How does this case study look in P3O terms?

Retrospectively, we can detect the gradual construction of a P3O model, as the 3 phases advanced
    ❑    Phase 1. Local CoE functions were set up (Centres of Excellence) supporting the deployment of Prince2.
The local CoEs
    ⁃    published standards, procedures, templates
    ⁃    provided training, coaching
    ⁃    ensured tool support
    ❑    Phase 2. A centralised the CoE function emerged. The local CoEs were merged into a single unified CoE.
The central CoE
    ⁃    measured the maturity of Prince2 and tool using with a P3P3 approach (P3M3 is a maturity model)
    ⁃    provided an Information Portal with standards, procedures, templates, etc
    ⁃    continued to provide coaching to teams with low maturity
    ❑    Phase 3. A Portfolio Office structure was deployed, with a central Organisational Portfolio Office managed by a senior manager.
Each Portfolio Office
    ⁃    introduced Portfolio Design - budget management, demand management, resource optimisation, portfolio optimisation
    ⁃    coordinated Portfolio Delivery - monitoring and control of projects, data consolidation, status reporting

This provided the foundations for solid Project Management.
We can see that the P3O support was a key enabler
    ❑    The P3O structure was a key enabler of for project management.  Without support from the CoE structures, this major Prince2 and tools deployment would not have succeeded, and the high maturity levels in Project Management would not have been achieved.
    ❑    The P3O structure was also an essential enabler for Portfolio Management structure. Without the Portfolio Office, the ambitious work to structure Portfolio Management would not have progressed. It was beyond the reach of the business managers responsible for the portfolios - the support of the Portfolio Offices in the P3O model was vital.

By looking back at the past, we learn lessons by finding a good frame of reference.

Now look forward to the future. To improve your organisation’s project management, use a good frame of reference. Try using the P3O framework to map out the future.

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.

A long term vision for PMOs

A bonus for a Danish public sector organisation

In November, I was in Copenhagen to work with people from the IT side of a large Danish public sector organisation

The plan was to focus on training about PMOs, but we went much further. They got their training but they also got a bonus.

The training was loosely based on P3O. The Danish team uses Prince2 for Project Management, and MSP for Programme Management. These are the existing cornerstones of the OGC guidance, so quite logically they are now looking at P3O, which is the OGC guidance on PMOs.

The P3O guidance for OGC is about Projects, Programmes and Portfolios (that’s the P3); and about how to support the P3 with an “Office” structure. That’s where the acronym comes from: “P3” plus “O” gives P3O.

In the first half of my visit, we covered all the P3O basics, of how to justify a PMO solution (that’s called the P3O value model) and how to design a PMO solution (that’s the P3O model itself).

In the second half, I expected to explain how to roll out a PMO solution (that’s called deploying the P3O model). But I spotted an opportunity. As the Danish team are skilled users of MSP best practice on programme management, we could do more than training. I put away my training material and all my prepared case studies, and focussed on the one case study which really interested my client – their own organisation.

So we started work on designing and implementing the client’s own PMO solution. That’s better than training. As the Chinese proverb says, “Tell me and I'll forget; show me and I may remember; involve me and I'll understand.”

We drafted several MSP documents
- Vision statement
- 5 year blueprint
- Risk analysis
- Project dossier

This went fast, and was very productive. As the Chinese proverb says, the Danes were involved, and they understood. But they didn’t only learn. They also concretely started work on their future P3O programme. That’s a bonus.

CMMI + Prince2 = a pathway to process improvement

Intro
This case study explains how a QA team used part of CMMI to measure – and enhance – the success of a Prince2 implementation in the IT division of a large European bank. The choice of CMMI PPQA as the QA toolkit (rather than a Prince2 based QA toolkit) was advantageous, as it allowed the QA team to focus on the real PM process rather than the formal Prince2 process.

Context
In 2007, my client’s IT division had a new project management process which it was struggling to impose. New and powerful tools for project management were proving hard to use, and were an additional barrier to process improvement.

There were around 500 concurrent IT projects in 7 portfolios spread over 3 countries, with about 130 PMs (project managers). Note the meaning of “IT” for the bank at this period: the “IT division” had responsibility for ICT infrastructure and operations; various “IS divisions” handled software and process change projects.

Management was very focussed on projects and wanted to drive PM process improvement. There was a major and vital IT transformation programme with an annual 20 million euro budget which was viewed as a vehicle for process improvement.

The PMO for IT was large (normally between 8 and 10 people), with the equivalent of 2 people working exclusively on PPQA. In mid 2007, most of the team worked on coaching and training – in 2008, the focus turned increasingly to other tasks (reporting, resource management, etc).

Process context
The bank was implementing project management as a process in IT and IS, based on the Prince2 process model. There was top management support for project improvement using defined processes, with KPIs to measure the process.

The decision was taken by IT in early 2007 to use the CMMI PPQA process area as the model for process improvement and therefore for providing the KPIs to measure progress.

What is PPQA?
PPQA is one of the 22 process areas in CMMI. In broad terms PPQA intervenes in the project process to
• Perform periodic project audits to assess compliance
• Help teams get back into compliance where needed
• Find opportunities to coach and improve.

PPQA details
A series of metrics was agreed with management, about 30 metrics per project, addressing 3 levels of project management maturity. Each individual metric was fully defined, both in terms of its process objective, and also the evidence to be examined to decide whether a project was compliant.

For each portfolio, a large and representative number of projects was selected, for example 40 projects out of 100 for the infrastructure team of 25 PMs. We sought to assess at least one project per PM.

An audit procedure and the PPQA assessment schedule was published and agreed with management (middle level IT management and portfolio managers). The analysis of a portfolio took between 2 and 4 weeks total elapsed time. The whole iteration for all portfolios took 3 months.

Each selected project was assessed by the PPQA analyst. The PPQA analyst published intermediate results, giving the chance for an appeals procedure and/or for corrections by the PM; and then final results. All results were stored and consolidated.

Results were communicated to the PM, to the portfolio manager; and in summary (consolidated form) to middle and senior IT management; and to the group.

Statistical analysis showing improvements in time over successive iterations was highly useful in motivating teams to participate in improvement activities

Overview of the 4 iterations
2Q07 – mixed results – drove improvements in the process documentation and training content
4Q07 – significant improvements in compliancy – boosted credibility of the project improvement initiative
2Q08 – assessment very focussed on Prince2 – emphasis on common process within whole group
4Q08 – new assessment model - truer measure of IT project compliance – actionable results

Why we used PPQA and not a Prince2 maturity assessment
We used PPQA as our toolkit for QA. This gave us a generic approach where our assessment was a measure of the effective process in use (and not just of the Prince2 textbook process). For example, a key part of the process was entering and maintaining accurate data in the PM tool. This is not part of Prince2, but was part of the process we measured. Equally, IT management stressed the validation of the project mandate, and again this is not part of Prince2, but was one of our key measures in PPQA.


In the 3rd iteration, in spring 2008, to satisfy group requirements, we used an assessment which was highly focussed on Prince2. This assessment generated the least useful data of all 4 iterations, as it missed so many essential process elements. This iteration was a negative “lesson learned” - it confirmed to us the advantage of using our “generic” CMMI PPQA approach against a Prince2 maturity model (based on the OGC P3M3 model)

Summary
In this large IT team, the process area of CMMI called PPQA was successfully used as a tool to measure and improve project management process compliance (even though the process that we measured was based on Prince2 rather than CMMI).



Reference: Project Management Success with CMMI, James Persse, Prentice Hall 2007

Prince2 and CMMI are trademarks of their respective owners.