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.

A. Product / value

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

☐ Is a benefits / value owner named?

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

☐ 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. Produce a one-page position for the sponsor: what is known, unknown and decision-due.

3. When conflict of interest is material, use an independent diagnosis rather than relying solely on the implementation team assessment.

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. It is not a completed client report and does not claim client results.

Executive conclusion

[1–2 paragraphs — blank]

Diagnostic questions answered / constrained

Question | Answer / constraint | Evidence link

[blank rows]

Evidence & confidence index

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

[blank rows]

Critical dependencies & decision latency

Dependency / decision | Owner | Due | Status

[blank rows]

Options (always include pause/stop)

• Pause

• Stop / controlled wind-down

• Continue under control

• Stabilize (bounded OS reset; capable receiver required)

• Restructure

• Rebuild or refer specialist

Recommendation & immediate actions

Action | Owner | Date

[blank rows]

Limitations, dissent, follow-on commercial interest disclosure

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

Appendices (hooks)

• Interview synthesis

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

• Clarity does not take over execution; client teams and vendors continue their assigned implementation work.

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.