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?

The Agile PMO – Leading the Effective, Value Driven, Project Management Office (Book Review)

by Michael Nir
Self-published by the Author as a Kindle eBook on Amazon.com, 46 pages (estimated, 10,400 words), £2.65 RRP (review copy supplied free of charge)
PragmaticPMO Rating:  ****

This book leads with a single central principle – that a PMO’s sole reason for existence is the creation of value for the organisation, and that the single most effective way it can do that is by managing the allocation of resources to projects. Of course, tools, methodology and processes are all good things to have, but identifying how to deploy resources for the best return on that investment is where a PMO really comes into its own.

I initially found such a forceful statement a little hard to swallow, but the book shows (using example scenarios drawn from the author’s consulting experience) several ways how the PMO can fail if it chooses to focus its efforts in other directions.

If a PMO fails to establish the necessary authority and credibility with the Project Manager (PM) community at a sufficiently early stage, it becomes relegated to performing only supportive, administrative work. This is so time-consuming that there is no time to develop more useful services, value delivery is limited and the PMO will be cut as soon as funding decreases.

If a PMO focuses on methodology, the PMs may superficially complete templates and processes just to keep the PMO quiet, but the completed templates and processes may bear little relation to reality. Unless the methodology is focused tightly on improving project delivery, this type of PMO merely increases administrative burden on PMs without enhancing value. Again, the PMO will be cut as soon as funding decreases.

PMOs that function mainly as a home for PMs do little to create value (other than managing the PMs as resources). Despite this it can persist for a long time as business value is not even considered, and the PMO duties are usually carried out by fairly junior (cheap) people.

PMOs that try to implement everything (resource management, methodology, templates, etc.) at once can appear to PMs as dictatorial rather than collaborative. This results in resistance to change and ultimately wasted effort in a failed implementation.

PMOs that focus on software tools before methodology, processes and templates spend a lot of time and effort customising the tool to accommodate the variety of approaches in the organisation. This is a very labour-intensive and expensive activity!

PMOs that implement an unsuitable methodology risk creating unnecessary barriers to implementation that slow down project delivery and upset customers.

So then, having covered several interesting (and familiar!) ways in which the PMO can fail, how is it to succeed? By treating the implementation of a PMO as a Change process, it is possible to increase the likelihood of success. Steps include: creating a sense of urgency; Creating a coalition of supportive stakeholders and engaging them to avoid surprises; Creating a vision with SMART short and long term objectives to instil pride; Communicating the vision regularly and consistently to instil trust; Empowering people to contribute and help to remove obstacles; Generating quick wins to gain support; and Embedding the changes in organisational culture.

Doing all this while focussing effort and new initiatives on the areas that will deliver the most benefit to the organisation soonest (and it helps if these also have influential and vocal stakeholders!) brings the best results.

The value created can be measured in terms of increasing the number of projects being delivered in a given time (since completed projects create value). As the availability of resources (people and/or money) is usually the single largest barrier to delivering more projects, increasing project delivery is often best achieved by creating a view of project and resource status to enable the most effective utilisation of resources across the project portfolio.

This is not a heavyweight book – you can read it from cover to virtual cover in about half an hour. Although it doesn’t go into detail describing the ideal approach (which in any case would differ in the detail from organisation to organisation), for me just as much of the real value in this book comes from the examples of what not to do and how that leads to failure.

Well worth the purchase price!

Benefits Realisation Management (Book Review)

– A Practical Guide to Achieving Benefits Through Change, by Gerald Bradley, Gower Publishing Ltd (Farnham, Surrey) 2010
ISBN 978-1-4094-0094-3, 352 pages, RRP £80 (review copy supplied free of charge by the publishers)
PragmaticPMO Rating:       ****

This well-written book starts by explaining the fundamentals of Benefits Realisation Management (BRM). It debunks popular myths, and explains why adherence to outdated beliefs can prevent organisations realising all of the benefits that could arise from change. However most of this “practical guide” is devoted to applying BRM to various situations.

First it covers how to apply BRM to projects and programmes (as early in the cycle as you can), then extends this to portfolios (projects or programmes applying BRM well are far more likely to deliver their business case benefits), and closes with implementing BRM across an entire organisation (run it as a programme and apply BRM to it to demonstrate the benefits). The text is peppered with real examples from the author’s extensive experience, and the liberal use of colour diagrams helps to cement understanding.

The book explains how best to apply BRM now if you are part way through the project/programme lifecycle, and also highlights the most important aspects to apply if you have limited time or resources (although this will not generate full returns).

It even has a section that summarises the entire book “in a nutshell” so that you can quickly find a summary of the principle you need and refer to the more detailed section of the book if necessary.

At an RRP of £80 this book is not cheap, but it has 300-odd pages of wisdom and insights to impart, some of which I have listed below to give you a flavour of what to expect.

Approach
  • Most current organisational change focusses on acquiring and implementing enabling technology (solutions looking for problems), without any subsequent steps to embed its use (business change).
  • Benefits are often derived to justify implementing some attractive capability. But benefits should be the reason sponsors commission projects. So begin with the end in mind. Don’t just implement capability; plan to use it to create value.
  • Starting with benefits increases sponsor buy-in and accountability, as the project flows from the sponsor to the implementation.
Stakeholders
  • Stakeholder = anyone who could screw things up!
  • Stakeholders deliver benefits by changing their behaviours to use new capability, so work with them.
Benefits realisation
  • Sometimes organisations “realise” benefits by removing benefit amounts from future budgets. However this can leave the organisation worse off (e.g. reducing headcount without improving efficiency)
  • The Project Sponsor is accountable for benefits, but realisation of each benefit should be “owned” by an operational manager. This person  will be highly motivated if they are also the beneficiary.
Projects and Programmes
  • Projects are usually defined in terms of delivering enablers. The business case benefits are often forgotten once the project is up and running.
  • To focus on benefits rather than enablers, name the project or programme after the outcome to be achieved (e.g. Crime Reduction, Customer Satisfaction), rather than the enabling deliverable (e.g. CCTV network, Ordering System).
BRM-Specific Roles & Responsibilities
  • Benefits Facilitator – Educates, challenges and guides projects and programmes on BRM. Ideally independent from projects and programmes, and business- rather than IT- or PM-aligned. Exists before the project (contributes to the business case), and afterwards (oversees benefit tracking). A role for the Enterprise PMO (EPMO)?
Planning for Success
  • “Proper” BRM costs about 5% of total project costs, but has a VERY high ROI.
  • BRM practitioners are scarce, so use them where they will have maximum impact and return.
Application of BRM to Projects and Programmes
  • Mapping benefit/dis-benefit distribution across stakeholder groups can identify gaps and disparities. If no-one will own a benefit, is it real?
  • Categorising benefits by type (Definite, Expected, Logical, Financial, non-financial) and by change type (starting new things, stopping old things, doing old things better) can identify duplication, and help with consolidation.
Measurement
  • It is tempting to value each benefit financially, to derive an NPV for the entire benefit set. Whilst possible, this can conceal assumptions (redundancies will result from higher productivity), and may produce double counting.
  • Measurement illustrates whether BRM is on track. “What you measure is what you get”, so choose KPIs carefully to encourage desired behaviours.
  • Set targets if the outcome is well defined, otherwise just track the measure and note the trend, with a view to informing future initiatives.
  • Start measurement (to provide baseline data) immediately the measure is agreed, or as soon as measurement is possible (to track trends).
Benefit dependencies
  • Holding workshops to generate benefits dependency maps scored with weighted paths helps to determine the order in which changes should be carried out, increases stakeholder buy-in to the changes, and gives a framework for realisation tracking.
  • Tracing benefits backwards to their enablers facilitates the creation of draft project briefs. If these changes are not already in progress, they can be costed and prioritised.
Structuring Change Delivery
  • Even if PMs only deliver enablers and outputs, they should keep an eye on benefits and the business case throughout the whole of delivery.
  • If programmes close on the completion of significant change activity, benefit tracking may suffer unless this is handed over to a function such as the EPMO.
Governance
  • Projects and programmes should be independently reviewed regularly to ensure the benefits are still viable. The project should only continue to completion if it is demonstrably worthwhile.
Relationship with Project, Programme and Portfolio Management
  • Benefits should be at the heart of PgM and PjM. For example, the Risks and Issues log should primarily contain risks to the realisation of benefits; Stakeholder engagement should focus on gaining benefit owners’ commitment to the realisation of benefits.
  • BRM can be used to maximise the benefits arising from change portfolios, and to assess the fit of proposed new Projects and Programmes with those already running.

How to keep your programme schedule on the right track

Having created a project or programme schedule, how do you use it as a delivery tool? Here’s the approach I have used successfully on several recent programmes.

How to keep your programme schedule on the right track

Background

During the final delivery stage of a multi-year relocation and Change Management project, with a few weeks to go before moving ~800 people and their equipment between sites, I was managing the integrated programme schedule to confirm we were in a position to move on the planned dates (or not!).

The Steering Committee (SteerCo) and Internal Audit wanted reassurance (via a series of pre-move readiness meetings) that we would be able to move on the planned dates, to know that the Business and Stakeholders would be happy to move on those dates; and for the programme to take any appropriate action to enable this to happen.

Prepare

To enable this, I created a suite of intermediate “collector” milestones on the programme schedule:

  • “People ready” to move (reflecting the completion of Change Management activity, both “Must have” and “Should have”)
  • “Systems & Building ready” to receive the People (both “Must have” and “Should have”)

I worked on the basis that in order to be in the “Must have” category, the absence of the deliverable had to be big enough to stop the move; otherwise it wasn’t really a “must have” but a “should have”. I made these intermediate milestones immediate predecessors of the first move (with any slack available between these and the first move date being explicitly shown as schedule contingency).  I obtained current information on forecasts and actual start/finish dates through weekly Workstream Lead (WSL) reports and regular 1:1 schedule review sessions, and updated the schedule with this information.

Monitor

I monitored the plan (and especially the critical path leading up to the first move) for the effect on the final deliverables of any updates. Each time I updated the plan with new information, I checked to confirm we were still on track to deliver the final deliverables on the planned dates, adjusting the contingency buffer if necessary.

In this way I spotted anomalies – for example, having updated the schedule with revised dates from weekly WSL reports, I noticed final delivery milestone had moved 2 weeks later than planned. Each WSL’s detail plan appeared to be on track in isolation, but taken as a whole programme (taking dependencies into account) the final deliverables were late.

Detect

My typical approach to finding the cause of an anomaly such as this is to trace the predecessors of the slipped deliverable, working backwards in time to find where the delay is ultimately coming from (usually this is from missing or outdated inter-workstream or inter-project dependencies, raising the need for greater detail or revised dependencies).

In the case of the example, I isolated the problem to the start of a technology Pilot, which in turn was dependent on an IT system becoming available following Technical Testing and User Acceptance Testing (UAT).

Re-plan, Recommend, Resolve

I then analyse the situation and propose some remedial options, in the case of the example these included:

  • Removing the IT system from the Pilot scope (introducing a quality risk)
  • Shortening the duration of the Tech testing before the UAT and Pilot (also introducing a quality risk)
  • Combining the Pilot with UAT by selecting UAT users for the Pilot, killing two birds with one stone (recommended approach)

The programme team opted to implement the combined UAT / Pilot approach I recommended, bringing the programme back onto schedule. The approach for Change Requests is similar:

  • Create a new version of the schedule (or insert new activities in such a way that they don’t affect the “real”, working schedule) to use as a “what-if?”schedule.
  • Make the changes as detailed in the Change Request, making or breaking dependencies as appropriate.
  • Assess the impact on the delivery dates, resource utilisation, financial forecasts, and make a recommendation to the programme director and ultimately the SteerCo to accept or reject the Change Request.

Result

As a result of using this approach:

  • The programme was kept on schedule, to deliver on time;
  • SteerCo and Internal Audit were reassured that the run-up to moving was in hand, as they were kept up to date on an ever-diminishing list of pre-move “must have” deliverables;
  • The Go/NoGo decision on moving was taken in the full knowledge that: all “must have” deliverables would be in place on day 1; most “should have” items would be in place on day 1, and the missing “should have” items would become available on specific dates post-move.

In this way, the schedule was transformed from a collection of dates and coloured sticky notes on the wall into a dynamic tool with which to proactively manage programme delivery.

So that’s my approach to keeping a programme schedule on track, learned through training and experience. It this approach useful to you? How do you keep your programme schedules on track?

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 on your next big project or programme?

How to create a useful programme schedule

How do you integrate the schedules of multiple projects into a single programme schedule that concisely conveys time-related information? This is the approach I have successfully used for several programmes.

How to create a useful programme schedule

I was brought into a programme which had only rudimentary programme spreadsheet-based plans, and which was therefore unable to forecast how delays in one part of the programme would affect other parts of the programme, or to assess the potential impact of change requests. Senior stakeholders needed a programme “road map” (to assess overall progress towards delivery deadlines, and to obtain some guideline forecasts for the annual budgeting cycle), and the programme director needed a detailed view of the activities leading up to delivery.

Purpose of the schedule

A programme schedule should not just be a pictorial representation of what we think will happen, or a rigid list of events to which the programme should slavishly adhere. Instead I believe it can and should be a flexible model of the programme’s activities that can forecast potential problems, be adapted to overcome those problems, and be used to enable on-time delivery.

Approach

Where they already existed, I used task lists and brainstorming session outputs as a starting point. I developed these by meeting with project managers (PMs) and workstream leads (WSLs), capturing their thoughts on the key activities of their projects directly into Microsoft® Project® (MS-Project), challenging duration estimates and dependency relationships as we worked. I refined the resultant draft schedules using stakeholder input before getting them agreed by all parties and baselining them.

Where there were no plans at all, I either held planning sessions or translated process flow diagrams prepared by Business Analysts into MS-Project plans, cross-linking these with dependences into an integrated and resourced programme schedule, with the critical path identified and highlighted.

I also worked with contributing PMs / WSLs to standardise elements of their plans (e.g. use of custom MS-Project fields) for easier integration into a programme schedule.

From this programme schedule, I prepared resource and financial plans for budgeting as required, custom filtered views (missed milestones, items due to start or finish in the next four weeks, etc.) for progress tracking, and highly summarised “road maps” for senior stakeholders.

I kept the schedule updated with progress and with the outcomes of approved Change Requests; I regularly reviewed forecasts against the schedule baseline to identify potential slippage; and prepared “what-if” plans showing the impact of proposed changes.

Result

In this way, the schedule was transformed from a collection of dates and coloured sticky notes on the wall into into a dynamic tool with which to proactively manage programme delivery.

Under this approach, the Programme Manager has a good forward view of the critical path to delivery (and the potential pitfalls along the way) and the Programme Board has a good overview of progress achieved so far, and the activities still to come.

But what about when things change? What do you do then? More about that in a separate post.

So that’s my approach to creating a useful programme schedule, learned through training and experience. It this approach useful to you? How do you keep your programme schedules on track?

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 on your next big project or programme?

® Microsoft and Project are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

 

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?

Processes are an organisation’s memory

Further to my post on Lessons Learned from project delivery, I’m going to take a calculated risk by standing up for the pragmatic application of process. Yes, that’s right, process.

Processes are an organisations memory

Now, people seem to enjoy a bit of process-bashing, and I get that: nobody wants to have their working lives organised for them to the point where they become a soul-less, heartless, brainless robot, but I am proposing the idea that processes are an organisation’s memory.

Let me illustrate this with a well-known story – the Fable of the Five Monkeys. If you don’t know this story, Eddie Obeng tells it beautifully in this very short (2½ minutes!) video.

Here is the story in a nutshell:

  • Five monkeys were kept in a cage with some bananas at the top of a ladder. Whenever one of the monkeys climbed the ladder to get a banana, all the monkeys were hosed down with cold water. Soon, the monkeys began to beat each other up to stop any other monkeys from climbing the ladder and getting them all hosed.
  • Eventually, the threat of cold water was removed, but the monkeys didn’t realise that and still stopped each other from getting bananas anyway.
  • Then, one monkey was replaced with a new monkey. This monkey didn’t know about the cold water, so when he tried to get a banana, the other monkeys beat him up to stop him.
  • One by one all the monkeys in the group were replaced, and all of them would stop each other from trying to get the bananas, even though none of the original monkeys were there, none of them had been sprayed with water and in any case the cold water had been turned off.
  • Effectively a culture had been created within which you get beaten up if you try to get a banana, but none of the monkeys understood why.

The meaning of this story is that to begin with, an organisation adopts a particular course of action – let’s call it The Process (e.g. ignoring the tempting bananas) for Sensible and Compelling Reasons – the result of lessons learned from a project perhaps (if you go for the bananas, you get hosed).

The organisation encourages everyone to use The Process (and beats them up if they don’t). However after a while, people change and no-one remembers what the Sensible Reasons for implementing The Process were, and all you have left is a secondary, cultural reason – because “we have always done it that way” (if we don’t use The Process, we get beaten up).

This situation has the following possible outcomes, each with their pros and cons:

  • The organisation carries on using The Process because “we have always done it that way”.
    • Pro – It may still be perfectly sensible to use The Process because the original Reasons for implementing it still apply (the person with the hose is still there, or the bananas were always poisonous). However,
    • Con – It may no longer be sensible to use The Process because the Reasons for creating it have disappeared (the hose person has gone). Using The Process may be at best inefficient, or at worst,dangerous (ignoring the handy supply of bananas may lead to starvation).
  • Someone new to the organisation cannot understand why The Process is being used, and implements The New Process, which they think is far more sensible.
    • Pro – It may be perfectly sensible to implement The New Process if the Reason for The Original Process is no longer applicable (the hose person has gone), or The New Process by pure luck addresses the original Reason. However…
    • Con – If the Reason still applies and The New Process doesn’t address it, then the organisation is in for trouble (we’re all going to get hosed!)

So, it seems to me that there is nothing wrong with having a process embedded into organisational culture so it becomes “the way we do things round here”, provided that the people that use the process know why that process exists, and the process is reviewed periodically to ensure that it is still appropriate.

Under this approach, the monkeys in the story would know that they must not touch the bananas or they will all get hosed. They would periodically review the approach to ascertain whether the Reason for The Process is still applicable (the hose person is still there), and to change the approach if the circumstances have changed.

By now, you are probably wondering how this applies to Project Management.

Whilst it may or may not be appropriate for an organisation to codify the management of an entire project as a process (there are many popular books and courses on the market that have done that already), I think there is a case for an organisation to document and manage any special ways they have developedof doing certain project stages (Start-up, Initiation, Execution, Closure, etc.) and often-repeated aspects of project management (e.g. Risk Management, Procurement, etc.) as processes, with a documented purpose, objective, and review schedule.

That way, someone (the PMO?) is responsible for looking after, say, the risk management process, and is periodically reviewing it with a view to improving it in the light of Lessons Learned by the organisation.

An approach I have used in a Portfolio Office role to embed lessons learned with some degree of success is to pre-populate the organisational Risk Register template with issues that have cropped up in previous projects, scored initially with a medium to high probability – this prompts the Project Manager to actively assess that risk in relation to their own project, and reduce the risk likelihood or impact if it is felt that it is either not relevant, or that the risk has been mitigated.

This approach makes it easy for the Project Manager to draw on previous organisational lessons (making it very clear why they might want to do things in the recommended way), and also puts the control and responsibility in the hands of the Project Manager, who can use their own (and the team’s) experience to judge whether a particular pre-loaded risk is relevant for the project in hand.

How does your project organisation ensure that people know why they do things, and that the organisational project management approach (or process, or methodology) stays up to date and relevant? Let me know in the comments.

How to make sure that Lessons Learned stay that way

I often wonder just how much project management organisations really learn from project successes and mistakes. I think we could all definitely learn better than we currently do.

How to make sure lessons learned stay that way

I will start by saying that we should not wait until the end of the project to learn lessons (both good and bad) – these will be happening all the way throughout the project and should be logged as they happen. Completion of a Stage (including the final one at the end of the project) present a convenient time to review lessons and take action (including communicating the lessons to the wider project community), but waiting until the end of the project to even identify the lessons represents a missed opportunity for continuous improvement. Having said that, the end of the project is where projects usually consider lessons learned (if they do this at all), in the form of a post-implementation review.

In my portfolio management office (PfMO) experience I have seen post-implementation reviews come up with the same lessons again and again (e.g. build contingency into plans; take more time and care to gather requirements; don’t Go Live without full sign off / back-out plans / user training, etc.), but I have seen even more examples where post-implementation reviews weren’t carried out at all because: the project was too small / too simple; the project finished too long ago / hasn’t finished yet; I don’t have the time; the project team is now working on something else / has all left the company; nothing happens with Lessons Learned anyway; I don’t think it’s worth the effort (delete as applicable!).

I think the PMO can help with Lessons Learned, and that the problems lie not only with identifying the lessons, but also with what to do with the lessons that have been identified to embed the learning into the organisation’s experience and memory. Here are some ways that the PMO can help, to make sure the Lessons are not only learned but also acted on:

  1. The PMO can add the lessons to the corporate PM methodology.
    Done well, robust PM processes and methodologies form part of an organisation’s corporate memory, and are built making intelligent use of the lessons the organisation has learned from previous projects. They are aimed at preventing the repetition of past mistakes without unnecessarily impeding delivery. But the more you add to the methodology, the more rigid and prescriptive it becomes, and the more likely it is to either be cheerfully ignored or blindly implemented in full (and you can bet it will be ignored on the big risky projects and implemented in full on the little simple ones!). The PMO should also avoid becoming the methodology police.
  2. The PMO could collect the lessons identified in a Big Database
    …but to be useful this relies on someone (PMs? the PMO?) reviewing new projects against all the lessons in the database, and identifying relevant points to note.
  3. The PMO could add the lessons to a checklist
    …but that relies on people (PMs)using the checklist and giving some serious consideration to what the items on the checklist represent (rather than just paying lip service and ticking the box). And there will always be the temptation for PMs to come up with a good reason why a checklist item doesn’t apply to the current project…
  4. The PMO can run Lessons Learned sessions
    where the PM of a completed project presents their Lessons to the rest of the Project Management community (but this relies on an open and honest communications culture, and/or bribing the attendees with cakes), or…
  5. The PMO could pre-load the Risk Register template
    with the risk of repeating mistakes made on previous projects – the mitigation for which would be to review the Lessons Learned Big Database for things to consider (and the PMO could add value by offering this as a service).

I think the last two approaches are the best, because one encourages the development of a learning community (this is the subject of a separate post) and the other places responsibility for reviewing past lessons (or not) with Project Managers, but supports them with a PMO service.

So that’s my approach to making project lessons “stickier”, learned through experience. What do you think? How do you ensure lessons from past projects are not just identified and logged, but learned and applied to new projects? 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 on your next big project or programme?

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.