Start with outcomes  

There’s a famous line from How Big Things Get Done by Bent Flyvbjerg: 

Big projects don’t fail because they’re ambitious. They fail because they’re poorly governed and poorly scoped. 

In government, transformation often starts with a solution: 

• “We need a new case management system.” 

• “We need AI.” 

• “We need to modernize.” 

That’s activity language. Successful programs start with outcome language: 

• Reduce claim processing time by 40%. 

• Increase first contact resolution to 75%. 

• Cut regulatory backlog in half. 

• Improve public trust scores by 15%. 

Transformation must be tied to measurable public value. 

If the outcome is vague, the program will drift. If the outcome is precise, the system can self-correct. Outcome clarity is not a communications exercise. It is governance architecture. 

 
Governance is design, not oversight 

Most governments treat governance as reporting: 

• Steering committees 

• Status decks 

• Traffic-light dashboards 

That’s oversight, but governance in transformational programs must be design authority. 

High-performing jurisdictions embed decision rights clearly: 

• Who owns scope? 

• Who owns funding trade-offs? 

• Who can kill features? 

• Who can redefine policy constraints? 

If no one can say no, scope will explode. If everyone can say no, nothing will move. Successful programs establish: 

• A single accountable executive 

• Clear escalation pathways 

• Explicit decision cadences 

• Integrated policy, operations, and technology leadership. 

Governance must reduce friction, not create it. 

 
Decompose the transformation 

Big transformations fail when treated as a single monolithic build. The better pattern is modular decomposition. Instead of replace the entire operating model. You break it into: 

• Service journeys 

• Capability clusters 

• Technology components 

• Regulatory enablers 

• Data architecture layers 

This is where program architecture matters. 

Successful transformation programs operate like portfolios, not projects. 

Each component: 

• Has a defined value hypothesis 

• Has an accountable owner 

• Has delivery milestones 

• Feeds into enterprise outcomes 

This mirrors principles found in scaled agile and portfolio governance models, but applied with public-sector rigor. 

The key question becomes -- what can we deliver in 6–12 months that moves the outcome metric? Transformation is not an event.  It’s a sequence of value releases. 

Align CX with Operations 

This is where many governments stumble. They redesign experience in isolation from operational process, but experience is an emergent property of process design. If you want faster service you redesign: 

• intake logic 

• decision authority 

• automation triggers 

• escalation thresholds 

Not just the front-end portal. 

Successful government transformations engineer process-driven experience architecture. 

 
Institutionalize risk management 

One of the biggest myths in government transformation is that risk can be eliminated before launch. 

It cannot. 

What matters is risk visibility and structured mitigation. In government: 

• Costs are underestimated. 

• Benefits are overstated. 

• Timelines are compressed for political cycles. 

Successful programs do the opposite: 

• Independent cost validation 

• Reference-class forecasting 

• Stage-gate funding tied to evidence 

• Transparent reporting to Treasury and Cabinet. 

Transformation requires professional program controls: 

• Integrated master schedules 

• Dependency mapping 

• Benefits realization tracking 

• Risk heatmaps updated monthly. 

This is not bureaucracy. This is operational hygiene. 

Build internal capability  

Another consistent failure pattern -- outsourcing transformation thinking. 

Vendors can implement. They cannot own accountability for public value. Successful governments: 

• Retain architectural authority 

• Build internal product management capability 

• Embed business process designers 

• Develop enterprise data governance.