Catalogue › Organisation Tailoring › operating-model-tailoring

Operating model tailoring

Right-sizes the AI target operating model for one organisation from its confirmed edition, overlay, archetype, signals and declared constraints - which structures to adopt now, which roles to combine, which forums to merge, what a partner covers, what to defer and what would trigger a change - each decision traced to a rule or constraint. Use when a generic operating model looks too heavy or too light, or when constraints change.

Department

Organisation Tailoring

Lifecycle

Envision, Mobilise

Maturity

explorer, adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Organisation Tailoring plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

A target operating model written for a large, federated organisation will crush a forty-person practice, and one written for a small team will leave a regulated multi-unit organisation without the separation and assurance it needs. This skill right-sizes the operating model for one organisation: from the confirmed edition, assurance overlay, archetype, signals and declared constraints, it decides which structures to adopt now, which roles to combine, which forums to merge, where a partner fills in, what to defer, and what would trigger a change. Every tailoring decision is traced to a rule or a stated constraint so it can be explained and revisited. Tailoring goes wrong when it trims the controls that protect people to save effort, when it copies a model from elsewhere, or when deferrals are never revisited.

When to use

• A confirmed edition and archetype exist and the operating model needs to be sized before it is designed in detail.
• A sponsor says the proposed operating model is too heavy (or too light) for their organisation.
• Declared constraints (capacity, budget, timeline, partner dependence) mean the standard model cannot be staffed.
• Circumstances have changed, such as a second business unit starting to build agents or a regulator's new expectations, and the model's weight needs revisiting.
• Two business units need different weights of operating model within one organisation.

When not to use

• Choosing the operating model shape and designing decision rights, build and support responsibilities - use ai-strategy:ai-operating-model.
• Recommending the edition, overlay and archetype in the first place - use organisation-tailoring:edition-and-archetype.
• Designing how the CoE itself runs - use ai-centre-of-excellence:coe-operating-model.
• Defining the roles and mapping them to the organisation's job roles - use organisation-tailoring:ai-role-catalogue.
• Quantifying the capability and capacity shortfall behind a constraint - use organisation-tailoring:capability-gap-analysis.

Questions to ask first

1. Has the sponsor confirmed the edition, assurance overlay and archetype, and which emerging signals were reported?
2. What constraints has the organisation declared (people's time, budget, timeline, internal skills, partner use), and which are firm?
3. Is there already an operating model, CoE or working group, and what about it works?
4. Which risk tiers will the organisation build or use in the next year, since separation and assurance requirements follow the tiers?
5. Do business units differ enough that one model will not fit them all?

Required inputs

• The confirmed recommendation from organisation-tailoring:edition-and-archetype, with rule ids and signals.
• The validated profile from organisation-tailoring:ai-profile-intake, especially delivery capability and constraints.
• Any existing operating model, CoE charter or working-group terms.
• The capability and capacity gaps from organisation-tailoring:capability-gap-analysis, where available.

Where a constraint is unknown, mark it [To confirm: ...] and tailor to the cautious reading: assume less capacity, not more. Never infer that a role exists or that someone has time because the organisation has a certain size.

Decision framework

Tailor each component of the operating model with one of five decisions.

Typical tailoring by edition:

Separation rules never tailored away: the role that builds a tier 2 or higher solution does not approve its release; a reviewer role is independent of the solution owner; a named accountable executive exists for any tier 3 or 4 use. Signals can strengthen components regardless of edition: agents emerging brings intake and agent ownership forward; shadow AI brings an approved-use starter forward; a formal assurance overlay strengthens evidence at every gate.

Practitioner approach

Start from the confirmed recommendation and read it back in operating model terms: "Scale, proportionate assurance, adopter archetype, with agents emerging and weak knowledge ownership." That sentence already says most of what matters: a business-owned CoE is right, adoption is the main effort, intake and agent ownership must arrive early, and knowledge ownership is a precondition rather than a later nicety.

List the components of the operating model (governing body, forums, roles, decision rights by tier, delivery route, support route, assurance, measurement) and take a tailoring decision for each using the five options. Write the reason beside each one, citing the rule id from the edition and archetype recommendation or the declared constraint. A decision with no stated reason will be reopened by the next person who disagrees with it.

Test combinations against the separation rules before agreeing them. Combining the adoption lead and Champions programme owner in a Starter organisation is sensible; combining the maker and the release approver for tier 2 work is not, however small the organisation. Where separation cannot be achieved internally, substitute a partner or a peer from another function, and say so.

Use substitutions and deferrals honestly. An AI working group in place of a CoE is a substitution with a trigger, such as a second business unit building agents or the first tier 2 solution entering delivery. A deferred knowledge pillar is a deferral with a trigger, such as the first agent grounded on owned content. Name who watches for each trigger; deferrals without a watcher become permanent gaps.

Check the tailored model against declared capacity. If the tailored model still needs more time than the declared roles have, either tailor further, bring in a partner, or flag the shortfall to organisation-tailoring:capability-gap-analysis. Do not hand on a model that cannot be staffed.

Explain the result to the sponsor in one page: what is adopted, combined, substituted, deferred and strengthened, and why. Make clear that the tailoring is a CopilotForge proposal based on stated rules, not a Microsoft classification, and that the sponsor can override edition-level choices with a recorded reason but not the separation rules. Then hand the tailoring brief to ai-strategy:ai-operating-model to design within, or use it to adjust an existing model.

Outputs

• An operating model tailoring record: each component with its decision (adopt, combine, substitute, defer, strengthen), depth, owner role, reason and rule id or constraint, recorded alongside the ai-operating-model template.
• A list of triggers for substituted and deferred components, with the role watching for each.
• A one-page sponsor explanation and a record of confirmation or recorded overrides.

Microsoft platform considerations

Platform governance components (environment zoning, maker controls, inventory) also scale with edition; tailor them using the zoned governance and CoE Starter Kit guidance in the source records, and check product facts in references/sources.md. Do not tailor on the assumption that a governance feature is available or licensed.

Adoption considerations

For explorers and adopters, tailoring should protect adoption roles and Champions coordination before adding delivery structures. A lightweight model with a strong adoption lead usually outperforms a heavy model with none.

Knowledge considerations

Where the weak-knowledge signal appears, strengthen knowledge ownership even at Starter: at minimum, name knowledge owner roles for any content an agent will ground on. The knowledge-management skills hold the detailed method.

Security and privacy considerations

Never tailor away the security-privacy gate from risk tier 2 or the DPO's role in personal data decisions. At Starter, reviewer capacity may be borrowed from IT or a partner, but it must stay independent of the builder.

Responsible AI considerations

Tier 3 and 4 uses require an accountable executive and responsible-ai review in every edition. If the tailored model cannot provide them, record that such uses are out of scope until it can.

Evaluation requirements

Not applicable, because the output is an organisational design rather than an AI solution; it is tested by walking two or three real scenarios through the tailored model and confirming none stalls or bypasses a separation rule.

Value measures

Track whether the tailored model is staffed (share of adopted roles with a declared owner), how many deferral triggers have fired and been acted on, and time from intake to decision for typical requests, reported by the Transformation Architect at organisation level.

Scale notes

Starter

Combine freely within the separation rules, substitute a working group for a CoE, partner for anything above tier 1, and defer most pillars with clear triggers.

Scale

Adopt the business-owned CoE, keep reviewer roles independent, combine only where capacity is genuinely limited, and bring agent ownership forward when agents are emerging.

Enterprise

Tailor per business unit where units differ materially, strengthen assurance where the overlay is formal, and keep hub standards untailored so units repeat them.

Hand-offs

• To ai-strategy:ai-operating-model with the tailoring brief, to design the model within it.
• To organisation-tailoring:ai-role-catalogue to define the combined and adopted roles.
• To organisation-tailoring:transformation-pack so artefacts are produced at the tailored depth.
• To ai-centre-of-excellence:coe-operating-model when the CoE's own design follows from the tailoring.

Reviewer gates

Not applicable, because tailoring releases no solution; the tailored model must keep security-privacy from risk tier 2 and the responsible-ai, evaluation-quality and design-authority gates independent of the roles that build.

Failure modes

• The model is trimmed by removing the reviewer roles that protect people, because they are the least visible.
• A model from another organisation is copied whole and does not fit the declared capacity.
• Deferrals have no trigger or watcher and quietly become permanent gaps.
• Tailoring decisions carry no reasons, so every new stakeholder reopens them.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Tailor away a separation rule, the security-privacy gate from tier 2, or the accountable executive for tier 3 and 4.
• Assume capacity or a role exists because of the organisation's size.
• Present tailoring decisions as Microsoft classifications.
• Defer a component without naming its trigger and who watches for it.