quick fixes are a real pain!

and here is why they often lead to more trouble than they resolve...

As project managers, we’re often requested to get roadblocks out of the way as quicklly as possible for the team to continue progressing. So, we’re quite often in problem-solving mode, attempting to resolve as fast as we can the issues that arise and risks that become facts.

A useful thing to keep in mind when doing so is to ask ourselves: are we really addressing the issue or are we only fixing a symptom of the issue? Understanding the difference between the two is very important. In other words, is our quick fix action really aimed at curing the root cause of the issue? Or is fixing the symptom only a step in the right direction? If the answer is yes to any of these questions, we’re on the right track. But it’s not always the case…taginlineimport

This post is inspired by a training session I organized and attended for the management board of a non-profit organization (PMI France-Sud) a couple of years ago. Jerry Brightman, a renowned leadership expert and president of a company called The Leadership Group, was kind enough to facilitate this educative session for our team.

Let’s take an example to illustrate the topic and walk through this case to better understand what could be happening: “a team member comes into your office to announce a probable delay on one of his deliverables.”

the way it usually starts:

1. We see a problem, or to be more precise the symptom of a problem. Definition of a symptom: “a sign, indication, manifestation; something caused by and indicative of a certain disease or disorder.” In this example, a team member signals that he may not be able to deliver his part of the project on time.

2. We apply a quick fix. This deliverable is on our critical path, we propose to provide some additional assistance to the person to get the task completed on time.

Let’s assume that this indeed fixes the symptom. In our example, the task is back on track. However, are we sure to have:

a) addressed the root cause of the problem, and

b) assessed the potential side effects of the quick fix we applied?
 

let’s see what too often happens after the initial quick fix:


3. The quick fix addresses the symptom but it has some side effects. For example, a side effect could be that the additional help provided to this task causes a delay on another task of the project from which we had to pull these assistance resources. Another side effect may be that it generates requests from many other persons to get more resources, or it demotivates the team members who were going the extra-mile to remain on schedule, or… As you see, a simple quick fix could have a significant ripple effect.

4. These side effects will in turn manifest themselves with new symptoms: It could be low morale in the team, threats of delays from other parts of the project, absenteeism…

5. We’re again tempted to address these new symptoms with even more quick fixes.

The loop goes on. The initial quick fix could place the entire project at risk.

So, what to do? How do we break the vicious spiral?

The proposed approach is to try by all possible means to avoid entering this spiral.

In step 1, when we see the symptom (the threat of delay on a deliverable that is on the critical path), we take a step back to understand why the symptom is there and what caused it. We may want to ask a few questions such as:

  • were the estimates incorrect?
  • did a risk materialize that we had or not accounted for?
  • were there changes to the requirements and how were these managed?
  • were some resources not available when they should have been?
  • was the learning curve incorrectly appreciated?
  • did we encounter technical issues?

We can easily see that the answers to the above questions may drive us in a second step to a completely different quick fix that should be better suited to address the primary/root cause and avoid or anticipate most of the side effects.

As Seth Godin highlighted it in one of his posts: "Bear shaving will not resolve global warning."  Or, as my first aid teacher repeated to his students: “Don't put a Band-Aid on a non-disinfected wound.”

Michel Operto

I've been leading IT projects for more than 20 years at telecom and computer manufacturers: Thomson Sintra, Digital Equipment, NCR, Nortel Networks, Orange Business. My passion is Project Management and leadership and I run a blog on the PM best practices at http://dantotsupm.com/