IT Operating Models
An IT operating model defines the structural arrangement through which an organisation delivers technology services, makes technology decisions, and aligns IT capabilities with mission objectives. The model specifies where IT staff sit within the organisation, who holds authority over technology choices, how services flow to users, and what governance mechanisms ensure accountability. For mission-driven organisations, the operating model must balance standardisation (which reduces cost and risk) against local autonomy (which enables field responsiveness and partner-appropriate solutions).
- Operating model
- The combination of organisational structure, governance arrangements, service delivery mechanisms, and resource allocation patterns that determine how IT functions within an organisation.
- Centralised model
- An arrangement where all IT staff, budgets, and decision authority reside in a single organisational unit, typically at headquarters.
- Decentralised model
- An arrangement where IT staff, budgets, and decision authority are distributed across business units, country offices, or departments with minimal central coordination.
- Federated model
- A hybrid arrangement combining central standards and shared services with distributed delivery and local decision-making within defined boundaries.
- Governance framework
- The structures, processes, and accountabilities through which technology decisions are made, implemented, and monitored.
Operating Model Components
An IT operating model comprises four interdependent components: organisational structure, governance arrangements, service delivery mechanisms, and capability distribution. Each component shapes the others, and changes to one ripple through the rest. Understanding these components as a system, rather than as independent choices, prevents the common failure of optimising one element while undermining another.
+------------------------------------------------------------------+| IT OPERATING MODEL |+------------------------------------------------------------------+| || +------------------------+ +------------------------+ || | ORGANISATIONAL | | GOVERNANCE | || | STRUCTURE | | ARRANGEMENTS | || | | | | || | - Reporting lines |<-->| - Decision rights | || | - Team composition | | - Escalation paths | || | - Role definitions | | - Accountability | || | - Geographic spread | | - Oversight bodies | || +------------------------+ +------------------------+ || ^ ^ || | | || v v || +------------------------+ +------------------------+ || | SERVICE DELIVERY | | CAPABILITY | || | MECHANISMS | | DISTRIBUTION | || | | | | || | - Support tiers |<-->| - Skills location | || | - Request channels | | - Knowledge centres | || | - Delivery processes | | - Training approach | || | - Partner integration | | - Succession depth | || +------------------------+ +------------------------+ || |+------------------------------------------------------------------+Figure 1: Operating model components and their interdependencies
Organisational structure determines where IT staff report and how IT relates to other organisational functions. A structure where IT reports to the Chief Operating Officer produces different outcomes than one where IT reports to Finance or where country IT staff report to country directors. The reporting relationship shapes budget influence, strategic involvement, and the perceived role of technology. Structures also determine span of control: a central IT director managing 45 staff across 12 countries faces different coordination challenges than one managing 8 staff in a single location.
Governance arrangements establish who can make which decisions, under what constraints, and with what oversight. Governance separates strategic decisions (which systems to adopt, which vendors to use, what architecture to follow) from operational decisions (how to configure a specific system, when to schedule maintenance, how to prioritise support tickets). Clear governance prevents both decision paralysis, where no one feels authorised to act, and decision chaos, where multiple parties make conflicting choices.
Service delivery mechanisms define how IT services reach users. These mechanisms include support channels (helpdesk, self-service portals, field visits), escalation tiers, service level expectations, and the boundary between what IT provides directly versus what users or local staff handle themselves. In organisations with field operations, service delivery must account for connectivity constraints, time zone differences, and the reality that a support call from a field office in South Sudan cannot wait for London business hours.
Capability distribution addresses where skills and knowledge reside. Centralised capability means expertise concentrates at headquarters, with field locations dependent on remote support. Distributed capability places specialists in regions or countries, reducing response time but increasing the total headcount required to maintain coverage. Most organisations blend these approaches: centralised for specialised skills (security, architecture, major systems) and distributed for high-frequency, context-dependent work (user support, local system administration).
Model Types
Operating models exist on a spectrum from fully centralised to fully decentralised, with federated and hybrid arrangements occupying the middle ground. No model is inherently superior; each offers trade-offs appropriate to different organisational contexts, scales, and operating environments.
Centralised Model
A centralised model concentrates all IT authority, budget, and staff in a single unit. Country offices and departments receive IT services but do not employ IT staff or control IT spending. All decisions, from strategic platform choices to operational matters like laptop procurement, flow through the central team.
+------------------------------------------------------------------+| CENTRALISED MODEL |+------------------------------------------------------------------+| || +------------------+ || | CENTRAL IT | || | | || | - All staff | || | - All budget | || | - All decisions | || +--------+---------+ || | || +-------------------+-------------------+ || | | | || v v v || +------+------+ +------+------+ +------+------+ || | Country A | | Country B | | Country C | || | | | | | | || | Services | | Services | | Services | || | received | | received | | received | || | (no IT | | (no IT | | (no IT | || | staff) | | staff) | | staff) | || +-------------+ +-------------+ +-------------+ || |+------------------------------------------------------------------+Figure 2: Centralised model with headquarters-based IT serving all locations
Centralised models achieve economies of scale through consolidated purchasing, standardised systems, and shared expertise. An organisation with 500 users across 8 countries requires fewer total IT staff when centralised (perhaps 6-8) than when each country maintains its own capability (potentially 12-16 when accounting for minimum viable staffing at each location). Standardisation reduces complexity: one email system, one identity provider, one approach to endpoint management.
The model struggles with responsiveness and local context. A field office experiencing connectivity issues cannot wait for headquarters (8 time zones away) to wake up. Local procurement through global contracts may cost more than locally-available alternatives. Standardised systems designed for headquarters conditions may perform poorly on low-bandwidth connections. Staff in field locations experience IT as a remote, unresponsive function that does not understand their operational reality.
Centralised models suit organisations with concentrated operations (most staff at headquarters), homogeneous technology needs across locations, and sufficient connectivity to deliver remote support effectively. Organisations under 200 staff often default to centralisation regardless of geographic spread, simply because the overhead of distributed capability exceeds the benefits.
Decentralised Model
A decentralised model distributes IT authority, budget, and staff to business units, country offices, or departments. Each unit employs its own IT staff, controls its own IT budget, and makes its own technology decisions. Central IT, if it exists at all, serves only as a coordination function or shared service provider competing with external alternatives.
+--------------------------------------------------------------------+| DECENTRALISED MODEL |+--------------------------------------------------------------------+| || +------------------+ +------------------+ +------------------+ || | COUNTRY A IT | | COUNTRY B IT | | COUNTRY C IT | || | | | | | | || | - Own staff | | - Own staff | | - Own staff | || | - Own budget | | - Own budget | | - Own budget | || | - Own decisions | | - Own decisions | | - Own decisions | || +--------+---------+ +--------+---------+ +--------+---------+ || | | | || v v v || +--------+---------+ +--------+---------+ +--------+---------+ || | Country A | | Country B | | Country C | || | Operations | | Operations | | Operations | || +------------------+ +------------------+ +------------------+ || || (Minimal or no central IT) |+--------------------------------------------------------------------+Figure 3: Decentralised model with autonomous country-level IT functions
Decentralised models maximise local responsiveness. Country IT staff understand local context, can procure locally, and respond immediately to operational needs. Decisions happen close to the work. Country directors control their technology investments and can align IT spending with programme priorities without negotiating with headquarters.
The trade-offs are significant. Without coordination, each country adopts different systems, creating integration barriers when programmes span countries or when staff transfer between locations. Data cannot flow between incompatible systems. Security standards vary, creating weak points that affect the entire organisation. Specialised expertise (security, architecture, complex integrations) cannot be maintained at each location economically, leaving countries without access to skills they occasionally need. Vendor negotiations happen at smaller scale, reducing purchasing power.
Decentralised models appear in two contexts: organisations that grew through mergers of previously independent entities (each bringing its own IT), and organisations where country operations are genuinely autonomous with minimal need for cross-country coordination. Pure decentralisation is rare in practice because even autonomous country operations typically share some systems (global finance, HR, email domain) requiring coordination.
Federated Model
A federated model combines central standards and shared services with distributed delivery and local decision-making within defined boundaries. Central IT establishes architecture, security standards, strategic vendor relationships, and shared platforms. Country or regional IT operates within these boundaries, making local decisions about implementation, support, and context-specific needs.
+-------------------------------------------------------------------+| FEDERATED MODEL |+-------------------------------------------------------------------+| || +--------------------------------------------------------------+ || | CENTRAL IT | || | | || | Responsibilities: | || | - Architecture standards - Strategic procurement | || | - Security policy - Identity platform | || | - Global systems - Specialist expertise | || +-------------------------------+------------------------------+ || | || +-----------------------------------------+ || | | | || v v v || +---------+--------+ +---------+--------+ +-------+----------+ || | REGION A IT | | REGION B IT | | REGION C IT | || | | | | | | || | Responsibilities:| | Responsibilities:| | Responsibilities:| || | - Local support | | - Local support | | - Local support | || | - Implementation | | - Implementation | | - Implementation | || | - Context adapt. | | - Context adapt. | | - Context adapt. | || +--------+---------+ +--------+---------+ +--------+---------+ || | | | || +-----+-----+ +-----+-----+ +-----+-----+ || | | | | | | | | | || v v v v v v v v v || +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ || |CO1| |CO2| |CO3| |CO4| |CO5| |CO6| |CO7| |CO8| |CO9| || +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ || |+-------------------------------------------------------------------+Figure 4: Federated model with central standards and regional delivery
Federation requires clear boundary definition. Central IT must specify precisely what is mandated (security standards, identity infrastructure, core platforms), what is recommended with approved alternatives (productivity tools, field equipment), and what is fully delegated (local vendor selection below threshold values, support processes, implementation timing). Ambiguous boundaries create conflict: central IT perceives non-compliance while regional IT perceives overreach.
The boundary typically aligns with risk and integration requirements. Decisions affecting security, data protection, or cross-organisational integration remain central because the consequences of inconsistency extend beyond the deciding unit. Decisions affecting only local operations, user experience, or context-specific needs delegate to regions because local knowledge produces better outcomes and central involvement adds delay without value.
Effective federation demands more governance maturity than centralisation. Central IT must trust regional teams to operate within boundaries. Regional IT must accept that boundaries exist for legitimate reasons. Both must communicate actively to identify where boundaries need adjustment. Organisations accustomed to hierarchical control often struggle with the negotiation and trust that federation requires.
Hybrid Arrangements
Most operating models in practice are hybrids, combining elements of centralised, decentralised, and federated approaches across different IT domains. An organisation might centralise identity and security (too risky to distribute), federate user support and implementation (benefits from local presence), and decentralise programme-specific systems (each programme has unique needs).
The hybrid approach acknowledges that different IT functions have different characteristics. Infrastructure benefits from centralisation: standardised networks, consistent security, economies of scale. Support benefits from distribution: responsiveness, local language, context awareness. Strategic planning benefits from central coordination with regional input: coherent direction with practical grounding.
Hybrid models require clear articulation of which model applies to which domain, preventing confusion about who owns what. Without this clarity, hybrid models degrade into unclear accountability, where central IT and regional IT each believe the other is responsible for falling-between issues.
Governance Structures
Governance structures translate operating model principles into accountable decision-making. A governance structure specifies the bodies that make decisions, their composition, their authority limits, and how they interact. Effective governance balances oversight (ensuring decisions align with organisational interests) against agility (enabling timely decisions without excessive process).
Governance Bodies
IT governance in mission-driven organisations typically involves three tiers of decision-making bodies, each with distinct scope and composition.
+-------------------------------------------------------------------+| GOVERNANCE HIERARCHY |+-------------------------------------------------------------------+| || +--------------------------------------------------------------+ || | EXECUTIVE / BOARD LEVEL | || | | || | Body: Senior Leadership Team or Board IT Committee | || | Scope: Strategy, major investments (>£250k), risk appetite | || | Frequency: Quarterly or as needed for major decisions | || | Composition: CEO, COO, Finance Director, IT Director | || +-------------------------------+------------------------------+ || | || v || +--------------------------------------------------------------+ || | IT LEADERSHIP LEVEL | || | | || | Body: IT Steering Committee | || | Scope: Architecture, vendor selection, policy, standards | || | Frequency: Monthly | || | Composition: IT Director, IT Managers, Business Unit leads | || +-------------------------------+------------------------------+ || | || v || +--------------------------------------------------------------+ || | OPERATIONAL LEVEL | || | | || | Body: Change Advisory Board / Technical Review | || | Scope: Change approval, incident review, operational issues | || | Frequency: Weekly or as needed | || | Composition: IT Operations staff, affected service owners | || +--------------------------------------------------------------+ || |+-------------------------------------------------------------------+Figure 5: Three-tier governance structure with scope and composition
The executive tier addresses strategic alignment and major resource allocation. This tier approves multi-year IT strategies, investments exceeding defined thresholds (£250,000 is common for mid-sized organisations), and decisions affecting organisational risk posture. Executive involvement ensures IT strategy connects to mission strategy and that significant investments receive appropriate scrutiny. Executive bodies meet infrequently (quarterly) and rely on prepared materials rather than working through details directly.
The IT leadership tier handles architectural decisions, vendor relationships, policy development, and standards. This tier ensures technical coherence across the IT function and alignment with organisational policies. The IT Steering Committee typically includes the IT Director, IT managers, and representatives from major business functions (programmes, finance, HR). Monthly meetings provide sufficient frequency for most decisions; urgent matters escalate to executive level or proceed through delegated authority.
The operational tier manages day-to-day decisions: change approvals, incident responses, support escalations, and implementation details. The Change Advisory Board (CAB) reviews proposed changes for risk and readiness. Technical review sessions address implementation approaches. These bodies meet weekly or more frequently, enabling operational agility while maintaining oversight.
Role Definitions
Clear role definitions prevent both gaps (no one responsible) and overlaps (multiple parties conflicting). The RACI framework, defining Responsible, Accountable, Consulted, and Informed parties for each decision type, provides a standard structure. However, RACI matrices only function when roles themselves are well-defined.
The IT Director or equivalent role holds overall accountability for IT strategy, budget, risk, and service delivery. This role typically reports to the COO, CEO, or in larger organisations, serves as a peer to other directors. The IT Director represents IT in executive discussions, translates organisational strategy into IT priorities, and ensures IT operates within policy and budget constraints.
IT Managers own specific domains: infrastructure, applications, security, support. Each manager holds accountability for their domain’s service quality, budget adherence, and capability development. In smaller organisations, these domains combine into fewer roles or collapse entirely into the IT Director.
Business system owners sit outside IT but hold accountability for specific systems’ fitness for purpose. The Finance Director owns the finance system from a business perspective; IT ensures the system runs reliably and securely. This separation prevents IT from making business decisions (what the system should do) while ensuring IT remains accountable for technical decisions (how the system operates).
Regional or country IT staff in federated models operate within central standards while holding local accountability for service delivery. Their reporting relationship varies: some report to central IT with a dotted line to country leadership; others report to country leadership with a dotted line to central IT. The former prioritises technical consistency; the latter prioritises local responsiveness.
Federated Governance
Federated governance extends the governance framework to organisations with distributed operations, autonomous country offices, or multiple legal entities. Federation adds complexity because decision-making must balance global consistency against local autonomy, and governance bodies must span organisational boundaries that may involve different legal entities, time zones, and operational contexts.
Federation Boundaries
Federation requires explicit boundary definition: what central authority controls, what regional or country authority controls, and where shared decision-making applies.
+--------------------------------------------------------------------+| FEDERATION BOUNDARIES |+--------------------------------------------------------------------+| || CENTRAL AUTHORITY || +---------------------------------------------------------------+ || | - Identity and access management architecture | || | - Security standards and incident response | || | - Data protection and privacy framework | || | - Strategic vendor relationships (>£100k annual) | || | - Core platforms (finance, HR, email domain) | || | - Architecture standards and integration patterns | || +---------------------------------------------------------------+ || || SHARED DECISION-MAKING || +---------------------------------------------------------------+ || | - Programme system selection (central standards, local choice)| || | - Regional vendor relationships (£25k-£100k annual) | || | - Implementation timing and approach | || | - Support model design within standards | || | - Capability development priorities | || +---------------------------------------------------------------+ || || LOCAL AUTHORITY || +---------------------------------------------------------------+ || | - User support delivery | || | - Local vendor relationships (<£25k annual) | || | - Implementation scheduling | || | - Local equipment procurement within standards | || | - Office IT infrastructure within standards | || +---------------------------------------------------------------+ || |+--------------------------------------------------------------------+Figure 6: Federation boundary definition with authority levels
Central authority applies to decisions where inconsistency creates unacceptable risk or cost. Security standards must be consistent because attackers target the weakest point; a country office with poor access controls compromises the entire organisation. Identity architecture must be central because users need single credentials across systems; fragmented identity prevents integration. Core platforms must be consistent because data must flow between countries and functions.
Local authority applies to decisions where local knowledge produces better outcomes and inconsistency carries limited risk. User support benefits from local delivery: staff who speak the language, understand the context, and can respond in the same time zone. Local equipment procurement within standards allows taking advantage of local availability and pricing. Implementation scheduling responds to local operational rhythms.
Shared decision-making applies to decisions requiring both central coordination and local input. Programme system selection balances standardisation benefits (reduced support complexity, easier staff transitions) against programme-specific needs that may favour different tools. The typical pattern defines approved options centrally while allowing local teams to select among them.
Cross-Entity Coordination
Organisations operating across multiple legal entities (common in international NGOs where each country may be a separate legal entity) face additional federation challenges. Each entity has its own board, potentially its own policies, and legal obligations to its specific jurisdiction. Central IT cannot simply mandate compliance; it must work through agreed frameworks that each entity’s governance adopts.
Cross-entity coordination mechanisms include:
Global IT policies adopted by reference into each entity’s policy framework, ensuring consistency while respecting legal separation. The global policy establishes standards; each entity’s board formally adopts those standards for their entity.
Service agreements between entities, where central IT (hosted in one entity) provides services to other entities under documented terms. These agreements clarify what central IT provides, what it costs, and what each entity’s obligations are.
Federated governance bodies with representation from each entity, ensuring decisions affecting multiple entities involve appropriate input. A global IT steering committee with regional representatives differs from a headquarters IT steering committee making decisions for others without consultation.
Coordination Mechanisms
Federation requires active coordination to function. Without coordination mechanisms, federated models drift toward either de facto centralisation (central IT makes all real decisions, regional IT becomes implementation-only) or de facto decentralisation (regions ignore central standards, consistency erodes).
Regular coordination meetings between central and regional IT (monthly at minimum) surface issues before they become conflicts. These meetings work best with structured agendas covering upcoming decisions, boundary clarifications, resource requests, and lessons learned from recent implementations.
Secondments and rotations build relationships and shared understanding. Central IT staff spending time in regional offices understand local constraints; regional IT staff spending time at headquarters understand central pressures. These relationships lubricate coordination by replacing institutional positions with personal understanding.
Documented standards with rationale enable regional IT to understand not just what the standard requires but why, enabling intelligent adaptation within the standard’s intent. A security standard requiring encrypted storage makes sense in most contexts but may need adaptation where reliable power for encryption overhead is unavailable. Understanding the rationale (protecting data if devices are lost) allows finding alternative controls (devices that never store data locally) rather than simply violating the standard.
Selection Considerations
Selecting an operating model requires assessing organisational characteristics, operational context, and strategic direction. No formula produces the right answer; the selection involves judgement about trade-offs appropriate to specific circumstances.
Organisational Characteristics
Organisation size affects viable models. Below 100 staff, dedicated IT functions at multiple locations cannot be economically justified; centralised or headquarters-plus-field-focal-points arrangements are typical. Between 100 and 500 staff, federated models become viable if geographic spread warrants distribution. Above 500 staff, the choice depends more on operational model than size.
Geographic distribution influences model viability. Organisations concentrated in one or two locations (even if large) suit centralised models. Organisations spread across many time zones with significant staff in each need distributed capability for responsive support. The concentration of field operations matters more than simply counting locations: an organisation with 80% of staff at headquarters and 20% distributed across 15 field offices differs from one with 30% at headquarters and 70% distributed.
Organisational culture shapes what models will function. Hierarchical cultures where decisions flow downward suit centralised governance. Cultures emphasising country office autonomy resist central mandates, making federated models (where standards are negotiated rather than imposed) more likely to succeed. Attempting to impose a model misaligned with culture produces compliance resistance and workarounds.
Operational Context
Field operations in challenging environments push toward distributed capability. When field offices operate in areas with unreliable connectivity, unstable power, and security constraints, they cannot depend on headquarters-based IT. Local IT capability, even if minimal, provides resilience that remote support cannot.
Programme delivery models affect integration requirements. Organisations delivering programmes that span countries need consistent systems and data integration, favouring centralised platforms. Organisations with country-specific programmes have less integration need, allowing more local choice.
Partnership patterns influence model design. Organisations working extensively with local partners may need IT capability in-country to support partner systems. Centralised IT cannot easily engage with a local partner’s systems or respond to partner support needs in local context.
Strategic Direction
Growth trajectory affects model investment. Organisations expecting significant growth should consider whether their current model will scale. A centralised model adequate for 150 staff may overwhelm a 6-person headquarters IT team when the organisation reaches 300 staff across additional countries.
Merger or restructuring plans influence model design. Organisations expecting to merge entities need operating models that can accommodate integration. Organisations expecting to spin off country operations need models that allow separation without disruption.
Digital transformation ambitions affect governance requirements. Organisations undertaking significant technology change need governance capable of managing change risk while enabling progress. Overly restrictive governance slows transformation; insufficient governance allows projects to fail without early intervention.
Implementation Considerations
Operating model changes carry significant risk and disruption. Unlike technical changes that can be implemented and rolled back, organisational changes affect people’s roles, relationships, and sometimes employment. Implementation requires careful planning and sustained commitment.
For Organisations with Minimal IT Function
Organisations without dedicated IT staff operate with an implicit centralised model: whoever handles technology (often an operations manager or administrator) makes all IT decisions. Formalising this into an explicit model, even a simple one, improves clarity and decision quality.
The minimum viable operating model for a small organisation documents who is responsible for IT decisions (even if it is the Executive Director), what governance applies (major purchases require board approval; operational matters are delegated), and what services IT provides (often a simple list). This documentation prevents assumptions and provides a foundation for growth.
When hiring first dedicated IT staff, the operating model determines their role. An IT Manager with decision authority and direct executive access differs from an IT Administrator executing decisions made by others. The role definition should precede recruitment to ensure candidates understand expectations.
For Organisations with Established IT Functions
Established IT functions changing operating models face transition management challenges. Moving from decentralised to federated requires building central capability while managing existing distributed staff. Moving from centralised to federated requires developing regional capability while maintaining service continuity.
Transition sequencing matters. Building governance structures before implementing structural changes ensures decisions can be made through new processes. Piloting with willing regions before organisation-wide rollout identifies issues at limited scale. Maintaining parallel structures during transition (old and new governance both operating) provides fallback if new arrangements fail.
Communication intensity during transition exceeds normal levels. Staff in both IT and business functions need to understand what is changing, why, and what it means for them. Uncertainty about role changes creates anxiety and performance impact; clear, frequent communication reduces this.
For Federated Structures
Implementing federated governance in organisations with autonomous country entities requires negotiation rather than mandate. Central IT cannot impose standards on legally separate entities; those entities’ boards must agree to adopt standards. The negotiation process builds buy-in but takes time.
Starting with high-value, low-controversy elements builds momentum. Security standards that protect everyone typically gain agreement more easily than standards that constrain local choice. Identity federation that enables single sign-on provides visible user benefit. Early wins demonstrate federation value before addressing more contentious areas.
Investing in relationship-building across federal boundaries pays dividends when disagreements arise. Conflict resolution through established relationships proceeds more smoothly than conflict between parties who have never met. Regular in-person gatherings of central and regional IT staff (where budget allows) build these relationships.
RACI Matrix Template
The following template provides a starting point for documenting decision rights. Organisations should adapt categories and roles to their specific structure.
Using this template
Customise decision categories to reflect decisions your organisation actually makes. Add or remove roles to match your structure. Review and update the matrix annually or when significant organisational changes occur.
+------------------------------------------------------------------+| TECHNOLOGY DECISION RIGHTS MATRIX |+------------------------------------------------------------------+| || DECISION CATEGORY | EXEC | IT DIR | IT MGR | BUS OWN | ||----------------------------|------|--------|--------|---------| || STRATEGIC | | | | | || IT strategy approval | A | R | C | C | || Major investment (>£250k) | A | R | C | C | || Vendor strategic partner | A | R | C | I | || Operating model change | A | R | C | C | || | | | | | || ARCHITECTURAL | | | | | || Platform selection | I | A | R | C | || Integration standards | I | A | R | C | || Security architecture | I | A | R | I | || Data architecture | I | A | R | C | || | | | | | || OPERATIONAL | | | | | || System configuration | - | I | A | R | || Change approval (standard) | - | I | A | C | || Incident response | I | A | R | I | || Support priorities | - | I | A | C | || | | | | | || PROCUREMENT | | | | | || >£100k annual | A | R | C | C | || £25k-£100k annual | I | A | R | C | || <£25k annual | - | I | A | C | |+------------------------------------------------------------------+| || R = Responsible (does the work) || A = Accountable (final decision authority) || C = Consulted (input required before decision) || I = Informed (notified after decision) || - = Not involved || |+------------------------------------------------------------------+Figure 7: RACI matrix template for technology decisions
For federated organisations, extend the matrix with regional roles:
+------------------------------------------------------------------+| FEDERATED DECISION RIGHTS (ADDITIONS) |+------------------------------------------------------------------+| || DECISION CATEGORY | CENTRAL | REGIONAL | COUNTRY | ||----------------------------|---------|----------|---------| || Regional vendor (<£100k) | C | A | R | || Local implementation | I | C | A | || Local support model | C | A | R | || Local equipment (<£25k) | I | I | A | || Standard exception request | A | R | R | |+------------------------------------------------------------------+Figure 8: Federated extension to RACI matrix