Business-driven PMO setup – Practical insights, techniques and case examples for ensuring success (Book Review)

by Mark Price Perry, 2009, J Ross Publishing, USA. ISBN 978-1-60427-013-6, 494 pages, RRP £60
Pragmatic PMO Rating: ****

The stated aim of this book is to show the reader how to create and maintain a business-driven PMO, because PMOs that are driven by the needs of the business succeed, whereas when PMOs that are driven by other motivations fail.

The book sets this out in a pattern of alternating chapters – one explaining a point from a theoretical or academic perspective, which is then supported by a shorter chapter or two demonstrating that point working in practice.

Rather than go through summarising each chapter, I thought it might be more helpful to list some interesting points or “Aha!” moments that I found in this book (and there were many).

On projects and project management generally:
  • Involve operations early in projects. Document operational concerns and deliver against them. Get handover documents signed, and exit project staff as quickly as possible.
  • Don’t use part-time operations staff on projects, as their primary loyalty will always be to operations. Make dedicated project people accountable with project-specific targets, contracts, etc.
  • Project managers should focus more on managing relationships and taking action, and less on managing RAID logs and keeping documentation up to date. Aim to produce the desired result rather than the planned result (although if these are the same then so much the better!).
On PMO setup and development:
  • A PMO should articulate its business value at or before inception, or expect to defend the additional cost.
  • Don’t “sell” the PMO to Management. Ensure the PMO delivers real business benefits, and let these speak for you. The main source of inadequate Senior Management buy-in to PMOs is probably the result of them having been “sold” a PMO they didn’t really want or need.
  • Most PM methodologies are geared towards large complex projects, but these often make up a tiny percentage of the PMO’s project portfolio. A PM methodology needs to be flexible and scalable to suit the size and complexity of the project being managed.
  • Methodologies should only be used at all if they improve results – “Best Practice” may not be a good fit for your organisation and its projects.
  • Not really an “Aha!” moment but one I very much agree with (see my posts on Watermelon and Green Side Up reporting) – if a project continually reports green RAG statuses across the board, then the budget and timescales were probably inflated – you should expect to see a range of RAG statuses in the lifespan of any project.
  • Project KPIs should reflect the needs of the business, not some internal, myopic, PM-specific measures. As people work to targets, you may as well direct their efforts to truly desirable outcomes.
  • Measure quality not in terms of how closely the plan was followed (it may have been the wrong plan), but how satisfied the customer is with the deliverables.

To sum up, some books once read get passed on to a colleague or put on the shelf and never looked at again. For me, this is not one of those books. Now that I have finished writing this review I will be reading this book again from the start, but this time with a highlighter pen in one hand and a pad of sticky bookmark tabs in the other!

I didn’t pay for this book (it was a gift – not from the publishers!) but I think it is well worth the cover price.

What has the PMO ever done for us?

What has the PMO ever done for us

With all due acknowledgement (and apologies) to Monty Python’s Flying Circus, whose film The Life of Brian inspired this post.

THE INTERIOR OF A DIRTY CITY PUB. A SHADY BACK ROOM WITH A CONSPIRATORIAL ATMOSPHERE. We join a meeting of the Project Managers’ Revolutionary Front, where Brother Reg (the chairman of the meeting) is proposing a motion to the members (all Project Managers), and a CxO guest.

REG (gesticulating at a complex diagram on a flip chart): …So we break into the PMO, set fire to the methodology and sabotage the automated status report reminder email! Who’ll second me so we can take a vote?

[Apathetic silence]

BRIAN (a project manager): Are you sure we should actually be ransacking the PMO, Reg? I mean, some of the stuff they do is really quite useful…

Reg: Useful?!  Don’t make me laugh! What has the PMO ever done for us?

Brian: Well, the project management methodology makes sure we all talk the same language; before we had a PMO we didn’t know whether we were using PRINCE2® or the PMBoK®!

NIGEL (another project manager): That’s right Brian, and they update the methodology with Lessons Learned so it’s relevant to our projects and not over-bureaucratic…

SISTER SUSAN (another project manager, under her breath): Unlike these meetings…

[Sniggers all round]

Nigel (quickly): They do health checks to identify where our projects may be at risk, and help us to bridge the gaps.

Susan: And they develop user-friendly document templates to save us time

Reg: OK, so there are two things the PMO has given us…

LORETTA (a CxO): Well, they distil all the project reports into concise, executive-friendly information so that we know what’s going on.

Brian: …and they build project plans that we can actually use, rather than just stick on the wall and ignore like we used to…

Loretta: …and they prepare exec-specific views of the plans…

Reg: Well yes obviously planning, but what else?

Nigel: They keep an eye on the details for us…

Brian: And that’s where the devil is, isn’t it people?

[Nods and murmurs of general agreement]

Nigel: Yeah, like actions for completion; risks for review…

Brian: Exactly! They liberate us to manage our teams to deliver on time, to quality, and within budget.

Reg: Alright, I accept the PMO vitally underpins delivery of the project portfolio, but apart from methodology management, terrific templates, intelligent information, practical planning, and monitoring the detail, what has the PMO ever done for us?

Susan: Well, remember those “zombie” projects that we should never have started but that just wouldn’t die? They got those stopped…

Loretta: And that freed up some budget for projects that actually deliver benefits!

Reg: Hmm, this meeting isn’t really going the way I planned it.

Susan (just loud enough for everyone except Reg to hear): Maybe he should have got the PMO to run it!

[Amused guffaws. Reg looks frustrated. The laughter fades into awkward silence; the meeting seems to have rather lost its purpose]

Reg: All those in favour of going for a curry?

What does your PMO stand for?

(well OK, mostly the “P” part…)

All over the web you will see people asking or debating what the “P” stands for in PMO. The “MO” stands for “Management Office”, but the “P” can stand for Project, Programme or Portfolio depending on the organisational context.

Axelos use the term P3O® to cover all three, but this is also confusing as the insertion of the “3″ makes many people think that the final “O” is actually a “0″ (zero) rather than the “O” of “Office”.

This can of course lead to confusion, so I suggest making a small alteration to remove the ambiguity. In my own writing I use:

  • PjMO = Project Management Office
  • PgMO = Programme Management Office
  • PfMO = Portfolio Management Office

This makes it very clear which kind of PMO we are talking about. Simples!!

What do you think?

How PMOs improve project governance

One of the benefits of having a Project Management Office (PMO) is that good governance reduces the risks of project delivery and increases its predictability. I will explain how this works in practice using as a case study a Portfolio PMO that I managed.

How PMOs improve Project Governance

The organisation ran a fairly large number of relatively short term projects to set up software systems for new distribution clients. These Client Onboarding projects were run by project managers, but without reference to a documented methodology or a central co-ordinating body. The timescales were often unrealistically tight, and projects would often either miss the due date, or would overspend on additional resources in order to meet the due date.

The tight timescales were usually imposed as a result of sales representatives making ambitious promises to clients without reference to the organisation’s capacity to deliver. Overspend to achieve the deadlines was authorised by the same sales representatives that set the deadlines, but the money to fund the overspend did not come from the Sales budget, and no assessment was made of the effect of the increased effort on the other projects under way.

We were tasked with turning this situation around.

We made the following changes:

  • We set up a “pipeline” list of all the projects likely to be started in the near future, and put in place an approval mechanism so that no new projects (including client onboarding) would be started without the approval of a Portfolio Board.
  • We developed a monitoring approach to enable the Portfolio Management Office (PfMO) to detect situations where a project Change Request may be required. A discussion between the PM and the PfMO would be prompted by the triggering of either of two indicators:
    • Finances: Actuals to Date and Estimates At Completion (EAC) were monitored against approved Budgets At Completion (BAC), with indicators to show when EAC exceeded BAC by more than a tolerance amount (expressed in both absolute and relative terms).
    • Schedule:Key project milestones were monitored, with indicators to show if these were forecast to be late against the baselined dates.
  • We measured changes from baseline on both a cumulative and incremental basis, to prevent large changes being concealed as a series of small changes.
  • We escalated the authorisation of Project Change Requests to an organisational level dependent on the size of the change (in terms of costs, time, and business value)
  • We devised templates to support PMs in requesting changes and determining the approval level required, and monitored numbers of approved and rejected changes (to identify “noisy” projects).

As a result, project changes were reviewed and approved at an appropriate organisational level, the highest of which included a full review of the change impact on the rest of the portfolio. In the space of a year, this (along with other initiatives) moved the Client project portfolio from a situation in which all Client projects missed either time or budget constraints (and around 15% missed both!) to a situation in which just 20% of Client projects missed time or budget constraints, and none missed both.

Even if you are cynical and take the view that implementing such a Change Request process merely sanctions the breaking of initial Time and Cost constraints, then at the very least it ensures this is done with eyes open and in the full knowledge of the impact on the project portfolio as a whole.

This approach effectively reduces the execution risk to the portfolio, and enables the Portfolio Board to consciously decide where to focus the organisation’s limited resources.