Standards vs Flexibility: Getting PMO Templates Right
Every organisation has its own templates and its own supporting process for producing project documents and managing project financials. These vary enormously — in approach, in rigour, and in the maturity of the organisation that produced them.
One of the clearest signs of that variation is how it feels to start a new job. Finding the tools you need and understanding the processes already in place is often the hardest part of the first month, and it is entirely an artefact of how well the PMO has designed its standards.
This post is about a single question: what should a PMO standardise, and what should it leave alone? Getting the line in the wrong place is expensive in both directions.
What the toolkit contains
On the document side, a typical project toolkit runs from business cases and project management plans through test plans and strategy documents to post-implementation reviews and close-out reports. For each one, a project manager needs to know: when to produce it, where the template lives, what the review process is, and where the finished document is stored.
On the financial side, the same applies to proposals, tender submissions, progress claims and invoices. Anyone with budget responsibility needs to understand how the budget was built, what the delegations of authority are, how it will be tracked, and which system or systems keep it current.
Establishing and maintaining this suite takes real effort — usually designed by the PMO, in consultation with delivery and finance, over months. The investment is justified: when an executive reviews a document for approval, standardisation means they are comparing like with like rather than deciphering a new format each time.
But organisations are complex and they evolve — through maturity, technology and politics. A template suite that cannot evolve with them becomes a liability.
What not to standardise: the content of the argument
If the fundamental purpose of a business case is to convey what the key concepts and benefits are, then the author must be able to do that without being constrained by a format that forbids variation.
Where the format is rigid, one of two things happens. Either the document becomes a form-filling exercise — technically complete, substantively empty — or the author finds a way around the process entirely. The second outcome is worse than the first, because work that circumvents governance becomes invisible: unbudgeted, unassured, and undiscovered until it fails.
So the content of a persuasive or analytical document needs flexibility. The author should be able to add a section, restructure an argument, or drop a heading that does not apply, without seeking permission.
Financial elaboration deserves the same latitude. As a project moves from a rough order of magnitude to an approved and granular budget, the level of cost detail changes. You need to be able to capture cost to the depth of detail you actually have, not to the depth the template demands. And over time, finance may need to extend or restructure the chart of accounts — which, without flexibility, triggers a change project rather than a configuration change.
What to standardise: structure, storage and transactions
Flexibility about where information lives, by contrast, is a disaster. Organisations with ineffective network folder structures and a dependence on email as a filing system lose an extraordinary amount of time to searching. That is the case for absolute rigidity.
In the financial sphere, consistency is required both for management and for presenting a consistent, professional face to suppliers and clients. Specifically:
- A defined chart of accounts so that whoever builds a project budget allocates cost to a standard code set that rolls up meaningfully.
- Firm transactional standards for raising an invoice or purchase order, and for paying or receipting goods and services.
- Consistent branding on outward-facing financial documents.
Note that the presentation layer still needs some give — corporate logos change, addresses change, clients demand a reference number in a particular place. Rigidity in what a number means; flexibility in how the page looks.
The rule, stated simply
Standardise the container. Liberate the contents.
Be rigid about where information lives, what a code means, and how a transaction is executed. Be flexible about how an argument is structured and how much detail exists at a given point in time.
How UniPhi implements the split
This balance has been at the core of the UniPhi product since its inception. Our founder, Mark Heath, had worked in several portfolio management offices before building it, and had seen both failure modes at close range: organisations too prescriptive to allow a real argument to be made, and organisations with no effective solution for the places where standards mattered most — finding a document, retrieving stored information.
So UniPhi is deliberately rigid where rigidity pays. Every unique project is the single reference point for all information relating to it. That structural rule is what makes it very difficult to lose a document, a risk or an issue through the ordinary user error of saving something in the wrong place.
And it is deliberately open where flexibility pays. Configuration is yours: we provide training and reference material so your team can make the changes you need. Two reasons for that. First, we are opposed to the vendor practice of charging exorbitant rates for minor configuration changes. Second, every client is subtly different — you know how your business runs, so you should be able to tune your deployment to match.
The template design tool exists for exactly this. Your templates, your structure, your chart of accounts — inside a system that will not let the output go missing.
Next in this series: No Reports, No Email, No Inbox
Related: UniPhi and the PMO · Methodology Compliance Without the Policing · Document Management Software
Want to see the template designer? Email sales@uniphi.com.au.