A project's scope takes up a few pages of the proposal. They are usually also the pages opened most often during the project. When the timeline slips, the budget is under pressure or the delivered work looks different from what was expected, both sides look at the scope first. At that point, how each side understood those sentences matters as much as what the document says.
Very few scope problems come from bad intent. Most come from the same sentence being read differently by each side, from unwritten assumptions and from expectations that naturally grow as the project moves forward. This article covers how scope is defined, written, walked through with the client and reopened when needed in design and software projects.
When an idea becomes a line item #
A client usually arrives with an idea: a new app, a refreshed brand, an admin panel that speeds up the work. In the client's mind the idea is a whole. The agency's job is to translate it into screens, modules, deliverables and hours. Every step of that translation leaves room for interpretation.
In design, "corporate identity" means a logo, colours and a typeface to one team; to another it is a set of applications running from business cards to vehicle livery. In software, "user management" can be a simple sign-in screen, or a module with role-based permissions, an activity log and single sign-on with the company account. Using the same word does not mean both sides mean the same thing.
That is why defining scope takes more than listening to the idea. The goal, the users, the existing systems and the must-haves need to be discussed and then turned into countable deliverables. This takes effort, and the question of who carries that effort comes before the project itself.
The price question and the cost of analysis #
Anyone with a project idea first wants to know what it will cost. That is a fair question; no work starts without a budget. But an accurate price depends on understanding the work in detail, and detailed analysis means days of meetings, review and writing.
In many markets this phase is sold as a separate service. A discovery or analysis engagement has its own budget, its output is handed to the client and the main project is priced on that basis. In Turkey the expectation is usually that a detailed proposal is prepared free of charge, so the cost of analysis stays with the agency for work that has not yet been approved.
The agency then has two paths. The first is to give an estimate after a short meeting. It is fast but risky: if the price is too low the agency either loses money or squeezes the work; if it is too high the client walks away for no good reason. The second is to run a detailed analysis at the proposal stage. The price is more accurate, but if the work is not won that effort goes unpaid. Both paths put pressure on one side. What matters is deciding up front who carries how much of that load.
Staged analysis: a range first, detail second #
To strike that balance we split the analysis into stages instead of doing it all at once. Each stage produces enough information to decide on the next. If things stop at any stage, neither side has spent more than necessary.
- In the first meeting we discuss the goal, the users, the timeline and the must-haves. This meeting produces a budget range and the assumptions behind it.
- If the range works for the client, we move to detailed analysis. The screens, modules and content to be delivered, and everything outside the scope, are written down at this stage.
- The proposal and the contract are based on this document. Price, timeline and payment plan map one to one to its line items.
A budget range is not a promise; it is a first reading of the work as described in the first meeting. Saying this openly prevents disappointment if the price changes after the detailed analysis. Writing the assumptions next to the range also shows which piece of information changed the price and why.
For large or unclear projects we propose the detailed analysis as a separate, paid discovery engagement. Its output belongs to the client, who can carry on with the document even if they decide to build the project with another team. That way the effort spent on analysis is not wasted for either side.
What a scope document should contain #
A good scope document does not have to be long, but it leaves no room for vague words. Its format changes from project to project, yet it always covers these points:
- Deliverables written in countable terms: how many screens, how many templates, which platforms and which file formats.
- What is out of scope. This is often the most useful section during the project, because it names up front the places where expectations quietly grow.
- Assumptions and what is expected from the client: when and from whom the content, images, access and third-party services will come.
- Revision rounds and approval points: what closes each phase.
- How new requests during the project will be handled.
In design projects the number of revision rounds and applications, and in software projects integrations, data migration and post-launch support, are the items most often left vague. Writing them down with what is known today, instead of leaving them as "we'll talk if needed", makes the later conversation easier.
The document gets written, but does it get read? #
However detailed the scope document is, there is no guarantee the other side will read it line by line. The client's priority is their own business. A proposal is often approved in the middle of a busy week, by looking at the total price and the timeline. The longer the document, the less likely it is to be read.
We do not see this as the client's fault; communicating the scope is part of the job. So we do not just send the document, we go through it together in the kickoff meeting. We read the out-of-scope items and the assumptions out loud, because later surprises usually come from there. Alongside the detailed document we give a one-page summary, and at the start of each new phase we briefly recap what that phase includes.
The aim of these steps is for both sides to look at the same picture throughout the project. A client who knows what they approved makes decisions more easily along the way.
New requests mid-project #
As the project moves on, the client gets to know their product or brand better. New ideas come up after the first designs, a missing flow is noticed during the work, something changes in the market. These requests are often valid and improve the product.
The difficulty is that these requests usually arrive without a name. Requests that come as "can we add this too" or "it's only a small thing" look small one at a time. To protect the relationship, keep the project moving or preserve a good working rhythm, the agency accepts most of them. A single request causes no harm. Once they pile up, the timeline and budget slip without anyone noticing, and by the end of the project either quality drops or the relationship gets strained.
Raising it is not easy either. Between two parties working together, a reminder about scope can come across as rigid or distrustful. Postponing the topic is tempting for that reason, but every postponed conversation turns into a harder one at the end of the project.
We log new requests on the day they arrive and check with the client whether they are in or out of scope. If they are out, we offer three options:
- Move the request to the next phase or release.
- Swap it with another item in scope; the timeline and budget stay the same while the priority changes.
- Price it as additional work and share its effect on the timeline in writing.
When the options are agreed up front, a new request does not turn into an argument; the client decides which option suits them. Being flexible on small requests that genuinely belong to the scope is part of this arrangement too. What matters is that the flexibility is visible and known to both sides.
Going back to the document in a disagreement #
The document earns its keep when the two sides remember something differently. Nobody fully remembers the details of a meeting held months ago. The written scope, approval emails, meeting notes and change logs move the conversation from memory to common ground.
Going back to the document should not be about finding out who is right. What you look at is what was discussed and what was assumed at the time. Where the document clearly includes or excludes something, the decision is easy. In grey areas where it can be read two ways, sharing the cost is often the healthiest route for both sides. It also helps to note such a case as something to write more clearly in the next project.
At that point the document only helps if it was written fairly. A text that protects only the agency and puts every risk on the client looks safe on paper but damages trust when a disagreement comes. The language of a scope document should define the responsibilities of both sides together.
Startups and limited budgets #
Early-stage startups often cannot set aside a separate budget for analysis. The product is not yet clear, resources are limited and the project runs on mutual trust. This works well as long as both sides keep the balance; many long-term partnerships start this way.
When the balance breaks, the risk grows. In a broad, unclear project that started from a quick estimate, if new requests keep coming while the budget stays fixed, one side will lose out. The healthiest route then is to narrow the scope. Cutting the first release down to what is truly needed, splitting the work into phases and pricing each phase on its own protects both the startup's budget and the agency's effort. We described how we narrow a first release in Three questions for narrowing an MVP scope, an earlier article on our blog.
Scope is a shared job #
No method removes scope problems entirely. A well-written document, a kickoff meeting where it is read together and an agreed way of handling new requests reduce the risk, but all of them depend on both sides taking part in the process.
On the agency side this means writing the scope clearly, walking the client through it and raising limits in time. On the client side it means knowing the document they approved, naming new requests as such and being open to the options. When both sides do this together, the scope stays a shared plan that everyone refers to throughout the project.
