How do projects succeed or fail? One day at a time. What is your focus during the day, do you always work on the most important aspects first, or do you get swept up in the tiny details each time. Too often it is these tiny details that become death by a thousand cuts. Sure it is great to have all those little features done and edge cases for functionality, but it so often comes at the expense of major features.
What is your time for iterations, how many iterations do you usually require?
This is often a major issue in larger teams, especially across departments. Tightening up iterations is essential and the decision making needs to be given to the people actually doing the work. Whenever there is someone who says that they could handle all aspects of a project in a day, or week or month, they are often talking about single person efforts where they created the art, game play mechanics and everything else without outside influence. If art or creative requires some feature to be “just so”, then the individual who has the final say should be working side-by-side with whoever is developing it until it is complete. If the need for a server call or API to work a certain way, the server dev should be the one writing and using the test cases from the client code. Everytime you introduce a task that requires two people and there exists a separation between those two people, the results will be extremely slow. Instead, having the participants nearly sequestered until the result comes through is essential.
What is better in most cases is to have people that can handle both roles, so there is not a need for two people on those crucial elements. It is also important to understand how much iterations cost. If there are ever more than three iterations on a single element it needs to get hammered out and finalized immediately. Iterations often come from too many individuals involved in the decision making, and the people doing and monitoring the work not being involved enough in the process. If it is not right by the third iteration of a completed work of functionality and can not have the details finalized, it should be put on the bottom of the work pile as a “nice to have”. Granted this usually becomes a highly visible topic that makes it difficult to ignore, but it is essential not to waste time on something that can not be decided. When asked for status, ask instead for requirements and also ask for confirmation that these are the final requirements. If there are still issues, ask the people involved to all sit down and get it to work as intended. If those people do not have the time, then it is very likely trivial anyway, and the numerous iterations a product of their ego, and thus good enough as is.
Another big problem is the lack of tools development. Consider tools as the scaffolding to build your project. If you don’t spend a little time building tools that improve workflow and minimize time for iterations you will waste a lot of time getting these things done manually. There does need to be a balance though as too much time on tools is also not put into the final product. In most cases tools are somethings you wish you had time to develop for, but don’t have time to do for “this” project, having a few people working on tools throughout the project will help minimize this issue when in a crunch.
What it all comes down to is how much closer do you get to your final goal each day? So often time is spent on trivial things that in the end don’t really matter to the end result. With every day of effort you should ask yourself, did I focus on implementing the feature that would make the game the most fun, stable or maintainable? If the answer is no, what were you working on, and why were you working on it instead? Often the answer to this is A: it was an iteration on an existing requirement, B: it was a new feature or request, C: it will only take a day to implement, so why not just get it done and over with now.
Every day matters, especially in a crunch.
There is a saying that I always liked, since games are notorious for feature creep and changes in requirements: You will have a good idea today, a better idea tomorrow, but the best idea… never! This is because the best idea today, is not the best idea for tomorrow. Hardware, software, opinions and markets all change, so sometimes you just have to go with a good idea.
Best of luck,