Lessons from failure: check the technical data

I would like you to (1) learn from the failures of others (the quickest, cheapest and least painful approach) and (2) embrace the idea that failure is not optional – it is your best friend.

Lesson: check the technical data

In November 1999, NASA lost a $125m satellite, the Mars Climate Orbiter within 37 miles of the surface of Mars. There were a number of causes of this catastrophic result:

  • a failure to spot that the data was in an imperial not metric unit (and to check the related assumptions)
  • miscommunication i.e. not clarifying the unit used
  • the focus on ‘better faster cheaper’ as a goal of the project rather than ensuring the satellite successfully arrived at Mars [read more].

In the 1982 Hyatt Regency walkway collapse, a failure to pay attention to technical details resulted in 113 deaths. The was no unusual or innovative engineering but a small detail “and yet it killed more people than any other building failure in the United States.” [read more]

In 2010, the Robin Rigg wind farm needed remedial works totalling EUR25m when a Norwegian standard for wind turbines made an incorrect assumption (resulting in the decimal point on a delta value being incorrect). As a result the turbines would fail to meet the contract’s technical requirements. Although held ultimately liable, one of the contractor’s arguments was that onerous requirements should not be hidden in the technical data! [read more]

What should you do?

Should you really throw caution to the wind?

I am not advising taking huge un-quantifiable or unnecessary risks. Far from it! As one of my favourite quotes [from IBA v EMI 1980] ends:

The law requires even pioneers to be prudent

As prudent pioneers we need to learn from the past. These 3 very expensive failures provide these 3 lessons:

  1. To check the technical data in the contract is correct (with technical and legal experts reviewing the whole contract for inconsistency, errors and ambiguities)
  2. Where even minor changes or defects would be catastrophic, to ensure the contract includes procedures to communicate changes, double-check data and encourage early warnings of issues
  3. To ensure the contract sets out the main project goal, and that this is used during decision-making as the project proceeds, so success is not derailed by cost-cutting.

Failure can only help if we face it head on, learn from it and change.

Like this article?

Share on Facebook
Share on Twitter
Share on LinkedIn
Share on Pinterest

Leave a comment