The Danger of “Just a Quick Favor”: Tracking the Cost of Ad-Hoc Requests

The requester saw the edit. The team lived the context switch.

“Quick” describes the visible action. It rarely describes the cost.

Count the whole interruption

Track time to understand the ask, locate the right work, make the change, validate it, communicate it, and return to the interrupted task. Add rework when the favor arrived without enough context.

Do this by category for a month. Do not build a surveillance system. You need the cost of the channel, not a courtroom transcript of every minute.

Log favors before doing them

Put ad-hoc demand into software project intake. A small request can use a small record: requester, current problem, outcome, owner, and time spent.

The broader bypass rule is in how to stop stakeholders from bypassing project requests. This page keeps the calculator on one apparently tiny favor until interruption, validation, and recovery stop hiding behind the word quick.

One team that logged 126 “under an hour” requests in one month. Leadership had been asking why a strategic launch slipped. The launch had funded a help desk nobody had approved.

Give the favor a tradeoff

Set an interruption budget or service window. When it is consumed, new favors wait or displace named work. Publish both totals.

Try the free Project Intake Evaluation Worksheet to find unofficial channels and test whether small demand reaches capacity planning. The favor stops being dangerous when it stops being free.