#NASATweetup – It’s a GO! Readiness Reviews and Your Projects

Image via Wikipedia

I’ve been tweeting a lot about NASA, the shuttle program, and space anniversaries lately because I’m attending the NASA Tweetup on 28-29 April.  I can’t tell you how exciting I am about attending, especially after the 10-day delay we experienced earlier in the month.  The delay was due to the Russian mission to the International Space Station (ISS) causing a traffic jam in space, so the Endeavour Shuttle launch was delayed.

Even though the delay was announced well before today, we didn’t know until just now that the date is a go because today was the Flight Readiness Review, where experts do a complete system risk assessment of all the systems and dependencies for Endeavour and the Space Station.

The Flight Readiness Review is a type of design and operations review that ensures that everyone and everything is ready for launch.

• More debris tile to provide more debris protection in more locations
• Systems on board the Space System needed to be checked because Endeavour will be doing maintenance on the Space Station
• Alpha Magnetic Spectrometer (AMS) being installed on the ISS requires checking
• ET-122, the External Tank, was struck during Hurricane Katrina and needed extra inspection. It is 10 years old and does not have all the improvements that newer tanks have.

If all the systems, people, software, facilities, and other components check out, the launch is scheduled.  So today, the official go ahead was given for the scheduled date.

All of this makes me think of larger application production rollouts.  I’ve been part of many readiness reviews, both formal and informal.  However, this usually with my methodologist or project manager hat on, not very often with a data architect hat.  I have a feeling that this is because the normal issues I would raise as a data architect (missing requirements, incorrectly implemented requirements, etc.) would be dealt with much earlier in the process, such as during a normal development quality control test.

Where problems usually arise late in the production cycle are when someone incorrectly sets data, not data structures incorrectly.  In even the most dysfunctional shops, most organizations have come to understand that allowing people to make ungoverned structural changes is a huge risk.  However, I have not seen nearly enough of the type of controls and monitoring for reference and master data, especially things like reason codes, reference codes (Customer type, Product type, etc.)

What I can appreciate about NASA’s Flight Readiness Reviews:

1. Documented.  Everyone knows ahead of time what their job is, what is expected, what the quality standards are.  They agree to it up front. There are manuals, checklists and checklists of checklists.
2. Expected.  No cowboy engineer thinks that he can make a quick change just before the launch and force the change to be accepted because it’s too late to undo it or too late to miss the date.  No one says "we don’t have time for the FRR.  Just put ‘er into production".
3. Formal. The review is scheduled.  It has assigned tasks.  Everyone, even external parties, know that it is coming and understand the role it plays.  There’s a press conference for the results.  There are probably even signatures.
4. Open. As far as I can tell, the results of each check is shared openly.  Even the "fixes".  The results are published.  Media can ask questions and the live results were tweeted throughout the day.
5. Reflective.  The review concentrates on failures, damages, problems and issues of previous flights.  These issues aren’t swept under the rug in hopes they don’t happen again.
6. Risk-based.  There are issues documented.  They are assessed against risk and probably cost.  Time is of the essence, but it isn’t the only discussion.  Risk is inherent in the space program. Understanding it and mitigating it is the name of the game.  Avoiding all risk would mean no space program

Of course, the reason NASA has such a strong governance process for shuttle flights is because lives are at risk, as well as a huge pile of money.  This doesn’t mean that our own application systems can’t do harm.  I tweet regularly about data breaches, customers who are harmed financially and businesses that are lost due to poor data policies.  Often these failures are due to poor governance. 

Even if you project does not have a formal readiness review you can have your own personal process.  I have many checklists and tests I run on data models and scripts I generate.  These are my own readiness reviews. I share them with team members. There’s a reason why NASA has readiness reviews and there are important reason why you should, too.

Related articles

2 Comments

• 
  Marie Haggberg 20 April 2011 at 11:46 AM

  I’ve found the “reflective” component to often be the most difficult for many companies, This may be due to company culture, lack of technical depth/understanding, or plain wishful thinking.

  Thanks for the good post.

  Reply
• Making The Hard Decisions On A Project–Lessons From NASA | InfoAdvisors' Blog 2 May 2011 at 6:29 PM

  [...] [...]

  Reply

Leave a comment

Click here to cancel reply.

Name (required)

Mail (will not be published) (required)

Website

Comment

Notify me of followup comments via e-mail. You can also subscribe without commenting.