‘Creeping Featuritis’ (or its spoonerisation in the title of this post) is a common problem in pretty much any area where projects are managed. There are lots of different terms relating to it, all reflecting different emphasis – feature creep, scope creep, mission creep, and so on. But they all get to the same essential point: things keep getting added to the plan, and trying to include them messes things up. Close Encounters is no different. Here’s a brief insight into how it’s affecting my development work.
The main cause of any of the types of creep mentioned above is “Good Ideas” (scare-quotes intentional). You see, you get started on planning something, and you come up with a plan, and let’s say it’s good. It’s a good plan, which does what you need it to, and can be carried out in a reasonably straightforward fashion. That’s good, right? But then someone comes up with a “Good Idea” to make it better, and the creeping starts. We just need to add this, or adjust that, or modify the other… and every “Good Idea” causes another “Good Idea”, and before you know it the plan (which did what you needed and could be carried out) is an unwieldy abortion, an monstrosity which requires exponentially-increasing time/effort/money to make happen.
The best-case scenario is that this get recognised, and the entire project gets quietly shelved, never to see the light of day. More usually, however, additional resources get thrown at it due to some variant of the sunk-cost fallacy, and it creaks and groans onwards, getting ever-larger and less capable of achievement as more “Good Ideas” join the pile. Eventually it makes it in front of its target audience, who are rightly appalled at it, and want nothing to do with it. In some cases it’s the only show in town, though, and everyone is forced to make do with the horror that has become real, until someone starts a project to replace it with something newer, cleaner, and simpler… at which point the cycle repeats.
One common way of dealing with this is to incorporate a “Good Idea Window” into the plan – a time period in which “Good Ideas” are considered for inclusion in the project, but after which the design is considered final. Actually, though, nobody can remember the last time anyone saw the “Good Idea Window” closed (I sent the engineer squad down to check on it, and it turns out it’s been rusted open). The suggested alternative term is “Good Idea Fountain”.
How has scope creep hit us here at Encounter Table Games? Well, let’s take the example of the heavy weapons for the expansion pack. I started with three, and that was fine – simple, but fine. Then, when I added the idea of squad types, I decided it would be cool to have the number of heavy weapons match the number of squads, so three became five (and later, six). Someone mentioned it would be cool to have different versions of each heavy weapon, so players could choose the one that fitted what they wanted best, or avoid the most annoying drawbacks – trying that out turned six heavy weapons into 12, two of each type!
Fortunately, I managed to reign it in there, and stamp on things enough so that we’re back down to six heavy weapons (possibly five, depending on how things go with production etc). There was another development branch (since abandoned, fortunately) which would have led to no fewer than 18 different heavy weapons, spread across six different expansion packs! Thankfully that one got called off fairly early, but you can see the problem – one “Good Idea” has ripple effects that spread across everything else, and the whole thing can get out of hand very quickly.
You’d think it would be obvious that scope creep was occurring, and just say ‘No!’ whenever anyone proposes something outside the original plan. And that would indeed prevent scope creep. Unfortunately, it would probably also prevent much in the way of quality assurance. More perniciously, it would also throw a spanner in the works of anyone trying to do iterative development (which I am). Especially during the discovery phase, it can be very hard to tell the difference between an idea that is genuinely good and will enhance the project significantly, and a “Good Idea” that will spread nothing but ruin in its wake.
Unfortunately, I don’t have any handy tips on how to prevent scope creep from occurring. My approach is to do lots of testing and development iterations, and test with as wide an array of players as possible, in the hopes that checking enough will put me on more or less the right path. I’m also willing to stop, step back, and say “no, this is getting too much”, when something starts growing beyond what I had envisaged. But scope creep is still something I struggle with, and I imagine the same is true in other settings too.
If you have any ideas about how to stop scope creep from getting out of hand, please let me know! Either in the comments or by messaging me directly.
Encounter Table Games 