There's No 'Root Cause' in Project Failure

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

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Joanna Newman
Vivek Prakash
Christian Bisson
Linda Agyapong
Cyndee Miller
Jess Tayel
Shobhna Raghupathy
Rex Holmlin
Roberto Toledo
Ramiro Rodrigues
Taralyn Frasqueri-Molina
Wanda Curlee

Recent Posts

Agile Evolves

3 Tips to Enhance Your Leadership IQ

3 Tips for Becoming a Better Listener—and a Better Project Manager

Maximizing the Value of Agile

A Scrum Master’s Duty


Categories: Stakeholder


"Complex problems have simple, easy to understand, wrong answers."
-- H. L. Mencken

When a relationship with a key stakeholder breaks down, or there is some other failure in your project, it's tempting to assume there is a 'root cause.' We think that by finding and fixing this key factor, the problem will be resolved.

Many tools help find the root cause and these tools work for simple problems. However, they are dangerous to use in complex systems.

The '5-Whys' approach assumes that each presenting symptom has only one sufficient cause. By asking 'why?' five times, you can drill down to the root cause.

For example, say that your boss complains that her computer is not working. You see the plug is out of the wall socket. You replace the plug and solve the problem, right? Well, the answer depends on how you define the problem:

Problem: Lack of power. Solution: Replace the plug.
Problem: Lack of training or knowledge. Solution: Teach your boss about the plug.
Problem: Poor joinery design. Solution: Put the power points on the desktop instead of on the floor.

The '5-Whys' approach requires the right definition of the problem to start digging for a root cause. Even then, the approach only follows one line of thinking, which limits its ability to identify complex interactions.

When considering problems in socio-technical systems, such as stakeholder relationships, the assumption that there is a single event that triggers a chain of events that lead to a problem is false.

Most problems have multiple contributing causes. Each element is necessary but only when all of the elements are combined 'correctly' is there sufficient impetus to create the breakdown. When trying to understand failures in complex systems, like relationships, a different paradigm is useful.

For example, let's say you used a range of motivational techniques to help your team perform that have worked well in the past. This time, however, the team disintegrated, and productivity dropped. Chances are that the problem emerged from a confluence of conditions often associated with the pursuit of success. But in this specific combination, there was "trigger failure;" each item was necessary, but on its own or in a different combination could be more beneficial.

These unexpected outcomes are encountered because complex systems, like relationships in and around a project team, have emergent behaviors, not resultant ones.

Complex causes require subtle management. You need to be continually prepared for nonlinear behaviors where small problems can result in large and cascading failures.

Rather then resolutely applying your standard approaches, look, listen and 'tune-in' to your team. When a complex system reaches the tipping point and collapses into failure, it is too late. You need to feel the issues emerging and adapt to the changing situation.  

How do you detect failures in stakeholder management?

Read more about stakeholder management.

Posted by Lynda Bourne on: June 14, 2012 10:59 AM | Permalink

Comments (1)

Please login or join to subscribe to this item
Travis Nice, PMP
I respectfully disagree that the cause for a project to not completed on time, go over budget, or fail to function as intended cannot be narrowed down to one or two root causes using common root cause analyses like the “5 Whys”. (Quality and Safety are inherently part of the scope.) Furthermore, ignoring Acts of God, labor strikes, war, and other events out of the project team's control, the root cause almost always lies within scope definition. i.e. If a widget cost more to build than planned, it's because the work (scope) required to build the widget was poorly defined. Likewise, if the widget took longer to build than planned, the amount of work (scope) involved was not fully understood. We are then tempted to the ask "WHY wasn't the scope fully understood". But at this point, asking "Why?" really transitions to asking Who?". This indicates you are moving from cause identification to solution development, which may be multifaceted and complex.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one anymore."

- Mark Twain

ADVERTISEMENT

Sponsors