Purpose

When to use this review

Use it at an agreed operating-model review, after a material organizational or service change, when recurring exceptions show that controls do not fit the work, or when outcome evidence calls the current model into question.

Review the operating system, not the performance of an individual practitioner. A model can contain the right words and still fail because authority, capacity, incentives, timing, or evidence do not support the intended behavior.

Preparation

Bring evidence that can support a decision

  • Use the current operating agreement, previous decisions, and approved exceptions.
  • Examine demand, capacity, routing, delay, rework, and decline patterns.
  • Include research, accessibility, delivery, outcome, incident, and feedback evidence.
  • Invite people who experience the model, including affected delivery partners and frequently excluded perspectives.
  • Record missing evidence and disagreement rather than forcing consensus.

Connected review

Review five areas as one operating system

Mandate and demand

Are purpose, scope, ownership, intake, priority, capacity, routing, and decline decisions understood and consistently applied?

Evidence and decisions

Can consequential findings and decisions be traced to suitable evidence, confidence, limitations, authority, and unresolved disagreement?

Delivery integration

Does evidence change planning, requirements, design, acceptance, release, exceptions, and post-launch learning at useful times?

Accessibility and responsibility

Are disabled people included, barriers acted on, exceptions governed, and privacy, safety, and responsible-use controls operating throughout delivery?

Outcomes and learning

Do reviews distinguish activity from outcomes, expose unequal effects, produce decisions, and retain knowledge another person can use?

Interpretation

Look for conditions, not maturity theater

Do not average unlike concerns into a single maturity score. A high aggregate can conceal an inaccessible service, weak decision authority, unsafe evidence handling, or a critical delivery gap. Describe the observed condition, evidence, people affected, confidence, and consequence of leaving it unchanged.

Action

Approve the smallest change that addresses the condition

  1. Separate root operating conditions from their visible symptoms.
  2. Choose whether to continue, change, test, stop, or escalate.
  3. Name the agreement, control, authority, workflow, or resource affected.
  4. Assign one accountable owner and a decision or delivery date.
  5. Define evidence of completion, intended outcome, and possible adverse effects.
  6. Set the next measure and trigger for reviewing the change.

Reusable artifact

Copy the Markdown review

Adapt this structure to the organization’s authorized governance environment. Link to controlled evidence instead of copying sensitive research, personnel, security, or operational data into an unsuitable review document.

# HCD operating model review and improvement plan

## Review control
- Operating model or agreement reviewed:
- Accountable owner:
- Review lead and participants:
- Evidence period:
- Review date:
- Version and status:
- Approving authority:
- Next review trigger or date:

## Review purpose and boundaries
- Decision this review must support:
- Scope included:
- Scope excluded:
- Material changes since the previous review:
- Known limitations or missing perspectives:
- People or groups affected by the operating model:

## Evidence considered
For each evidence source:
- Source and period:
- Owner and permitted audience:
- Question it helps answer:
- Confidence and limitations:
- Contradictory evidence or disagreement:

## Connected operating review
For each review area:
- Area: Mandate and demand | Evidence and decisions | Delivery integration | Accessibility and responsibility | Outcomes and learning
- Intended operating condition:
- Evidence of what is working:
- Evidence of friction, delay, exclusion, or risk:
- Recurring exception, workaround, or dependency:
- People or outcomes affected:
- Confidence and evidence gap:
- Continue, change, or stop recommendation:

## Cross-system findings
- Patterns appearing across multiple areas:
- Root conditions rather than visible symptoms:
- Conflicts between user, mission, policy, accessibility, and delivery needs:
- Risks requiring escalation or immediate control:
- Knowledge that should be retained or shared:

## Improvement decisions
For each approved action:
- Decision and rationale:
- Operating model, agreement, control, or practice affected:
- Accountable owner:
- Contributors:
- Due date or delivery checkpoint:
- Evidence of completion:
- Intended outcome and possible adverse effect:
- Follow-up measure and review trigger:

## Review conclusion
- Continue unchanged:
- Change now:
- Test before wider adoption:
- Stop or retire:
- Unresolved decision or evidence gap:
- Communication and publication plan:
- Approval and date:

Guardrails

Check the review before approval

  • Does the review support a named decision rather than only discussion?
  • Are lived experience and unequal effects visible alongside operating metrics?
  • Are accessibility failures prevented from disappearing inside an average?
  • Are findings traceable to evidence, confidence, and limitations?
  • Are recurring exceptions and workarounds treated as operating evidence?
  • Does each approved change have authority, ownership, timing, and follow-up evidence?
  • Will the operating agreement and connected guidance be updated when decisions require it?
  • Can another person understand what changed and why?