Useful PMO? First, know yourself!

Last week I had the chance to talk to a global organisation about potential improvements to their PMO practices. I had a few pieces of background:

• they are not satisfied with the quality of current PMO outputs;
• they are going through rapid growth;
• they are undertaking an ERP-enabled business transformation programme;
• they are trying to embed Agile ways of working.

Aside from that, I had little idea what specific help they were looking for or would value as useful. I had been re-reading Sun-Tsu and the thought flashed into my mind:

• "Know the enemy, know yourself, and victory is never in doubt, not in 100 battles.
• He who knows self but not the enemy will suffer one defeat for every victory.
• He who knows neither self nor enemy will fail in every battle."

Obviously a potential client is not an enemy, but the principle holds. If you're not sure what the other party wants, and have no way of knowing in advance, you can at least prepare your "knowledge of self" and give yourself a 50:50 chance.? Since I didn’t want to look silly by focusing my preparation on one aspect and being blindsided when their priority turned out to be another, I sketched down some thoughts on several different perspectives or “lenses”, any or all of which could be useful ways of looking at what a PMO might need to do for this organisation. I obviously can’t share client specifics, but I thought it could be useful to share the lenses themselves here.

1. Customer Service lens
2. Service Catalogue lens
3. ERP Transformation lens
4. Target Operating Model lens
5. Lean-Agile lens
6. PMO-centric lenses

1. Customer Service lens

What do our customers think of our existing PMO “products and services”? We can ask them to rate defined aspects. Or we can ask more open-ended questions like the keep/stop/start trio: what are we doing that we should keep on doing? What are we doing today that we should stop doing? What are we NOT doing today that we should start doing?

[A tip from my old Customer Service days: you can, within reason, score higher satisfaction by fixing a customer problem effectively, than you score if they never had a problem in the first place. It speaks to the provider's ability to listen, to care and to fix competently.]

Advantage: we're talking about real, existing products & services;

Disadvantage: we are limited to only those products & services that already exist.

2.??Service Catalogue lens

A lot of work has been done in the PMO field over the past 10 years and among other very useful outputs there is now an off-the-shelf PMO Service Catalogue and related PMO Competency framework. So, another thing we can do is validate what the PMO should be doing by referring to the catalogue of potential services – which of them chime with our customers’ needs? What are their priorities (think “Now”, “Next” and “Later”) and what kind of development roadmap do we in the PMO need to deliver on them incrementally? The catalogue & framework provide generic materials that will accelerate our bespoke delivery.

Advantage: the off-the-shelf publications cover a lot of ground, giving us accelerators for dozens of possible PMO services;

Disadvantage: a naive customer might say "I want it ALL and I want it NOW"; a naive PMO might underestimate the work of developing, introducing & staffing new services.

3.??ERP transformation lens

An organisation facing into its first ERP transformation has little idea of what’s about to hit it. The PMO can help folk get ready by proactively turning the chosen ERP methodology into more consumable playbooks and other services. The PMO is also ideally placed to turn ERP lessons learned into advice and support. Architecture principles, Data Management, Integration with retained legacy tech and Organisation Change Management are among the top “gotchas” or lessons learned – often very painfully – from transformational programmes.

Advantage: we can sieze the chance to learn from others' past mistakes, rather than insist on painfully learning from our own, inevitably similar future experiences;

Disadvantage: while the SAP method is publicly available, other ERP playbooks seem to be proprietary to System Integrators. And they all downplay the non-ERP elements, especially integration & OCM.

4.??????Target Operating Model lens

The Target Operating Model or Future Business Capabilities model is a great asset for a transforming organisation or a rapidly growing organisation. The PMO can help by allying with Enterprise Architects and Business Analysts to ensure three key things happen:

1. PMO plan-based reporting can speak directly to what TOM capability is being delivered when;
2. PMO RAID management can focus in on what dependencies are driving the TOM capabilities and what risks or issues are threatening them;
3. Make sure the TOM includes the target “Change The Business” [project & change delivery] capabilities and not “just” the target “Run The Business” [operational] capabilities.

Advantage: if there is an accepted, understood TOM, the mapping of business units to business capabilities to end-to-end processes and their underpinning technologies is a kind of "Rosetta Stone" for translating scope, risk or contingencies for various audiences.

Disadvantage: there isn't always a TOM - nor is the TOM always accepted or understood.

5.??????Lean-Agile lens

Agile transformation is business transformation – this shouldn’t surprise folk, but it does. Making “Agile” a reality can be rewarding, but it is not always easy. Especially where different teams have different understanding and/or acceptance of what exactly “Agile” means for them! A useful PMO will leverage its cross-cutting relationships to become a source of Agile standards and a provider of Agile support, putting itself in a position to explain the “why?” and “how”. At our best, we do this as true Servant Leaders, acting as an ally to the delivery teams, scrum masters and product owners as well as to affected project sponsors and business SMEs. Usually, all of these people will know their individual parts of the puzzle better than we do - but few of them will have our cross-cutting remit to bring things together coherently at a delivery & reporting level.

Advantage: not only can the PMO support Agile Delivery, but we can "eat our own dogfood" and adopt Agile practices within the PMO itself too;

Disadvantage: the Lean part of our Lean-Agile remit is going to include getting out of the way. Self-organising delivery teams don't want or need all the old PMO services. That can feel like painful rejection.

6.??????Miscellaneous PMO lenses

This last item covers several different lenses, but as they are fairly well known to PMO practitioners and closely related, I bundled them together in my own preparation. Another time I might look at them separately, especially if I needed to share them with less PMO-centric people.

• From the Axelos P3O model, we can consider the four PMO contexts: the temporary Project Office; the temporary Programme Office; the permanent Portfolio Office; the permanent PMO Centre of Excellence. Which context(s) need attention?
• From the House of PMO competency framework, we can look at the four PMO competency domains: P3M Administration; P3M Support; PMO Management; P3M Enabling. Which domain(s) are priorities for action?
• From CMMI (or P3M3), we can look at the five process maturity levels: L1 Initial; L2 Managed; L3 Defined; L4 Quantitatively Managed; L5 Optimised. What level is "good enough" for which processes? Where do we have painful maturity gaps?

Advantage: these concepts can bring helpful theoretical clarity to a working landscape that in practice is bound to be something of a mish-mash of hybrid roles, partial remits and mixed maturities.

Disadvantage: the concepts may be too inward-looking for our customers & partners - they will see their issues in their own way, and how we translate that into contexts and domains is often frankly uninteresting for them.