Decision framing and engineering operating diagnosis · Lesson 4

Test rival explanations of delay

5 min read

Lesson objectives

  • Build falsifiable hypotheses about engineering delay and select low-cost evidence that distinguishes them before recommending an expensive intervention.

When design packages are late, a manager may blame understaffing, an engineer may cite changing requirements, and a supplier may cite delayed purchase decisions. Each account may describe some packages, but putting the accounts in one meeting does not prove one explanation for every delay. The adviser converts complaints into hypotheses that predict different traces in the work record. 'Too few people' alone is weak; make it testable: with complete, stable inputs, waiting before first review increases because review capacity falls below the arrival rate of ready packages. A requirement-change hypothesis predicts an early comment followed by revision after the baseline. A procurement hypothesis predicts technically ready packages waiting for a supplier decision or final data. Do not turn people's names into causes before checking event order.

Build a four-column test matrix: hypothesis, expected observation, observation that would weaken it, and required data. Supporting evidence may fit several explanations; discriminating evidence changes their relative plausibility. Delay in ten packages shows a problem but does not separate reviewer scarcity from incomplete inputs. Dates of input readiness, first comment, and requirement change do more. Sample on-time as well as late packages; looking only at late cases hides whether change is just as common among successes. Record sample limits and request the original event log rather than a selected summary. Reconstruct each package timeline. Where key timestamps are missing, recommend a short period of better logging before claiming to know the cause.

Do not equate correlation with causation. Rework may rise in weeks when a manager assigns more reviewers because extra reviewers were a response to trouble, not its cause. Approval may take longer because a safety review found a defect, and that time has preventive value. Use event order, comparison among similar packages, and a bounded trial before proposing major reorganization. Prioritize hypotheses by decision impact and uncertainty: an expensive staffing commitment that cannot be reversed quickly deserves stronger evidence than a two-week reserved review slot. When operational safety is at stake, do not wait for lengthy statistical analysis before escalating to the authorized person and holding affected work under the organization's procedure.

In the unit's advisory report, separate what the register establishes arithmetically, what the comparison suggests, and what needs testing. The adviser can say that requirement changes were more common among late packages in this sample. The adviser cannot promise that freezing requirements will remove half the delay. Write a reversal condition before the trial: if rework time does not fall under a controlled version while review quality remains intact, investigate waiting and procurement explanations. If rework time falls but field defects rise, the trial has not succeeded. Keep the change log so follow-up results can be interpreted. This gives the authority a revisable recommendation instead of treating the first numerical association as certain cause.

Lesson summary

Build falsifiable hypotheses about engineering delay and select low-cost evidence that distinguishes them before recommending an expensive intervention.