Project Intelligence Root Cause Analysis

Root Cause Analysis

Purpose

Take the change log in the Change Events list and produce a complete causal analysis: the root cause, the chain of events that followed from it, the signals that were present but not acted on, and a clear verdict on what could have prevented the outcome. Every finding must be traceable to a specific event number in the list.

Inputs Required

This skill reads from the Change Events list on this SharePoint site, populated by the Change Event Extraction skill. If the list is empty, run Change Event Extraction first.

Step 1 — Apply the Counterfactual Root Cause Test

For each HIGH signal-strength event in the change log, apply the following test:

"If this event had been handled correctly — escalated, change-ordered, validated, or resolved — would the downstream impact events still have occurred?"

Score each candidate event on three dimensions:

The event with the highest combined score is the primary root cause. If two events score equally, prefer the earlier one (earlier failures compound more).

State which event number from the change log is the root cause, and show the scoring table.

Step 2 — Trace the Causal Chain

Starting from the root cause event, trace the forward sequence of events that led to the impact event (the moment the failure became visible or unavoidable).

For each step in the chain:

• Reference the event number from the change log
• State what happened
• State why it followed from the previous step
• Identify whether there was an intervention window at this step — a point at which the chain could still have been broken

Maximum 8 steps. If the chain is shorter, do not pad it.

Format:

[Event #N] → [What happened] → [Why this followed] → Intervention window: [Yes/No — if yes, what would have closed it]

Step 3 — Map Intervention Windows

For each point in the causal chain where intervention was still possible, produce a structured entry:

For the "Why not taken" column: use only what the documents say. If there is no documented reason, state "Not documented — possible reasons include [infer from context, max 2 options]".

Step 4 — Early Warning Signal Analysis

From the change log, identify every event that was a signal of the eventual failure — regardless of whether it was labelled as such at the time.

For each signal, complete the following table:

Detectability — was the signal visible to a normally attentive PM or delivery lead?

• HIGH: the signal was explicit and named in a document
• MEDIUM: the signal required connecting two or more documented facts
• LOW: the signal was present only in hindsight, or buried in a technical appendix unlikely to be read

After the table, state:

• Total signals identified
• Signals with HIGH detectability that were not acted on (these represent the clearest governance failures)
• Average lag in weeks between first HIGH-detectability signal and the impact event

Step 5 — Failure Classification

Classify the failure on two axes:

Primary failure type — select the most accurate:

• Scope creep: undocumented additions to agreed deliverables
• Assumption failure: a baseline assumption was accepted without validation and proved materially wrong
• Governance failure: change control processes were not followed when they should have been
• Technical underestimation: complexity or volume was not anticipated and not discovered until late
• Resource / dependency failure: a third-party dependency, unavailability, or skill gap caused the failure
• Communication failure: decisions were made but not documented, leading to misaligned expectations
• Compound failure: multiple types contributed — specify which two or three, and which was primary

Secondary dimensions (rate each 1–5):

State each rating and a one-sentence justification.

Step 6 — Produce the Recommendation

State a single primary recommendation — the one action, if implemented, that would most have changed the outcome.

Structure the recommendation as:

RECOMMENDATION [One sentence — the specific action]

When to implement: [At which point in the engagement — e.g., "before sign-off on the project plan", "at the Week 2 discovery workshop close"]

Owner: [Role responsible for implementing this — be specific, e.g., "Engagement Manager", "Data Architect", "Client Sponsor"]

What it changes: [One sentence — the specific downstream events this would have prevented, with reference to event numbers from the change log]

Implementation detail: [2–3 sentences describing exactly how this would be done in practice — not generic advice]

Step 7 — Persist findings

7a — Write back to the Change Events list

Update the following items — do not modify any other columns. An event may qualify for more than one category; apply all relevant updates:

• Root cause event: set Is Root Cause = Yes, set Root Cause Statement to the one-sentence root cause statement from 1.1, set Causal Chain Step = 1.
• Causal chain events (each step from 1.2, in sequence): set Causal Chain Step to the step number (root cause = 1, next = 2, etc.).
• Intervention window events (each event from Step 3): set Intervention Window = Yes, set Intervention Action to the one-sentence description of the action that was available at that point.
• Early warning signal events (each event from Step 4): set Early Warning Signal = Yes, set Detectability to the rating from the signal table (HIGH / MEDIUM / LOW).

7b — Save analysis document to Project Documents library

Save the full analysis (all three sections) as a document to the Project Documents library.

Filename: Root_Cause_Analysis_[YYYY-MM-DD].docx — where the date is the date of the most recent status report in the library.

Document header (before the analysis content):

• Analysis run: [today's date]
• Covers documents through: [title and date of the most recent status report in the Project Documents library]

7c — Update SHAREPOINT.md

Add or overwrite the Project Analysis Summary section in SHAREPOINT.md with:

• Last analysis run: [today's date]
• Covers documents through: [date of most recent status report]
• Root cause: Event [#] — [title]
• Root cause date: [date]
• Root cause statement: [one sentence]
• Causal chain: [numbered list, max 8 steps, one sentence each]
• Failure type: [primary classification]
• Preventability: [rating 1–5]
• Recommendation: [one sentence]

After all three steps complete, confirm: "Analysis saved to [filename] in the Project Documents library. Change Events list updated. SHAREPOINT.md updated."

Output — produce the following in chat

SECTION 1: ROOT CAUSE ANALYSIS REPORT

Begin with the following framing statement, exactly as written:

"Names in this analysis record who held information or decision authority at each point. This analysis identifies process and governance gaps — where controls were needed and not in place."

Then state: "The Change Events list has been updated — root cause event, intervention windows, and early warning signals are now flagged."

Present the analysis in the following order:

Root Cause

State the root cause event number, title, and date. Then the one-sentence root cause statement from Step 1.

Causal Chain

Numbered sequence (max 8 steps): event number, what happened, and whether an intervention window existed at this step. One sentence per step.

Failure Classification

Primary failure type. Preventability rating (1–5) with one-sentence justification.

Recommendation

Structured recommendation as specified in Step 6: what, when, owner, what it changes.

Do not include the counterfactual scoring table, intervention windows table, or early warning signal table here — those appear in full in the Detailed Full Analysis (Section 2).

SECTION 2: THREE SUMMARY LEVELS

Produce all three of the following, clearly labelled:

ULTRA-SHORT SUMMARY

For: executive slide decks, steering committee updates, RAID log entries

Write 4–6 bullet points. Each bullet is one sentence. Cover only: what the root cause was, how long the warning window was open, what failure type this represents, and the single recommendation. A reader should understand the verdict in 20 seconds. No background, no process detail.

GET ME UP TO SPEED

For: a delivery director being briefed, a client asking "what went wrong", a new PM inheriting the engagement

Write 3–5 paragraphs. Chronological. Imagine briefing someone intelligent who knows nothing about this project and has 3 minutes. Cover: what the project was, what the root cause event was and when it happened, what signals appeared and how they were handled, what the causal chain looked like from the outside, and what the recommendation is. Include specific event numbers, dates, and names from the change log. Write in plain English — no jargon, no passive voice.

DETAILED FULL ANALYSIS

For: post-mortem reviews, governance audits, contract disputes, project retrospectives

A structured narrative with one paragraph per step of the analysis. This is the complete record — every finding matters. Include:

• The full counterfactual scoring table (all candidate events, all three dimensions)
• The full intervention windows table (all columns from Step 3)
• The full early warning signal table (all columns from Step 4) with the three summary statistics
• The failure classification with all secondary dimension ratings and justifications
• The recommendation with full implementation detail

Do not summarise away detail. This section should be suitable for a formal project review or a legal review of the engagement record.

SECTION 3: ROOT CAUSE INTELLIGENCE DASHBOARD

Produce this section under the heading ## ROOT CAUSE INTELLIGENCE DASHBOARD.

Root Cause Metrics

Signal Disposition Summary

For each signal in the early warning table, show its disposition: Actioned / Logged but not resolved / Noted informally / No action taken / Not documented.

Present as a horizontal bar or count breakdown:

• Actioned: N
• Logged but not resolved: N
• Noted informally: N
• No action taken: N
• Not documented: N

Top 3 Intervention Failures

The three intervention windows where action was most available but not taken, ranked by downstream impact:

1. [Window description — date — who could have acted — what was the specific action available]
2. [Window description — date — who could have acted — what was the specific action available]
3. [Window description — date — who could have acted — what was the specific action available]

Failure Classification Summary

State:

• Primary failure type
• Whether this was a systemic or one-off failure (systemic = the same failure pattern is likely in other engagements run the same way; one-off = specific to unusual circumstances)
• One sentence on what changed in the organisation's delivery approach would prevent this class of failure recurring