On how I came to co-create a project management tool for game developers.

About 2 years ago I left a steady job to pursue a project that had been gestating in my brain for a long, long while.

My wish was to create a project management (PM) tool that was particularly well suited to game developers. Note the use of the term developer and not development... I will come back to that.

I've worked as a project manager (in its various guises) for longer than I care to remember. This invariably involved using a project management tool to organise, share and monitor work-to-be-done. In more recent years I did this in the context of game development.

I can only speak from my own experience: behind the façade of perfectly aligned columns on a scrum board, beautifully woven Gantt charts and enticingly downward trending burndown charts, lies the inevitability of self-combusting gamedevs and project managers on a steady diet of Prozac (I exaggerate slightly for effect).

Game development is a very messy business. Simultaneously facing the dragon (own team) and giant (publisher), the project manager is invariably trying to bring order to chaos. And while the PM tool of choice is just one lever to reclaim some measure of sanity, it is nevertheless an important one.

The biggest issue with these tools is simply that most game developers are extremely averse to using them, with the obvious exception of those in some kind of project management capacity who live and breathe by them. There are a number of reasons for that - which I won't explore here, except for one central one.

The sobering outcome of this reluctance is that many PM tools end up serving as glorified communication tools for upper management or external parties: you desperately need to paint a positive picture of the future - as more often than not it has determining consequences for the project's survival.

It is a vicious circle: your planning becomes more and more disconnected from reality, your team becomes ever more squeamish about making estimates citing that the plan is unrealistic, leading to even more unrealistic plans and, before you know it, all attempts at gaining some manner of control on your project becomes moot.

Now, there is a school of thought that says: it doesn't matter what tool you use, because even if the team doesn't want to use it, it's the project manager's job to gather accurate data (clipboard in hand, of course ^^), feed the tool himself, and share the relevant output to the team. I personally don't subscribe to that, and have not seen it work.

I am of the firm belief that the tool should first and foremost provide value to the team. All other considerations - e.g. what the project manager wishes for, or the publisher demands - is cherry on the cake. Clearly you may not always have the luxury of choice.

But there's a rub. Two, actually.

The first one is that when it comes to adoption of tools, there is no "team", only individuals who all want something different. It is incredibly difficult - not to say frustrating - to get everyone in the team wholeheartedly committed to using one tool despite those differences.

The other rub is that the very essence of PM tools is to expose brutal reality, which includes human fallibility. Few people are willing to expose themselves thus, unless the organisation has gone out of its way to create that kind of environment, which includes amongst other things near flawless recruiting.

It is an almost unsolvable problem, but that doesn't mean you can't take a shot at it, which is effectively what we are doing at Codecks.

The starting point for developing Codecks was to be very opinionated as to what it should do and not do, and accept those constraints with the understanding that the tool will not suit everyone. Instead, it will hopefully become a rallying point for those that think along similar lines.

So how is it opinionated? The tool had to remain relatively simple (adoption by individuals in the team is key) but not so simple that it just became a glorified to-do list. So we made some trade-offs, and I will talk about 3 of those.

For one, Codecks focuses on a few core features and does not offer e.g. Gantt charts or Resource Management. This is because these features ultimately (and unfortunately) become outward-focused, with a high cost in product complexity. A consequence of this choice is that it will not suit large organisations.

The second - and probably more radical - choice we made was to use a collectible card game metaphor (with Hand and Deck of cards) for the interface and work breakdown. This also comes at a price, but has proven to be a hit for those that 'get' the metaphor. There's something about choosing a deck cover image that you just can't beat :)

Behold the deck library! This is what your backlog looks like on Codecks.

The third important choice we made was to provide very powerful options to filter and organise your cards (cards are the basic building blocks of Codecks). The reason is simple: you will invariably end up with a very, very large backlog, which leads to despair.

We made sure that anyone (not just the project manager) could quickly create a view that meets their immediate needs, and thus never feel overwhelmed.

There are many other considerations we designed in Codecks (e.g. how we handle workflow, or notifications) but ultimately the focus was not on the process of game development but the people.

Feature-rich tools sound great in theory, but few game developers ever get to exploit them to their full effect and often pay a heavy price in team uptake.

This, incidentally, is why elegant tools like Trello, for all their simplicity, continue to be very popular for smaller teams.

Do I want to be able to set-up complex workflows and task dependencies? Sure I do... in theory it sounds great, even necessary. But from my own experience that has never really worked.

Meanwhile, the most basic requirements of sound project management, things like clarity of focus on the next milestone or the ability to eloquently query your data to separate the wheat from the chaff in a given context, gets lost amidst the complex UI of a feature-rich tool.

Codecks is no panacea for successful project management, but the few things it does really well, and it’s playful interface, may make the difference between a tool used by every team member vs. one only used by project managers.