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.

Project reporting shouldn’t be “green side up”

Following on from my post on watermelon reporting, I wanted to share another, related, phenomenon with you – “green side up” reporting. This describes the phenomenon where the health of programmes and portfolios is reported more favourably the higher up the organisation the reports are circulated; that is to say that in the project world everything looks green when viewed from above.

As with watermelon reporting, it’s not my expression but I can’t remember where I heard it.

So what are the factors that might lead to this progressive greening of status?

  • Programme Managers want to be perceived as being in control of their programmes, so although the programme may contain one or two amber or even red projects, they want to avoid the unwelcome attention of the CxOs, and so they report the programme as green overall;
  • The amber or red status of one project is diluted by the green status of other projects in the programme: if a programme comprises say ten projects, how many of these need to be amber or red before the programme overall is considered amber or red?
  • As with watermelon reporting, the problem probably really should have been reported (perhaps as amber) some time ago, and to report it as red now would expose that it wasn’t as amber reported before;
  • Also as with watermelon reporting, there’s still an opportunity to turn it around before the next report and due and then no-one will need to know anything was ever red, will they?

Leaving aside factors shared with watermelon reporting, which I have covered in a separate post, Green Side Up reporting is a Bad Idea because:

  • The organisation’s executives (CxOs) will think that everything is always green (in the same way that VIPs and Royals think that the whole world smells of fresh paint all the time!). This could mean that CxOs only become aware of problems when it is already too late to do anything about them;
  • The organisation’s executives (CxOs) will not believe the reports they are receiving.

So what are the alternatives? Here are a few possibilities:

  • The RAG status of programmes could be calculated based on some sort of average of the contents (the calculation of which only the PMO will understand, and which in any case will result in all programmes and projects being amber all the time instead of green or red, which doesn’t really help the CxOs);
  • The status of programmes and portfolios could be reported in the form of a “RAG pie”, with slices showing the proportions of red, amber and green (more accurate, but not exactly simple!);

    Pie chart showing the percentage of projects that are Red, Amber and Green
    Pie chart showing the percentage of projects that are Red, Amber and Green
  • The health status of programmes and portfolios could still be based on the assessment of the programme managers (because they are paid to manage programme-level problems), but the Portfolio PMO could add an exception reporting mechanism that exposes any red projects and provides more detail on these separately so that the CxOs can dig into this if need be.

I think the last one is probably the most practical and pragmatic. What do you think? Have you seen Green Side Up reporting? How is the health of your programmes related to the health of their constituent projects? Do you have any options to add to my list? How do your CxOs stay informed about the real health of their programmes? Let me know in the comments.

Watch out for watermelons in project reports

How do watermelons get into project reports? and why should you watch out for them?

Watch out for watermelons in project reports

“Watermelon reporting” describes the phenomenon where according to a project status report things appear to be green on the outside (i.e. the project’s RAG status is reported as green, with no issues), but if you delve a little deeper and look inside, it’s actually red right through (i.e. there are serious issues). I can’t take the credit for coining this expression but I can’t remember where I heard it either [14Jul 16 update – I’ve found a 2011 article on DZone, so it would seem that the credit for coining the phrase is due to Marc Loffler – kudos to him!].

So what are the factors that might lead a PM to report a project as green when it’s really red?

  • It’s embarrassing for a PM to admit that “their” project is not going as well as it could/should be;
  • It increases the risk that the project will be cancelled (and we all know what happens to a PM whose projects get cancelled…);
  • The problem really should have been reported (perhaps as amber) some time ago, and to report it as red now would expose that it wasn’t reported amber before;
  • There’s still an opportunity to turn it around before the next report is due and then no-one will need to know it was ever red, will they?
  • “We don’t have red projects in this organisation” (oh yes you do!)

Looking at these reasons, you can see that most of them come from the assumption that red is a Bad Thing, and that this is the PM’s Fault – i.e. the organisation has a “blame” culture. Unfortunately, concealing red status inside a green status report is seldom a good idea, for the following reasons:

  • The sooner a problem is identified, the cheaper it is to rectify;
  • The sooner the PM escalates problems to the Sponsor, the more likely it is that the Sponsor will hear about it from the PM (rather than from another senior stakeholder with an axe to grind, for example!);
  • The sooner the Sponsor hears about the problem, the more time they have to perhaps mobilise resources to help, pave the way for a resolution, or manage the message;
  • The consequences of the concealment being discovered get worse the longer the concealment persists (and this is more a case of when rather than if, a bit like when children lie to their parents)
  • If the project really is red enough to be cancelled, then doing this would be in the interests of the organisation, and no PM will win friends by keeping a bad project going longer than it should be.

Of course the PM should not be flagging every little issue and running to the sponsor every half hour (they are paid to sort most things out) but they should be flagging the project as red when any of the constraints (i.e. budget, schedule, quality, benefits) are seriously threatened, and feeling no shame in doing so.

Red should not be seen as an indicator that there is (or should be!) blood on the corporate carpet; instead red should be seen as the colour of the distress flare that the PM is effectively launching to alert stakeholders to the fact that there is trouble, and some tough decisions may need to be taken.

As a PMO, wherever I see watermelon reporting, I encourage the PM to be brave and honest enough to ask for help. Have you seen watermelon reporting? Do your project managers “keep calm and report it as green”? If so, how have you dealt with it? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of stuff, why not talk to us about taking care of it all for you on your next big project or programme?

Project data in, portfolio insight out

How do you give senior management a “helicopter view” of all the change that is going on in an organisation, so that they can make informed decisions on how to spend their change budget? Here’s how I tackled it…

Data in insight out

What I found…

I came to a new Portfolio Management Office (PfMO) in which status was being reported in various formats. Reports were consolidated but this was based on low-value-add copying and pasting of information into lengthy reports. Pretty much every project proposal was being approved, with no view of the organisation’s capacity to implement them. This resulted in projects getting in each other’s way, competing for resources and overloading Subject Matter Experts (SMEs*).

The Goal

The COO tasked me with developing an integrated view of the portfolio to enable sensible prioritisation decisions to be made, and with developing a resource view looking up to one year ahead.

There was neither the appetite nor the budget to invest in a software tool, so the solution needed to be home-grown.

What I did

Standardise and integrate

I ensured that project data was being collected in a standardised way to enable automated collation into a portfolio view by developing an integrated “Project Status Workbook”. This is effectively a multi-page spreadsheet combining RAG Status reports, Risk, Issue, Dependency and Change Registers into a single recording and reporting document for each project, with a stakeholder dashboard showing key pieces of information in a simple graphical format.

Then I developed a consolidating spreadsheet, using VBA macros to collate project data in various categories.

Analyse and interpret

I analysed the data to provide management information to the Portfolio Board (e.g. % of Projects Red/Amber/Green; % of projects Delivered on Time/to Budget; Portfolio focus on Run/Grow the Business, etc.).

I charted trends to provide insight into project management effectiveness.

I introduced simple Demand Management, using a simple spreadsheet to compare resource demand (from active and proposed projects, on a FTEs per month basis) with planned supply in various categories (PMs, BAs, Developers, BAU SMEs, etc.) to enable the Portfolio Board (C-Level executives) to assess the viability of the planned project portfolio within the prevailing (tight!) resource constraints.

Whenever a new project request was received, I added in the forecast resource demand to show the effect on the “deliverability” of the portfolio as a whole.

I used a derivative of this approach when carrying out the annual financial planning exercise. This started with the annual portfolio budget figure, and showed how the projects (prioritised by the portfolio board using a weighted scoring approach covering factors such as complexity, benefits, risk, strategic alignment, etc.) chip away at the portfolio budget until it runs out at “The Cut”, beyond which lower priority projects would need to be put on hold, delayed, rejected or stopped.

I overlaid the resource view onto the financial view to see how the scheduling of the chosen projects affected the resource demand.

…and the result?

The Project Portfolio Board received a concise, consistent and informative view of Portfolio Status, and were able to consider project proposals against the context of the organisation’s capacity to implement them. Projects were better prioritised and scheduled so that difficulties related to resource bottlenecks were reduced.

So that’s my approach to generating portfolio insights, learned through the experience of getting it wrong and coming up with a better way. It this approach useful to you? Let me know in the comments.

If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you?


*I use the term SMEs to mean people from the operational business who are subject matter experts in the processes or business areas that are to be changed. They do not necessarily contribute to the change itself or form part of the core project team, but their contribution is invaluable in shaping the changes that are made and how they are to be made.

How to take charge of your project portfolio’s annual budget

Project and Programme Managers (PMs) are used to managing projects within a budget for the project stage or the whole project, but they sometimes overlook the context of the organisational annual budget; this is especially important if the project spans multiple financial years.

How to take charge of your project portfolio's annual budget

Project funding approval for a whole project or project stage can be thought of as the Portfolio Board deciding that the project’s Business Case is viable, and that the project should go ahead.

This approval can be given once for the whole project (usually if the project is relatively small, short in duration, low in complexity and risk), or gatewise at the beginning of each stage (usually if the project is relatively large, long in duration, high in complexity and risk). This approval can also be separate and distinct from the financial year budgeting process (figure 1).

Figure 1: Financial year vs. project budgeting
Figure 1: Financial year vs. project budgeting

Inclusion of project funding in the financial year budget can be thought of as (usually) the Finance department deciding that the organisation can afford to spend £x on projects as a whole, with the projects making up the budget being selected based on some prioritisation rationale.

So a project managers’ forecasted project costs need to stay not only within the budget for the project (current stage and overall), but also the financial year budget (this is especially important if the project covers more than one financial year).

So how to apply this to portfolios? I was brought into a PMO facing an annual project budget considerably smaller than the previous year’s, with no way to forecast whether the proposed portfolio could be delivered within budget. The organisation had also mandated moving labour spend from Consultants, via Staff Augmentation (comprising flexible resources and independent Contractors), to permanent Internal staff. This is how I approached it:

  1. I devised a standardised way of classifying labour costs to enable comparison across projects (projects had previously been accounting for labour costs in a variety of ways).
  2. I introduced an approach requiring PMs to validate their remaining project cost forecasts every reporting cycle when updating actual costs.
  3. I created an automated report to extract financial data from the project portfolio system and present a monthly breakdown of costs over the financial year (with actuals in the past and forecasts in the future). Labour was broken down further (Consultancy / Staff Augmentation / Internal) to reveal trends (figure 2).
Figure 2: Breakdown of monthly costs by standard cost category
Figure 2: Breakdown of monthly costs by standard cost category

Thus, stakeholders could see every month whether the portfolio was on track to deliver within the financial year budget and track the movement of labour from high towards lower cost labour sources as mandated.

After a few months monitoring, I noticed that there was a “bow wave” phenomenon, with projects seeming to “push” cost forecasts in front of the current month (figure 3). I suspected this was because the projects were forecasting to use up the remainder of the funds allocated to them, so I challenged the PMs to ensure that the forecast to the end of the year represents the forecast cost of the work remaining.

Figure 3: Project cost forecast "bow wave"
Figure 3: Project cost forecast “bow wave”

 

After some revisions to the forecasts, and delays to a number of projects (some deliberate, and some arising from outside the organisation), the outcome was that all the projects in the portfolio could be delivered well within the new lower budget, with a surplus being returned to the organisation.

Does your organisation monitor against annual financial budgets as well as end-to-end or gatewise project budgets? How does your PMO ensure that projects stay within all of these? Let me know in the comments.