Programme Governance
Part of Scaling process automation
Comparing central and team-led automation delivery
Compare central, team-led and shared automation delivery by process knowledge, specialist skills, release decisions and support.
Choose a delivery model by deciding where process knowledge, technical skill, release decisions and continuing support will sit. A central team can provide common platform controls and specialist expertise. Team-led delivery keeps changes close to the people who understand the work. Either arrangement needs a clear route for decisions and incidents.
Compare the same work under each model
Take one proposed automation whose business result and eligible cases are already defined. Compare how three arrangements would deliver and operate it.
| Arrangement | Useful when | Question to resolve |
|---|---|---|
| Central delivery | Specialist integration, access or release skills are scarce and work can enter a shared queue. | How will the builders learn local exceptions and respond when rules change? |
| Team-led delivery | The process changes often and the team has trained people to build and support within agreed controls. | Who reviews wider access, standards and shared dependencies? |
| Shared delivery | Local process decisions and common technical controls both matter. | Which decisions sit with each group, and who carries a request across the boundary? |
Microsoft's adoption guidance describes governance maturity stages and recommends clear policies and control over data access, solution development and environment management. Its fusion-team guidance says workload teams should manage day-to-day, as-needed and emergency tasks, with support from outside teams when necessary. The allocation should account for both governance needs and the support a workload requires.
Trace a change request
Ask how each arrangement would add a new eligible case type. Who confirms the business rule? Who checks source data, permissions and affected workflows? Who builds and verifies the change? Who authorises release, updates support instructions and receives later incidents?
For central delivery, estimate the queue's capacity and the process knowledge it needs. For team-led delivery, specify the controls the team must meet and the specialist help it can reach. For shared delivery, name a role that moves the request between groups. “Both teams own it” does not tell anyone where to send a stalled change.
Trace an incident
A local maker may understand why a case is wrong but lack access to diagnose a failed connection. A platform specialist may restore the connection but be unable to decide whether the business case can be retried.
Name the first responder, technical escalation and business decision maker, and establish how they will share case evidence.
Check leave cover, required support hours and changes to components used by several teams. A quick build does not establish that its builders can maintain a growing set of live workflows.
Choose for a defined class of work
A team might deliver a bounded internal workflow within common controls, while a central group handles integrations used across departments. Choose the allocation for the class of work at hand.
After several releases, review actual change lead time, unresolved incidents, corrections and effort in both groups. If a bottleneck or ownership gap appears, adjust the allocation while keeping accountability for the business result.
