Project Management

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

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Lynda Bourne
Kevin Korterud
Peter Tarhanidis
Conrado Morlan
Jen Skrabak
Mario Trentim
Christian Bisson
Yasmina Khelifi
Sree Rao
Soma Bhattacharya
Emily Luijbregts
David Wakeman
Ramiro Rodrigues
Wanda Curlee
Lenka Pincot
cyndee miller
Jorge Martin Valdes Garciatorres
Marat Oyvetsky

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie

Recent Posts

3 Ways to Challenge the Agile Norm

What’s In Your Return-To-Work Contract?

How To Foster Effective Group Decision Making

3 Tips for Avoiding the Single Point of Failure

The Power of Diverse Project Teams (Part 2): How To Elevate Your Cultural Awareness

Categories: Innovation

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?

Posted by Lynda Bourne on: May 24, 2021 06:42 PM | Permalink

Comments (8)

Please login or join to subscribe to this item
Although all projects are unique endeavour however the real skill of project management team is to create a realistic plan considering various risks identifying multiple mitigation strategies to proactively deliver the project on-time & within budget with quality & safety.

Dear Lynda
Very interesting the theme that brought to our reflection and debate
Thanks for sharing, for the historical background and for your opinion
I appreciated the suggestion: "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 ".
It seems to me to be a good preventive measure

Thanks Lynda,

Murphy's Law, as it pertains to project delivery, is the reason why we put so much effort into risk identification.

When we consider project delivery risks, it is often the most difficult to identify risks that constitute the greatest danger. That is one of the reasons why we need to put extra effort into risk identification.

An excerpt from the book "Bullet Dodging - A Risk Management Handbook for ICT projects" describes the issue well:

"One danger to watch out for in your risk identification workshop is people wanting to rush through risk identification if they feel they dont have enough time. When people are under time pressure and stressed, their vision tends to narrow. Questions like, "What are the key things we must do?" can lead to narrow thinking that can seriously reduce the value of your risk identification efforts.
If you run short of time, dont fall into the mistake of succumbing to catch phrases like "80:20 rule," "focus," "prioritize," and "critical success factors." Such catch phrases narrow thinking and reduce the effectiveness of risk identification.
Instead, manage your time throughout the workshop to forestall any sense of urgency and encourage broad, open mindsets.
You may have to run through all the easy and obvious risks before people start to identify the edges of uncertainty. Allow enough time to cover the easy and obvious first before probing for the more difficult areas of uncertainty.
The real danger often lurks within the difficult-to-identify 20% of the project risks. The easily identified 80% are more likely to be handled within the projects normal course. In risk management, it is not these low-hanging fruit that cause trouble; it is the hard-to-reach 20% nestled in the upper branches where the real danger lurks! Keep to the agenda and work your way through the probing tools to ensure you capture as many risks as possible.
In the following section, we explore the tools and techniques that you can use to prompt participants to identify more risks. I recommend holding back these prompts until after the natural flow of new ideas from brainstorming has dried up, lest the prompts influence and divert your participants natural flow of thought.
Once the natural flow of ideas has run out, tools and techniques provide an effective prompt to uncover the more difficult to identify risks. They encourage participants to identify risks that hadnt been considered before. Keep in mind that the objective is to stimulate thought about uncertainty. Even if one aspect of a tool or technique is not directly related to your project, it might inspire a participant to think of one that is."

Valid comments Alan but missing the point of the post. The 'risk workshop' is never enough. The application of 'Murphy's Law suggested is every time something is started evaluate the actual potential for something to go wrong - in engineering this is called 'Take-5' (minutes to work out how to do the job safely before starting).

Thanks Lynda. Very insightful.

I think before 2020, many project managers would honestly tell you that they didn't put a lot of effort on this.

Thanks Lynda. Very insightful.

I think before 2020, many project managers would honestly tell you that they didn't put a lot of effort on this.

Thanks Linda, there are so many uncertainties along project execution... this is why proactive preventive risk management approach is very relevant, trying to anticipate, drafting what-if scenarios and action plans for each of them (or, at least, those which causes the highest impact on the metrics considered important for that specific project).

Please Login/Register to leave a comment.


"If we knew what it was we were doing, it would not be called research, would it?"

- Albert Einstein