This actually an article that I wrote close to a year ago. I made it in draft in Blogger and then never got around to publishing it. There is a lot here which I think is simplistic, but it surprises me how much of it still holds true. So enjoy!
----
So after a few weeks of crazy technical work as well as project management I've got a few titbits of information on how to run a project. And amusingly enough, a lot of what I learnt had a lot of overlap with gaming.
1. Business Case / Reconnaissance & Forward planning.
In all strategy games, sending in a forward scout to figure out what is going on in the enemy camp usually will give you a significant advantage. Why are you building Anti-Infantry units when he is going straight for vehicles? Shouldn't you figure out what he is trying to kill you with first so you can build the opposite? Sure you'll take a hit to your production since you're not using a unit for mining, but it'll be worth it when your build the right units for the job. In the same vein, shouldn't you understand what your customer wants exactly rather than rushing to build something that won't solve the right problem and will simply get your project axed?
2. Team composition / Combined arms
Who goes into battle with purely one type of unit? Idiots and spammers that's who. And in any realistic game you find this will get you killed. Similarly going into a project with gung-ho hackers will probably result in a cancelled/delayed project. A team need different types and I don't just mean roles. I mean you need the visionaries, the pragmatists, the pedantic types and of course the motherly types to look after this awkward lot.
3. Stub development/ Hit and Run
Just because the bulk of your army isn't ready yet, or your economy isn't in full gear isn't really an excuse to not do lots of harassment of the enemy. So just because you don't have all the information you need, doesn't mean you can't develop by skunk-working, or writing stubs for the bits you don't understand and then doing the rest later.
4. Self-Improvement / Building a Economy
I'd like to think I encourage people to keep improving their skills even if we're running close on the deadline. In a match, often it is tempting overstretch your economy and strike the opposition. It is a balancing act. Not focusing on skills/economy will result in you losing steam before long and being ineffective, whilst overdoing the skills/turtling in your base means you're not getting out there, solving the bigger problem at hand.
5. Force multipliers.
In most games there is a unit or building which doesn't do anything by itself, but confers benefits to those units around it. These are called force multipliers since their mere existence means your entire army is now more effective. This could be a 'supply truck' that improves the damage/hit points of every unit near it. Similarly in projects, you will find some people are force multipliers which aren't very effective by themselves, but multiply the powers of others. Managers of various forms typically fall into this role, but you'll find the overly helpful tester or help desk engineer can also maximise the strengths of your development team. Some tasks are force multipliers in that if you do those tasks early, you could allow a number of tasks to start in parallel, speeding up the entire process.
6. There is a place for heroes, but communication works better.
Say what you will, heroic efforts by a single developer in software development do exist and I'm willing to say all risky projects have needed it to succeed. It is just like the guy who somehow manages to destroy the enemies economy behind the lines, ignoring the fact his allies need him at the forefront. Communication is better, and I don't mean communicating the fact you're not coming back to help. Communication is core to winning in a game and even more so in project management. You need people to know what you're doing and make sure everyone is in alignment to win the task at hand. And if this means your team provides a distraction whilst you go and kill their worker drones, so be it. As long as you agreed to that as a team.
7. Your plan will typically be screwed very quickly.
What will be instantly familiar to both project managers and gamers is that the best laid plans of mice and men go astray. Going in with a set plan is a good idea since you have a reasonable starting point. And things don't always wrong. But nine times out of ten they will. A module will be harder to implement than estimated, an ally will have raptors 'killing their manz' before they know it.
Exceptions
Unlike games where is it often black and white, you have to be careful about defining your enemy. Other teams are not your enemy and treating them as such will get you in trouble quick smart.
Also most modern RTS games make you focus on looking after each unit individually and giving them directions. Unfortunately this doesn't work when you're dealing with intelligent people. Developers don't like being micro-ed generally and trying to do so simply makes both you and him/her less effective.
