Tactics for Production Part 2

I think it is important to dive deeper into the concept of project management. It's not complicated: A project manager or producer manages resources and processes to optimized efficiency in development. How one goes about it is often up for debate, and being an indie developer, this further stretches the already thin resources available to manage game development.  

First, let's cover two popular PM Systems:

Waterfall Project Management: This style of management is often referred to as traditional project management and was popularized in post-World War II redevelopment in Japan and further developed in the many NASA missions to space in the '60s and '70s. Waterfall style of management consists of heavy planning up front that produces detailed specifications for development. It also goes to great lengths to track resource expenditures and assigns costs to them to optimize in the future.

SCRUM and Agile (these systems are similar): SCRUM/Agile was popularized in the late '90s and exploded in the early 2000s. Basically, the notion that projects can be "specced" out early with a specific set of requirements was thrown out the window, and lighter specs with many iterative prototypes and game versions replaced the rigid development stages of Waterfall. For creative ventures, this style of project management is popular to this day.  

These systems stress small teams that focus of short-term deliverables that can be looked at, played, and iterated from an early stage. In addition, there is a strong system of checking in daily, or even multiple times a day, to make sure teams are working in concert. In addition, there is a pool of tasks that are available for anybody who finishes a task early. In contrast to Waterfall, this system has less rigid requirements.

Other concepts:

• Every time we do a project, whether we know it or not, we are practicing project management. The question is whether it's a formalized system or all in one's mind. They are all forms of project management.
   
• It is probably that a mix of systems works better than a purely defined system. 
   
• Good management requires an analysis of the cost and resources associated with a formal system of project management. It is not just the cost of having a resource dedicated to project management. The whole team often has to participate daily to get the intended benefits from either of these systems.  

Pros and Cons of Waterfall Project Management

• Pro: Documentation is very important. As teams get bigger or more decentralized, documentation becomes increasingly important. I have found this to be true in every situation I have faced as a producer over the years. Waterfall places a huge emphasis on documentation, which is good thing.
   
• Pro: Waterfall front loads risks. I go by this saying, "If you can't make it sound fun on paper, it will be hard to make the game fun by building it." Of course, this doesn't always apply, but it does place a high bar on creativity in the early part of production.
   
• Con: I have seen teams led astray by documentation. Documentation in games are intended to be living documents. This means that weekly, sometimes daily, updates should be made based on feedback, play testing, and general progress in the game. It is nearly impossible to fully detail a game on paper. It's similar to writing a script with no wiggle room for changes and doing it all in one take ... This would be unreasonable. So, people take design too literally and stop looking for the fun in tweaking the game and taking feedback. Both good documentation and flexible design practices through game play iterations can be done at the same time!
   
• Con: Teams mismatch the resources to the job. In other words, there is not enough resources dedicated to project management, so a producer or other manager puts 5% of their time into it and expects it to work. Many people blame having project management in place as the reason the project is late or of poor quality and argue against having any PM in place, which is faulty logic. 

Pros and Cons of SCRUM/Agile Project Management

• Pro: This system focuses on "seeing is believing." It is very true that often our imagination is much bigger than our ability to deliver. It happens quite frequently in game development. This system puts pressure on the development team to deliver working parts of the game early and frequently. There is less trust in the written word, and that is often a good thing.
   
• Pro: Communication tends to be better with this system. However detailed and process-oriented Waterfall is, the system stops short of defining ways to meet and measure success in those meetings. SCRUM and Agile really stress the importance of these frequent smaller team meetings. This is a great thing.
   
• Con: This system can be abused and misused by developers who hate documentation or early design work on paper. The argument is that because things change so much in development, why bother creating all this documentation? My experience tells me that this is dangerous thinking. Teams (especially larger, decentralized teams greater than 10) need guidance to stay on the same course. Unless you want to do 4-hour team meetings every day to check everything, documentation is still needed in this system. This refers to specifications such as design docs but also task management and meeting notes. In short, SCRUM and Agile don't equate to no docs.

This is just the tip of the iceberg of project management topics. In the next blog, I will cover how we do project management at Codex Worlds and why. Hopefully, you find this topic worthy as a developer or aspiring developer. Great games are not just made by programmers, artists, and designers. Many games never finish because of poor project management. The irony is project management often gets the blame.