Every project I've watched go sideways had the same issue. Somebody says "scope creep," everyone nods, and the room decides to blame the Scrum Master for failing to prevent it, or the Product Owner for changing requirements. We should have pushed back harder. We should have had a change control process. We should have been more disciplined. We need more Agile. We need less Agile.
That's not what happened. In every one of those projects, I couldn't have told you in one sentence what the project was supposed to accomplish. Neither could anyone else in the room. Scope creep isn't a discipline problem. It's what fills the space where a goal should have been.
A Project That Couldn't Fail
My first job out of college had a project called Reporting Dashboard. That's not the real name. I'm not interested in calling out the company. The point was to track ad performance. What we actually spent our time on was the technology: which reporting engine, and how far we could abuse it into fitting the system we already had. We'd paid for that platform. It was going to work whether or not it wanted to. It didn't, and we found that out slowly and expensively.
Nobody asked which ad decisions the dashboard was supposed to change. Nobody asked who would open it on a Monday morning, or what they'd do differently after they looked at it. Those questions weren't shut down. They just never came up. I didn't ask them either. I was twenty-two, and I assumed the people above me were holding answers I hadn't earned access to yet.
The project ran for years before I got there, and I assume it ran for years after I left. It never went into production. The part that stuck with me isn't that it failed. It's that it couldn't fail. There was no condition under which anyone could stand up and say the Reporting Dashboard is finished, and no condition under which anyone could say this isn't working, we should stop. Both of those sentences need the same thing underneath them, and we didn't have it.
Goals Have Verbs
Here's the distinction, which I couldn't have named until a few jobs later. "Reporting Dashboard" is a noun. Nouns name a thing you're building, and a thing under construction can always have more added to it. There's no sentence you can build out of a noun that tells you when to stop.
A goal is a verb with a number attached. Cut the time the media team spends assembling the weekly performance report from four hours to twenty minutes. Get us to the point where we kill an underperforming campaign within a day instead of at the end of the month. Those are ugly and specific and much harder to get everyone to agree to, which is exactly why the noun keeps winning. The noun lets eight people leave the room believing eight different things and feel good about the meeting.
Nobody Asks for Scope Creep
Nobody on that project asked for scope creep. What we got were ordinary questions from people doing their jobs. Could it slice the numbers a different way. Could it pull in the feed we were already paying another vendor for. Could a client see it instead of just us.
Every one of those is a fair question. That's the trap. With a goal in the room, each one gets measured against it: does this move the media team from four hours toward twenty minutes? Some would have. Most wouldn't. Both answers are easy to say out loud when there's a number sitting on the table, and neither one requires somebody to volunteer as the difficult person.
We had no number on the table. So the only things left to weigh a request against were who was asking and how tired we were that week. Every request turned into a yes, and it turned into a yes for a reason nobody wanted to write down.
The client-facing question is the one I'd flag now. Putting it in front of a client meant a second product wearing the first one's clothes, with its own security model and its own answer to what counts as acceptable downtime at 2am. Nobody wanted that, because weighing it would have required something to weigh it against. It went onto the list with everything else. The list had no criteria. It only had room.
When You Can't Put a Number on It
The obvious objection: some work is genuinely exploratory. You don't know what the outcome should be, because finding out is the work. Demand a number up front and you'll get a fabricated one, which is worse than none at all, because now people have to defend it.
That's fair, and it doesn't get you out of having a goal. It moves the goal somewhere else. When you can't say what the result should be, the goal becomes the question you're trying to answer and the date you'll have an answer by. Find out whether our event data can reconcile against the vendor's, and know by the end of the month. That's still a verb, and it still has a stopping condition, which was the part you were missing. A goal doesn't have to predict the future. It just has to give you something to work towards.
If You're Already in too Deep
At a kickoff, this is easy advice: write the verb before you write the backlog, and write down what you're not doing right next to it. Most people reading this aren't at a kickoff. They're eight months into something shapeless, watching the list get longer every week, with no standing to call a reset.
You can't retroactively define the goal you should have had. Nobody is going to give you a meeting for that. What you can do is ask the questions that would have produced it, in the rooms you're already sitting in.
- What changes for somebody if we ship this? If the answer comes back as a list of features, ask again. Features aren't changes. You're looking for a person whose week is different.
- Who opens this on Monday, and what do they do differently after they look at it? A named role beats a department name. If nobody can produce one, you're building for an audience that doesn't exist yet.
- What would have to be true for us to stop? This one makes people uncomfortable, because it sounds like you're asking permission to quit. You're not. A project nobody can stop is a project nobody can finish.
- If we could only ship a third of this, which third? People who won't state a goal directly will state it happily in this form. Whatever they pick is the goal.
None of those are objections. They're questions, which matters when you're the youngest person in the room and you've correctly worked out that you have no leverage. Nobody gets marked down for asking who the user is.
If the answers come back sharp, you got the goal you were missing, and the next scope conversation gets a lot shorter. If the room goes quiet, the silence is your answer. Write it down somewhere, even if nothing changes that week.
What I'd Tell my Younger Self
I've thought about that project more than it deserves. Not because it failed, and not because I could have saved it; I couldn't have. I was the most junior person on it, and I had no idea what I was looking at.
What I'd tell him is that the question he was afraid to ask was the cheapest question in the building.
Who opens this, and what do they do differently afterward? He assumed the silence meant the answer lived somewhere above his pay grade. It didn't live anywhere. Nobody had it. Asking wouldn't have exposed him as the kid who didn't understand the project.
It would have exposed the project. Years before anyone wrote a line of code, and long before anyone in a postmortem got around to calling it creep.
