Acceptance of the developed solution

1. Prepare the decision from the delivered solution

Requirements approval establishes a reference; acceptance of the developed solution concerns what was delivered. Prepare the second decision using the candidate version, demonstrated scope, results against criteria and known gaps. A list of green tests with no connection to the commitment may not answer stakeholders' questions.

In a fictional middleware replacement, decision makers need to know whether agreed processing, recovery and operation were demonstrated for the proposed version. Summarize what meets criteria, what remains unresolved and which options the applicable authority can choose.

Include a recommendation and its rationale so each decision maker need not reconstruct the entire technical history. Keep detailed evidence accessible for those who need to inspect it. The analyst organizes these connections and facilitates the decision; a well-presented package does not automatically transfer solution acceptance authority to them.

2. Obtain decisions covering the necessary responsibilities

Identify which responsibilities acceptance requires in the project's context. Business confirmation of functional outcomes may not cover an operational obligation reserved for APS. Conversely, operational approval does not resolve disagreement over expected user behavior.

The package should show who decides each matter and how those decisions compose the outcome. This lesson's exercises state the rule explicitly; an actual project must confirm its applicable governance. Do not require a signature from every contributor when the rule designates representatives with sufficient authority.

That can delay an already valid decision without adding coverage. When a representative is absent, use the provided delegation after confirming scope and validity. A meeting with many attendees is not itself a complete decision.

What matters is coverage of the required responsibilities for the same acceptance object.

3. Define the effect of an accepted limitation

A known limitation can receive different treatment depending on its nature and available authority. If the rule allows a presentation discrepancy to be accepted, the owner can do so with explicit scope, rationale, action and timing. That decision must not be extended to a mandatory control the same rule does not permit to be waived.

Nor should every limitation be presumed to require rejection of the whole solution. Present options within actual boundaries: correct before acceptance, accept a permitted limitation or defer the decision. Clarify whether a condition must be met before deployment or may be tracked afterward.

“Accepted subject to demonstrated recovery” does not establish readiness while that demonstration is missing. Record an observable condition and who confirms it. Pressure from a maintenance window may justify bringing decision makers together quickly, but it does not independently change the meaning of the condition they approved.

4. Connect acceptance to the version that will proceed

The decision must identify the solution it covers. If the version changes after sign-off, check whether the change affects scope, criteria, evidence or decision conditions. Not every difference requires repeating every test; impact analysis may justify reusing valid evidence and confirming only the affected part.

However, a “small patch” label does not establish equivalence. In a fictional example, R9 was accepted with a tested queue configuration and recovery behavior. R10 changes those queues' retry policy.

The R9 package does not automatically decide R10 even if the supplier retains the commercial name. Identify the difference, obtain the appropriate assessment and route the decision for the current reference. Preserve the earlier decision rather than retrospectively changing the version it names.

This makes each point-in-time decision understandable and prevents history from appearing to demonstrate an assessment that never occurred.

5. Communicate what can proceed and what remains conditional

A solution can be accepted while still awaiting an authorized deployment window. Sign-off is a relevant input to proceeding, but other project conditions may remain applicable. In one exercise, Business and APS accept R9; operational authorization permits deploying R9 only on Monday between 22:00 and 23:00.

Communicate both facts: the solution is accepted and execution is planned within that window. Do not turn approval into an instruction to execute immediately or describe acceptance as nonexistent because the window has not arrived. Use statuses preserving these distinctions and identifying the next action.

After deployment, follow value measurement with the assigned owners. Acceptance of demonstrated behavior does not guarantee all savings forecast in the business case. The handover to operations should make the decision outcome, continuing conditions, follow-up ownership and support reference clear.

6. Workshop: prepare the acceptance record

Fictional conditions: R9 demonstrated matching for the complete test population and recovery in 18 minutes against a 20-minute limit. Business may accept presentation differences and accepts an abbreviated label with a later correction and owner.

APS confirms operational criteria. The rule requires these two decisions; both identify R9. A separate authorization permits deploying R9 on Monday between 22:00 and 23:00.

The supplier proposes replacing R9 with R10, which changes retry behavior after a timeout and has not been assessed. Write each version's status, the immediate action and the limitation that must remain in the record. Worked reasoning: R9 has valid acceptance under the stated conditions, with the accepted label and follow-up action; preparation for its authorized window can proceed.

R10 needs change analysis, applicable evidence and a corresponding decision. Retain R9 as an available alternative if technically usable and within authorization. Do not extend sign-off to the new behavior or automatically reopen every decision without assessing impact.

Common pitfalls

Requirements approval as solution acceptance; sign-off transferred between versions; a missing condition as a completed action; acceptance as immediate execution or guaranteed benefit.