The Standardise-Customise Dilemma
"Sure, that process might work for other projects… but our project is different."
This is the paradox facing every project. Everyone wants the benefit of standardised forms and governance…. except when it applies to their project.
Maybe your project is different. Maybe it’s got more stakeholders, more ambiguity, more legacy systems, or tighter timeframes. But if every project is treated as an exception, then what’s the point of having a standard approach at all?
That’s the tension inherent in any collection of projects. Customisation creates adaptability and ownership, but standardisation makes it easy to see everything.
Standard control at what cost?
Standard project methods offer the promise (or allure) of consistency. Status reports are aligned. Metrics roll up neatly. You can compare across streams, identify red flags, scale what works and spot trouble across your portfolio.
But in complexity, standardisation can lead to false comfort. You end up measuring what’s easy and not what matters. Your team may tick all the boxes while missing the warning signs. Focussed on the dashboard while you drive off a cliff.
Standardisation can mask underlying problems if applied too rigidly. Focusing on structure in an emergent project can send it down the wrong path, and a perfectly executed plan can still fail if it solves the wrong problem.
Conversely, the complete absence of guidance, allowing a 'free-for-all' approach, will inevitably lead to chaos, particularly when managing a multitude of projects.
So how do we find the balance between standardised and customised?
Size is not the answer
Most organisations draw a line between big and small projects. Large initiatives get the full treatment of charters, governance boards, and risk reviews. Smaller ones get a lighter touch, having to fill out half the forms or a simplified checklist.
But size is not the real difference. Complexity doesn’t scale with budget; It scales with ambiguity.
A low-budget initiative might face intense stakeholder politics, like changing a long-standing process with political landmines. A high-budget infrastructure project might be relatively straightforward, if it’s been done multiple times before with known variables.
The difference isn’t the size. It’s structure, context, and the type of uncertainty in play.
And that’s where the one-size-fits-all approach breaks down.
Matching customisation to complexity
If you want to tailor project management and governance approaches, don’t separate by size, separate by complexity.
The project process should reflect the level of complexity:
1. Uncertainty and Disagreement: Are there unknowns or significant disagreements among stakeholders?
2. Technical Expertise: Does the project demand in-depth technical knowledge or specialised skills?
3. Change Dependency: Is project success contingent on a willingness to adopt new ways of working, rather than simply completing tasks?
4. Prior Projects: Is there a history of similar projects that can provide a reliable roadmap and reduce uncertainty?
These are markers of complexity. If we don’t understand the complexity we’re facing, we’ll either over-engineer a simple project or be unprepared for one that presents a deceptive level of messiness.
Key elements of an adaptive project
Effective project teams demonstrate a keen ability to "read the room" and adapt their approach to fit the specific context.
To support this adaptability, project operating models need to have:
Standard Frameworks: Provide a common language for consistency and comparability across projects.
Flexible Approaches: Enable teams to modify processes and tools to suit changes in the level of uncertainty.
Adaptive Governance: Embrace learning and adaptation rather than strict adherence.
Something to think about:
When trying to decide on the level of standardisation or customisation consider:
How broad is the range of projects you’re taking on?
Does your governance model support the different levels of complexity?
