ACUTE PMC

Troubled Technology Project Assessment Checklist


A practical self-assessment for troubled technology projects and a Clarity-style decision brief.


TL;DR

A troubled technology project needs an evidence-backed view before more spend. This page publishes an assessment checklist across Product, Process, People, Technology, ownership and decision-rights signals, plus an illustrative blank Clarity-style Project Health and Decision Brief structure.


Completing the checklist does not qualify a buyer for any Acute intervention. Findings inform decisions; they do not select Diagnose, Stabilize or Lead Recovery by themselves.


What “troubled” means here

Troubled means material uncertainty; a status-vs-reality gap; slipping, stalled or unstable delivery; or consequential decisions pending.


Distinguish:

• Troubled — uncertainty and control/evidence problems; usual first need: independent diagnosis / decision pack.

• Failed — recovery path rejected or value destroyed; usual first need: controlled closure, lessons and obligations.

• Active operational incident — current or imminent operational harm; incumbent incident containment first—not ordinary diagnose.


Assessment checklist

Mark each item RAG or 1–5 if you wish. Unknown ≠ green. List unknowns explicitly.


  1. Product / value

  2. ☐ Is the business case still valid under current scope and constraints?

  3. ☐ Is a benefits / value owner named?

  4. ☐ Is remaining value vs cash-to-complete known at decision grade?

  5. ☐ Are immutable contractual, regulatory and transition obligations listed

B. Process / control

☐ Is there a credible dated baseline (not a hope reset)?

☐ Does change control actually bind scope?

☐ Are forecasts traceable to evidence—or aspirational?

☐ Does a measurement / acceptance register exist (even draft)?


C. People / sponsorship

☐ Is a sponsor and deputy who can bind decisions named?

☐ What is decision latency on critical items?

☐ Is a receiving delivery owner named and funded?

☐ Are political blockers and escalation routes explicit?


D. Technology / delivery evidence

☐ Are known technical risks listed with owners?

☐ Are integration / vendor constraints visible?

☐ Is status reporting reconcilable to operational evidence?

Non-claim: this checklist is not an exhaustive code audit unless separately scoped.


E. Ownership & decision-rights signals

☐ Who owns execution vs who owns advice?

☐ Is there a decision-rights schedule: decisions, tolerances and escalation?

☐ Watermelon signals: green decks vs red operational reality?

☐ Sponsor confidence vs evidence confidence—do they match?


How to use without a consultant

  1. Score or RAG each item; keep unknowns visible.

  2. 2. Produce a one-page position for the sponsor: what is known, unknown and decision-due.

  3. 3. Prefer independent diagnosis language—not the implementer’s audit—when conflict of interest is material.

  4. 4. If you only need a decision pack, that points toward Diagnose. Severity alone does not unlock Stabilize or Lead Recovery.

Example contexts include Workday / Oracle Fusion payroll distress, post-go-live remediation and other troubled technology programs.


Entry / disqualification (educational mirror of Clarity)

Usually answerable: sponsor decision required; minimum evidence path exists; truth-seeking allowed.

Usually reject or pause ordinary diagnose: predetermined “prove continue”; concealed conflicts; denied minimum evidence; unmanaged active incident without incumbent containment.


Sample Clarity Brief structure — ILLUSTRATIVE BLANK

Illustrative blank structure only. Not a completed client report. No fabricated findings, metrics, logos or testimonials.


  1. Executive conclusion

  2. [1–2 paragraphs — blank]

  1. Diagnostic questions answered / constrained

  2. Question | Answer / constraint | Evidence link

  3. [blank rows]

  1. Evidence & confidence index

  2. Source | Finding | Confidence (H/M/L/Unknown) | Owner

  3. [blank rows]

  1. Critical dependencies & decision latency

  2. Dependency / decision | Owner | Due | Status

  3. [blank rows]

  1. Options (always include pause/stop)

  2. • Pause

  3. • Stop / controlled wind-down

  4. • Continue under control

  5. • Stabilize (bounded OS reset; capable receiver required)

  6. • Restructure

  7. • Rebuild or refer specialist

  1. Recommendation & immediate actions

  2. Action | Owner | Date

  3. [blank rows]

  1. Limitations, dissent, follow-on commercial interest disclosure

  2. [Blank — record dissent and any follow-on commercial interest honestly]

  1. Appendices (hooks)

  2. • Interview synthesis

  3. Assumption / risk extracts

What Clarity does not do (public non-claims)

• No exhaustive code/config forensic audit by default

• No legal/clinical opinion

• No guaranteed recovery, savings, or deadline preservation

• No automatic conversion to Rescue or Recovery

• Client retains execution after


When findings suggest Stabilize vs Lead Recovery (educational only)

Signal | Ownership posture to discuss (human-qualified)

Bounded control reset + capable receiving leadership | Stabilize

Ongoing leadership/coordination gap requiring delegated direction | Lead Recovery

Truth/decision only | Diagnose

Value much less than cost / unsafe authority gap | Stop / pause evaluation


Human qualification required. Checklist severity does not select the offer.


FAQ

Is this an implementer audit?

No. Independent diagnosis — not the implementer’s audit.


Does completing the checklist unlock Rescue?

No.


Is the blank brief a sample of Acute results?

No. It is structure only.


How does this map to Acute’s method?

TRUTH → CONTROL → RECOVERY → TRANSFER is a method, not purchase tiers


Related pages

• Decision table: /resources/continue-stabilize-restructure-stop-rebuild

• First-control (educational): /resources/first-control-window-72-hours

• Project Clarity — Diagnose · Rescue — Stabilize · Recovery — Lead Recovery

• /for-ai-agents


Contact: Andrew.Davenport@acutepmc.com

Acute Project Management Consulting LLC (Arizona) ≠ Mumbai lookalike.