IT Project Communication and the NASA Launch Process

I’ve always been a space nut.  I was one of those nerdy kids in the 60’s-70’s who sent handwritten letters to NASA asking for mission photos, and actually received several back, which was quite a thrill. Do they still have the money to do that?  Probably not.

I’ve been thinking a lot lately about the importance of communication in large-scale IT programs, how prone to failure our programs/deployments are, and the lessons I had by listening in on the Ares 1-X launch last Fall.

While the great majority of people saw the few seconds of the actual launch on TV, I invested several hours listening to the live launch feed, which due to several factors (including a ship entering restricted waters) was pushed back multiple times and eventually took place the following day.

Why invest the time? I found myself intrigued by the communication process used between Mission Controllers* and the dozens of people on the line, each with their own accountabilities and at diverse locations around the globe. It immediately reminded me of many large-scale IT projects I have been a part of, and here’s what I took away from the experience:

1. The Launch Controller was the clear hub in a hub-and-spoke discussion model, and there was no confusion over how the process would work. Everyone on the line knew the communication process well.
2. Although there were a dozens of people on the line, each individual knew when to speak. Generally, an individual would only speak when (a) specifically asked to report, (b) when giving an update on an item referenced earlier, or (c) when they sensed a real conflict with another dependency. This kept non-value-added chatter to a minimum.
3. The Controller routinely stated the situation summary in a beacon-like approach, including the next time everyone would be polled or updated. This was especially helpful in a situation where individuals were coming on and off the line, each trying to manage their own high-pressure situations amid a desire not to be the one factor holding up the launch.
4. The Controller repeated back the majority of what he heard to each individual to ensure clarity. While many would see this as wastefully repetitive, there were several instances where that repetition itself became critical to understanding what was going on.
5. Although individual tensions may have been high, the formality of the process and the Controllers’ training seemed specifically designed to moderate the potential roller-coaster of gut-level reactions to events as they played out, keeping the plan on track.
6. There was a cadence to the effort that I found very impressive, and a sense that everyone on the line knew that the process being followed was proven, had value, and they had an important part to play.

Two scenarios from the feed that have stayed with me:

• At one point, there was confusion as to whether the Controller was asking an individual to execute a change (move the clock up), or what the effort would be to execute that change.  How many times has this happened in an IT project you have been a part of? “Are you telling me to do something, or asking me the effort necessary should we choose to go that route?” In so many instances the request to estimate an action is seen by staff as a telegraphed desire to actually do it, potentially leading to errors.
• In another example (that happened only once), several events came together against a rapidly-approaching deadline, and the calming influence of the Controller seemed to break down for just a minute or two. At that point another, more senior individual* came on the line, and rather than making a snap decision, he reminded everyone to get back to their established process and continue using it to determine the next course of action.  Again, how many times has this happened to you in a large IT program? When the process broke down and everything was escalated to you as the decision-maker at the last minute, did you make the snap judgement for your team, or did you instead ask them to utilize their established process to determine the next action?  What did they learn from you, if you took it out of their hands?

Say what you want about the bureaucracy and waste in a large institution such as NASA; these folks know how to communicate well in a complicated deployment (launch), and there seems to be much we can learn from them in managing large IT programs.

Your comments are welcome. If this post was helpful, you might like to subscribe to the RSS feed, sign up for weekly updates via email or follow me on Twitter.

Tagged as: Program Project Management, Project Communication