Surviving PMO Success — The Process Maturity Trap

One of the unexpected challenges in our PMO journey has been that success can make an enterprise-level PMO appear less relevant.  A PMO must transform its approach to stakeholders or it won’t take full advantage of the improvements it fostered.  One manifestation of the problem unfolds thusly:

1. An enterprise PMO composed of PM thought leaders executes a PM improvement program that delivers methodology, training, tools, and change management initiatives to its stakeholders (e.g., regional, local, unit PMOs).
2. Those stakeholders [largely] adopt those initiatives and transform their project operations in significant and measurable ways.
3. This transformation creates a new set of PM thought leaders, who often surpass the knowledge and hands-on experience of the original enterprise PMO.

The business problem has reversed; the enterprise PMO now becomes the organization that needs to change to reflect the new reality.  Deliverables that were relevant in moving from low maturity processes no longer work with a more sophisticated audience.  This issue is compounded by the difficulty in recognizing the changed environment.  Who wants to admit that he/she is no longer automatically at the vanguard of knowledge? 

In other words, the challenge for a successful enterprise PMO is: “Who will change the change agents?”

Making sure that your deliverables’ benefits are realized

With all my recent scope management posts lately, here’s a timely post on benefits realization (here) at John Gough’s iJourneys blog (here).  I like the theme of his post, that “…benefit realisation does not start when the project ends.”   I also second his point that IT sees itself as apart from the “business” and often has a leadership void at the top.  John puts it plainly:

Get Out of the Comfort Zone — There is a view…that the IT project manager delivers the project (i.e. the delivery of outcomes) but the business is responsible for building capability and realising benefits.  CIOs complain that they are too often sidelined by the business, but they do not always have the balls to … declare that: “we have taken the project this far, now give us responsibility for the business change”.

I’m not very comfortable, however, with his suggestion to:

Ditch the Business Case — The Business Case is designed to justify the project, but too often towards the end of the project, the dusty document is retrieved to “see what the benefits were”. The benefits are the project, and should guide the process from beginning to end, whereas the Business Case is just a means to an end.

My experience is that ditching the business case is what happens too often.  It should inform deliverable definition, the expected outcomes of those deliverables, the relative priority of proposed scope changes, and the benefits expected from the outcomes.  Instead, projects deliver ”whatever,” the outcomes and benefits aren’t what were expected, and IT wonders why IT is “sidelined” by the business. 

Hat tip: Elizabeth at Girl’s Guide to Project Management (here)