So, the milestone plan called for “Two new hero abilities”—two new actions or powers the player can use.
I’ve done this enough that I should have known that it wouldn’t be as simple as that. Sure, it looked like a pretty clean line in a scope document. It’s clear, simple, and seemingly straightforward. Design can explore a few ideas, throw out the ones that are obviously too large, and move the remaining options into implementation.
We try a few, then throw them out because they’re terrible. Then, finally, one of those abilities shows promise, and we get it to something like 80%.
Yay. It works. The base idea is there, demonstrable and reviewable. But once the team can actually try it… It begins…
We see the ability needs one small new thing to make it read properly. Nothing especially alarming on its own, so the team starts working through it.
But that, then, creates three more things.
Now I have engineering needs that were not in the original plan, new animation and visual-effects work, and another balance pass. The player strategy around the ability changes too, which starts affecting how it fits with other parts of the game.
Here’s the tricksy part - The team is still building two hero abilities. Nobody added a third. On paper (or, more likely, a spreadsheet somewhere) the scope hasn’t changed.
The work and requirements, though, absolutely have.
The two abilities are still two abilities
And here, we get a first hand view of what makes scope difficult in creative work. We tend to describe it through the visible units: two abilities, three concepts, one campaign direction, a prototype, a trailer cut, a set of launch assets.
Those units are useful for planning… And are also a fairly incomplete description of what the team is being asked to solve.
Looking at the abilities, for example. Design was trying to hit the goal and trying to stay within the lines. Two abilities. None started just adding or building random features. We ideated, playtested, and the team learned something by making and trying the work. An idea that seemed contained in planning turned out to need more support before it could do its job.
That is normal. Honestly, I think it is rare that the exact right decision or boundary is defined at kickoff. The initial definition gives the team somewhere useful to start. Then the work teaches us things.
Where we can fail on the leadership side is not seeing or acknowledging that the assignment and plan changed based on what we learned.
If the additional engineering, animation, effects, balance, and strategy work is necessary for the ability to succeed, taking it on may be the right call. But it is still a call. The cost does not disappear because the new work arrived one reasonable piece at a time - though, admittedly, it can make it much harder to see.
This is why I have a hard time treating scope as a project management activity. Production can show the schedule impact, track the additional work, and help the team understand what is moving. Someone still has to decide whether the new work belongs in the current commitment.
That decision is leadership.
Scope is the agreement we keep updating
We need to stay focused on clearly asking what is in and what is out. We really need to be asking that consistently across a deliverable, phase, or milestone.
That seems nice and clear-cut in a sentence. In reality, though, for creative leadership, it’s super messy. The in/out boundary depends on several other agreements: what the current work is meant to help us decide, what level of quality that decision requires, which risk we are trying to expose, and what we are deliberately willing to leave unresolved.
Those agreements do not need to be perfect at kickoff (I’m not sure they can be). They do need to be visible enough that we can tell when new information has changed them.
Going back to my ability example, “make it read properly” might be essential. If players cannot understand what the ability is doing, the team may not be able to evaluate whether the design works at all.
Or that extra readability could be a finish problem attached to an ability whose central idea has not earned more investment yet.
Both are possible. The task list alone will not tell us which one is true.
We have to go back to what the current work is supposed to solve, prove, or help us decide. Then we can ask whether this new thing changes that decision, supports it, or belongs to a later pass.
That is scope in practice. Not defending the original list because it was written down, and not accepting every new need because it appears valid. It is keeping the agreement current as the team learns - while also keeping an eye on the big picture and timeline.
“One small new thing” needs a conversation
To be clear, I don’t think the answer is to make teams escalate every adjustment. That would slow the work to a crawl, and most small implementation decisions really should stay with the people closest to them. It would also make myself and everyone on the team miserable, which I tend to classify as “a bad thing.”
What you want to keep your radar tuned to are phrases like “Oh, it works, we just need one more thing.”
Sometimes we do just need one more thing. But then sometimes (and by sometimes, I mean most of the time) that one thing is the beginning of a chain the team cannot see yet.
Before absorbing it, I want to understand what the new work is supposed to solve. Is there a smaller or faster version we could try? What is the smallest test that would tell us whether the idea is working? How will we recognize that we have reached a dead end rather than continuing to feed the work?
I would also want to know which design or product pillar the new work supports. If we cannot connect it to something the project has already decided matters, that does not automatically make the idea bad. It does make the decision to pursue it less obvious.
And then there is the question creative teams often avoid because it is the least fun one: what are we going to give up to get this done?
Everything is a tradeoff. Maybe the answer is time. Or, we have to settle for less polish on another part of the deliverable. It’s possible the right call is to cut or push one of the two abilities. It’s also possible, based on the playtesting, that we as a leadership group, need to settle on some schedule risk because the ability proved so promising.
The flip side is, that it’s also possible that nothing has to move. Teams sometimes have room, and not every addition creates a crisis.
But we should understand that before the work quietly becomes part of the baseline.
A change can be right and still create drift
From a leadership and production perspective, the uncomfortable reality is, we often have to accept change. But each accepted addition or change moves the milestone a little further from the target we originally planned against.
Again, that might be correct. The original target was based on what we knew before the team did the work. If implementation reveals a better answer, I do not want the team trapped by an outdated plan just so the scope document stays clean.
But every one of those changes carries something with it: more risk, schedule pressure, different deliverable content, or a change in when the milestone can actually be considered complete. Often more than one.
When we accept the change without naming those effects, we lose track of how the milestone drifted and why. A few weeks later, the work is noticeably different from the baseline, the timing no longer makes sense, and everyone has a slightly different memory of when the commitment changed.
There usually is not one dramatic scope decision to point at. There are ten small ones, each reasonable in the moment.
That’s what we as leaders and production-folks have to keep visible.
The goal is not to prevent drift at all costs. Creative work changes because teams learn, and sometimes the learning should change the plan. But, we have to understand when we have made that choice and carry its consequences into the rest of the project, and understand what that means and what the impact is (or could be).
The work is going to teach us something
A good scope gives the team a useful starting point - and, ideally, some breathing room. It names enough of the current agreement that people can make progress without waiting for leadership to answer every possible question in advance.
Then the team gets started on the plan, and reality, annoyingly, has to butt in. Stupid, stupid, reality.
Once that happens (which for the game industry is typically 4-5 pico seconds after work begins), scope becomes an ongoing leadership practice. We have to decide whether new information changes the current decision, whether a smaller test would tell us enough, what the additional work supports, and what we are willing to trade for it.
If we choose to expand the work, we should name that choice. Update the target. Show the effect on timing, risk, and the rest of the deliverable. Capture why the decision was made while people still remember.
The two hero abilities may still be the right commitment. They may even be better because the team followed what the work revealed.
But by the time one small addition has become engineering, animation, effects, balance, and strategy work, we are no longer managing the scope we wrote at kickoff. We are making a new agreement.
Leadership needs to own that agreement while there is still time for the team and the plan to respond to it.
Author note: I’ve spent my career leading and supporting cross-discipline creative teams, primarily in game development, with a focus on production clarity, alignment, and communication. I’m currently building planning tools for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.