The Small Favors That Quietly Sink Software Projects

Note: This story was written with AI assistance and edited by me.

Note: An earlier version of this piece, "How to Write a Software Statement of Work That Prevents Scope Creep," was published on DEV.

The most expensive sentence I ever heard on a software project was "while you are in there, could you also..." It was said politely, in a friendly status call, about something that sounded tiny. Nobody wrote it down. Three weeks later the team was building an entire reporting module that no estimate had ever covered, the client believed it was included, and everyone was quietly frustrated with everyone else.

I have spent years writing and negotiating these documents, first as a partner at a software consulting company that grew from about $6M to $60M in under three years, and later while building a fully remote consultancy from scratch. The lesson repeats itself: projects drift not because people are dishonest, but because the page they agreed on was too vague to hold them together.

Why Scope Quietly Grows

Scope creep rarely looks like a problem when it starts. It looks like helpfulness. A designer adds one more screen because it seems obvious. A stakeholder who joined late assumes a feature was always part of the plan. A developer fixes something "while they are there" and resets everyone's expectations. Each step is reasonable on its own. Together they wreck timelines, budgets and trust.

A statement of work exists to give both sides one shared picture of the project. When it is clear, small requests are easy to recognize as new. When it is fuzzy, every request becomes a debate about memory.

What I Put on the Page

The goal, in everyday words. Before any feature list, describe the outcome the client wants for their business. A plain goal gives everyone a test for new ideas: does this help us get there, or is it a detour?

What is included, and what is not. List the screens, integrations, reports and environments being delivered. Then write a second list, just as specific, of what is excluded. That second list has saved me more arguments than any clause a lawyer ever drafted.

What "finished" means. Agree on a definition of done up front: reviewed, tested, deployed to a staging environment, documented and signed off by a named person. Without it, a feature can be complete in the developer's mind and barely begun in the client's.

Testable acceptance criteria. For each deliverable, a few short statements anyone can check, such as "an invoice can be downloaded as a PDF from the order page." Clear criteria make approval fast and make it fair to say when a request is new work rather than a bug.

The assumptions underneath the estimate. Access to systems by a certain date, final designs before coding starts, a partner API that behaves as its documentation says. When one of these breaks, the document already explains why the plan must shift.

Who decides. Name the person who approves work, who may request changes and who settles disagreements between stakeholders. Plenty of scope fights turn out to be arguments about who was allowed to ask.

A simple path for change. Every new request is written down, estimated for time and cost, and approved in writing before anyone builds it. Keep the process light enough that people use it. A short form or a ticket template is plenty.

Milestones tied to accepted work. Link payments and milestones to deliverables that have passed their criteria, not just to calendar dates. That keeps attention on working software instead of busy weeks.

Keeping the Document Alive

Even a strong document fails if it goes into a folder after kickoff and never comes out.

Read it together on day one. Go through scope, exclusions and the change path with the client team. It feels awkward for a few minutes and prevents weeks of tension later.

Name the first change gently. The first unwritten favor sets the tone for the whole engagement. Treat it as routine: log it, estimate it, and let the client choose. In my experience, most clients are relieved by that clarity.

Revisit scope at each milestone. Compare what was delivered with what was agreed, record the approved changes and adjust the plan. Small corrections along the way beat one painful renegotiation at the end.

Clear Pages Make Good Partners

When scope creeps, it is usually not because the client is difficult or the vendor is greedy. It is because two reasonable groups were carrying two different pictures of the same project. A careful statement of work, with a real definition of done, checkable criteria, honest assumptions and an easy change path, puts everyone in front of the same picture.

Write it with care, look at it every week, and the project has a far better chance of landing on time, on budget and with the relationship still intact.

I took a firm from $6M to $60M in under three years.