Military Tactics for Software Development!

I caught up with Tim for lunch this week, and we got onto the topic (as is inevitable during any sustained interaction with me) of software development projects…and why they seem to go awry more often than not. I was telling him about this awesome series I’ve been watching ABC called Battleplan, where they analyse a number of military tactics, and discusses their pro’s and con’s.

It occurred to me during the last episode, that there are some amazing lessons to be learnt from military tactics, especially around those to do with warfare, for software project teams. Now, I’m no expert on anything to do with the military or war (well, I have an ongoing stare-off with the freaky old dude who lives next door, but that doesn’t look like escalating into a first-strike scenario anytime soon), but I’ve seen my fair share of failed campaigns from my time in the development trenches. So this experience, and the TV series gave me some ideas…

Now the first thing any good campaign needs, is an objective. The objective gives you an idea of where you want to be after the campaign, and what you need to organise, execute and achieve to get there. Now the first thing I’ve learnt is ONLY HAVE ONE OBJECTIVE!! Why? Because it’s easier to plot your course that way. If your objective is more than one thing, then your more than likely going to have more than one path, and just like herding cats, you’re going to multiply your effort, divide your resources, and ultimately reduce your chance of success.

Next you need the build-up. I love this idea, because it is one of the areas that always plagues projects. The build-up is all the things you need to do to get ready to undertake your campaign. Like getting your hardware (servers, desktops, test equipment), software (OS, dev tools, SDKs), people (Project Managers, Developers, Architects) identified, allocated, transported, setup and ready for action. I mean, how many people have been on that project where day 1 arrives, and there aren’t even any machines ready to start work on, let alone a project plan. The build-up also includes the planning; who is doing what, with what, and when? And it also includes the strategy; if we plan for this, and this happens instead, what do we plan to do then? The build-up also includes intelligence; checking to make sure everything is as it was when you started planning, and adjusting your measurements and tactics should things have changed. If you think the enemy is at co-ordinates x,y,z and plan for that, what happens when they move to a,b,c before you execute!?

The next step is the polony in the sandwich. It’s time to execute. No thinking here! No planning here! No nothing here except work! Each resource has their assignment. Each assignment has an order of execution, a start and end time, and a desired outcome. The only adjustments that are made are operational, and are not deviations, just corrections. If your planning is right, you shouldn’t get to a situation where you expect a building to be at point x, and when you get there, it’s not. At that point, you’re hosed, and just like on the battlefield, when that happens in a project, your going to pay big time.

And finally, when everyone has executed their assignments, and all assignments have achieved a positive or negative outcome, and there is nothing more to be executed, you are at the endgame. This is the place you wanted to get to when you set out your objective. It’s not some place you aim to arrive at, it’s the place you arrive at after you set your aim. It’s the place you craft your next campaign from. It’s the place you regroup, reschedule, and re-evaluate. Essentially, it’s the milestone point between campaigns that are part of a bigger strategy.

Thinking of this process made me realise something; the flow of action is one way. In fact, once you arrive at the objective, and you’ve used the objective to direct the build-up, the objective is useless. Why? Because the objective is a statement, a single idea, not a set of factors. And planning tasks week to week or day to day is really just an indication of chaos. It’s an admission that the whole team, from the Planners, Managers, Do’ers, have no real idea of what they are up against. Just that they need to do some stuff, and hopefully get some kind of result.

And the more I think about it, the more I realise that if teams were to put in the effort during the objective and build-up phase, that they would probably realise that not all campaigns are worth the effort and potential cost. I mean, if you measure the level of effort required during the build-up and execution phases, and assess the potential position at the endgame, that most objectives would not seem worthwhile anymore. And therefore, the percentage of software misfires would be less.

Anyway, food for thought.

Comments (5)

  1. Gary Short says:

    yeah the only thing wrong with planning software development like a military campaign is the old military adage that no plan survives first contact with the enemy. 🙂



  2. John Dougan says:

    "Plans are nothing. Planning is everything."

    — Dwight D. Eisenhower

    I take this to mean that any given plan is mostly valueless. The important part is being able to go through the planning process at need and generate a new plan to fill in gaps in the old plan or generate an entirely new plan with the current state being the start point. Because sometimes the building really isn’t there and there is no way you could have known that ahead of time, or you discover the initial objective is not what you wanted.

  3. davidlem says:

    That’s an awesome quote John. I suppose I take it to mean that the plan itself is merely an artefact of the process; so ultimately, if your planning process is bunk, so will your plans. Don’t you just love perspective?

  4. Bruce says:

    Unfortunately, a lot of times you (a) can’t avoid having multiple requirements, and (b) don’t know enough to completely plan the entire project in one shot.

    I don’t know what the best solutions are for (a).  I believe (b) is why there is so much emphasis on iterative development strategies these days.  It goes by names like "agile" and "extreme", but as far as I can tell the meat of the ideas are to do smaller chunks of work and to re-evaluate plan and progress more frequently.

Skip to main content