You are handed a design brief for a system spanning four departments. What do you do before designing anything?

Map who decides, who is affected and who can stop it

Three distinct groups, frequently conflated:

Decision makers — who signs off scope, budget and the trade-offs. Usually fewer people than the invitation list suggests.

Affected parties — whose work changes. They are often not in the room and they determine whether the system is adopted.

Blockers — security, legal, procurement, a platform team, a union. Each can stop a launch late and cheaply, and each is far cheaper to engage early.

Then find the conflicts before designing around them

Four departments will want incompatible things — usually about data ownership, process order or who is accountable for an outcome. Those conflicts do not resolve themselves during implementation; they surface at user acceptance testing as a disagreement the architecture cannot satisfy.

Surface them deliberately: interview each separately, then present the contradictions together. It is uncomfortable and it is far cheaper than discovering them in integration.

Establish who arbitrates

If the four departments disagree and there is no named decision maker above them, the design will oscillate. Getting that person identified — and getting them to accept the role — is a precondition, not a formality.

What to produce

A one-page map: names, their interest, their influence, what they need, and how they will be engaged. It looks like project management and it is architectural, because every unresolved stakeholder conflict becomes a structural compromise in the design.