Murphy's Law: It’s a Call to Action, Not an Excuse

 

By Lynda Bourne

Anything that can go wrong will go wrong.

We’ve all heard—and have probably uttered—this epigram many times.

The origin of the phrase now known as Murphy’s Law is often attributed to U.S. Air Force colonel and flight surgeon Dr. John Paul Stapp, who directed research Project MX981 in the late 1940s. The objective was to determine the effect of gravitational forces (g-forces) on the human body—and to use this data to work out how to safely eject pilots from high-speed jet aircraft. The experiments involved rapidly accelerating and decelerating rocket sleds carrying varying payloads, including human volunteers. For many of these experiments, Stapp served as the volunteer so he could apply his medical knowledge directly to what he was feeling. Over the years, he collected a catalogue of broken bones and other injuries, but no one was seriously injured or killed in large part due to the application of Murphy’s Law.

To validate the experiments in Project MX981, Stapp required very precise measurements of the stresses being experienced by the volunteers. He became aware that Capt. Edward A. Murphy was working on another project involving centrifuges, which included designing very accurate systems to measure the g-forces exerted on the person in the centrifuge.

From Stapp’s perspective, Murphy’s sensors seemed to be ideal for accurately measuring the forces the person strapped to the rocket sled experienced. Murphy happily agreed to Stapp’s request to modify his sensors and shipped a couple to Stapp for use. However, the first experiment Murphy’s gauges failed completely: No measurements were recorded. When Murphy came out the morning after to investigate the failure, he found the gauges were oriented incorrectly and is reported to recall saying, “If there is more than one way to do a job and one of those ways will result in disaster, then somebody will do it that way.” Murphy had made accurate drawings of the gauges and instructed the people who would install them but had not made it clear that the gauges had to be positively oriented in only one direction.

The origins of Murphy’s Law lies in a conversation following this failure. Murphy recalled saying, “Well, I really have made a terrible mistake here, I did not cover every possibility.” Stapp replied: “Well that’s a good candidate for Murphy’s Law,” according to Nick T. Spark’s “A History of Murphy’s Law.”

The experiments continued with the final test run before the project was terminated. With Stapp as the volunteer, the test resulted in the sled accelerating from 0 to 630 miles (1,014 kilometers) per hour—the highest land speed of any human—in 5 seconds, creating a force of 20 Gs. The sled then stopped in 1.4 seconds, imposing 46.2 Gs of force on Stapp.

When asked many years later about the remarkable safety record of Project MX981, Stapp said one of the key factors was the application of Murphy’s Law: “The entire team adhered to Murphy’s Law, they always kept in mind whatever could go wrong would, so they made extreme efforts to think up what could go wrong and fix it before the test.”

While your project is unlikely to have the risk profile of a ride on a rocket sled, designing potential problems and failures out of the overall system pays dividends. Success is designed in, not tested in. To apply Murphy’s Law proactively, you need to think through everything before you start work. Ask yourself: When one part fails, does the system still work? Will it still function as it was supposed to do? What are the single points of failure? What are the processes someone can do incorrectly?

This type of thinking establishes potential critical failure points, where there’s a need to put redundancy into systems. It also pushes teams to ensure the opportunity for human error is eliminated wherever possible. There are formal approaches to applying Murphy’s Law, such as failure modes and effects analysis or reliability engineering used in system engineering and on the design of critical systems. But you probably don’t need to be this sophisticated on your project. Simply ask your team to think through what can go wrong and what can be done about it. This approach may be included in the project’s regular risk reviews or included in the agenda for the daily stand-up or other team meetings.

How will you apply Murphy’s Law with your team?