Downtime can mean life or death!

When I was in grade school I read a book about Ernest Shackleton the Antartic explorer. I was fascinated by his story of survival under the most brutal of conditions. Over the years when ever I saw something concerning Shackleton and the race to the south pole it caught my attention immediately.

Shackleton's expedition was a failure, they didn't reach there goal, and nearly lost there lives. It was only through courage and shear determination that they managed to survive. When you study the Shackleton expedition you find that the crew was ill prepared, there ship the Endurance wasn't well suited for the ice and eventually was crushed and sank. The Endurance crew being stranded, was forced to sail to South Georgia Island, hundreds of miles away in open life boats. Shackleton was also probably overly optimistic, and aggressive in his plan, taking on more risk than was necessary.

Often times I think IT projects are like Shackleton's expedition, they fall short of the goal, and a massive heroic effort is required to survive. Many times I have seen a change go into production that was said to be "transparent, no one will notice", twenty four hours later, sleepy eyed technicians finally get things back to normal. The technicians are applauded for there superhuman effort, and no lessons are learned.

The best IT organizations aren't always perceived as doing much, since they don't suffer these catastrophic failures. IT failures don't have the same life and death consequences as an Antartic expedition at the turn of the 20th century, but they can mean life or death to the business.

For a life and death survival give me Shackleton. For IT survival give me good planning and careful execution.