Production 101 - #14 Scope Management and the Art of Cutting
How to manage what’s in the game before you run out of time to make decisions
Scope management runs every week throughout production; a single kickoff agreement is a starting point, and a late descope conversation is evidence it stopped running.
Every uncontrolled change to scope is a hidden tax on the schedule; the change request process exists to make those costs visible.
MoSCoW (Must have, Should have, Could have, Won’t have) forces teams to sort features before the crisis, with full information and without time pressure.
Cutting a feature is a production decision; how you communicate it determines whether the team survives it intact.
This is part of the Production 101 series.
Features never get cut when they should. They get cut when there’s no other choice, usually three days before a milestone, in a meeting nobody wanted to call. The designers are furious, the engineers are exhausted, and the thing you’re cutting is the thing the team spent six weeks building.
That’s disaster recovery. Scope management starts months earlier, in a conversation that nobody wanted to have when it was still optional.
The difference comes down to when you started. I’ve been on both sides of it, and I can tell you without hesitation: the disaster recovery version is worse in every possible way. It costs more time, more goodwill, and more schedule than the early conversation would have. The only reason it happens is that nobody wanted to be the person who said, early on, that this feature might not make it.
That person is the producer. That’s the job.
What scope management actually is
Scope management is the continuous discipline of keeping the work matched to what’s achievable. A single kickoff meeting where you agree on what’s in the game is a starting point, useful but insufficient. A panicked descope conversation three weeks before ship is an admission that the discipline wasn’t running. Scope management is the habit of checking, every week, whether what’s in the backlog still fits in the time available, and adjusting before the gap becomes a crisis.
The word “continuous” is doing real work there. Scope isn’t static. The team’s velocity changes. Dependencies shift. A feature that looked like two weeks of work turns out to be four. The things that were reasonable assumptions in pre-production get tested against reality in production, and some of them don’t survive the test.
The producer’s job is to keep the plan honest as that happens. Holding onto the original plan because everyone signed off on it at the start is how projects arrive at alpha in denial. A plan that has drifted from reality becomes a fiction that costs you the ability to see the actual problem.
“A plan that has drifted from reality becomes a fiction that costs you the ability to see the actual problem.”
This is why scope management pairs directly with scheduling. Post #13 — How to Build a Milestone Schedule covers how to build a schedule that’s honest about capacity. Scope management is what keeps it honest as the project moves forward.
Why you need a change request process
Every uncontrolled change to scope is a hidden tax on the schedule and the team. The individual changes each seem small. “Can we just add a quick colour option to the character creator?” Fine. “Can we squeeze in one more map?” Sure, sounds manageable. “While we’re doing the UI pass, can we also rethink the inventory system?” That one feels slightly bigger but the art director really wants it.
Add these up over twelve weeks and you have a project that’s carrying six months of hidden work with no corresponding extension to the timeline. That’s how milestones slip: thirty reasonable decisions made independently, each below the threshold of alarm.
The change request process exists to make that accumulation visible. Before any addition to scope gets agreed, it goes through a fast, lightweight assessment: what does this actually cost in time and resource, who does the work, and what, if anything, comes out to make room for it? You answer those three questions and then you make the decision with full information.
The studios where I’ve seen scope creep worst were the ones where the change request process was either absent or so heavy that people routed around it. If adding a feature to scope requires filling out a five-page form and waiting two weeks for approval, people will just start the work and log it against a vague backlog item. The process has to be fast enough that using it is easier than bypassing it. A fifteen-minute conversation and a single-line entry in the change log is enough. The goal is a light gate, not a bureaucratic barrier.
How to triage features under pressure
There will come a point on almost every project where the honest answer to “will we ship everything on the list?” is no. The question then is which things go.
The quality/time/resource triangle is familiar territory, possibly too familiar. You can have any two of the three. Better quality in less time costs more resource. More features in the same time means lower quality or more resource. The triangle describes a real constraint. No amount of motivation or heroics moves it. The useful question when scope is too large is which of these three levers you actually have, given your real constraints.
But knowing the triangle doesn’t tell you which features to cut. For that you need a way to sort the backlog by actual necessity, not by loudness or seniority of the person who wants the feature.
MoSCoW is a framework I’ve used consistently for this. The letters stand for: Must have, Should have, Could have, Won’t have. The names are self-explanatory, which is part of why it works. You go through the feature list and every item gets placed in one of the four categories. Must haves are things the game cannot ship without; they define the product. Should haves are things that matter but won’t prevent the game from shipping if they’re absent. Could haves are desirable but genuinely optional. Won’t haves are explicitly out of scope for this release.
The value of MoSCoW is the conversation it forces. If three different stakeholders have different views about whether a feature is a Must or a Should, that disagreement needs to be surfaced and resolved before the crisis, not during it. The framework provides the vocabulary. The producer’s job in triage is to facilitate that conversation, drive it to a decision, and own the process rather than the answer. Scope cut decisions draw on three perspectives simultaneously: the PM brings product priority, the CD brings quality bar, and the producer brings feasibility; no single role owns the outcome, and how studios handle the final call varies.
“The producer’s job in triage is to facilitate the conversation and own the process. The answer belongs to the team.”
The MoSCoW sort should happen early in production and then be revisited at each major milestone. By the time you’re in alpha, the Won’t Have list should be long. A long Won’t Have list means the project has arrived at an honest picture of what it actually is. That’s a healthy sign.
Cutting without destroying morale
Cutting a feature and dismissing the work that went into it are different things, and the difference matters.
When a feature gets cut, someone on the team built it, or spent weeks designing it, or argued for it in meetings. That work was real. The person who did it knows it was real. If you communicate the cut in a way that implies the work was wasted, or that it didn’t matter, you damage something that takes a long time to repair.
How to do it correctly: acknowledge that the work was good. Explain the constraint clearly, without softening it to the point of ambiguity. “We have eight weeks and fifty items on the Must Have list. This feature is a Could Have. It’s coming out.” That’s the whole message. No hedging, no false hope that it might come back, no suggestion that the decision is provisional when it isn’t.
The team can handle bad news. They’ve been in games long enough to know how this works. Bad news dressed up as something else is what breaks them. “We’re going to park this for now” when you mean “this is cut” is a form of dishonesty that people see through immediately and resent for months. Say the real thing.
In my experience, the teams that hold together through cuts are the ones where the producer told them the truth early and consistently. The teams that fracture are the ones where the cut felt sudden and unjustified, usually because the scope conversation had been avoided for weeks. The cut is survivable. The absence of honest conversation before it is what does the damage.
There’s also a practical dimension. If people don’t understand the real reason a feature was cut, they’ll invent one. The invented reasons are usually worse than the real one. They involve someone deciding their work doesn’t matter, or that there’s a political agenda, or that the project is secretly in worse shape than anyone is saying. Information vacuums fill with anxiety. Fill them with facts instead.
How to say no to a stakeholder
Saying no to a publisher request or a studio leadership directive on scope is a skill that takes time to develop, and getting it wrong is costly. The instinct, particularly early in a career, is either to say yes to everything or to say no in a way that sounds like reluctance rather than production reality. Both responses create problems.
The version that works is this: present the constraint as a production reality. “Here is what we can deliver in the available time, given current capacity and the features already committed.” That sentence invites a conversation about priorities. “That’s not possible” is an opinion and invites pushback about whether you’re trying hard enough. Those two responses land very differently in the room.
This only works if you have the data. Current velocity. Remaining capacity. A dependency map showing what blocks what. The outstanding Must Have list. With those things, the conversation is about facts that both parties are looking at together. Without them, it’s about whether people trust your judgment, which is a harder argument to win under pressure.
“Present the constraint as a production reality. ‘Here is what we can deliver in the available time’ invites a conversation. ‘That’s not possible’ invites a fight.”
When a stakeholder pushes back on a no, the question to ask is whether the push is about priority or about capacity. “We want this feature” is a priority argument; the answer is to show what comes out if it goes in. “We need this feature” suggests it should have been in the Must Have list; the answer is to go back to MoSCoW and reassess. In either case, you’re working from the plan, not from a negotiating position.
How scope creep actually happens
It’s rarely one big thing. The post-mortem of a slipped schedule almost always reveals the same pattern: thirty small things that each seemed reasonable at the time. A small UI improvement here, a quick feature there, an extra platform nobody formally agreed to. Each individual decision was made by a reasonable person responding to reasonable pressure.
Scope creep is an emergent property of reasonable people making reasonable decisions independently. Nobody sets out to sink a schedule. It happens because each individual change is too small to trigger alarm, and the accumulation only becomes visible when the schedule is already gone.
This is the argument for the change request process, and for keeping the MoSCoW list visible to the whole team. When individual decisions are made in isolation, the cost is invisible. When they go through a central point and land on a list that everyone can see, patterns emerge faster.
I’ve sat in post-mortems where the team was genuinely surprised by how much scope had drifted. They could name individual decisions that had seemed fine at the time. What they hadn’t seen was the aggregate. Running the MoSCoW list as a standing agenda item in production meetings is the simplest thing I know of for keeping that aggregate visible. It takes ten minutes. It pays for itself every time scope starts to drift.
The other thing scope creep teaches you is that “just a quick thing” is almost never just a quick thing. A small feature that touches the core game loop will generate testing requirements, tutorial copy, UI work, and at least one design iteration. The cost multiplies out from the initial estimate in ways that are predictable if you look at the dependency map, and invisible if you don’t. The change request process, done properly, makes you look at the dependency map every time.
If you’re working on the schedule that scope management feeds into, Post #13 — How to Build a Milestone Schedule covers the mechanics of keeping a milestone plan honest as conditions change. The two disciplines sit next to each other and work better together.
For a broader look at how production governance fits together, Production 101 #8 on legal documents gives useful context on the contractual side of what goes in and comes out of a project.