Learning From Our Mistakes

As a child, I learned an old saying as I would curiously explore our local dairy farm, “The first kick by a mule is educational.” Fortunately, I understood the magnitude of that saying, even though I was amidst Holsteins, and paid a lot of attention to my special relationship to my bovine friends. In business, however, it seems we struggle with the concept of experiential learning.  We seem to repeat the same antics getting our projects into the equivalent trouble time after time. If you really learned from your mistakes, ERP implementation would be from rote.  The issue is that we have failed to structure business to learn from our mistakes. Especially in the information technology (IT) world, we need a culture that allows us to find the root cause of problems as they occur and fix them at that time.



To proceed down a recovery path, people need to admit there is a problem. Denial, pride, ego, emotion, and inertia blind us to the issues of the situation. Project managers stubbornly believe they can correct the problems. As news leaks out about the  increasing trouble, executives decide to help by assigning additional tasks, new processes to follow, numerous spreadsheets to complete, and daily reports to distribute. Eventually, the customer becomes aware and they go to the steering committee demanding action. The latter gets action. The resulting scramble to appease the customer, however, does little to solve problems. It only addresses the symptoms.

Addressing The Problem With Logical Analysis

The solution is a methodical, calm approach of auditing the project’s current state, analyzing the options to make it successful, negotiating a new approach, and implementing the new plans.

The project audit acquires data to drive the rescue. Like the well-accustomed financial audit, this phase is an objective, nonjudgmental data gathering exercise. Few, if any, actions are taken. Increased communication and reduced chaos are the only improvements that result.

The second step is analyzing the information, identifying the root causes of problems, and formulating a recovery plan. The most critical point is associating problems with their sources so that its genesis will be addressed and fixed. Correcting problems at their root eliminates them from affecting this and other future projects. Unfortunately, in the mayhem and haste of fixing most projects, this essential step is often sacrificed. The result…failure to learn from our mistakes.

The Rescue Is Its Own Project With Its Own Plan

The recovered project’s plan is necessarily different from the original. Something on the project must change, time has been lost and money spent, one or both are over budget; otherwise, the project would not be red. These changes require stakeholder approval. Therefore, the third step of the recovery process is negotiation and approval of the new approach. Without a thorough understanding of the problems, identifying the root causes, and developing plans to address them, attempting to convince anyone that the new solution is any better than its predecessor is fruitless.

With negotiation complete, the root causes can be addressed and the new plans executed. Addressing the root causes first makes the project run like any successful project.

The Three Projects In A Rescue

Thinking of the recovery as a project itself requires understanding the stakeholder’s requirements and getting their agreement on the rescue’s deliverables. Hence, there are three projects in every rescue effort. The recovery project is sandwiched between two other projects—the failing project and the new successful project. The recovery process generates multiple corrective actions that will predicate the new successful project. The benefit of properly addressing a failed project is the deliverable of the recovery project—corrective actions. Properly applying these corrective actions solves the problems so it will not reoccur on this and follow-on projects.

Experience shows that most problems have little to do with the internals of the project itself. The most common are related to the organizations that are responsible for the project. How the project was conceived, its size and complexity, inadequate managerial support, the organization’s lack of discipline, or its policies and procedures are by far the most common in dooming a project. These problems need to be fixed in the organization, rather than in the project.

To understand the knowledge required to identify and solve the root causes, let’s look at a common issue for system integrators. Integration projects often get into trouble because the assigned people are lacking the skills to adequately do the work. There are two solutions to the project’s problem: 1) train team members to acquire the required skills, or 2) replace them with appropriately trained resources. Besides the objections to the cosst involve, this fails to address the real problem. The audit the recovery manager must ask, “Why are resources missing these skills?” It is surely not the individual’s fault. A common reason is that a combination of policies generates this problem. System Integrators must keep their staff billable; therefore, they have policies to use internal resources prior to bringing in outside help. Unfortunately, they normally lack any proactive policy about training staff on the technologies required to fulfill their strategic roadmap. The training must be part of overhead or factored into the time and cost of the project. Initially this looks great—a lower bid price. The result is a project with deficient resources and higher final cost, which is usually not covered by the customer.

A Learning Culture

Organizations excel when their projects are successful. To turn the ever present project failure problem into continued success, we need to take a deliberate, methodical approach to rescuing them. Look beyond the reaction to Band-Aid the project in an effort to get to rapid completion and focus on solving the root causes. This requires a new attitude and company culture. One that realizes that we must change how we conduct business, dismantles organizational silos, and uses each failure as an educational opportunity. In this environment, each failure becomes a gold mine for improving our organization and the first kick by the mule becomes educational.


About Todd C. Williams

Todd C. Williams can be found on most social media venues by the moniker BackFromRed. In his book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure (AMACOM, 2011), he explores the rhymes and reasons for project failure, how to rescue them, and methods to prevent their reoccurrence. The book contains nearly 70 case studies to show how problems were addressed in real life and is available at all major bookstores. You may read his blog at http://ecaminc.com.



  1. Hi Robert,

    On the “three recovery projects” point. Why are you saying that the old project is different from the new project? Both are the same, the recovery project is just a process to put the project on the right track… Am I missing something?

  2. Dana Craig (@danalcraig)

    This is a great post, Todd. Thanks for sharing your thoughts with us.

    Another barrier to associating problems with sources seems to be a general reluctance to speak negatively or ‘assign blame’, whether the discussion points to processes, individuals, or other downfalls. I’ve experienced some corporate cultures where it is very difficult to get people to a comfortable enough place to have this discussion or perform this analysis in any thoughtful way, even in the face of a failing project. If the PM hasn’t been consistently building a foundation of trust, it’s almost impossible.

    PM’s need to understand and embrace that their role as team-builder, trust-builder, and leader extends beyond the project team and is critical to the success of a project or the ability to recover a failing one.

    Looking forward to hearing more from you on Friday!