Comments on: Making The Hard Decisions On A Project–Lessons From NASA http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/ Love Your Data - Team Data Wed, 01 May 2013 23:34:34 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: Peter Thomas http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-674 Peter Thomas Thu, 05 May 2011 08:09:05 +0000 http://blog.infoadvisors.com/?p=752#comment-674 Hi John,

I think that the idea of simple guiding principles is a sound one, but they also need to relate to something concrete and not simply be platitudinous. To pick on one thing, what does “data integrity is never compromised” mean in practice. It is a goal that most people would agree with, but what would people do that is different on a day-to-day basis?

It is a bit like the corporate slogans that are bandied about. If there is not a connection between the macro and micro levels then the people actually carrying out the work of an organisation are likely to simply shrug their shoulders and get on with whatever they were doing before.

All the best

Peter

]]> By: John MacIntyre http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-673 John MacIntyre Thu, 05 May 2011 03:40:29 +0000 http://blog.infoadvisors.com/?p=752#comment-673 It’s important to remember as well that the decision procedures don’t need to be lengthy binders and binders of procedures either. It can be as easy as a few guiding principles; all tests must pass, data integrity is never compromised, we don’t deploy anything that hasn’t been tested to production, etc…

]]> By: Karen Lopez http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-672 Karen Lopez Wed, 04 May 2011 19:48:32 +0000 http://blog.infoadvisors.com/?p=752#comment-672 Yeah, I’d love to see the look on my CIOs face if I said she had to start implementing NASA procedures to move forward. I’m currently sitting in Florida, waiting for the cause the first launch attempt being scrubbed to be fixed. From an observer’s point of view, I just want to see them light that candle. I feel so much like an end user who has no idea why this is taking so long, why they can’t just run out to Radio Shack and get a new control module power unit and a heater and put everything into production…er…outer space.

But I think Rob’s excellent point is that we often forget in the heat of the moment, just as we all think we are ready for production, that we should outline some Go/No Go terms so that our emotional attachment to the release don’t overrule the logical arguments of why putting something into production prematurely might cause harm to others.

Ultimately, our duty as professionals is to mitigate harm, even if it means professional or personal emabarrassment to team members. Having some formal procedures is a good thing. Having them ahead of time, before the excitement of a launch is even better.

Yes, NASA changed their decisions based on some catestrophic failures that most of of us in IT don’t have to face. But we still manage to put things into production that we new were faulty, that we knew would cause harm. That’s the unacceptable part.

I’m going to head off and check the weather predictions and the NASA.gov website for the 10 millionth time today…and I might just head over to Radio Shack to see if they have any spare power units hanging around.

]]> By: Peter Thomas http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-671 Peter Thomas Wed, 04 May 2011 14:40:36 +0000 http://blog.infoadvisors.com/?p=752#comment-671 Hi Rob,

I agree with you – but not sure that an organisation the size of NASA, carrying projects of the complexity that they do, can ever be an exemplar for more quotidian projects that most readers would be involved in.

Maybe you have done so already, but I would encourage you to read Richard Feynman’s annexe to the Rogers Commission report on the Challenger disaster. Common to our world, one of the things that this focused on was the manner in which software was developed and tested. Another is the general approach to estimating and aggregating risks of failure. Some salutary reading in there for any IT professional; even those not involved in life-and-death situations IMO.

All the best

Peter

]]> By: Rob Drysdale http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-670 Rob Drysdale Wed, 04 May 2011 14:30:57 +0000 http://blog.infoadvisors.com/?p=752#comment-670 Peter,
Every organization, and even profession, needs to learn from their failures and improve their processes and procedures. That’s why you see improvement in safety legislation, engineering standards, etc. I agree that there have been failures in the past, but they still have a lot more rigor in their procedures than most organizations do and I think it’s important to highlight that because I think we can learn from what they do.

]]> By: Peter Thomas http://blog.infoadvisors.com/index.php/2011/05/02/making-the-hard-decisions-on-a-projectlessons-from-nasa/#comment-668 Peter Thomas Mon, 02 May 2011 23:29:08 +0000 http://blog.infoadvisors.com/?p=752#comment-668 Maybe WWND was based more on bitter experience than anything else – well-documented failures of project management contributed to some of the more tragic episodes in NASA’s history. Maybe you need to change the acronym to WWNDN with the final N standing for Now.

Peter

]]>