Magazine Spring 2015 Research Feature

Reducing Unwelcome Surprises in Project Management

Many project challenges and failures catch executives by surprise. But not all such surprises are truly unforeseeable — if you know where to look.

Tyson R. Browning and Ranga V. Ramasesh Reading Time: 22 min 

Topics

Permissions and PDF

Why do so many projects fail to meet their goals for time, cost and performance? Regardless of the answer, many project managers and their executive sponsors seem to be surprised when a new project gets off track: “Why didn’t we see that coming?” Even projects that employ sophisticated techniques for risk management can encounter surprising derailments. Those methods, while powerful, can only manage known risks. But projects are new and unique. What about the things that we don’t even know that we don’t know? These “unknown unknowns” — often called “unk-unks” — are lurking in every project, just waiting to emerge, surprise and derail plans. To what extent are they inevitable? What could we do better?

Project knowledge comes from learning about the project — its overall context, its goals and objectives, the process for achieving them, the people, tools and other resources to be deployed, and how all of these affect one another. This learning begins in the planning stages. One might think that planners would consider all of the scenarios, evaluate all of the options and identify all of the risks — but that is seldom the case. Many planners resist wasting resources on planning projects that may never happen. Even after a project gets the green light, a typical attitude of many managers is: “We’re already behind. We know what we need to do. Let’s get started!” As a result, the distinction between what is knowable about a project and what is actually known can be quite large.

Many so-called “unk-unks” aren’t really unk-unks at all. Rather, they are things no one has bothered to find out. Indeed, there are two kinds of unknowns: unknown unknowns (things we don’t know we don’t know) and known unknowns (things we know we don’t know). (See “Converting Knowable Unk-Unks to Known Unknowns.”) Every project has some of both. The techniques of conventional risk management apply only to the known unknowns. Yet some unk-unks are knowable and can be converted to known unknowns through a process of directed recognition.

Topics

About the Authors

Tyson R. Browning is an associate professor of operations management at Texas Christian University’s Neely School of Business, in Fort Worth, Texas. Ranga V. Ramasesh is a professor of decision sciences at Texas Christian University.

References (19)

1. These five project subsystems have been noted in several prior works, including T.R. Browning, E. Fricke and H. Negele, “Key Concepts in Modeling Product Development Processes,” Systems Engineering 9, no. 2 (summer 2006): 104-128; S.D. Eppinger and T.R. Browning, “Design Structure Matrix Methods and Applications” (Cambridge, Massachusetts: MIT Press, 2012); and R.V. Ramasesh and T.R. Browning, “A Conceptual Framework for Tackling Knowable Unknown Unknowns in Project Management,” Journal of Operations Management 32, no. 4 (May 2014): 190-204.

2. S.D. Eppinger, “Innovation at the Speed of Information,” Harvard Business Review 79, no. 1 (January 2001): 149-158.

Show All References

Tags:

Reprint #:

56319

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.

Comments (4)
Rabindranath Bhattacharya
Dr. Rabindranath Bhattacharya

First of all I Iike to thank the authors for such a wonderful very relevant article. I would be curious to know where the natural calamities like flood or earthquake would be placed. Are these  unknowns-unknowns or knowable unknowns for a project?  in supply chain  parlance it is underestimation of the probability  of an event  likely to happen. In such cases managers try to overlook the things saying this won't happen instead of taking alternate route since  there is hardly any past record (once in a blue moon!) for the incident also. 
Is it possible to mitigate the risk  for large scale disruptions of the projects owing to these natural calamities? How much the cost and time overrun  are expected to be taken into account in such cases?
Wouter Teijema
Thanks for sharing thisI I created a software company called Gordians having No More Surprises as a tagline to help organisations manage known unknowns and explore unk-unk's. We take a pragmatic approach that covers parts of most of the points mentionned above to create dashbords that provide a strong first line of defense against surprises, specially in large complex initiatives, to proactively address surprises. So fully endorse the article!!
JEFFREY A MORROW
Really well done! You have given us a useful modeling framework, one that I will take advantage of. I particularly like the "development as problem solving"  perspective. 

One question: where does technology (un)readiness fit in? It seems it might get lost in a number of the Situations categories but in my (commercial aerospace) experience it's a big deal on its own. Much of what passes for tech readiness risk mitigation seems to exist as a kind of comfort blanket i.e., as it's own form of mindlessness; even so, when you do tech dev on the critical path and try to hold the launch schedule and business case you spawn all sorts of killer unk-unks.
Shahidul Islam
It's really a important post. I enjoyed this article. Congratulations.
undefined