The Change Request Wearing a Favor Badge

Filed by: D.B. Trench

Field line: A favor is still scope if it changes work, evidence, or risk.

The request came through Teams with a smiley face.

Quick favor — can we add a comparison view to the pilot dashboard? Nothing major. Just current quarter beside prior quarter so leadership can see the trend.

Nothing major had arrived at 4:38 on a Thursday, which is when scope likes to dress casually and test the locks.

The request sounded reasonable. That was the problem.

Bad scope rarely arrives with a cape and dramatic music. It arrives as a helpful improvement from someone who is almost always correct that the product would be better with it.

The dashboard did not currently store prior-quarter values in the format the comparison required. The trend logic had not been approved. The vendor-owned interface would need a configuration change. Pilot scripts had already been written. UAT started Tuesday.

The request was not evil.

It was expensive.

The first reply drafted itself in my head and did not leave my hands:

Absolutely not.

Tempting. Also useless.

“No” without impact becomes personality. Impact gives the no somewhere to stand.

So the response that went out was plainer:

The comparison view is a useful enhancement. To include it in the pilot, we need to assess data structure, trend logic, vendor configuration, pilot scripts, and retesting. I do not recommend adding it directly to the pilot scope without that assessment because it could affect the current UAT start.

The stakeholder called ten minutes later.

I thought this would just be a display change.

“Part of it is display,” I said. “The display is the last inch. The first mile is data, logic, configuration, and test evidence.”

That landed. Not because it was clever. Because it was specific.

By the afternoon check-in, the request had a new name:

Candidate release-two enhancement, pending impact assessment.

Then leadership asked whether the pilot could still “show the idea” without building the full version.

That was how the favor tried again through a side door.

We agreed to a static mock-up in the demo deck, clearly labeled as future enhancement, not pilot functionality. The actual pilot stayed clean. The pilot date survived. The stakeholder did not get the feature. She got visibility that the feature had not been dismissed.

That distinction matters.

Some scope battles are lost because PMs only know how to absorb or reject. There is a third path: expose the cost, protect the current release, and give the idea a legitimate place to wait.

I made one edit before the minutes went out:

Comparison view deferred from pilot build due to impacts on data structure, trend logic, vendor configuration, pilot scripts, and retesting. Static concept may be shown in demo as future enhancement only.

Six weeks later, someone asked why the comparison view was not in the pilot.

The answer was already in the record.

The stakeholder still wanted it.

Good. It was a good idea.

It just stopped eating the pilot while smiling.

---

Scope triage: Use this when a “quick favor” touches data, testing, approvals, vendor work, or delivery dates.

First response: “This may be useful, but it changes the work. Let’s assess the impact before adding it to the current release.”

Safe holding place: Candidate enhancement, release-two item, or demo-only concept — clearly labeled so it does not sneak into the build.

Record line: “[Request] deferred from current scope pending impact assessment on [areas].”

Free field tool: Grab the Trench Field Notes Kit for usable wording when scope arrives as a quick favor.