Write the scope before you write the code
A project often runs late because the team and client have different ideas of what is being built. A short written scope gives both sides something to check before development starts.
A build is three months in. The team has written clean code, but the client opens the latest version and says it is not what they expected. Both sides left the first meeting with different ideas of the product.
The problem is often the scope. The team built what it understood, while the client expected something else. Neither had a document clear enough to catch the gap.
What a written scope is
A scope is a short document with three parts.
- What the software must do. Each item is a thing a named user can do, such as "a customer can pay by card and receive a receipt by email". It is not a feature label like "payments".
- What the software will not do. Leaving something out needs an explicit decision. "No refunds in this version. The team handles them manually" settles an argument before it starts.
- How we will know it works. For each item, the check that proves it. If nobody can describe the check, the item is not understood yet.
A scope like this can fit in a few pages. Write it in the client's words so they can check and approve it.
Why conversation is not enough
A conversation can feel like agreement even when people have filled the gaps with their own assumptions. The engineer imagined one user role while the client expected three. The client expected data from the old system to move across, but nobody mentioned the old system.
Writing brings those gaps into the open. You cannot describe what a user needs to do until you know who that user is. Questions that might have surfaced months later can be answered before they cause rework.
The tradeoff
A written scope takes time at the start, including the client's time. Early questions can be uncomfortable because they expose decisions the business has yet to make.
It also makes change visible. A new idea in week six needs a new decision about time and cost. That can feel slower than asking for changes as they come up.
In exchange, there is less rework. The estimate has a defined scope behind it, and both sides can check whether the agreed work is complete.
Writing one in a week
- Day one. List the people who will use the software and what each one needs to get done. Leave screens for later.
- Days two and three. Turn each need into an item with its check. Mark every item nobody can write a check for.
- Day four. Decide what is out. Cut until the list is the smallest version worth releasing, and write down each cut and the reason.
- Day five. Read it together, line by line. The client signs it. The build starts from that page.
The scope may change during the build. When it does, record the decision and its effect on time or cost.