PMOs get more Value with Portfolio, Programme and Project Offices guidance with P3O®: 2013

Most organizations are seeking to get better value from their projects, and better support for changes initiatives though a modern PMO model.

Typically, a PMO will start as a repository for tools and methods and some planning support - but there's a lot more that can be done.

A good PMO will improve efficiency with better project selection, streamlined templates and decision gates and better information flow.

Better Delivery support through key resources and a streamlined process to assist with project selection and planning and delivery.

Strategic decision support as a Portfolio office with rolled up Dashboard Reports to facilitate better investment decisions

Streamlined reporting with simple or advanced tools - the modern PPM solutions can be set up and operational in a week with 'input it once' data reporting, making it easier for PMs to report and faster for PMOs to roll up information into dashboards for better decision making.

More projects completed on time and budget - or stopped if they clearly don’t deliver any value.

The purpose of the Portfolio, Programme and Project Offices (P3O®) guidance is to provide universally applicable guidance that will enable individuals and organizations to successfully establish, develop and maintain appropriate business support structures that will allow:

• Informed senior management decision making on strategic alignment, prioritization, risk management, optimization of resource, etc to successfully deliver their business objectives
• Identification and realization of business outcomes and benefits via programmes
• Successful delivery of project outputs that enable benefits within time, cost and quality restraints.

There is a big focus on Adding Value – What value P3Os can bring to the PMO and the organisation including a business case, funding models and performance measures.

At Yellowhouse we have been consulting and training in P3O with PMOs since 2009. With the new textbook, we move to a 5-day training format with more new content and revised exams.

Course information is here, with courses in Brisbane, Sydney and Melbourne. Or we can come to you for an in-house course.

P3O® is a Registered Trademark of AXELOS Limited. Yellowhouse is an APMG Accredited Training Organization and  Consulting Organization 

Yellowhouse 2014 Courses and changes

At Yellowhouse, we specialise in best management practice training courses.
Household brands. International certification. Excellent training facilities. Great trainers.
Experience. The difference.

We are starting 2014 with a great range of courses for you.

We've been training people in PRINCE2 since 2002. In Australia, Europe (France, Russia); New Zealand, India and Papua New Guinea.
Our Brisbane course schedule is listed here: 
We offer courses in Darwin, Sydney, Melbourne, Wellington and Auckland.

Our Certification courses:

• Project Management: PRINCE2
• Program Management: MSP
• Portfolio Management: MoP
• PMO Management: P3O
• Managing Change with Change Management™
• Benefits Management: Managing Benefits™
• Risk Management with MoR (Management of Risk)
• Agile Projects with Agile PM™

We also offer customised training, executive and governance workshops, in-house courses and a range of beneftis, planning, start-up workshops.

So when you think of the training you need - think Yellowhouse. We have great training for you.

MSP® surprise #3: MSP shortcomings in transition management

The third surprise, embedded in the MSP 2007 Guide and not resolved in the MSP 2011 Guide (despite my earnest attempts to contribute to a change in this area as part of the MSP review process) is that MSP is largely silent or vague about the ‘how’ of transition management. Everyone talks about it, but most people have no idea how to do it.

In MSP 2011 there are about 42 references to transition plan and transition planning. But there is no Transition Plan. This was one of my recommended changes to the guidance. Why not have a transition plan as we reference the ‘document’ so many times, and assign some responsibility to developing, maintaining and actioning the plan. But it is all a bit vague. For example, we can find references to the transition plan or to planning transition throughout the Governance themes and the Transformational flow chapters.

In Appendix A, there are three Information Baseline grouping in MSP 2011 (Boundary, Governance and Programme) and there are 28 documents covered with 6 plans in the Programme section. But there is no Transition Plan in Appendix A. This needs to be addressed in the next version, along with clarification of the difference between the Business Change role and the Business Benefits Role. Let’s go deeper. There are similar bullet-pointed references to the transition activities in the Programme Plan and the Benefit Realization Plan. In essence, MSP has a ‘bob each way’ on where transition belongs, without defining that the BCM owns the transition plan.

The Programme Plan, produced and managed by the Programme Manager, contains a bullet point about transition planning under typical content:

• Transition planning information and schedules[1]
• Details of transition schedules”[2]

The Benefits Realization Plan, produced and managed by the Business Change Manager, contains a bullet point about transition planning under typical content:

In Managing the Tranches, we read about the Transition plans, but there is no reference to the Producer, Reviewer or Approver, as there is for the other 28 documents included in the information baseline documentation.

Transition plans prepared earlier in the tranche will be activated when the project outputs have been combined and tested, the capability is ready for transition and operations is ready to use them, changing their ways of working.[3]

OK, but how are they prepared, and by whom and where is an Appendix A reference?

In the Chapter 9, Planning and Control, in the first of two almost identical sections on transition (the other being Chapter 18, Managing the Benefits, there is a reference to the Programme Manager and the BCM working together around transition.

The programme manager and business change managers (BCMs) work closely together to manage all aspects of transition.[4]

While this is a good reference in terms of aligning the responsibilities for project delivery, transition management and benefits management, there is a lack of clarity around the specific responsibilities.

In Chapter 18, there is some more specific reference to the transition plan under the heading of “Initiate transition”.

As the projects approach completion, the relevant business operations need to be prepared for implementing the outputs from the projects. The transition plan is reviewed and updated to reflect the activities of transition. These activities need to be managed into the business environment, ensuring successful take-up of the new capability while maintaining the appropriate level of business as usual.[5]

While the BCM is responsible for “Initiate transition”, the transition plan still doesn’t exist as an MSP document. Yet it is clear from the intention of the chapter and the assignment of the RACI chart that the BCM is responsible. We have clients who use quite detailed transition plan templates they have created themselves or modified to support the baton change from the delivery of project outputs through to achievement of outcomes and benefit realization.

This is Blog 4 in a series of 4

• Three MSP® surprises related to Business Change Management and Benefits Management
• MSP® surprise #1: project managers don’t manage transition
• MSP® surprise #2: Business Change Managers and managing benefits

MSP® surprise #3: MSP shortcomings in transition management

MSP® is a Registered Trade Mark of AXELOS Limited; he Swirl logo™ is a trade mark of AXELOS Limited; Yellowhouse is an MSP® Accredited Training Organization:

MSP® surprise #2: Business Change Managers and managing benefits

At the cutting edge with senior management groups who are setting up MSP (Managing Successful Programmes) for the first time in their company or agency, getting champion support for the model is the first problem.

When management finds it hard to recognise the major benefits of implementing MSP to run a program, with the associated changes and challenges posed for governance and decision-making, projects and delivery mode, business involvement and ownership, the Cranfield benefits model and how to engage key business stakeholders in the end-to-end process.

Further, when senior managers and department heads realize when implementing MSP that “the business” is accountable for realizing and managing the benefits, they are often quite surprised. Remember, most people don’t know how to quantify a benefit, how to plan for benefits, how to cost a benefit against the cost of delivering the blueprint or the relationship between benefits and the business case (to justify the blueprint), benefits and the blueprint (the future state model), benefits and the programme plan (to build the blueprint), benefits and the business strategies.

I worked with a Programme SRO and Programme Manager to help set up an ICT Realignment Programme using MSP in a government agency. I supported them through the elements of the Program Definition, culminating in a Blueprint and Programme Plan with a “very draft” benefits approach. There was senior management involvement, but the consultancy ended before the finalisation of the Programme documentation.

About a year later, I was asked by the SRO to come in and brief the Business Change Managers as it was about a month before a Tranche “go live”. There were six BCMs invited plus the Programme Manager and the SRO. So I prepared a two hour workshop based around the BCM role and responsibilities and the MSP “Realizing the Benefits” chapter. I knew we were in for some fun when I received an e-mail from the SRO’s assistant the day before the session stating that all was in readiness, but some people were asking “What does BCM stand for?”

What indeed?

The fun part was when they saw the RACI chart and saw that the BCM was Responsible for everything in Transition. So the response was:

“How are we supposed to do all that and who’s going to pay for it?”

These are good questions in Defining a Programme, but not so helpful if not addressed until Realizing the Benefits. It was a late and unfortunate stakeholder engagement process, but the program could only succeed if the business owned the change, and the benefits.

So we need to teach them. There are some training opportunities with MSP courses, governance workshops, benefits planning workshops, benefits mapping exercises, writing benefits management strategies and consolidating benefits plans and helping the BCM to develop and understand Benefit Profiles aligned to the related projects and programme tranches. But it is all new to them and there is a high risk of failure on the business side of the equation.

The second part of the surprise in MSP is that “the business” is accountable for the Business Change. We are still a long way from the embedded understanding that the business owns the balance between “run the business – change the business” and it is a business decision to invest in a programme using MSP to transform that part of the organization from the current state to the future state, to the target operating model defined in a blueprint and delivered by project outputs, business changes new capability, outcomes in the business and the associated benefits aligned to business strategies.

So we train the business to understand and lead on Change Management. Not the big picture Organizational change approach, but ‘transition management’, moving the business with the outcomes from the projects towards the realization of benefits through a transformational change process, managed and owned business side by a BCM.

This is Blog 3 in a series of 4:

• Three MSP® surprises related to Business Change Management and Benefits Management
• MSP® surprise #1: project managers don’t manage transition
• MSP® surprise #2: Business Change Managers and managing benefits

MSP® surprise #3: MSP shortcomings in transition management

MSP® is a Registered Trade Mark of AXELOS Limited; he Swirl logo™ is a trade mark of AXELOS Limited; Yellowhouse is an MSP® Accredited Training Organization

MSP® surprise #1: project managers don’t manage transition

As an project manager with 20 years experience running projects with a “change role” reporting to the project manager, one of the biggest surprises I had when learning and applying MSP was that the project manager was not responsible for transitioning the change into the business. This still comes as a surprise to many project managers when they come to understand the BCM role and review the Delivering Capability and Realizing Benefits chapters in “Managing Successful Programmes with MSP (2011)”. 

For most of them, it’s part of what they do as a project manager. And maybe they don’t do it that well. And maybe that’s not their fault.

Many of the people I train and consult to have difficulties with this concept. Traditionally, the project manager is appointed to deliver the project including the changes associated with this. After spending several years with MSP, I have developed a strong (supportive) view that “it’s all about the business” and that change and transition management belong to the business.

I have always been intrigued by the official research and statistics talking about ICT project success rates. We recently saw a statistic that nearly 70% of ICT projects fail in some way.

In virtually every case of failure, management fails to anticipate serious problems. Even in cases where challenges are likely, ICT failure is too often considered business-as-usual, with executives throwing their figurative hands in the air, in surrender to chance or bad luck.

ICT failures happen when managers exercise insufficient judgment, possess too little experience, hire the wrong people, ignore warning signs and, crucially, fail to involve affected employees in a way that eases the path to success.[1]

But the statistic needs to be clarified – what does project success mean? Is it the successful delivery of a solution or the successful transition of that solution into the business? We have all seen successful delivery ruined by poor business take up in the transition and the project gets the blame.

Although tempting to blame project managers for failure, we must point attention to senior executives for allowing the conditions for failure to exist in the first place. The underlying reasons fall into three categories:

1                 Unrealistic and mismatched expectations
2                 Conflicts of interest among customers, vendors and integrators
3                 Corporate organization structure that conspires toward failure[2]

I recently participated in a discussion forum by suggesting that project success and failure needs to be clarified. Does success mean that the time/cost/quality/scope elements were achieved within tolerance? That is, is the deliverable fit for purpose and did it come in on time and budget? From the IT or infrastructure project manager’s perspective, that is what matters. But often you cannot determine the value offered by a project until 12 months or more after completion. Just because something met the rules of the triple constraint doesn’t mean that the business gained a benefit. And why did we the business spend all this money anyway?

The question about project success is one for the business. In MSP, it can be asked because the Business Change Manager is a business-side role and the success should be measured by the business against a pre-agreed measure of the expected benefit.

This is Blog 2 in a series of 4

• Three MSP® surprises related to Business Change Management and Benefits Management
• MSP® surprise #1: project managers don’t manage transition
• MSP® surprise #2: Business Change Managers and managing benefits

MSP® surprise #3: MSP shortcomings in transition management

MSP® is a Registered Trade Mark of AXELOS Limited; he Swirl logo™ is a trade mark of AXELOS Limited; Yellowhouse is an MSP® Accredited Training Organization

Three MSP® surprises related to Business Change Management and Benefits Management

After working with MSP since 2003, I became an MSP Advanced Practitioner in 2006; an MSP Trainer in 2007; then an MSP Registered Consultant in 2009. I have copies of each of the versions of the MSP Guide. 

Since first exploring MSP, I have been fascinated by the separation of the role and tasks of transition management from the project manager’s domain to the change manager’s domain. I have been further challenged in implementing MSP into client organizations with the dual BCM roles of transition management and benefits management.

To be honest, most people don’t get it the first time. Some don’t get it the second time either. I have become used to people trying to short-cut the vision, the blueprint, the program plan, ignore benefits mapping and the benefits profile for the sake of making their lives easier, or so they mistakenly think.

The three following Blogs investigate the broad topic of Business Change Management and Benefits Management, with a specific focus on my experience with the MSP Cranfield model focused on the relationship between delivering a project output through the business change elements of transition management and benefit realization.

It is my understanding that a correct application of the intent and best practice application of programme transition management will improve programme performance and add value to a programme. The alternative view will be explored as well – that is a poor application of transition management will result in reduced value being ascribed to a programme.

I spend a lot of time exploring the impact of effective programme Transition management in the context of the changing roles of the Business Change Manager and the recommended introduction of the Benefits Manager role to the MSP Organization. My observations from practice have prompted me to suggest that we can add more value to a programme by separating the linked activities of “transition management” and “benefits management” into two roles; specifically, the Transition Manager and the Benefits Manager.

From practice and observation, it is clear that there can be too much weight applied to one key person in the Business Change Manager role within a complex programme if the transition activities and benefits activities are combined into the one role.

It is my recommendation that in some “transformational change” programmes, the separation of the change and transition elements of the BCM role from the benefit realization elements will contribute to a better achievement of the end goal of a programme. Both elements are dependent on maintaining the focus on outputs (the projects), the change (pre-transition; transition; post-transition) and the benefits (benefit mapping, benefit plans, benefits profiles) and this has proven to be one of the biggest pain points in fostering effective application of the MSP framework.

There are three big surprises in the way MSP deals with transition and benefits management. The next 3 Blogs cover these:

MSP® surprise #1: project managers don’t manage transition

MSP® surprise #2: Business Change Managers and managing benefits

MSP® surprise #3: MSP shortcomings in transition management

MSP® is a Registered Trade Mark of AXELOS Limited; he Swirl logo™ is a trade mark of AXELOS Limited; Yellowhouse is an MSP® Accredited Training Organization

PRINCE2 Courses in Darwin with Yellowhouse

Everyone is looking for a better way to run their projects to deliver effective change. 
If you have a structured methodology and trained project staff, this will certainly help.


In Darwin there are a number of exciting public sector and commercial projects improving the community and the business environment.

Yellowhouse best management practice courses and consulting services have been available in Darwin with George Koulakis as our Associate since 2008.

We have trained over 100 project staff in PRINCE2 - helping Territorians to run better projects in a better way with clear methods and tools and good governance.

the next course is from 24 March 2014 at the SkyCity Resort Conference Centre.
All you need to do is register here

Yellowhouse is a PRINCE2 Accredited Training Organization