Effective Time Management
Time management is a of dire importance to both a team and project. While most of it revolves around an individual and how they prioritize their workload, I feel there is a way to mitigate bad time management and make the most out of good time management. I see team managers as being the primary force behind this, since they have the most influence on the way a team works. There are three aspects that I feel they need to keep in mind for this: overall communication, project scope, and individual passion.
Overall communication contains both within a team and with the forces outside of the team. The quality of a teams channel of discussions can have a serious impact on the following two, and so setting up stable, efficient, and valuable is paramount. What, though, can a manager do to help his team achieve this? I feel the key is removing any potential blockers that the team runs into.
For example, one of the most debated topics I’ve seen has been what platform to conduct daily communication on. There are a bunch of options: Skype, Discord, Slack, and more. Each argument has various good points from functionality to the social implications of one over the other. Despite all these points, I don’t feel that the decision of a platform should be taken so seriously. Instead, the service chosen should be done by the team itself, and disrupt them as little as possible.They already use Slack? Continue to do so. Discord? That’s perfectly fine as well. The goal should be to make the flow of information as seamless as possible.
This gets a little more difficult for communication between outside of the team, but the same principle applies. I feel like the manager should try to accommodate as much as possible, while facilitating a continuous flow of information. This might result in the team becoming uncomfortable, but the key to mitigate this issue would be small steps. What steps to take depends heavily on the current state of the team. Do they never interact with anyone from the outside? Try introducing the idea of having a short meeting, once a month or weekly, with someone not directly involved in development. Already a thing? Raise the idea of adding them to any team specific Slack or Discord channels.
Next, the scope of a project can affect time management through how much work a team needs to put in in total. A lower level will decrease the total amount while a higher level will inevitably increase it. Getting the smallest amount, while still addressing the core aspects of the project, is the goal here. Less overall time the project takes, the less likely teams will have to crunch at the end to meet any missing requirements from adding a critical feature.
In order to do this, however, requires efficient and effective communication. All the necessary functions of a game should be known and understood by everyone on a team as early as possible. Any changes need to be brought up quickly, discussed, and decided upon. The faster this loop happens, the lower the amount of wasted work and thus effective use of time.
On my team, we first started prototyping back in August with four members, but in December we brought on six more. Due to this, we had a natural point at which we could re-assess the scope of our project. We held a meeting with everyone involved, and discussed our goals for the project starting with the basics: how many levels, enemies, and hazards? What were our goals for the project? It was important everyone was there so that we could all come to an agreement together, and make sure everyone understands each aspect. Once we had an agreed upon range of specifications we were able to effectively plan out the project.
Ideally, everyone on a team will have an innate desire to work on the project, but it should be expected that this level will vary across team members. The job of the producer is to ensure that those who are vehemently passionate don’t break those that aren’t, while making sure the product meets its deadlines.
This past project, we ran into some trouble when introducing our six new members. Our four original members were, naturally, going to be more passionate about the project than the newer members. To mitigate this, during the onboarding process, we specifically tried to bring on members for a purpose. Within this area we gave that new member full jurisdiction, which allowed them to take ownership over a part of the project and increased their passion. This also aligned with their strengths: areas they both had skills in and were interested in doing. It was hard to get this match right away with everyone, but we made sure to find an aspect that each member could get passionate about.
This is how we’ve approached managing the time spent on the project over the course of its development. There have been some hiccups along the way, but for the most part we’ve been able to stay on a steady course. In retrospect, I feel like the area I put less effort into was the Individual Passion section. I relied heavily on my leads to encourage the team members, and I should have gotten more involved at regular intervals to keep up with members.
Thankfully, we’ve still gotten to the point where we can confidently put it out on the market. At this point, we’re squashing bugs and going through the Steam onboarding process. So excited to release!
Thank you for reading!
Enjoy the read? Want to chat? Follow me on Twitter @LiamCraffey