Separate a Service Defect from a Request to Change the Scope

Substantively revised October 21, 2026. Author interpretation, documented cases and hypothetical examples are distinguished below.

Direct answer

Compare the reported behavior with the agreed delivery baseline before deciding whether a request is a defect correction or a scope change. Preserve the requirement, the delivered version, the reproduction and the requested outcome. If the output fails an existing agreed condition, record a defect against that condition. If the requester wants a different condition, assess it as a proposed change. If the baseline is ambiguous, record the ambiguity and resolve it explicitly rather than using a confident label to conceal missing agreement.

Classification does not by itself determine liability, payment or legal entitlement. Those depend on the actual arrangement and context. This article provides an operational way to discuss what changed, what failed and what decision is needed. A team can authorize an urgent containment measure while keeping a disputed classification open. The important boundary is between stabilizing a problem and silently agreeing to every proposed replacement requirement.

Key takeaways

Size is not the distinction between a defect and a change. A tiny new request can alter the promise, while a large repair can be necessary to satisfy the original one. Nor does the requester's preferred label settle the question. Compare evidence with a versioned agreement, and separate classification, impact assessment and authorization into visible decisions.

Split mixed requests. A broken export and a request for two additional formats need not share one disposition. Keep unresolved interpretation visible, describe the effect on existing commitments and test the delivered result against the condition actually approved. The Baseline Difference Record below is my proposed operating framework, not a standard established by the cited institutions.

Definitions and relationships

A baseline is the agreed description of an output at a specified point, including the conditions used to judge it. A defect is a demonstrated failure relative to an applicable condition in that baseline. A proposed change modifies the desired condition or scope. An assumption is a belief used in planning that may never have been agreed. The first task is identifying which of these objects the conversation actually contains.

An acceptance condition describes an observable result. An implementation describes how the supplier produces it. Changing the implementation can be necessary to correct a defect without changing the required result. Conversely, a request that looks like a small implementation adjustment can change an externally visible behavior. Examine the promised outcome rather than classifying solely by the amount of code or effort involved.

The requester reports a need, the delivery specialist investigates behavior and the authorized owner decides consequential changes. One person may perform several roles in a small service. Keep their judgments distinguishable: the person who discovers a problem may understand its cause without having authority to move another customer's date or alter the agreed deliverable.

Observation: the argument starts before anyone opens the agreement

A customer says a delivered report is wrong because the totals exclude cancelled orders. The supplier says including them would be extra work. Both statements may be sincere. Neither resolves whether the agreed report was supposed to include those orders. The conversation has jumped from dissatisfaction to cost before identifying the condition against which correctness should be judged.

Look for phrases such as “obviously included,” “only a small change” and “we always meant.” They often signal different remembered versions of the same promise. A polished ticket title can make the conflict appear settled when it is not. The useful next action is to find the relevant specification and reproduce the disputed result, not to win a vocabulary contest.

This matters after a promotion or change of account owner because the new decision maker may inherit commitments without their context. A colleague's memory can guide the search for evidence, but it should not become the only surviving record of what was promised. Preserve uncertainty when the agreement is incomplete; pretending the record is precise will make the later decision harder to defend.

Root cause: three questions have become one

The first question is whether the delivered behavior meets the agreed condition. The second is what work would be required to produce the requested behavior. The third is who can authorize that work and on what terms. Combining them creates circular reasoning: expensive work becomes “a change” because it is expensive, or urgent work becomes “a defect” because the requester needs it immediately.

Another cause is a moving reference. The team edits the requirement after a discussion, then tests the old delivery against the new wording without recording when the wording changed. The earlier output may have been wrong, right or ambiguous under the earlier condition; the updated document can no longer answer that question alone. Version references keep the history intelligible without preventing improvement.

Vague acceptance language compounds the problem. “A useful monthly summary” leaves many choices unstated: period boundary, cancellation treatment, grouping and rounding. When a dispute exposes such ambiguity, the responsible response is a clarification decision with explicit consequences. Do not manufacture an old agreement retrospectively merely because a precise specification would now be convenient.

Framework: the Baseline Difference Record

The record has five parts: Reference, Observation, Difference, Impact and Authorization. Reference identifies the agreed condition and its version. Observation describes the delivered behavior and a reproducible example. Difference states whether the requested outcome restores, modifies or clarifies the condition. Impact describes the work and affected commitments. Authorization records the decision without rewriting what the earlier evidence showed.

Reference should be narrow. Quote or point to the relevant clause, approved example or acceptance test, rather than attaching an entire proposal and hoping someone will interpret it. Record the applicable version and the relationship to the delivered output. A requirement approved after delivery may guide future work but cannot silently become proof of what was agreed before delivery.

Observation should separate symptom from explanation. “Rows with cancellation status are absent in export version 3” can be reproduced. “The developer forgot the cancellation logic” is a causal hypothesis that needs investigation. Use authorized sample material and preserve the minimum evidence needed. A dispute record should not become an unnecessary copy of sensitive customer data.

Difference can be restoration, modification, clarification or mixed. Restoration aims to satisfy an existing condition. Modification proposes a new one. Clarification resolves a gap that the available evidence does not settle. Mixed requests should be split into independently decidable parts. This vocabulary is an author-designed aid; a contract or organization may use different defined terms, which should take precedence in its actual process.

Impact describes dependencies, validation, timing and risk. A repair can affect other deliverables even when its classification is clear. Authorization identifies who approved which outcome and what remains disputed. It can permit a limited diagnostic or containment step while postponing the wider change. Keep a proposed estimate distinguishable from permission to implement it.

Three documented examples

NASA's configuration-management guidance describes baselines as agreed descriptions and connects proposed changes with evaluation, approval and implementation verification. This is a documented engineering context in which changing a reference is controlled. A small service need not reproduce NASA's governance structure. The transferable distinction is between a known reference and a proposal to alter it. [S1]

NASA's requirements-management guidance connects requirement changes with impact assessment, traceability and communication. It illustrates why changing one requirement can affect more than its immediate wording. The guidance does not decide the commercial terms of an ordinary client engagement, and this article does not claim that adopting its vocabulary creates any particular contractual right. [S2]

The UK Government Service Manual discusses user stories and acceptance criteria as ways to describe user needs and judge whether work meets them. This provides a concrete example of stating observable conditions rather than relying only on a task label. Such criteria still need interpretation in the context of the actual service; a checklist cannot repair an agreement that never addressed the disputed behavior. [S3]

These examples support three practices: identify the reference, examine consequences and describe the observable outcome. They do not prove that every disagreement has a mechanically correct classification. Human interpretation remains necessary where the record is incomplete. Keeping that limitation visible is part of the method rather than an exception to it.

Case study: one request containing a repair and an addition

Consider a hypothetical reporting studio delivering a monthly sales workbook. Its approved example specifies totals for completed orders and one currency column. After delivery, the customer reports that a completed order is missing and asks for totals in two additional currencies. The studio receives one message, but it contains two different requested outcomes. All quantities and events in this case are invented for explanation.

Reference identifies specification version 2 and the approved example. Observation reproduces the missing completed order using a permitted test extract. Difference classifies that part as restoration of the agreed inclusion rule. The currency request modifies the required output. The studio records them separately so investigating the omission does not appear to approve the additional currencies or delay the repair until a broader negotiation finishes.

Suppose investigation takes 30 minutes, the correction and retest are estimated at 90 minutes, and the new currency behavior needs a separate two-hour assessment before an implementation estimate is credible. These are illustrative planning values. They should not be added into one confident delivery promise, because the last item describes learning required before the team knows the work, not a known implementation duration.

The authorized owner starts the correction, agrees an update time and asks whether the customer wants the separate assessment. The record retains the original condition, the reproduced failure and the proposal. If the team later approves the currency addition, it creates a revised baseline. The corrected original and the expanded future output now have intelligible relationships rather than competing stories about what the initial message meant.

Application: investigate an ambiguous requirement

When the baseline says only “include sales,” ask which recorded examples, discussions or approvals help interpret that term. A customer may reasonably understand cancelled orders differently from the supplier. Describe the interpretations and their effects on the output. Do not select the interpretation that minimizes work and then present it as an established fact. Escalate the ambiguity through the actual agreed decision route.

A useful clarification can name what will apply from now on while preserving disagreement about the earlier output. State whether existing reports will be regenerated, which versions will be replaced and how recipients will recognize the change. A corrected file without an explanation can leave people comparing incompatible results. The record should make the current authoritative output easy to identify.

For recurring services, convert repeated ambiguities into better examples and acceptance conditions. If cancellation treatment creates a dispute every month, document an agreed example with completed, cancelled and returned orders. Do not create a universal form for every possible business rule. Improve the specific boundary that has already shown itself capable of producing conflicting interpretations.

Failure example: the requirement is edited to erase the defect

A hypothetical supplier discovers that a delivered chart omits a required category. Rather than recording the failure, someone changes the acceptance checklist to match the chart. The next review passes, but the record no longer explains what the customer originally approved. The apparent improvement in compliance comes from moving the reference, not improving the output.

Preserve the original condition and record the proposed revision as a new decision. If the customer genuinely prefers the narrower chart, that can be a valid change, subject to the actual agreement. It does not make the earlier omission disappear. Keeping both versions protects future readers from treating an authorized new preference as proof that no earlier mismatch existed.

Tradeoff and counterargument

A reasonable objection is that this process can make a small service feel adversarial. It will if used mainly to reject requests or assign blame. Use it to clarify useful choices: correct the agreed behavior, assess a new outcome or resolve an ambiguity. A short shared example often settles more than a long defensive email about who said what.

Another objection is that urgent incidents cannot wait for classification. Separate containment from final disposition. An authorized temporary measure can reduce immediate harm while the team investigates the baseline and consequence. Record its limits and expiry. Urgency may justify a narrow action under an existing policy; it should not silently authorize an unrelated redesign or erase the need to understand what failed.

Common mistakes

Do not classify by effort alone. Do not treat a renamed ticket as evidence that its content changed. Do not assume every customer complaint is a defect or every supplier inconvenience is extra scope. Investigate the observable mismatch and the applicable condition. When evidence is absent, use a clarification state rather than pretending certainty.

Avoid bundling an undisputed repair with an optional addition in a way that blocks both. Avoid updating a baseline before the decision is authorized. Avoid closing the report immediately after implementation without checking the agreed behavior. Avoid making a universal claim about who must pay; the operational classification helps the discussion but does not replace the actual agreement or competent advice where needed.

Action plan

Choose one disputed request and identify the delivered version and applicable condition. Reproduce the symptom with a minimal permitted example. Write the requested outcome separately. Compare them before discussing an estimate. If the request contains several outcomes, split them into distinct decisions with their own evidence and dependencies.

For each part, record restoration, modification, clarification or mixed, together with the reason. Obtain the appropriate authorization for the proposed work and communicate effects on current commitments. After delivery, verify the approved outcome and identify the current authoritative version. Preserve the earlier record so later reviewers can distinguish the original failure from a later improvement.

During the next service review, look for recurring ambiguities rather than merely counting defects. Improve one acceptance example that would have prevented a repeated dispute. Keep the decision record short enough to use. Its value lies in connecting a real condition to a real observation, not in collecting a large number of unused fields.

FAQ

Is a small request always included in the original scope?

No. Size describes effort, while scope describes the agreed outcome. A small modification can add a new requirement. Check the applicable condition and actual agreement before assigning a disposition.

Can a large repair still be a defect correction?

Yes. The amount of work does not establish whether the delivered output meets the baseline. Keep technical impact and classification separate so neither becomes a substitute for evidence.

What if there is no written specification?

Inspect the available approved examples and records, identify uncertainty and resolve it explicitly. Do not invent precision retrospectively. Improve the next agreement using the ambiguity the current request has exposed.

Does classification determine the price?

Not by itself. Commercial treatment depends on the actual arrangement and context. This method organizes the operational facts and decisions; it does not establish a universal payment rule.

Should the customer reproduce the problem alone?

Not necessarily. A specialist can help investigate using authorized material. Ask for observable behavior and expected results without requiring a customer to diagnose implementation details before receiving assistance.

Can one request be both a defect and a change?

Yes. Split independently decidable outcomes. Restoring an existing inclusion rule and adding a new export format need not share one approval, estimate or delivery decision.

What if the requirement changed during delivery?

Identify which version applies to each output and when the change was approved. Preserve the relationship between versions rather than testing all earlier work against the latest wording without explanation.

Is a changed implementation a scope change?

Not automatically. A different implementation may be needed to satisfy the same outcome. Examine external behavior and the actual agreement, including any specifically agreed implementation constraints.

How should an ambiguous request be labeled?

Use a clarification state and explain the competing interpretations. The label should expose the missing decision rather than forcing uncertainty into a confident defect-or-change category.

Can work begin before the dispute is settled?

An authorized bounded diagnostic or containment step may proceed under the actual process. Record what it permits and what remains open so action is not mistaken for agreement to every proposed outcome.

Who approves a consequential change?

The person or role authorized under the engagement's decision process. Technical knowledge helps assess impact but does not automatically grant authority to change price, scope or another customer's commitment.

What should a reproduction include?

The delivered version, relevant environment, permitted input, steps, actual result and expected condition. Use enough detail to investigate without copying unnecessary confidential material into a broad discussion.

Should approved changes overwrite earlier records?

No. Create a traceable revision and retain the earlier reference. Later readers need to understand what was approved at each point and why two outputs may legitimately differ.

What closes a defect record?

Evidence that the agreed correction was delivered and checked under the applicable process. A status change alone does not explain which behavior was verified or whether the customer received the correct version.

How can this stay proportionate?

Use one concise reference, one reproducible observation and one explicit decision where that is sufficient. Expand the assessment only when uncertainty or consequences justify it, not because a template has empty fields.

Recommended books

Software Requirements by Karl Wiegers and Joy Beatty is useful for thinking about requirement clarity, traceability and change. Use its discussions to improve the observable conditions in a service agreement, while adapting the level of process to the engagement rather than copying a large-project procedure.

Exploring Requirements by Donald C. Gause and Gerald M. Weinberg encourages investigation of assumptions and competing interpretations. It is relevant when both parties believe a requirement was obvious. The book supports better questions; it does not decide the commercial disposition of a particular request.

Getting to Yes by Roger Fisher, William Ury and Bruce Patton offers a negotiation perspective when classification has become personal. Read it to separate interests and options from blame. A constructive conversation still needs the concrete baseline and evidence that make the disputed work understandable.

Further exploration

Take one recently closed correction and compare its final output with the condition that existed before the complaint. Can another reviewer identify the mismatch, the authorized decision and the verification without relying on someone's memory? Where the connection breaks, improve that specific record. A service becomes easier to change when it can explain what it promised before the change began.

Primary evidence sources

• [S1] NASA: Configuration Management
• [S2] NASA: Requirements Management
• [S3] GOV.UK: Writing user stories

Related concepts: systems thinking, wealth structure, and the survival loop. Read the editorial policy and citation guide.