Scope Creep and How It Arrives

Nobody asks for a large expansion of scope. They ask for something small, you do it, and three years later the contract describes a service that stopped matching reality long ago.

The commercial decision in “Scope Creep and How It Arrives” is stronger when it rests on consistently recorded delivery effort rather than memory. An MSP can use this project guide to relate time to clients, projects and recurring tasks, while keeping service quality, contractual scope and customer outcomes as separate measures.

For an independent operational benchmark, compare the local practice with official ITIL resources; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

How it arrives

"While you're here, could you look at..."

A new application nobody mentioned.

A site that opened without a conversation.

A user who rings a technician directly.

And the project that was going to be one afternoon.

Why it works

Each request is small and refusing it feels disproportionate.

The technician who says yes is being helpful, which is what you hired them for.

And nobody is counting, so the accumulation is invisible until the margin is gone.

The measurement

Time recorded against things outside the contract.

Which requires that technicians record it, which requires that recording it is not treated as complaining.

A monthly figure for out-of-scope effort is the whole control, and most providers do not have one.

The response that is not a refusal

"Yes, and that is outside the agreement — I will log it and we will include it in the monthly summary."

Do the work. Record it. Show it.

The accumulation becomes visible to the client rather than invisible to you, and the conversation happens with evidence instead of frustration.

The periodic reset

Annually, or at renewal: here is what the agreement covers, here is what we have actually been doing, let us align them.

Either the scope expands and the price moves, or some things stop.

Both are better than the drift, and clients generally find the conversation reasonable when it is based on a record.

The direct-access problem

Users ringing a technician's mobile bypasses everything: ticketing, scope, billing and the service desk's visibility.

It feels like good service and it is how an account becomes unmeasurable.

Route everything through the desk, including for the client's senior people, and explain why in terms of service rather than process.

Where to be generous deliberately

Small favours build relationships and some should simply be done.

The distinction is whether you decided or drifted.

Set an informal allowance — a few hours a month absorbed without discussion — and treat anything beyond it as scope, which keeps the goodwill without the bleed.

What to check

Do you measure out-of-scope time?

When was the agreement last compared against what you actually do?

Do users contact technicians directly?

And is there a stated allowance for small favours?

The point

Scope creep arrives one reasonable favour at a time.

Do the work, record it, and show it in the monthly summary.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.