How to define project scope before the work starts

The project is agreed in principle, but that does not always mean its working boundaries are clear. Before kickoff, name what will be delivered, how far the work extends, what the commercial boundary is, and what happens if a later request changes that baseline. This is operational alignment—not legal drafting.

Vague scope creates a commercial decision nobody knows they need to make

A phrase such as “design the website” can sound settled while leaving page count, formats, revisions, client inputs, and exclusions unanswered. When one of those questions surfaces mid-project, the client may hear a normal detail while you hear additional work. The problem is not bad intent; it is that the baseline never made the boundary observable.

Confirm four critical boundaries first

1. Named deliverables: identify the actual outputs, not only the broad objective.
2. Extent and completion: use quantities, formats, or observable completion points so “done” is understandable.
3. Commercial boundary: record the agreed fee, included hours, rate, or another limit that defines the work being bought.
4. Additional-request rule: agree that a request beyond the baseline will be assessed and any price or timing impact approved before the extra work starts.

Then make the supporting boundaries explicit where they apply

Revisions

State the number of included rounds or define the kind of refinement included. A revision adjusts an agreed direction; a new deliverable or replacement direction may be new work. If revisions genuinely do not apply, say so rather than inventing a limit.

Exclusions

Name adjacent work a reasonable client could assume is included. For a design project, that might be copywriting, development, stock-image licensing, or source-file preparation. Exclusions work best when they resolve a plausible misunderstanding, not when they list every service in the world.

Client inputs and dependencies

Record content, access, feedback, decisions, or approvals the client must provide and when they are needed. If there are no client dependencies, mark the area not applicable instead of creating artificial requirements.

Assumptions

An assumption is a condition on which the effort or approach depends—for example, one decision-maker will provide consolidated feedback. Record it if the work, timing, or price would change when it proves false.

Check the boundaries, then confirm them in one message

The readiness check treats missing deliverables, extent, commercial terms, and change handling as critical. It separates those from supporting gaps and explains what to resolve. Once the result is ready, the confirmation template turns the same categories into a calm pre-kickoff message.

When a later request changes the baseline

Confirmation does not prevent requests from changing. It makes the comparison possible. When a client later asks for more, compare the request with the recorded deliverables, revision boundary, exclusions, dependencies, and assumptions. If the request changes the baseline, estimate the impact and get approval before doing the additional work.

Where CREEPLOCK fits

After the client confirms, CREEPLOCK can record the commercial baseline: deliverables, revision limit, exclusions, assumptions, included hours, value, and rate. It does not analyze a contract, send the email, obtain a signature, or make the agreement legally sufficient. Its job begins with an explicit baseline and continues when later requests need to be assessed, priced, approved, and tracked.