Scope creep and the missing sign-off: the question answered in ten minutes

The hard question

Six months after a reporting system went live, the client appointed a new finance director. In her first review she asked a pointed question: who agreed that the reporting module would ship without the custom dashboards? In many organisations that question starts a week of searching through inboxes, meeting notes and memories, and ends with two sides who each remember a different agreement.

The project manager did not search her inbox. She opened the task for the specification. It held three versions of the document. Version three carried the approval of the client's lead, with the date and the time it was given, and a note that the dashboards had moved to phase two. Both sides had agreed, in writing, on the version that mattered.

What made the difference

The meeting took ten minutes. The relationship stayed intact, and the change request for phase two was signed the same week. Nothing heroic had happened. The team had simply kept every deliverable on its task, kept every version, and recorded the approval on the version it approved, not in a separate email thread.

The textbook name: scope creep and the missing sign-off

Scope creep is the slow growth of what a project is expected to deliver, without a matching change in time, budget or agreement. It is usually blamed on demanding clients, but its root is more often a missing sign-off. When deliverables are approved in a hallway, a chat or a call, there is no record of what exactly was accepted. Months later, each side remembers the version that suits it, and every disagreement becomes a negotiation from zero.

The cost is not only the extra work. It is the time spent proving what was agreed, the trust lost while proving it, and the change requests that never get signed because nobody can show what the baseline was.

Signs to watch for

A missing sign-off rarely looks like a problem on the day it happens. The client lead says the specification looks fine in a meeting, the team nods, and work moves on. The warning signs come later. Documents are shared as attachments with names like final, final-2 and final-reviewed. Nobody can say which version the client actually saw. Change requests are argued about rather than priced, because there is no agreed baseline to price them against.

Another sign is where approvals are found when someone needs them: in a personal inbox, a chat thread, a photo of a whiteboard. If the proof of an agreement depends on one person's memory or mailbox, the agreement leaves the project when that person does.

The cost grows with time. A disagreement in month two costs a conversation. The same disagreement in month eight, with a new finance director and a delivered system, costs weeks of senior time and, too often, a discount given to keep the peace.

How to prevent it

Keep the deliverable and its approval together. Every deliverable belongs to a task. Every revision is a new version, never an overwrite. The approval is given on a specific version, by a named person, at a recorded time. And the client's approver must be able to approve without friction, otherwise approvals drift back into email and chat.

How ApprovedFlow does it

In ApprovedFlow every deliverable lives on its task, with each version kept. The approval is recorded on the version it approves, with who approved and when. Client approvers act straight from the email, without needing an account, so the sign-off happens where they already are and lands where the project can find it.

A question for you

When the hard question comes on your project, where would your team find the answer, and how long would it take?