Testing causal hypotheses

After organising the evidence, a different danger appears: confusing a symptom with a cause. “The project is late” describes a time difference. “There are too many meetings” is an observation that could be a cause of delay or a response to it. An attractive diagram of arrows is not enough without event order and a plausible mechanism. Start with a timeline of scope decisions, specification releases, resource approvals, deliveries, acceptance tests, and deferred decisions. For each event record the planned and actual date, dependency, and evidentiary source. A useful causal question is whether the disputed output date would have changed if one factor had not occurred, given the remaining constraints. That question does not create certainty, but it identifies a hypothesis that can be tested.

Organise diagnosis in three layers. The first contains observable symptoms, such as a four-week delay or 120 hours of rework. The second contains direct mechanisms, such as requirements revised after build began or an unavailable test environment. The third contains enabling conditions, such as no named change approver or failure to reserve the environment in the resource plan. Do not put “poor leadership” at the root until a specific decision or behaviour that could be changed has been identified. Problems can have several mechanisms. In that case an intervention should prevent their recurrence rather than suppress one visible symptom. End every branch of the causal tree with a test: which record would support it and what observation would contradict it?

Use competing hypotheses rather than one favoured story. If final delivery stalled, hypothesis A may be late supplier delivery, B delayed client approval, and C changed acceptance criteria after build. Seek discriminating evidence: a testable delivery timestamp, the approval request date, successive criteria versions, and each period's effect on the critical path. Do not add delays mechanically. Two days on parallel activities do not necessarily move launch by four days. Draw a simple dependency sequence and estimate the causal window. An approval three days late but off the critical path can reveal a governance weakness without explaining the specific finish-date slip.

Use counterevidence. If another team received the same requirements and did not rework, how did its experience, environment, or timing differ? If a supplier had received approval early, was there an independent constraint? Comparison with nearby cases helps, but context differences limit the conclusion. Ask for examples that run against the preferred explanation: were some changes approved rapidly while delivery still slipped? That would weaken the claim that all delay came from a slow change board. Do not select the sponsor's supporting record and discard the rest. In the finding, state confidence, its basis, the strongest alternative explanation, and the next test if the decision remains high-stakes.

The practical recommendation is not merely “hold more meetings.” Name two controls: assign a payment-design decision owner with an approval deadline and escalation route; and establish a backup integration environment or a readiness gate before build begins. The first reduces approval waiting but not environment failure. The second addresses technical unavailability but does not accelerate a missing decision. If a backup is costly, pilot it for the high-impact payment component. Measure approval waiting time, environment downtime, and rework against defined pre-intervention baselines. Meeting count is a weak success measure: it may rise while decisions remain blocked.

Phrase the finding to match the evidence. “Late approval contributed approximately five working days to the payment chain under the stated calendar assumption; the rest of the slip is unallocated” is more defensible than “the client caused the delay.” The estimate changes if weekends are excluded differently, if independent build work could have started before approval, or if the environment remained unavailable after day 13. Naming such conditions is not an excuse for vagueness. It tells the authorised decision maker what additional information is worth obtaining before purchasing an expensive remedy.

— deeper instruction

When a causal hypothesis leads to expensive advice, seek a cheaper discriminating test before commitment. If test-environment speed is said to explain the whole delay, compare one day in an alternate environment with ordinary work on the same task version, then inspect whether the downstream activity actually moved. If design approval still blocks it, the environment was not the only bottleneck. Do not generalise a one-day result across the entire project. Use it to recalibrate confidence and choose the next test. Record what result you expected if your preferred hypothesis were wrong, so that every possible observation cannot be reinterpreted as support for the same story.