From Standardisation to Adaptation: The PMO and Complex Projects
This post draws on themes UniPhi's founder has presented to the Sydney PMO community and the Australian Institute of Project Management, on a question that has not aged: how should the PMO develop standards for complex projects?
It is a genuine bind, and it deserves better than the usual answer.
Complex is not the same as big
The most common error in PMO design is treating complexity as a matter of scale. It is not. A large project with well-understood scope, a stable environment and a single accountable client is complicated — it needs discipline, sequencing and control. A project with contested objectives, multiple interdependent parties, emergent scope and a shifting regulatory context is complex, and it needs something different.
The distinction is practical. In a complicated environment, the right answer is knowable in advance, so prescription works: define the process, follow it, and the outcome follows. In a complex environment, the right answer emerges through the work, so prescription does not work — it locks in a plan formed at the point of least knowledge.
Most PMO standards were designed for complicated projects. Most consequential projects are complex.
The consequence of forcing one on the other
When a PMO applies a one-size-fits-all standard to a complex project, three things happen.
Judgement gets displaced by compliance. A project manager with twenty years of experience spends their time satisfying a template rather than exercising the judgement they were hired for.
The plan becomes a fiction that must be defended. Because the baseline was set before the scope was understood, variance reporting turns into an exercise in explaining why reality is wrong.
Delivery routes around the PMO. The work gets done in shadow tools by people who have concluded, reasonably, that the official process is an obstacle. The PMO loses visibility of exactly the projects where visibility matters most.
The argument here is not against method. It is that a project manager should broaden their knowledge of as many methods and tools as possible, and apply whichever is appropriate to the situation in front of them — rather than accepting a single standardised approach imposed regardless of context.
What adaptive standards look like
The PMO's job in a complex environment is not to prescribe the approach. It is to define the invariants — the small set of things that must be true regardless of approach — and let the rest adapt.
A workable set of invariants:
| Invariant | Why it must be fixed |
|---|---|
| Where information lives | Retrieval is impossible if this varies |
| What a cost code means | Comparability and roll-up depend on it |
| Who holds which delegation | Governance is meaningless without it |
| That risk and issues are recorded | Portfolio exposure cannot be assessed otherwise |
| That decisions leave a record | Assurance and learning both require it |
Everything else — the schedule technique, the reporting cadence, the level of estimate detail, the shape of the business case, whether the team runs sprints or stages — should be a choice made by people who can see the situation.
This is the same principle explored in Standards vs Flexibility, applied at the level of method rather than document: standardise the container, liberate the contents.
The paradox this resolves
Here is the objection an executive will raise, and it is a fair one: if every project runs differently, how do we compare them?
The answer is that comparability comes from the data structure, not the process. If two projects both allocate cost to the same chart of accounts, both record risk against the same scales, and both report actuals from the same source, they are comparable — even if one ran PRINCE2 stages and the other ran two-week sprints.
This is why the tooling question is not separable from the standards question. A platform that enforces the data structure while permitting process variation lets a PMO be simultaneously flexible and rigorous. A platform that enforces the process forces the PMO to choose.
Where the value shows up
Organisations that get this right stop improvising solutions to problems they have already solved elsewhere, and start using what they know. Consolidated cost history becomes benchmark pricing. Repeated risk patterns become a standard risk set for that project type. Adaptive delivery becomes a capability rather than an exception granted grudgingly.
UniPhi exists to provide adaptive solutions to complex problems — bridging the gap between on-the-job effort and project value, so organisations can maximise opportunity in an emergent market rather than improvising their way through it.
For the PMO, that is the shift from being the department that enforces the process to being the function that makes good delivery possible. It is a considerably better job, and a considerably more defensible one at budget time.
Related: UniPhi and the PMO · Standards vs Flexibility: Getting PMO Templates Right · The Five Problems Every PMO Faces · Delivering Project 13 with UniPhi
Delivering something genuinely complex? Email sales@uniphi.com.au.