Scope Change Decision Review

SCOPE CHANGE NOT READY FOR COMMITMENT

Case analyzed

Halfway through a customer implementation, the customer asks to add Salesforce and NetSuite integrations. The original plan included only SSO. The delivery lead says both integrations are “small,” but engineering has not estimated them, security has not reviewed new data flows, and the go-live date has not changed.

This review uses only the supplied facts. It does not assume access to production systems, private records, vendor portals, or approvals that were not provided.

Verified evidence

• VERIFIED: Original scope included SSO only.
• VERIFIED: Customer requested Salesforce and NetSuite integrations.
• VERIFIED: Delivery lead called them small.
• VERIFIED: Engineering has not estimated them.
• VERIFIED: Security has not reviewed new data flows.
• VERIFIED: Go-live date is unchanged.

Concrete findings

1. The requested integrations are a material scope delta because they introduce new systems, data flows, testing, and dependencies.
2. The unchanged go-live date has no evidence supporting feasibility because effort and security impact are still unverified.
3. The current record is not safe to close merely because work has started or a status label says complete; closure must follow the evidence and acceptance condition for this exact case.
4. The next action should repair the missing decision/evidence boundary without rewriting history or inventing facts that were not available at the time.

The controlling rule for this case is

A scope change is ready only when the requested difference from baseline is explicit, material impacts and dependencies are understood, acceptance criteria are updated, and the people authorized to own cost, schedule, risk, and approval have made traceable decisions.

The supplied facts are sufficient for a concrete case verdict, but not for claiming approvals, delivery, acceptance, or test results that were not supplied.

Required actions

1. Document baseline scope and both requested integrations as deltas.
2. Obtain engineering estimates including build, test, credentials, failure handling, and customer dependencies.
3. Map data flows and obtain required security review.
4. Present schedule/cost options instead of silently absorbing the change.
5. Update acceptance criteria for each integration.

Deterministic validation

• Approved scope identifies exactly which integrations are committed.
• Schedule is backed by estimates and dependency dates.
• Security review covers actual data flows.
• Customer acceptance criteria are objectively testable.

Validation must use this exact scenario, not a generic substitute. Preserve the dates, owners, amounts, systems, dependencies, customer promises, or source records that make the case materially different.

Evidence boundaries

• UNKNOWN: Exact integration requirements.
• UNKNOWN: Customer sandbox availability.
• UNKNOWN: Commercial authority for extra cost.
• UNKNOWN: Whether original go-live is contractual.

These unknowns do not erase the conclusion. They define the exact evidence needed before closure without guessing.

Decision and handoff

Keep the case open until the stated acceptance condition is evidenced, the responsible owner is identifiable, and any remaining exception is explicit. Record the outcome beside the original evidence so a later reviewer can see what changed, who approved it, and which condition was actually satisfied.

If the decision changes later, preserve the superseded reasoning rather than silently overwriting it. A later reviewer should be able to reconstruct the chain from original request to evidence, decision, action, and verification.

Closure rule

Close only when the requested result is supported by evidence. No completed action, customer acceptance, approval, production verification, or passing test is claimed unless it was actually supplied in this case.

Additional acceptance detail 1

Because this case establishes that original scope included SSO only., the closure record should also show that the related action was completed in a traceable way: Document baseline scope and both requested integrations as deltas. The evidence should be attached to the same case or linked with a stable identifier, not left only in chat, memory, or an unreferenced status field.

Additional acceptance detail 2

Because this case establishes that customer requested Salesforce and NetSuite integrations., the closure record should also show that the related action was completed in a traceable way: Obtain engineering estimates including build, test, credentials, failure handling, and customer dependencies. The evidence should be attached to the same case or linked with a stable identifier, not left only in chat, memory, or an unreferenced status field.