Skip to content
Back to Site

Decisions and Sign-off

Convert meeting outcomes into durable governance by recording the decision, authority, evidence, conditions, launch impact, accepted limitations, and closure status in one register.

The Decisions & Sign-off sheet makes important project choices explicit. Use it when a scope choice, accepted limitation, risk treatment, Full Migration decision, launch condition, or go-live approval needs a named owner, approver, evidence, and review state.

A meeting conclusion or chat message can guide work, but it is not a durable project decision until the agreed outcome, conditions, authority, and evidence are recorded.

Field groupFieldsHow to use them
IdentityDecision ID, Decision Type, Related IDsGive the decision a stable reference and connect the task, risk, validation, or redirect evidence that led to it.
DecisionDecision / Scope, Rationale, OutcomeState what is being decided, why, and the resulting approval state.
ConditionsConditions / Accepted LimitationsRecord the constraints, required follow-up, or limitation attached to the outcome.
AuthorityDecision Owner, Approver, Decision DateIdentify who prepared or owns the decision and who has authority to approve it.
Evidence and timingEvidence Link, Review / Expiry DatePreserve proof and schedule re-review when the decision is temporary or conditional.
Launch controlLaunch Blocking?, Review Status, NotesMake it clear whether the decision must close before launch and whether the record itself is complete.

Use decision types to keep the register searchable

Section titled “Use decision types to keep the register searchable”

Available decision types include Scope, Exclusion, Mapping, Additional Option, Add-on, Approved Customization, Accepted limitation, Risk treatment, Full Migration, Launch readiness, Go-live, and Post-launch closure.

Choose the type that reflects the decision being authorized. Do not use a decision row to duplicate an unresolved task or validation finding. Link to those rows and record only the decision that follows from them.

The available outcomes are Pending, Approved, Approved with limitations, Rejected, Deferred, and Not applicable.

Approved with limitations requires the accepted limitations or conditions to be recorded. The decision should also state who owns the remaining action and how closure will be verified when follow-up is required.

The workbook calculates Review Status as a completeness signal:

Decision stateReview Status behavior
Pending or DeferredOpen
Outcome is set but Decision Owner, Approver, Decision Date, or Evidence Link is missingIncomplete evidence
Approved with limitations but no conditions are recordedLimitations missing
Required decision and evidence fields are completeComplete

Set Launch Blocking? = Yes when the project cannot be authorized for launch until that decision reaches an acceptable outcome. Project Overview treats launch-blocking decisions that are not Approved or Approved with limitations as open readiness blockers.

Do not clear the blocking flag only to make the summary appear ready. Change it when the business rule or launch condition itself changes and record the reason.

  1. Link the validation, risk, redirect, or task evidence.
  2. Describe the exact limitation. State what differs from the original expectation and which business or operational effect remains.
  3. Record the rationale. Explain why the limitation is acceptable for this project.
  4. Assign conditions and follow-up. Include monitoring, cleanup, or a review date when the acceptance is not permanent.
  5. Identify the approver and decision date.
  6. Set the Outcome and Launch Blocking? state. The record should make the next project action unambiguous.

Use Define Sign-off Criteria to establish the approval standard before using this sheet as the final decision record.

Review Project Overview and readiness after material decisions change. Use the end-to-end worked example to see how tasks, risks, validation, redirects, and decisions stay connected across a complete migration project.