The Four Words That Save a Project: Out of Scope, Agreed

"I just assumed that was included."

I have heard that sentence in a project review roughly once a year for most of my career, and it has never once come out of the mouth of somebody who was happy. It is always said calmly, which makes it worse, because the person saying it genuinely did assume it, and they are about to find out what that assumption cost.

The deliverables section of a scope document is the part you sweat over and the part that gets skimmed. People read it once, recognise roughly what they expected, and move on.

The exclusions section is different. When there is a disagreement in month five, the exclusions list is the only page anyone opens. It is also the only part of the document that tells your team where to stop, which matters more than most leaders admit, because a good engineer with an unclear boundary will keep going out of pride until somebody stops them.

So write it as a proper section, not a defensive footnote. Be concrete enough that a stranger could use it to settle an argument. "Data migration of the 9 legacy applications currently using the old directory is not included" beats "legacy application migration is excluded" by a distance, because the second one leaves you arguing about which applications count as legacy.

Let's be honest about what actually stops you. It is not that you can't think of the exclusions. You can list six of them right now for whatever you are running.

It is that writing them down feels like starting a fight on day three of a relationship you are trying to build. There is a commercial lead who wants the customer to feel like they are getting everything. There is a sponsor who will read the list as a list of things they are not getting. And there is the quiet worry that if you are too precise, you look difficult, or worse, you look like you are already building an excuse for failing.

I understand that feeling and I think it is exactly backwards. The awkwardness of the exclusions conversation is fixed. It is one uncomfortable half hour in week two. The awkwardness of the alternative is unbounded, and it arrives at the worst possible moment, usually in front of people whose opinion of you matters.

Being difficult in week two is cheap. Being surprised in month five is not.

There is a craft to this and it takes about ten minutes to learn.

Every exclusion should come with a door. Say what is out, say why, and say how it could come in. "Not included in this phase. Can be added through a change request. Our current estimate is around 4 weeks of effort, which we would need to agree before the design freeze in June." Now you are not refusing anybody anything. You are telling them the price and the deadline for changing their mind, which is a service, not a rebuff.

Pair each exclusion with the in-scope item it sits next to, so the boundary is visible. "In: single sign-on for the 12 applications in appendix B. Out: the 9 applications on the old directory." A person reading that can see the line, and can tell you immediately if the line is in the wrong place, which is the entire point of writing it in week two rather than month five.

A research university, 14 weeks, single sign-on across the main application estate at two campuses, run by an engineering department of 30. In the scope document there was an exclusion that took me about five minutes to write and one slightly tense conversation to get agreed: the 9 applications still authenticating against the old directory were out, with a note that they would need their own piece of work.

Week six, a new programme director joined and asked why the research grants system wasn't in the rollout plan. That system was one of the 9.

The whole thing took a ten-minute conversation. I opened the document, showed her the line, showed her the signature and the date underneath it, and we talked about whether to raise a change. She raised one, it was funded separately, and I came out of that meeting with more credibility than I went in with.

Without that line, the same conversation runs for three weeks, involves three levels of management on both sides, and ends with someone absorbing the work unfunded. Usually the team. Usually by working weekends nobody thanks them for.

The last piece is the bit people skip because it feels bureaucratic.

An email saying "looks good, thanks" from someone who was not in the meeting is not sign-off. Verbal agreement in a corridor is not sign-off. Sign-off is a named person with the authority to commit, agreeing to a specific version of a specific document, on a date you can point at.

It does not need a signature workflow or a portal. An email that says "attached is scope v1.2, please confirm you are happy with the deliverables and the exclusions in section 4" and a reply that says yes will do. Store it. Version the document. When it changes, send the changed part and get the yes again.

And revisit it at milestones. Scope agreed in February and never reopened is not a protection by June, it is a museum piece.

Open whatever you are running, find the exclusions section, and if there isn't one, write it now.

Then send one email to the person who can actually commit on the customer or business side. List what you are not doing, in plain sentences, with the change route next to each item. Ask for one word back: agreed.

If they won't give you that word, you have learned something important in week two instead of month five, and you should take that straight to your sponsor.