• A PMO needs to support
  existing change delivery practices including portfolio, programme &
  project management.
• The challenge for any PMO
  is to continue to add value for the business. The PMO can improve the
  integration & maturity of change delivery.
• Integration is about more
  than the maturity of any one change delivery practice. We need to examine
  how different maturity levels can work together.
• The PMO also needs to
  understand & resolve conflicts.
• We need a workable way of
  managing an integration initiative.
• We need to summarize this
  mix of practices and maturity in a single compelling picture.

For more information visit www.pmo-symposium.com

I’ll be delivering a one day workshop on Integrating Best Practice in Change Delivery at the European PMO Symposium in Berlin on 24 June 2011 www.pmo-symposium.com .

You may already have come across my Practices for Delivering Change presentation in one form or another http://www.afaprojects.com/blog/?p=626

This workshop will recap on project, programme & portfolio management as well as several other change delivery practices. But I want to take these as building blocks and go to explore how we integrate practices in our organizations. To do that I need to mix in a few other useful concepts:

• Firstly adopting a change delivery practice is all about achieving a capability maturity level that makes business sense. Se we need to be proficient a both carrying out maturity assessments and  creating an achievable action plan

• Secondly we really adopt a single change delivery practice. These days we are likely to be deploying a whole range of practices. We need to be clear how practices fit together…or not

• Since I wrote Tailoring PRINCE2 more than a decade ago, I’ve encouraged clients to vigorously scale each practice so it can be embedded as seamlessly as possible into the organization.

• Finally each integration initiative needs to be desirable, viable and achievable. But I’d also add another criterion. The disruptive impact on the business needs to be minimised, while still ensuring we get true behaviour change.

So there is a lot for us to discuss in Berlin.

But I want to go further and encourage an exchange of experience. I’ve started a discussion in the European PMO Symposium Group on LinkedIn. So go across to LinkedIn and join the grouphttp://www.linkedin.com/groups?home=&gid=4306258&trk=anet_ug_hm.

I’d like to hear your experience of Integrating Change Delivery Practices.

I found myself being quite radical in some of the ideas I’ve submitted. I thought I’d share them with you and ask if you agree or disagree?

P3M3 should be commended on its comprehensiveness but this is only of value to a limited proportion of potential users…and to consultants who can revel in the complexity!

It is written in language that is understandable by those of us who can understand (appreciate) Level 5 behaviours.

We should consider writing each Level in language and at a level of detail (granularity) that is appropriate to that Level.  Consequently the Level 1 descriptions and a Level 1 assessment would be simpler than a Level 2 assessment and so on. This would as a by-product, define a set of incremental and increasingly rigorous assessments.

Taking this idea a little further should and could there be an integrated Level 1 description or one covering portfolio & programme management?

Secondly, the model has become more prescriptive as it has evolved. We need to reverse this trend. Level 3 can be summarised as central standards with flexibility. Every element at Level 3 should  test for both those central standards and the associated mechanism for flexing in defined circumstances. This flexibility test has already been lost from the detail of much of  the model at Level 3.

Level 2, I would describe as potentially repeatable behaviours. If a group are displaying appropriate behaviours, say managing risks. They are at Level 2. There does not need to be either consistent documentation, or consistent behaviours per se. Level 2 descriptors should consequently describe and test the  outcome not the inputs. If, in order to achieve the outcome in a particular set of circumstances, there need to be inputs such as consistent behaviours or documentation, so be it. But the Level 2 model needs to differentiate between the end and the means to the end.

If I haven’t delivered a course for a while or its new and I am still getting used to it, then I need to do some preparation, of course.

And sometimes the group dynamic in the training event simply does not work. Some delegates, trainers and employers think trainers have magical powers they can use to make a course come together.  I take a different view.

There are lots of models of team dynamics. Tuckman’s forming, storming, norming & performing model is probably the best known. It says a team has to progress through various stages before it can perform. Belbin team roles are also useful. Each of us has certain preferred roles in a team but for a teem to be successful there needs to be a mix of personalities.

A trainer can monitor the team as it evolves and can compliment the natural roles of the other attendees, but the trainer is still only one person contributing to a larger group. It’s a simplistic model to think the trainer is “in charge”.

Anyway, back to the hardest course.

I’ve just completed an Accelerated MSP Advanced Practitioner Course. It should take 8 days and we completed it in 5. We worked together for about 11 hours each day and then the delegates did homework. I was working with a new partner and the delegates were all existing trainers in other methods. I think that make it harder not easier.

So well done everyone for putting so much into last week. But now I need a rest!

In the first case, a charity runs a number of independent schools. They run building projects where new education facilities are provided to a school. Most of the work and expenditure is devoted to constructing the buildings. But there is a significant input form the school which might be adjusting the way it delivers education.

You could run this change initiative as a small programme with a relatively large construction project at its heart. I’ve seen MSP used successfully in this way. But the charity preferred to run the initiatives as projects.

Spending approval for the build could not be delegated below the Board of Governors for legal reasons. So for those stage boundaries, the Board of Governors acts as the Project Board. For other stage boundaries there is a lower level Project Board – the Facilities Director, the School Head or Bursar, one Governor, etc.

I must say I can’t recall the last time I came across split level project boards. But it this case it clearly works!

The other example is a fairly new tech company, that has now grown to about 500 people, launching a new  product. It’s a complex product going into a global market so it’s a large initiative. They decided to use a programme model for the campaign.

As is often the case in an entrepreneurial company, the directors are very hands on. One is both SRO and actively involved at many levels, both managerial and technical, throughout the programme. It’s still a programme because they need for example a Vision & Blueprint and sophisticated Stakeholder Engagement. But it’s a remarkably flat programme governance structure. The programme manager does have to imaginative in the way she works  but the programme is another success.

The lessons are:

• Aligning with the culture is key.

• MSP & PRINCE2 are not isolated change delivery practices. Its possible to mix and match.

• Flat programme governance and layered project governance can both succeed in the right circumstances.

There is a disused windmill near where I live. A few years ago I became a trustee of the charity hoping to refurbish the mill. Our chairman was both overly ambitious and rather too independent. The funding bid he submitted was not approved and the committee broke up. Last year some new blood decided to have another go and a few months ago I was invited back onto the reformed committee. I decided to be more assertive this time.

I went to my first committee meeting in January and listened with growing impatience to colleagues discussing everything from the detail of window hinges to running a fully functional windmill. A windmill is more that a building it is a piece of society and I felt we were talking about a small transformational change programme.

But we didn’t have a vision.

I steered the conversion away from the plan for the next few weeks to the vision and it quickly became apparent that we had a diverse range of visions. Our secretary was wonderful. She encapsulated the essence of the discussion, summarised the visions and  recorded our agreement that we were initially going for a more modest vision. (Don’t meeting secretaries have a fabulous power to rewrite history!)

I volunteered to help write a new funding bid and set to work with a few colleagues. Some were experienced project managers, but it was soon apparent that although we could describe the project, we hadn’t fleshed out the detail of how we would operate after the end of the project.

We had no blueprint.

At a fairly noisy sub-committee, I got agreement to put the blueprint on the next full committee meeting agenda. Frankly my colleagues didn’t really get what I was aiming for. I was given just 20 minutes to forge a blueprint.

So at the next committee meeting I was again pushing my colleagues as hard as I could to get their help to create an alien document.  But we did agree a blueprint and it was enormously useful in helping us draft a coherent funding bid, which went off a few days ago.

I was worried a I had pushed my colleagues too hard. But was really pleased to read in our local paper an interview with our chairman. He was describing a better future – our vision and blueprint. I thought it read well. Realistic but compelling. He even made a point of emphasising that we were not  going for some of the more ambitions visions that had been bandied about at that first committee meeting.

My conclusion: MSP works!

But not all organisations are taking such a positive
approach to the challenges. Too many are just not spending anything on research
& development. That approach may make the short-term cash position look
stronger but any organisation that is not moving forward is moving backwards. Over
quite a short period of time organisations which do not continue to develop
soon start to lag a long way behind their competitors. And in the public sector
those comparison league tables will soon show up which organisations are losing
capability as remaining staff are no longer encouraged to develop their
thinking & their practice.

Now is the time to invest in training & development
activity so that when the end of the recession comes your organisation will be
ready to take on the new opportunities as soon as they appear.

It was very hard work but great fun.

If your knowledge of PRINCE2 is theoretical (or even a bit rusty), or you are uncomfortable cooperating with others to achieve a deadline, perhaps you should give PRINCE2 Professional a miss.

But if you are really comfortable with applying PRINCE2 in the real world and get a buzz from working with others in a high pressure environment, then go for it!

In the 2009 Refresh of PRINCE2 we reduced the content on techniques and I think that was the right think to do. But it means we are loosing some of the practical experience of real world Product Based Planning that build up over the years.

Here are some of my top tips:

How Many Products at the Top?

Lets start at the very beginning…..Isn’t that a line from a song in the Sound of Music? Anyway, you have brainstormed products, hopefully with a good range of stakeholders. There is a very strong human tendency to drill down into the detail. That means we can overlook significant high-level products. Product Based Planning helps us pause and get the top level scope right.

So once we have a dozen or more products identified its time to sort the top level of the Product Breakdown Structure.

Necessary and Sufficient Stuff

The test of the top level is first of all “Is this set of products necessary and sufficient?” Do we need them all and are there enough products to cover everything? Forget about lower level products when applying this test, they will only distract.

How Many is to Many?

I’m often asked how many products should there be at each level. The answer is between 3 and 7. This range initially came from span of control theory but has been proved over time. If you have more than that, it will make integration too difficult.

One to Many

If you have a good cross section of stakeholders you may at this point get into a debate on how to decompose the final product. As a PBS is a strict one to many structure you can only use one view of the project.

The classic example is an accounting system where the users want accounts receivable, accounts payable etc. and the IT people want databases, screens, etc. There is no right answer, it depends on the relative power of different stakeholder groups. But whatever conclusion you come to is very important for the project. It will dictate the whole overall approach. So make sure stakeholder groups are properly represented at your planning workshop.

Which Ones Stay Up

How do you decide which products should stay at a given level? The answer is that the products at a level should be of broadly comparable significance.

Broadly comparable for me is within a ratio of 1:3. If we could quantify the benefits associated with each product on a financial basis, and that’s almost impossible. But if we could, then products worth between say £30 and £90 could sit at the same level. But a £20 product would have to sit at a lower level and a £100 product at a higher level.

You might decide the effort to build a product is an acceptable metaphor for significance. But you might need to again come back to the relative power of stakeholders to reach a consensus.

Estimating

You can also get into some early and crude estimating as there is an approximate 5:1 ratio between levels. Level 1 is 1 product, Level 2 is 5 products, Level 3 is 25 products, etc.

Level 4 products are each “worth” 1/125th of the Level 1 product and so on.

How Far Down

You need to decompose to a level of detail at which you can control within tolerance. It the tolerance is a team week and the team size was 10. I would want a lowest level of granularity of 10 products for each week of the stage, each within an average effort of 1 person week. That gives me an order of magnitude more detail than I have to report upwards.

If you are finding these rules of thumb a bit baffling, I suggest you might need to sit down quietly and draw some breakdowns with numbers on them, before you go into a workshop.

Integration Products

Each lowest level product is “real”. It could have a product description with a quality method, criteria, etc.

If you have to demote products then you might need a place holder called “stuff” – that’s fine.

If you have decided to stop your decomposition at this level then you might need to put a bit more detail on the “stuff” product. Think about cooking. You can have a product called “ingredients” before you know what the ingredients are. That detail can come later.

When you later decompose that level and each of the products at the level, you may get into integration products and collective groupings.

There was quite a battle a few years ago over this subject. Initially the argument was that when you decomposed a product, the higher level product became empty. As I’m an engineer and have spend a lot of my time dealing with integration testing, I put forward the idea of the integration product. There was a lot of resistance but over time the integration product has been gaining ground.

Let me give a very simple bit of guidance. Whenever you decompose a product, that higher level product becomes an integration product. Always.

No really – always.

A collective grouping is a meaningless concept.

A higher level product can always have a test associated with it. If X decomposed into A, B & C then the test associated with X is at the very least “Are A, B & C fit for purpose?”

End of debate.

Getting to the Flow

This is already a mammoth blog, sorry. I’ll deal with moving across to the Product Flow Diagram in a subsequent blog. But if you have any questions on this lot, do get in touch.

But, last week with a client in Germany, I was discussing implementation of P3O and other practices and I have come up with a few thoughts. I’d be interested in your views.

We talk about Tailoring consisting of:

• Embedding in your organization to adopt the method &

• Tailoring for your specific change initiative to adapt the method.

I’ve taken these terms from the PRINCE2 manual and modified them to be applicable to any change initiative not just a project. I’ve also moved on from the definitions I gave in Tailoring PRINCE2 which were Implementing and Scaling.

I wonder if there are actually a few more steps that it would be helpful to refer to. I’m coming round to the idea that there is an Integration Cycle.

The Integration Cycle consists of:

• Researching
  • Relevant global and context-specific practices
    • I increasingly get into conversations about which practices a client should adopt. Its not as simple as just choosing from  the Cabinet Office (OGC) Best Practices in Change Delivery. Clients may also want to consider related, more technical practices, at the same time.

• Assessing
  • Capability maturity either using formal maturity models or less formal methods
    • A P3O survey recently showed that maturity assessments was one of the least used parts of the P3O manual. That’s a pity, but I suspect that problem is you have to be mature to use a maturity model. We have to offer immature ways of assessing maturity!

• Designing
  • A coherent and beneficial Practice Set
    • I’ve looked back at Tailoring PRINCE2  which was about scaling down – a Practice Sub-Set, if you like. If only the world was that simple! Now we also have to consider scaling up – adopting a number of practices. And in reality we are likely to adopt a number of practices but also select parts of each practice.

• Embedding
  • In your organization to adopt the chosen Practice Set
    • I think P3O gives the best advice on embedding in the Implementing and Re-energising chapter. But there are also a few useful ideas on approaches to implementing in MoP.

• Tailoring
  • For your specific change initiative to adapt the Practice Set.
    • We are back at the PRINCE2 Tailoring chapter!

These five processes form a cycle, so you can iterate round the cycle, improving or adjusting  the maturity level and perhaps widening or narrowing the organizational scope.

Finally I feel comfortable talking with clients about an Integration Cycle. Integration makes clear that we are trying to come up with a set of practices that fit together and also fit with the business.