Deciding What the Project Will Not Do

Nobody sets out to double the size of a project. It happens one reasonable request at a time. Could the new form also send a confirmation email? Could the report include last year’s figures too? Could we add the Spanish version while we are at it? Each addition is small. Together they add weeks, and because nobody decided to make the project bigger, nobody adjusted the deadline or the budget.

This is scope creep, and it is one of the most common ways projects go wrong. The good news is that most of it can be prevented with a few habits at the start and one rule during the work.

What scope is

A project’s scope is the work it will do and the things it will deliver. Writing it down sounds bureaucratic, but a clear scope is what lets you plan, estimate and say with confidence when the project is finished.

The most useful part of a scope statement is often the list of exclusions: what the project will not do. People rarely argue about what is included. They argue about what they assumed was included. Writing “the new site will be in English only; other languages are a separate project” settles a question that would otherwise surface in week eight.

How common scope creep is

Very. In PMI’s 2018 Pulse of the Profession survey, 52% of projects completed in the previous year had experienced scope creep (PMI). More recent PMI data shows the gap between organizations: in the 2024 report, organizations that offered none of the support measures PMI asked about saw scope creep on 39% of projects, against 28% for those offering three or more (PMI Pulse of the Profession 2024).

Why it happens

The goal was vague. If success is “a better onboarding experience”, almost any addition can be justified. If success is “new customers complete setup in under ten minutes”, many additions are clearly beside the point.

Exclusions were never written down. Everyone filled the gaps with their own assumptions.

Small changes skip the conversation. A developer adds a feature because it only takes an afternoon. A designer adds a page because the client mentioned it in passing. Each one escapes the trade-off discussion that a bigger change would trigger.

Saying no feels unhelpful. Especially with clients or senior colleagues, it is easier to agree and absorb the work than to discuss it.

How to prevent it

Write a one-page scope before work starts. Include the goal, what will be delivered, what will not be delivered, the main assumptions and who approves changes. Get the sponsor to agree to it in writing. An email reply is enough.

Be specific about deliverables. “A website” invites argument. “A five-page website: home, about, services, pricing and contact, with a contact form” does not.

Name the person who approves changes. If anyone can add work, everyone will. One person, usually the sponsor, decides what comes in.

Use the one rule: every change gets a trade-off. When a request arrives, the answer is not yes or no but “yes, and this is what it costs”. Something else moves out, the deadline moves, or the budget grows. The person asking chooses. Most requests survive this conversation only when they really matter, which is exactly the point.

Handling a change request

Keep it simple. Write down what is being asked, why, and what it would take. Then put the options to the person who approves changes: add it and move the date, add it and drop something of similar size, add it to a later phase, or leave it out. Record the decision in a change log, a plain list with the date, the request, the decision and its effect.

The log matters more than it seems. Three months in, when someone asks why the project is late, it shows each decision and who made it.

Saying no without damaging the relationship

Most people asking for additions are not trying to cause trouble. They have spotted something useful. Treat the idea with respect, then make the trade-off visible: “That’s a good idea. Adding it pushes launch back about a week. Do you want to do that, or put it in phase two?”

Phase two, or a backlog of future improvements, is the most useful phrase in scope management. It lets you say yes to the idea and no to doing it now.

Where this fits

Scope is one of the five decisions covered in our guide to getting projects over the line. A clear scope also makes planning possible, as explained in Plans That Survive Contact With Reality. The free Project Management course on Train Your Skills includes a lesson and a template on scope. Start the course here.