Right-Sized Public Tech pattern atlas

Public Technology Failure Pattern Atlas

Find recurring public technology procurement and delivery failure patterns, then turn the pattern into a practical decision pack.

The hook is recognition

Find the pattern before the project becomes the procurement.

Start with the symptom your team can see. Each pattern names the minimum evidence, one useful test, the primary-source discipline behind it, and a neutral route for doing the work.

Use it in a meeting

Choose one pattern. Test it against current evidence. Leave with a decision pack.

Build a decision pack

Filter by work

Showing all 12 patterns.

Pattern 01 · Buying and scope

The solution arrives before the outcome

#

What you see

The request names a product, platform, or feature set, but not the user, operating decision, or measurable change that matters.

Why it matters: Teams can compare features while remaining unable to test whether the purchase solved the underlying problem.

Minimum evidence

  • Named users and the decision or task that must improve
  • A current baseline and a measurable target
  • Evidence that process repair or current-system changes were considered

First useful test

Rewrite the request as: who needs to do what differently, using which evidence, by when?

Sources behind this pattern
Build from this pattern Pressure-test the purchase

Pattern 02 · Buying and scope

Everyone participates, but nobody owns the decision

#

What you see

Operations, finance, procurement, technology, security, privacy, and leadership attend meetings without a named decision owner or escalation path.

Why it matters: Important questions stay open until they become schedule pressure, contract ambiguity, or an unreviewed operational risk.

Minimum evidence

  • One accountable operational owner
  • Named finance or procurement and technology or security reviewers
  • Decision rights, escalation conditions, and approval records

First useful test

Ask who can accept, reject, or stop the work, then record the evidence that person needs.

Sources behind this pattern
Build from this pattern Build a cross-functional decision pack

Pattern 03 · Buying and scope

The RFP becomes the discovery process

#

What you see

The team is drafting a solicitation while outcomes, data, dependencies, evaluation evidence, acceptance, or exit conditions remain unresolved.

Why it matters: Vendors are forced to price and interpret uncertainty differently, making proposals harder to compare and delivery harder to govern.

Minimum evidence

  • Testable outcomes and a bounded scope
  • Common evidence and demonstration conditions
  • Whole-life cost, acceptance, monitoring, and exit questions

First useful test

Run the readiness check before finalizing requirements or publishing a schedule.

Sources behind this pattern
Build from this pattern Run the RFP readiness test

Pattern 04 · Buying and scope

Purchase price hides the operating commitment

#

What you see

The comparison emphasizes subscription or implementation price while staffing, integrations, security, records, support, change, and exit work remain outside the decision.

Why it matters: A low apparent price can create a larger unsupported operating obligation after selection.

Minimum evidence

  • Implementation and recurring operating work
  • Internal staffing, integration, security, and support assumptions
  • Transition, export, retention, and exit costs

First useful test

Put every cost and owner on one timeline from preparation through exit.

Sources behind this pattern
Build from this pattern Use the Scope Cutter

Pattern 05 · Evidence and control

The records cannot be reconciled

#

What you see

Contracts, assignments, service records, invoices, adjustments, and approvals use different identifiers or totals.

Why it matters: Reviewers cannot reproduce why a line was paid, held, credited, or corrected without manual investigation.

Minimum evidence

  • Stable vendor, contract, service, date, rate, and invoice-line identifiers
  • A documented source for approved service evidence
  • Separate exception resolution and payment approval records

First useful test

Attempt to trace five invoice lines from authority through service evidence to the final payment decision.

Sources behind this pattern
Build from this pattern Open the transportation control map

Pattern 06 · Evidence and control

Exceptions live in email and memory

#

What you see

Missing evidence, disputed charges, corrective actions, and approvals are resolved in disconnected messages or informal conversations.

Why it matters: The organization cannot see recurring causes, aging work, unresolved risk, or the evidence behind a decision.

Minimum evidence

  • A named exception type and status
  • An owner, due date, evidence request, and escalation rule
  • A final resolution linked to the underlying record

First useful test

Sample ten recent exceptions and ask whether another reviewer can reproduce the outcome from the retained record.

Sources behind this pattern
Build from this pattern Build a decision pack

Pattern 07 · Evidence and control

Reporting is collected without a decision path

#

What you see

Teams gather status reports, supporting files, or performance measures but do not connect them to review, corrective action, escalation, or closeout.

Why it matters: More reporting creates administrative load without changing oversight or operational outcomes.

Minimum evidence

  • Each requirement mapped to an owner and acceptable evidence
  • Review criteria and a response to missing or unacceptable evidence
  • A documented close, continue, correct, escalate, or stop decision

First useful test

Pick one requirement and trace it from submission through the decision it changed.

Sources behind this pattern
Build from this pattern Use the grant monitoring kit

Pattern 08 · Evidence and control

The portfolio contains projects that cannot be compared

#

What you see

Initiatives enter the roadmap with different definitions of value, cost, risk, urgency, dependency, and completion.

Why it matters: Leadership prioritizes narratives instead of comparable operating evidence and cannot explain why work started, moved, or stopped.

Minimum evidence

  • A common problem, outcome, owner, cost, risk, and dependency record
  • A smallest next decision rather than an assumed full project
  • A start, sequence, hold, combine, return, or stop decision

First useful test

Place three proposed initiatives side by side using the same intake fields and identify what remains incomparable.

Sources behind this pattern
Build from this pattern Use the portfolio intake kit

Pattern 09 · AI and automation

The AI demonstration is a presentation

#

What you see

The vendor shows curated examples or slides instead of running a common, representative test with observable inputs, outputs, errors, and human decisions.

Why it matters: Buyers cannot compare performance, failure modes, operating effort, or whether the system is suitable for the actual workflow.

Minimum evidence

  • A common representative test set and disclosed conditions
  • Expected outputs, unacceptable outcomes, and human review steps
  • Retained test results, errors, explanations, and unresolved questions

First useful test

Require each vendor to perform the same bounded task using the same safe sample and evidence standard.

Sources behind this pattern
Build from this pattern Build an AI evidence agenda

Pattern 10 · AI and automation

Human authority is implied, not designed

#

What you see

The team says a person remains in the loop but cannot name what the person sees, can override, must document, or is accountable for deciding.

Why it matters: A nominal human review can become a rubber stamp when authority, evidence, time, and escalation are not built into the workflow.

Minimum evidence

  • Decisions the system may support and decisions it may not make
  • Evidence shown to the authorized reviewer
  • Override, escalation, logging, and appeal conditions

First useful test

Walk one adverse or high-impact output and ask exactly who can stop, correct, or reverse it.

Sources behind this pattern
Build from this pattern Scope the AI decision

Pattern 11 · AI and automation

The service can change without reacceptance

#

What you see

Models, prompts, integrations, data sources, or vendor terms may change without a defined notice, regression test, approval, or rollback path.

Why it matters: A service that passed evaluation can behave differently later while the public organization remains accountable for its use.

Minimum evidence

  • Material-change definitions and notice requirements
  • Regression tests tied to the accepted operating conditions
  • Approval, rollback, suspension, and exit rights

First useful test

Ask what can change after acceptance and which changes trigger a new test or approval.

Sources behind this pattern
Build from this pattern Open the AI worked example

Pattern 12 · K-12 operations

The security plan has no recovery proof

#

What you see

The organization can point to policies, backups, or vendor assurances but not to a recent exercise, restore result, named decision owner, or recovery sequence.

Why it matters: Written controls do not show whether people, systems, vendors, and communications can restore critical services under pressure.

Minimum evidence

  • A critical-service inventory and recovery order
  • Recent backup restore-test evidence
  • Named incident, communications, legal, privacy, and vendor decision paths

First useful test

Walk the first hour of one realistic scenario and identify the first three decisions that lack an owner or evidence.

Sources behind this pattern
Build from this pattern Run the K-12 readiness session

Source record

Primary-source disciplines used in this edition

Last verified August 26, 2026

The atlas translates recurring control and delivery disciplines into working questions. It does not declare that a particular organization failed, establish a legal conclusion, or make federal guidance universally applicable. Responsible officials must verify the rules and evidence that apply locally.