Project Scope Baseline Template for Client Work

Download the blank project scope baseline spreadsheet. No account is required. Save a copy before adding your project details.

A project scope baseline is the point of reference used to determine whether later work is part of the original agreement or a change. It is not a promise that requirements will never evolve. It is the agreed starting line against which changes can be measured.

The Project Management Institute describes baseline control as requiring documentation and management approval for changes. A small client project needs the same clarity, though usually with fewer formal roles and documents.

Use these fields in a statement of work, kickoff brief, or approved project note. The example describes a fictional Orbit Bikes campaign website.

The actual deliverables and dates should reflect the signed agreement. This sample is an educational template, not a substitute for legal drafting.

Specific enough that two people would reach the same conclusion about whether the item was delivered. “Build a website” is not a usable deliverable definition. “Design and build three named pages, one contact form, and a mobile navigation menu” is more testable.

Include file formats, environments, and acceptance criteria when they affect the output. A logo package might need SVG, PNG, and a usage sheet. A website launch may require tested redirects or accessible form labels. If the deliverable can be interpreted several ways, clarify it before pricing and scheduling the work.

It is equally important to list exclusions. “Photography not included” prevents an assumed photoshoot from quietly appearing during build. Write exclusions in ordinary language, with options for quoting additional work later.

Define what counts as a round, who consolidates comments, and which stages are open to review. For example, “Two rounds of design feedback on the approved homepage concept” is clearer than “Two revisions.”

A correction that brings work up to agreed acceptance criteria is not automatically the same as a discretionary redesign requested after approval. Classify requests against the actual terms rather than applying a rigid universal rule. The out-of-scope guide gives language for discussing work that does not fit the baseline.

Create a change record that names the requested outcome, estimated cost, schedule impact, and approver. Once authorized, add it as a new scope version or approved amendment. Keep baseline v1 available. You want to compare original work plus approved changes, not continually revise history.

A change decision should also update operational work: new tasks, dependencies, dates, and owner assignments. However, a new task in your project system does not by itself prove client authorization. Make the decision record discoverable.

Describe it as a shared reference point that protects both sides. It gives the client confidence about what they are paying for and gives the team a basis for estimating changes openly.

Here is the version of the project scope we are starting from. If a new idea comes up, we can absolutely look at it. We will compare it with this baseline, explain any effect on cost or timing, and get agreement before adding it.

This approach leaves room for collaboration without treating every idea as included by default.

Noddis is a project management app that keeps project work, notes, follow-ups, and history connected. Use the baseline in the project's context and link approved change decisions to relevant work. Noddis Drift measures growth relative to an established scope baseline, which can support a more concrete conversation about added work. It does not replace contractual approval. See the client project tracker for the operational overview or explore the demo.

Before starting your next project, ask a colleague to read the baseline and identify the deliverables, exclusions, reviewer, and acceptance conditions. If they have to guess, clarify those items now.