the plan that kept becoming five plans

I was reviewing a plan for a small project not long ago, and every time I came back to it, it had grown. None of the growth happened because anyone did anything wrong. Each new piece made sense on its own. It would connect to something we already had. It would let someone outside the immediate group use it. It would take a decision off my plate later. Reasonable, one at a time.

The problem was that none of those pieces was the actual job. The plan had one thing it was supposed to do, and by the time I looked again, it had picked up five separate things that were not that. I stopped and cut all five. Later, the same thing happened again, and I had to cut it a second time.

That is the whole incident. What I want to get at here is why I let it happen twice and what I actually check for now, because "cut the scope" is easy advice and much harder practice.

small additions are the hardest scope creep to catch

A plan that suddenly asks for something huge and unrelated gets rejected fast. Everyone notices that one. What is much harder to catch is five small additions, each one reasonable by itself. One more connection to another system. One more way for someone else to use it later. One more piece of automation that would save a step down the road. None of those is a bad idea in isolation. I would have approved any single one of them without much thought.

That is what makes this kind of scope creep so much harder to catch than the obvious kind. Nobody has to slip anything past you. You approve it yourself, five separate times, because each individual approval was correct. The plan only becomes a problem when you stop looking at the additions one at a time and count what they add up to. Counted one at a time, each addition was reasonable. Counted together, they added up to something else. It is a different, bigger project than the one that was approved, still going by the original plan's name.

the question that actually matters

For a long time my real question when reviewing a plan like this was "does this make sense." Almost everything makes sense. That is not a useful filter, because a version of the plan with five extra things attached also makes sense, in the sense that none of its individual parts are wrong.

The question that actually catches this is narrower: is this the one job the plan is supposed to do, or is it a different job that just happens to be described in the same document. The line I used to stop myself, at the point I finally caught it, was close to this: "Stop stepping out of your lane and worrying about how it's all going to connect to the rest of the whole ecosystem." That is the whole test. Not "is this smart." Is it the job.

cutting it once was not enough

I cut the five things out. I felt good about it, the way you feel good about any decision that clears something up. Then the same plan came back later with the same kind of additions attached again, for the same reasonable-sounding reasons, and I had to cut it a second time.

That told me something I did not want to hear. The discipline is not a single decision you make once and then move on from. It is something you have to keep applying, because the pull toward "while we're at it, let's also" does not go away just because you said no to it one time. I do not think that pull ever fully goes away. I think you just get faster at noticing it.

what actually stays in the plan

What I kept, in the end, was the one thing the plan was supposed to do, and nothing else. Not because the other five things were bad ideas. Some of them were probably good ideas, for some later plan that does not exist yet.

The discipline I am actually practicing is not making a plan smart enough to anticipate everything it might eventually need to connect to. It is making a plan narrow enough that it can actually get built and finished before it turns into five plans instead of one.