Space 2014

Many of you will have played the Apollo 13 ITSM simulation. Many more of you will have seen the film. Some of you might have been sufficiently  intrigued by the story to go in search of more information about NASA  and the lessons we can learn from both their successes and failures. Some of those lessons were  clearly described by Col Hadfield at the last Pink conference in Vegas, for instance the need to practice failure.

What you almost certainly won't have done is to attempt to run your very own space programme.

At least not until now.

Let me introduce you to Kerbal Space Programme.

Just moved into a beta release  it offers you the chance to build up to manned, or at least kerballed,  interplanetary space exploration from very basic beginnings.

The physics are slightly simplified, and currently component unreliability is not built into the game engine, but trust me as you play it you'll find quite enough things go wrong to keep you busy and to keep you thinking about ways to avoid mistakes that lead to failed missions. I'm not proud, I have to confess that still I have several kerbals stuck in orbit around distant planets with only the very vaguest chance of being rescued when my technology reaches the next level. And one or two kerbals who sadly didn't make it home

So what are some of the lessons a game like this can teach you that are transferable to ITSM?

Gene Krantz, the crew cut Apollo programme controller  is on record as saying "The main reason Apollo succeeded after the loss of the Apollo 1 astronauts is that we introduced excellent configuration management."  It applies in this simulation as well. As you build launch vehicles, capsules and landers you'll get to understand how important it is to know exactly what equipment you've put into every vessel. Few things are as annoying as piloting to the other side of the solar system, successfully landing and planting a flag only to find that the gallant crew cannot get back on board to return to Kerbal because you've  forgotten to add back on a ladder that you took off an earlier version to save weight. Just like in IT we get caught out by that unimportant change that nobody bothered to record.

Why did you have to save weight? Well because nothing comes for free in this world, or out of this world.  Everything has an impact on something else. Often that impact does not become apparent immediately so Root Cause Analysis becomes interesting, as it does in IT when the root cause isn't something that happened immediately before the outage.

As well as keeping track of configuration items another key tool  essential to getting your kerbals to set foot on distant planets is good workflow. You always need to be on top of what id due to happen next, and whether it it still the "best next action". That leads to  considering your...

...

...

...Timing. The same action can have disastrously different results if mistimed. Much like those IT departments who only decide to implement best practice ITSM after senior management have already lost all faith in them.

Obviously that error of judgment is obvious to any one who has seen the progress of previous ITSM initiatives. That is unless those lessons learnt in the past aren't actually transferable. For instance a knowledge of how Russia and the USA used un-manned probes to go where no man had gone before doesn't really translate to the kerbalverse, where unmanned probes drain limited battery power much quicker than the almost indestructible kerbals. Just because something worked for one organisation doesn't mean it will work in your situation, and in particular you need to be aware of the dangerous halo effect.