I come from a background of IT development, where I worked in multiple roles from programmer to system architect. During that time I saw many different project management techniques ranging from the overly heavy and bureaucratic ones to the very light and agile ones. It might actually come as a surprise to some of you that working on graphics heavy AAA games has not felt all that different from working on the kind of software projects I had been part of before. This is partly because I have a very strong background in developing games and related technology as a hobby but also because there are just so many similarities between the two.
I’m writing this blog post because over the years I’ve been hearing many of my colleagues in the games and IT industry expressing their doubts about using processes found perfectly suitable in the other. Personally I feel that it’s important to study different industries to find the best ways to operate. In this post will be writing about my experiences on project management in the IT industry and comparing them to what I’ve been seeing in the world of AAA game development. I will start off by talking about different types of projects and the processes used to manage them. Further down I will talk about managing teams and end the discussion with thoughts on how art is viewed in the respective industries.
The post is mostly targeted toward people who only have experience in one or the other industry, but dual-wielders like me might also find it interesting to read about the experiences of other people with the same fate. I also wanted this to be an introduction to the topic for possible future posts, which is why I did not try to be overly comprehensive in my covering of the topic. So if you have ideas related to this post that you would like me to post about in the future, just leave a comment.
What kinds of projects are we talking about?
The types of projects we were working on in my IT days were mostly custom systems that customers ordered from us. In some cases we went directly to the customer with a plan to sell them an idea. The range of projects varied quite a lot. There were projects that simply gathered information through a given workflow and systems that the companies used to manage their payroll or even their portfolio of products with.
Compare this to say the racing games that we have been making here at Bugbear. Instead of collecting information to compute a person’s payroll you choose a region to drive in, select a car and punch through every wall you can find!
The difference here is the entertainment value. While the first is purely a functional system the later is only about entertainment. Personally I think it’s interesting how the borders between gaming and serious applications are becoming somewhat blurry. We’re currently looking for new types of applications to games as the larger world starts taking note of what you can achieve with interactivity. This has gradually paved the road for serious games. Also different methods discovered in the field of computer gaming are rippling into other areas of computing as well. A notable example of such development is the birth of general purpose computing using graphics processors.
What about the processes?
In my world of IT, when we started working on one of our projects, we typically interviewed the customer about what the basic requirements were and gathered a requirements analysis document that was to form the basis of the system’s initial technical design. The customer had an idea and it was up to us to define how that idea could be implemented. This initial technical design was usually the basis for selling the actual implementation and the design was sometimes made as a separate project altogether.
During the project we would constantly check with the customer whether the requirements were still valid and that we were actually moving in the right direction. We tended to have the system architect and project manager visit the customer on a regular basis with a demo of the system to show. These visits often resulted in drastic changes to the design.
The reason why we received so much change requests was that we had not asked all the right questions, neither was the customer able to answer them accurately enough. If you ask me, there is nothing odd about this. We as humans are limited by how much we can visualize before actually having something to play with. This is the same reason why chess is much simpler when you only have to think about the next move than having to build whole a set of winning moves the moment you first touch a pawn.
There you have it, iteration is the key to successfully finishing an IT project. Personally I think that most of my colleagues understood that but often it was the customer who wanted us to make a full design with all the details and commit to it in price and schedule. There might also have been some lack of trust in agility in the sales department that prevented them from really pushing the idea to the customer. I’ve been hearing that change is taking place there, however, so kudos to that.
In game development iteration is even more important. You can always design a game from start to finish, looking at all the details, designing all the interfaces and game modes from start to finish and even fill in the credits page! The fact remains, however, that you will not get it right. Something in the design just will not fit and has to be cut. You will also come up with new ideas once you get a working version of the game. This is why we need to constantly monitor the progress of the project so we can make adjustments and plan where to move the knight on our next turn.
Small agile teams
Scrum and Kanban are a really good basis for creating your own personalized project management strategy. There’s a saying that if you are not exactly following Scrum you’re not following it at all. Personally I feel a bit differently about this topic and see communication as the biggest takeaway in any process. Both in games and in IT, I’ve noticed that a lack of communication has been the reason for most of the significant nose dives.
Another thing to keep in mind is team size. Communication happens best when you are working with smaller teams. Quoting J. Richard Hackman, the writer of the book “Leading Teams: Setting the Stage for Great Performances.”, “My rule of thumb is that no work team should have membership in the double digits, and my preferred size is six.” The design has to be broken down into smaller features that the teams can then start working on separately. My personal experience in working with teams has shown that they should also be given autonomy on how to exactly implement the feature. This empowers them to actually make their own choices on the implementation details while still retaining control over the overall implementation. No autonomy, on the other hand, has lead to team members just waiting for new tasks without thinking themselves about how to proceed.
I also feel that hierarchy is important to some extent. People have to be empowered and be given the choice to do things in a certain way but hierarchy can make sure that the process continues smoothly with someone having the last say. As a person in a leading role it’s important to guide people in a certain direction and listen to them instead of just bossing around. People tend to lose their creativity around people with a “my way or the highway” attitude.
Team sizes have been more of an issue in game development than in IT projects. Those projects have usually required smaller teams with a few exceptions. But if you are working on a large software project where team sizes grow you will still be faced with the same issues as in game development and I would argue that the same solutions will work, in most cases at least.
What about art?
You might have noticed that I have not spoken much about art yet. This is where the IT projects I have been working on and the games I now make differ the most. At Bugbear we have a legion of artists and level designers that create the actual content for our games. In addition to game designers, this group of people comes up with a large portion of our functional requirements.
Many of the software projects I was developing actually had a heavy focus on content as well. It was not sound and visual arts like here at Bugbear but it was content created by the customers to make the software functional. Starting to use a certain system usually meant giving our customer the necessary tools to populate the new system with information. This meant that project management would have to shift a bit at the late stages of the project to facilitate those needs.
To some extent you can think of the content teams as internal customers with programmers building the tools for them to build the game content you see on the screen and hear through your speakers. Their requirements play a big role in how we design our features and how they are prioritized.
I hope this discussion goes to show that there are many similarities in the types of projects I have worked on in the IT industry and the projects I currently work on. This basically comes from the fact that in both industries we are working on a system that has a user interface, is interactive and has some kind of content. This is why I encourage you to keep your eyes open for ideas that come from other industries and think about how they could be applicable in your field of interest.