Frame an advisory decision from conflicting evidence

A sponsor may say that the design team is slow and ask an adviser to identify who is responsible. That embeds a conclusion before defining a useful decision. The adviser first identifies a decision the sponsor can make, its deadline, and the options still open: add review capacity, stabilize design inputs before issuing more packages, or change the package sequence. Bound the question before analyzing it. A decision this week about next month's packages differs from an assessment of individual performance. A decision charter names the authority, required output, non-negotiable constraints such as safety checks and technical approval, and the point beyond which gathering more evidence will no longer help. This prevents a list of indicators from replacing a decision.

Start an evidence ledger with the unit, period, and source. The number of late packages is neither the number of engineers nor a percentage of lost hours. In this training case a review team received 24 packages over four weeks; 9 were returned at least once and 7 missed a target decision date. Do not infer that 9 of the 24 were late: the overlap is unknown, and a return may reflect useful detection of an error. Record the three observations separately, then add confidence and missing information: the first submission date, the first comment date, and the recorded reason for return. If 'package' means something different in design and construction registers, reconcile definitions before combining them. Where delay records are incomplete, state a range or check a sample instead of reporting false precision.

Construct two explanations that evidence could distinguish. Hypothesis A is a review queue constraint: packages with complete inputs accumulate at review, with a long gap between submission and first comment. Hypothesis B is late change to technical inputs: comments arrive promptly, then a package returns because a client requirement or interface drawing changes. Both may apply to different packages, so do not insist on one cause before classifying cases. For each hypothesis, write an expected observation and an observation that would weaken it. Request a timeline for six delayed packages across package types, not anecdotes chosen to confirm the sponsor's view. Compare waiting time before the first comment with rework time after it, while marking packages without documented timestamps. Formal decision analysis helps when criteria and uncertainty multiply; it cannot repair missing basic package-flow data.

In the advisory memo, distinguish 'observed,' 'plausible,' and 'recommended.' State a reversal condition. If time to first comment falls but total delay does not, investigate rework and later approvals instead of repeatedly adding reviewers. If interface changes stop but packages still wait for first comments, a capacity test gains force. Do not report 9 divided by 24 as a delay rate or failure probability; it is only the fraction of packages returned in that period. Comparisons across teams mislead unless their units and periods match. The adviser makes this limit visible to the decision authority and proposes a short evidence-gathering plan rather than turning the initial complaint into a judgment about people.