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."