Diagnose the work and its boundary

Can the contributions be completed independently and combined at the end without either party revisiting a choice it has already made?

ExampleTwo teams build standard components against a settled interface, then assemble them without changing either component.

Can work normally move through a known, one-way handoff without later learning causing the earlier party to change its decision?

ExampleAn API contract is accepted, then a client team implements against it; a late handoff may delay the client, but it does not make completed client work wrong.

Does a change in one function require a substantive response from another, followed by a further response back before either can proceed?

ExampleA hardware constraint changes firmware behaviour; that changes the product promise; the revised promise then changes the hardware or firmware choice again.

At the next handoff, will the receiving party need information that cannot be honestly named or specified today, and that the teams will recognise only while working?

ExamplePerformance testing may reveal which telemetry, fallback behaviour, or customer exception the downstream team actually needs.

Does new evidence from another part of the work make an existing commitment materially wrong, so that output must be revised, replaced, or discarded?

ExampleA safety test exposes a thermal limit, making completed charging logic, test cases, and customer guidance invalid rather than merely late.

Do the parties draw on the same finite constraint and need to make a trade-off between their needs?

ExampleBoth teams need the same engineering capacity, safety margin, market window, budget, or sales attention; allocating more to one leaves less for the other.

When the work fails to coordinate, is the usual consequence completed work that must be redone or discarded, rather than only a late handoff?

ExampleCode, test automation, operating guidance, or a customer commitment has to change after a contradiction is resolved.

Does a disagreement become visible to the relevant people and reach a decision before dependent work has time to harden around the unresolved position?

ExampleA conflict found on Tuesday is resolved in the working loop, rather than waiting until the next monthly programme review while dependent teams continue to build.

Can the people who hold the technical, commercial, and operational context resolve the trade-off without routine escalation to a programme board or senior sponsor?

ExampleA cross-functional working group can choose between a lower performance target and a later release without waiting for a monthly steering meeting.

Do the parties share enough evidence, history, and assumptions that adjustment starts with the trade-off itself, rather than a long reconstruction of background?

ExampleThe people deciding can inspect the same test result, customer promise, and prior decision instead of spending the first twenty minutes explaining why each matters.

When a commitment changes, are the change and its reason visible where dependent teams work, rather than disappearing into a private call or chat thread?

ExampleThe revised threshold and why it changed appear in the shared decision record or delivery tracker, where engineering, product, and support can find them.

Does a person or regular working forum integrate cross-boundary consequences as normal work, rather than reviewing them only after a milestone is at risk?

ExampleAn empowered integrator or cross-functional working session checks the change across hardware, software, product, and support before each side commits more dependent work.