Handling Ambiguity
Making progress when the requirements are unclear, the stakeholders disagree, and waiting for clarity is not an option.
Definition
Most real architecture happens before the requirements are settled. The skill is progressing anyway, without either freezing or committing prematurely.
The techniques
Separate what is unknown from what is undecided. Unknown facts can be researched. Undecided positions need a decision-maker, and identifying which you face determines who to go to.
Do the work that is independent of the answer first. In almost every ambiguous situation a substantial part of the design does not depend on the open question. Doing it produces progress and frequently clarifies the question.
State assumptions explicitly and proceed. "We are assuming a peak of 5,000 concurrent users; if it is 50,000 the design changes in these ways." That is far better than waiting, and it frequently prompts the answer — stakeholders correct a stated assumption more readily than they answer an open question.
Design for a range rather than a point. If the number might be 10x or 100x, ensure the design works at 10x and can be extended at 100x.
Prefer reversible moves while ambiguity persists. Keep the one-way doors closed until the ambiguity resolves; make the two-way ones freely.
Force the decision where it is genuinely blocking. Present two or three options with consequences and ask for a choice. Stakeholders decide far more readily between options than in the abstract, and an open question rarely resolves itself.
What to avoid
- Waiting for clarity that will not arrive.
- Guessing silently, so the assumption is invisible and unchallenged until it is wrong.
- Designing for every possibility, which produces a system optimised for nothing.
- Escalating every ambiguity, which teaches the organisation you cannot operate without direction.
The communication that makes it acceptable
Be explicit about what is assumed, what is decided, and what remains open. A design document with a clear "open questions" section and stated assumptions is far more credible than one that appears certain — and concealed uncertainty is discovered later at greater cost.
Interview question
"You must start designing and the requirements are genuinely unclear. What do you do?"