Part 2: The Scope Field Is Where Most Projects Quietly Grow Past What Anyone Approved
The Scope field of the project charter
Four weeks into the clinic's digital intake project, someone from billing asks a reasonable-sounding question: "While we're in there, can it also handle insurance pre-authorization automatically?" Nobody in the room says no. It sounds adjacent. It sounds helpful. It sounds like the kind of thing a good project manager should just say yes to. Six weeks later, the original go-live date is gone, nobody remembers deciding to push it, and when the sponsor asks what happened, there isn't a clean answer. There's just a string of small yeses that each made sense on their own.
That's scope creep, and it rarely looks like a single bad decision. It looks like a dozen reasonable ones, none of which anyone checked against anything, because nothing was written down to check them against. That's the job of the Scope field, the second field in the project charter 8-pack. Part 1 of this series covered the Business / Opportunity Description, the paragraph that states the problem the project exists to solve. Scope is the next decision, and it's the one most charters get half right: teams are usually fine at listing what's included, and consistently bad at writing down what isn't.
What this field is actually doing
Scope has two halves, and they're not equally weighted even though they look like it on the page. In Scope lists the products, services, processes, business units, and systems the project will actually touch. Out of Scope lists what it explicitly won't, not because nobody thought of it, but because someone deliberately decided it doesn't belong here.
The In Scope list is the easier of the two to write, and most people stop there. The Out of Scope list is the one doing the real governance work. Without it, silence gets read as permission. The moment a stakeholder raises a request that isn't addressed anywhere in the charter, you have no document-based way to say no, only your own judgment in the moment, which is a much weaker position to argue from than a page everyone already signed off on.
None of that makes the boundary permanent. An Out of Scope entry establishes the current boundary, not a final ruling. If a new request deserves consideration, assess its effect on cost, timing, resources, and business value, then obtain approval before adding it to the plan. The point of writing the list down isn't to shut the door on every future conversation; it's to make sure scope only changes through a deliberate decision instead of drifting in one small yes at a time.
The mistake almost everyone makes: skipping the Out of Scope list
Here's the pattern. Someone writes a solid In Scope list, feels like the field is done, and moves on. The Out of Scope section stays blank, or gets a single vague line like "anything not listed above." That line feels like it covers the gap. It doesn't, because it doesn't name anything specific enough to point to later.
The value of an Out of Scope list isn't that it predicts every future request. It's that it names the requests you already know are coming, the ones that got floated in a hallway conversation or a planning meeting and quietly tabled. Writing them down turns "we decided not to do that" into a documented decision instead of something you're reconstructing from memory three months later under pressure.
A second version of the same mistake is writing scope too broadly to be useful. "Everything related to patient intake" isn't a scope statement, it's an ambition. If you can't enumerate the actual work, you haven't defined scope yet, you've described a direction. Scope has to be specific enough that a reasonable person could look at a new request and tell, without asking you, whether it's in or out.
Four questions that build both lists at once
The same discipline that worked for the Business / Opportunity Description applies here: answer plain questions first, then assemble the lists from the answers, rather than trying to write a polished scope section from a blank page.
What specific products, services, or processes does this project actually touch? Be enumerable. "The intake system" isn't a scope item. "Digital intake form configuration for front desk and billing at all three locations" is.
Which business units, locations, or systems are included, and just as important, which similar ones aren't? If only some locations or departments are in, silence about the rest gets read as inclusion. Say so explicitly.
What adjacent requests have already come up that this project won't address? These are the easiest Out of Scope items to write, because you don't have to invent them. Someone already asked. Write down what they asked for and that it was deferred.
What's being pushed to a later phase rather than dropped entirely? Naming something as Phase 2 rather than simply excluding it is a way to hold the boundary without dismissing the request. It tells the stakeholder their ask was heard, just not now.
One caution on that last question: describe deferred work as a candidate for a future phase unless that phase has already been approved. Deferral does not guarantee funding or delivery, and promising a Phase 2 just to make an exclusion easier to accept creates an expectation you may not be able to keep.
Once those four are answered honestly, the two lists mostly write themselves, and they'll be specific enough to actually hold up when someone tests them, which they will.
What this looks like in practice
Back to the clinic. The Business / Opportunity Description from Part 1 named the problem: front desk staff re-entering patient data from paper forms at three locations, adding roughly eleven minutes to check-in and contributing to two missed insurance authorizations last quarter. The project exists to give the clinic a shared digital intake system.
Run that through the four questions. In scope: configuration and rollout of a digital intake form across all three locations, front desk and billing staff training, and syncing captured data into the existing records system. Locations: all three clinic sites, no exceptions. Adjacent requests already raised: automatic insurance pre-authorization, which billing asked about in the kickoff, and a patient-facing mobile app, which came up informally but was never part of the original business case. What's deferred rather than dropped: insurance pre-authorization automation, flagged as a strong Phase 2 candidate once the core intake system is stable.
Put together, the Out of Scope section reads something like: "This project does not include automated insurance pre-authorization, a patient-facing mobile app, or any integration beyond the three existing clinic locations. Insurance pre-authorization automation is a candidate for a Phase 2 project once the digital intake system has been live for at least one full quarter."
Notice what that sentence does. It doesn't just say no. It gives billing a real answer about where their request went, which makes the boundary easier to hold without the conversation turning adversarial. When the pre-authorization question inevitably comes back up in week four, the project manager isn't improvising a reason to say no. They're pointing at a line everyone already agreed to.
Why the Out of Scope list protects the relationship, not just the timeline
Scope documents get treated as a scheduling tool, something that protects the deadline. That's true, but it undersells what the Out of Scope list actually does day to day. Every stakeholder has a reasonable-sounding request. A PM who says no based on personal judgment is making an enemy. A PM who points to a line in a document everyone signed is just doing their job.
That distinction matters more than it sounds like it should. Projects don't usually fail because someone made one dramatic bad call. They erode because the person managing them said yes a dozen small times to avoid a dozen small uncomfortable conversations, and the charter is the tool that makes those conversations unnecessary in the first place. An undocumented boundary can make a scope discussion feel personal. A documented one keeps the conversation about the plan instead of about who's saying no.
It also protects resourcing honestly. A team can't commit to capacity against undefined work. When scope is specific and bounded, a lead can say with a straight face what their team can deliver in the given timeline. When it's vague, every estimate is really a guess dressed up as a plan.
A habit worth watching for
One thing that quietly weakens this field even when the intent is right: mixing assumptions and dependencies into the scope list. Take the records system upgrade in the clinic example. The upgrade itself, the records system being ready to receive migrated data, is a dependency: something the project relies on another team to deliver. The expectation that it will be completed before go-live is a separate thing, an assumption: something being treated as true for planning purposes that hasn't actually been confirmed. Record both in the appropriate charter field, Dependencies and Assumptions respectively in Field 8 later in this series, rather than folding them into the scope list. Scope should only describe the work the project team is accountable for delivering. Blurring the two makes it unclear who's actually on the hook for what, which defeats the purpose of writing any of it down.
Practical takeaway
Before you move past this field, write down the single request you're most confident will come up mid-project, the one that's reasonable, adjacent, and not actually part of what you're building. Put it in the Out of Scope list by name, with a sentence on where it goes instead, a future phase, a separate initiative, or nowhere. If you can't name one, you haven't been in enough planning meetings yet. Ask around before you finalize the charter.
What comes next
With the problem defined and the boundaries drawn, the next question is who actually owns getting this done. That's Field 3, Team, and it's where a surprising number of charters make the same quiet mistake: naming a sponsor and a project lead who turn out to be the same overcommitted person. That's Part 3 of this series.
Download the Scope Quick-Reference
Ready to put this into practice? Use the Business / Opportunity Description Quick-Reference as a simple one-page guide to the four questions, the solution-vs-problem check, and a fill-in-the-blank template for writing this field on your next charter.
