Evidence register and triangulation

Consulting does not begin by believing the latest status dashboard. It begins by identifying what each indicator purports to measure. A board report may show 80% complete while a test log says half the critical scenarios have yet to run. Neither number is necessarily fabricated: one might be the fraction of tasks closed, the other the fraction of functional outputs accepted. Record the definition, unit, cutoff date, and recorder of each measure. Before calling the project nearly finished, ask whether tasks were weighted by effort or value, whether migration and training are included, and whether closure was independently checked or estimated by the assignee. Inconsistent definitions can themselves explain apparently conflicting evidence.

Build an evidence register with short rows: a specific claim, original source, date, scope, directness of the source, contradictory material, and the test needed to resolve it. The primary record of a scope change is the approved decision or signed change log, not a slide summarizing it. For spending, separate paid invoices, purchase commitments, and estimates for unfinished work. For acceptance, separate supplier delivery from client approval. A document is not always superior to an interview: minutes may prove formal authorization while an interview reveals that a team followed a different version. Triangulation examines one claim using different kinds of evidence; three reports repeating the same unverified statement are still one evidentiary chain.

Classify each finding as established, likely, disputed, or unavailable using an explicit rule. Established can mean an original record consistent with an execution trace, not metaphysical certainty. Likely means convergent indications with a gap that does not change a low-stakes decision. Disputed means material sources conflict and require a test. Unavailable means a record was not supplied, not that the event did not occur. Failure to find approval minutes does not prove that approval was never granted. Search the archive or ask the decision owner and set a date for closing the gap. Match the strength of testing to the stakes: a large budget change requires stronger evidence than a cosmetic change to a report.

Inspect the data's origin and transformations. If a programme manager reports 42 of 50 tasks complete, request the task list, the definition of complete, and the timestamp. Perhaps the denominator omitted ten tasks added after the original scope was approved. Including comparable tasks gives 42 of 60, or 70%, if the closure criteria are consistent. That fraction alone says little about the finish date: one remaining critical-path activity could delay launch. Explain the difference between correct arithmetic and a metric fit for a launch decision. A task closure rate cannot stand in for user acceptance when the sponsor needs to know whether the service works.

In interviews, ask for events before explanations. “Which decision were you waiting for, when did you request it, and which next activity was affected?” is more productive than “Why did procurement fail?” Record who said what, distinguish direct observation from inference, and offer a factual summary for correction without allowing one participant to erase another's view. Protect personal names when the role is sufficient. When a supplier and product owner disagree on acceptance, request the version of the criteria each used and when it was communicated. The dispute may reflect an unpropagated specification change, an omitted test, or a resolvable misunderstanding. Bad faith is a conclusion requiring evidence, not a starting label.

Test sensitivity to new evidence. If the four tasks were formally accepted after the team's list, the acceptance percentage changes, but a payment-blocking defect remains an independent constraint. If the defect is minor and has an approved workaround, a limited release might become possible with acceptance by the risk owner. State what evidence would change your recommendation and what would not. This focuses collection on a decision instead of accumulating documents that cannot affect it. If customer data are inaccessible, use a permitted anonymised sample or simulation. Lack of sensitive access is not a reason to seek broader permissions than the mandate requires.