Project Management tools goal vs utility

If you’re reading this you have no doubt some knowledge of the development cycle of a game, if you don’t I’m sure you can imagine. Without going too much in detail it boils down to: a too small group of people taking on too big of a task. This obviously causes it’s own problems but luckily we’ve had a bunch of generations before us to figure out solutions to these problems: Project Management Methods. If you just Google this you’ll quickly find a whole list of them with ‘Scrum’ probably being the one on top. Just to paint a picture here’s a small sample list:

As you can see, there’s plenty of solutions to choose from. Each with their own strengths and weaknesses. In the game industry Scrum is the one that receives the most praise. With Kanban also having a pretty strong cult following. They all convince readers with very nice buzzwords such as Lightweight, Clarity, Stakeholders,… claiming they will solve certain types of problems within a team and while the tool itself is often more than capable of doing that there is one problem: They require a team to use them….

In many instances project management tools are used because upper management needs to receive information about how the project is going. Sadly in a considerably amount of these instances these tools are not properly adjusted to the teams or projects and are only used for upper management to gather information. Afterwards this information is partially used to make decisions that have direct impact on teams and projects. This is incredibly inefficient and causes ripple effects to other aspects of projects that it should not affect. A tool that is not fit to a team’s needs causes incredible overhead for individual team members to the extent that it causes high levels of stress which bleeds into the work they should be doing in the first place. The tools should be in function of the team and not the other way around.

As a producer or team leader you should assess the usage of these tools. If some are not being used properly or efficiently you have to decide what’s the best course of action:

Obviously changing the team is almost never a good idea so the ones that are left are to change the tool or explain it. In bigger companies the latter is often chosen because they want everyone to use the same tool which means that changing it causes more work and problems than explaining it. For smaller teams however changing the tool to the needs of the team is the way to go. A risk here is that you create a Frankenstein management system which does not make sense anymore.

The conclusion Is a rather obvious one. However this is something that is often forgotten. As a producer you should know what the team needs. The tool that you use to gather and present information should be custom made to these needs. In bigger companies this is still the case, however you should weight the impact of a change and see how it will benefit teams. When a tool does not provide the team with what they need or worse requires them to do more work in order to give someone or something information it can cause anything from annoyance to severe stress. In a healthy team you would like to avoid unnecessary stress and annoyance. In any team and project you will have this. The last thing you want is that the tool you are using is causing more problems than it is solving.