Scope – the inconspicuous project killer

There are many things that can go wrong while working on a project. And I mean not only technical difficulties, interpersonal relations, lack of time and experience, et cetera. They all can get in the way, but in my opinion, nothing breaks the spirit more effectively than a badly estimated scope.

Long time ago…

When I was 15 years old, me, my brother, and my friend started a project called Troika. It was meant to be a roleplaying game in an open world, with a detailed scenario, a cast of characters, and hundreds of side-quests. We obviously wanted to do it in 3D and fully voice-acted, because there is nothing a 15 year old can’t do. And we were pretty good at it – after several months of development we’ve almost finished one in-game location – it was textured (mostly), and it was implemented in a game engine, so you could walk around it. So a decent 0.07% of the game was done!

Of course that “project” was a kid’s fantasy, but it points to a bigger problem. More often than not, what people lack in terms of experience and organization, they try to make up for with lots of enthusiasm and hype. But working on enthusiasm alone is a short-lived strategy. There also needs to be a plan in place; sensibly specified scope is the most important of its parts.

Back to reality

Already six months into the project, we’ve done a lot. Our site is up and running. The backend structure of the application is done, the layout is functional. We’re now working on bug fixes and planning to do a major code refactor. We still haven’t started our work on frontend, so the website looks raw (that’ll be our next step after the refactor). Today our site looks like this:

Of course we’re nowhere near the finish line – but this time the game we want to create is small, confined and doable… or is it?

It turns out that once again we’ve fallen into a trap of trying to make a game that we would love to play. A game that would be professionally designed, with artwork, animations, sound, music, and a bustling online community. That’s obviously something that has to be done by a team of game developers working full-time. It was easy not to worry about all the things we won’t be able to do, back when the prospect of doing them was still in the abstract future. Last week came the moment of a reality check; after rediscussing the scope of our project, we have decided to do something smaller instead of a full-blown game. Something that can be done in a short time and that can be released as soon as possible. We’ve decided to implement a fully functional chess game in Phaser 3 with our own assets. And it is simple! – Krzysztof has written a playable version in just one week! After we’re done and everything is working as intended, we’ll once again discuss our goals.

The moral of the story

– If you say something along the lines of “we don’t know how we’ll manage to do that, but let’s worry about it later” – it’s a warning sign. Think hard about every major aspect of the project – if there are some things that you have no idea how you’ll do, there is a strong chance that problem won’t go away by its own.
– Read about “the sunk cost fallacy”, the tendency of people to invest in something that is doomed to fail anyway, just because they’ve already invested in it a lot of time, effort, and/or money.
– Make sure the scope of your project can be fine-tuned as you go. And start small!

And don’t let the badly estimated scope kill your project!

One Reply to “Scope – the inconspicuous project killer”

Leave a Reply

Your email address will not be published. Required fields are marked *