How to mitigate project failure

Project Failure is not planned. Or is it?

Panglossian \pan-ˈglä-sē-ən\ adj.

Markedby the view that all is for the best in this best of possible worlds.
Excessively optimistic.

Merriam-Webster Dictionary


If you work in projects frequently, these situations will be all too familiar to you.

First situation, you are attending a kick-off meeting, looking forward to a new project, getting to know the colleagues with whom you will be sharing the next weeks, months or even years. Project managers describe how you, as a team, will reach your expected goals and guide you through a slide deck prepared with great intention and sometimes, unbridled optimism.

Now to the second situation.

A project manager in distress. Maybe the one who gleefully took you through that kick-off deck or maybe they are gone already. Unmet deadlines, budgets blown, low morale, disgruntled sponsors, and end-users who are still to benefit from the results of the project. Or worst, and most dreaded, an angry customer.

This short article is about one of the reasons why this happens and three simple questions you can ask yourself to prevent any problem that may occur during the project [1].

Since hindsight is 20/20 and we are all experts ex-post, let us try to outline what can be done at the earliest stages to prevent reaching this point.


Three Simple Questions to Mitigate Project Failure

What questions can project managers ask, before planning their projects, to mitigate failure?

  • Am I planning my project based on a standard blueprint, or on previous similar projects?

The reality of our work, the fast pace, the pile up of new projects, can put us in a position in which recycling a generic blueprint is a quick, relatively safe way to kick-start a project.

Many organizations provide these handy tools.It is worth taking an hour or two to reflect and ask ourselves if what we are using truly represents what our project should look like.

  • What assumptions are being considered in my planning? Do they match the reality of my project?

It is common to base a project plan on a scope document or on a sales order (in smaller organizations or projects). Those documents often describe with detail which considerations have been taken by your Sales team (or your purchasing department, depending on which side you are on).

At the handover, assumptions need to be checked, defied, debunked, rebuilt, and turned into clear delivery objectives. It is an often-overlooked task and that has hard consequences later in the project.

With this information readily available, how much time or effort would it take to validate it with your project team or counterparts? And how much time or effort will it save you in the future?

  • From experience, what are the main sources of risk for similar projects? Are those being considered in my planning?

Some years ago, in a workshop, I met a particularly pedantic ivy-league graduate [2] and we got to talk about the steps each of us took when setting up a project in Microsoft Project.

I rejected his advice quickly but have learned the hard way that he was right, and I was very wrong. How often do we dismiss other people’s hard-earned experience?

It should not be a breakthrough notion to stay on high alert and be appreciative of guidance. Relevant guidance, pedantic or otherwise, can be very powerful.

Whatever your project is about, somebody in your network must have gone through it before. A quick chat can save you time and money and steer you away from incautious planning.

This “systematic tendency toward unrealistic optimism about the time it takes to complete projects” [3] is known as The Planning Fallacy[4]. This is reflected in forecasts that look suspiciously like best-case scenarios and could benefit from looking at the results of previously executed similar plans [5].


It is never too late 

Planning fallacy occurs when we ignore experience, do not check on similar projects or endeavors, or fail to review the assumptions of our planning. It is easy to be swept by the enthusiasm of a new project and forget that if something can go wrong it often will [6].

Asking these three simple questions can help us evaluate the strength of our planning and tweak where necessary.

  1. Am I planning my project based on a standard blueprint, or on previous similar projects?
  2. What assumptions are being considered in my planning? Do they match the reality of my project?
  3. From experience, what are the main sources of risk for similar projects? Are those being considered in my planning?

It is never too late to stop and try this approach; it is embedded in most of the project management methodologies we apply nowadays. However, the later in your timeline that you stop and ask these three simple questions, the more effort it might take to adjust and deliver successfully.

By: Fabio Rodriguez

Senior Project Manager

[1] Clearly, not all projects meet the same fate. There are many accounts of successful implementations, flawless deliveries, and such. There are plenty of success stories, one-pagers, and white papers available to all of us who rejoice in our peers’ success.

[2] Later I found out that it had been a two-week extension class.

[3] Thaler, R.H., & Sunstein, C.R. (2009). Nudge: Improving Decisions About health, wealth and happiness. London: Penguin Books.

[4] Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures”, Management Science 12 (1979): 313-27.

[5] Kahneman, D. (2012). Thinking, Fast and Slow. London: Penguin Books.

[6] Murphy’s law is an adage or epigram that is typically stated as: “Anything that can go wrong will go wrong”, source Wikipedia ‘Murphy’s Law’