The Picture Most Organisations Are Living In
A new system is implemented.
The project is declared successful.
Training is completed.
The vendor is paid.
Six months later:
- Workarounds start appearing
- Reports are questioned
- Processes still feel slow
- Teams complain the system “doesn’t work properly”
Leadership senses something is off—but can’t quite pinpoint why.
So another initiative begins.
Another improvement program.
Another system enhancement.
Another round of workshops.
And yet, the organisation doesn’t fundamentally improve.
What’s Actually Happening
No one owns the outcome.
- IT owns the system
- The project team owned delivery
- The business uses the process
But no one owns whether the organisation is actually better as a result.
This is not a capability problem.
This is an ownership problem.
The Missing Discipline
Every organisation is doing capability development every day:
- Implementing ERP and CRM systems
- Redesigning processes
- Improving data and reporting
- Driving automation and efficiency
But this work is fragmented across teams.
It is not treated as a discipline with clear roles and accountability.
The Structure: The Roles within Capability Development
In practice, capability development requires five distinct roles.
Each role exists in most organisations—
but rarely with clarity.
When these roles are undefined or blurred, value is lost.
When they are clear, transformation becomes predictable.
1. Capability Architect
Design – Defines what should exist
What this role does
- Understand how the organisation creates value
- Map capabilities across processes, systems, and data
- Identify inefficiencies and structural gaps
- Design the future state
- Define how systems should support operations
- Build a roadmap aligned to business direction
Why it matters
Without this role:
- Systems are configured around current problems
- Projects optimise the wrong things
- Roadmaps become reactive
In many organisations, this responsibility is:
- partially done by IT
- partially by vendors
- partially by business
Which means it is not truly owned by anyone.
Real-world pattern
An organisation implements an ERP without clearly defining:
- how procurement should work end-to-end
- what good looks like for finance operations
The system goes live…
but simply digitises existing inefficiencies.
2. Implementation Team
Delivery – Builds what was agreed
What this role does
- Translate requirements into solutions
- Configure systems
- Manage timelines, risks, and stakeholders
- Coordinate delivery
- Test, train, and deploy
Typical roles include:
- Project Manager
- Business Analyst
- Change Manager
- Testers and Trainers
Why it matters
Without delivery:
- Strategy never becomes reality
- Nothing changes
But this role has a clear boundary:
It is temporary
They deliver the capability.
They do not own it after go-live.
Real-world pattern
A well-run project:
- Workshops completed
- System configured
- Users trained
- Go-live achieved
Everything looks successful.
Yet, within months, issues begin to surface.
Because delivery is not the same as value.
3. Product Owner (System Owner)
Ownership – Ensures the system is used effectively
What this role does
- Own the application (ERP, CRM, HR systems)
- Manage enhancements and backlog
- Ensure adoption across users
- Provide ongoing support and training
- Continuously improve system usage
Why it matters
Without this role:
- Systems degrade over time
- Users revert to manual workarounds
- Features remain underutilised
The system exists—
but its value declines.
Real-world pattern
Post go-live:
- Teams bypass workflows
- Reports are inconsistent
- Data quality drops
A strong Product Owner:
- corrects usage
- refines configurations
- reinforces adoption
4. Process Owner
Ownership – Ensures the process delivers outcomes
What this role does
- Own end-to-end business processes
- Define how work should flow
- Remove inefficiencies and bottlenecks
- Align roles and responsibilities
- Set and monitor KPIs
- Drive continuous improvement
Why it matters
Without this role:
- Process inefficiencies remain
- Systems get blamed unnecessarily
- Performance does not improve
Real-world pattern
A procurement system is implemented.
But:
- approvals remain slow
- duplication still exists
- accountability is unclear
The system works.
The process does not.
5. Capability Owner
Control – Owns the outcome
This is the role most organisations are missing.
What this role does
- Own the end-to-end performance of a capability
- Align system, process, and people
- Track whether expected benefits are realised
- Prioritise improvements across competing demands
- Hold all roles accountable to outcomes
Why it matters
Without this role:
- Ownership is fragmented
- Improvements are localised
- Value is never fully realised
Everyone contributes.
No one owns.
Real-world pattern
After an ERP implementation:
- IT confirms the system is stable
- The project team confirms delivery is complete
- The business still struggles
No one is accountable for closing this gap.
A Capability Owner asks:
- Are we faster?
- Are we more efficient?
- Are we reducing cost or effort?
- Where is value leaking?
The Shift That Changes Everything
Most organisations focus on:
- delivering projects
- implementing systems
- improving processes
Very few focus on:
clear ownership of outcomes
Final Thought
Capability development is not about more initiatives.
It is about clarity of roles and accountability.
When each role is clearly defined:
- Design becomes intentional
- Delivery becomes effective
- Ownership becomes real
- Value becomes measurable
And most importantly:
The organisation actually improves.
