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 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.