Standing Up a PMO Where Nobody Wants One

The trigger was a dependency blind spot that escalated straight to the CEO, so the first services should be the ones that address exactly that, and nothing else.

First:

1. Cross-team dependency and risk visibility - a lightweight view of what teams have committed to each other and where the seams are, harvested from the existing issue tracker rather than through new team reporting.
2. A fast escalation path - the failure was not only detection, it was that the first escalation was to the CEO. A named route with a service-level expectation for decisions above the team level.
3. A cross-team decision log - the incompatible data models were a decision nobody owned. Recording who decided what, and when, is cheap and immediately useful.

Defer explicitly: gate reviews, a standardised delivery methodology, benefits tracking, resource allocation, stage-gate funding authority. They solve problems this company does not yet have, they are exactly what the VPs expect to hate, and with 1.5 FTE you cannot run portfolio governance and dependency management simultaneously. Choosing the one tied to the visible failure is the design decision. Write the deferral into the charter so it is a promise, not an omission.

Do not ask them to adopt anything. Start pull-based: run the dependency view for one quarter and put it in front of them before they ask for it, at a level of detail they can act on - "these three integrations collide in week six" rather than a portfolio heat map.

Take work off their plate rather than adding it. Find the cross-team status update their leads currently assemble by hand and write it yourself for a quarter. Being useful is the only argument that beats "you will slow us down".

Never escalate over their heads without telling them first. The CEO's backing is real, but spending it in month one converts neutral into permanent opposition and you only get to spend it once.

Give them structural influence: a veto on the service catalogue at the six-month review, and a named engineering counterpart who reviews the dependency view before publication. Measure your own reliability - if the view is late or wrong twice, you have confirmed their prior and no amount of charter language recovers it.

Set the target realistically. "Tolerant" is success. Enthusiasm is not required for the service to work, and chasing it leads to over-promising scope.

Success should be behavioural and falsifiable, not a maturity level:

• The dependency view exists, is current, and at least two of the VPs use it in their own planning - evidenced by them referring to it in their forums, not by a survey.
• At least three cross-team conflicts were resolved at working level rather than escalating to the CEO, with dates.
• Median time from cross-team conflict to decision is measured and falling against a first-quarter baseline.
• The analyst's time is not consumed by any report with no regular reader.
• The charter has been renewed by the CEO with both VPs' sign-off and a defined service list, including what the PMO will not do.

Signals to stop and rethink:

• The dependency view is consumed only by the CEO. That means the PMO has become a reporting function for the top of the house, not a decision function for the teams.
• Teams are maintaining duplicate data to satisfy the PMO.
• The PMO's existence is being used as the reason teams no longer talk to each other directly.

In any of those cases the honest recommendation is a smaller scope, or folding the dependency function into product operations, rather than defending the current shape.