Agreement on the requirements baseline

1. Define the decision object

Approving a baseline means agreeing the requirements reference from which work will proceed. The team needs to know what enters that reference, what was deferred and which assumptions remain open. A signature on a presentation titled “Migration” may be insufficient when two incompatible requirements versions exist.

Prepare an identifiable proposal: version, included capabilities, exclusions, relevant criteria and earlier decisions constraining it. In a fictional reconciliation project, B7 includes matching movements and recovering queues, while a new dashboard remains deferred.

The decision on B7 does not implicitly approve the dashboard or demonstrate that the solution has been built. Before the meeting, confirm that decision makers can access material describing the same proposal. A stable, understandable reference supports discussion of substance; a technical identifier without an explanation of consequences does not replace understanding.

2. Choose a technique compatible with authority

Facilitating consensus, ranking preferences and obtaining approval are related activities, but they may use different rules. Voting helps reveal preferences; it decides approval only when the applicable governance gives it that effect. Define participants, quorum, decision threshold, reserved rights and the treatment of objections in advance.

In this exercise, a baseline can be approved with two favorable votes out of three, provided the owner confirms any change to a mandatory control in their area. Two votes cannot replace that confirmation. Another context may have one approval owner supported by specialist consultation.

Do not apply the exercise's rule to every project. Also explain what consensus means: everyone's support, absence of a reasoned objection or willingness to accept a decision can mean different things. The technique should make agreement observable and enable a disagreement to be routed, rather than produce a count with no defined meaning.

3. Investigate the reason for an objection

When two teams disagree, ask which consequence each is trying to avoid and what evidence could change their position. “We do not approve this requirement” may mean the rule was misunderstood, capacity is missing, a control conflicts or another option offers greater value.

These reasons require different responses. In one example, APS reads “recover automatically” as replaying already confirmed movements; development intended to resume only pending ones. An example showing input, state and outcome clarifies behavior before approval is collected.

If clarification changes the material commitment, update the proposal and let decision makers assess the change. If a preference for a deferred dashboard remains, record its reason and future disposition without artificially turning it into a mandatory-requirement violation.

The facilitator helps make reasons comparable and understood; they do not give themselves authority to settle every conflict.

4. Make international participation usable

Distributing an English document does not establish that participants understood the same commitments. Prepare a summary with examples, consequences and decision questions; ask representatives to explain the highest-risk points in their own words.

This exposes differences that a general invitation for questions may miss. For an asynchronous decision, agree the response period, accepted channel and how approval, objection and absence will be recorded. In one exercise, a missing response requires contacting the designated alternate; it does not count as a favorable vote.

When a message comes from a different colleague, confirm that delegation covers this decision and period. The aim is valid participation without requiring everyone to join a call simultaneously. Retain relevant responses and the version they addressed.

Translation must preserve conditions such as “within two minutes”, rather than merely use familiar terminology for each team.

5. Record the effect and limits of agreement

A decision record should let another person reconstruct what was approved and by whom. Include the reference, applied rule, outcome, relevant reasons and conditions. Distinguish a condition preventing approval from taking effect from a later action the decision permits to be tracked.

For example, “approve only after consumer confirmation” leaves the decision dependent on that confirmation; it is not equivalent to “approve now and track training on the agreed date”. If wording is ambiguous, confirm the decision maker's intent before translating it into a status.

An objection may remain recorded even when the authorized rule produces approval. There is no need to erase disagreement or claim unanimity. In incremental delivery, the approved reference may cover only the defined increment; future items retain their status.

When a material change arrives, compare the new commitment with approved scope and route the necessary decision. Earlier approval retains historical value without automatically covering everything added later.

6. Workshop: a valid decision with recorded disagreement

Fictional conditions: B7 contains retention requirement R41, matching requirement R42 and recovery requirement R43. Dashboard R44 is deferred. The rule requires two favorable votes among Business, APS and Security, plus the relevant owner's confirmation when a mandatory control changes.

B7 retains the already confirmed R41; Business and APS vote in favor. Security understands the proposal and prefers to include R44 without identifying a control violation. Write the outcome and remaining decisions.

Worked reasoning: the two votes satisfy the rule and no control changed; approval of B7 can be recorded while preserving Security's preference and R44's deferral. Do not describe unanimity. Variation: B8 reduces R41 retention and lacks the control owner's confirmation.

The same two votes no longer suffice to make B8 effective. Record the pending condition and obtain the competent decision. The difference is not the number of votes: it is the condition applicable to each proposal's content.

Common pitfalls

Votes without a rule; silence as consent; preference as a universal veto; a prerequisite treated as a follow-up action; a baseline as proof of a delivered solution.