Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

4 Comments

by Phillip Smith

In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes.  Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.

Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem.  There is a balance between empowering the team and being so distant that you appear to be “checked out”.  Find that balance (it will vary by project and by team) and use it to your advantage.  Teams that work independently within a process set tend to accomplish a lot –  and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.

While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”.  In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.”  We can use that as an example of a situation that calls for specific action.

No one wants to pass defects downstream through the development process, such that a bad requirement results in an incorrect design, or that an incorrect design results in code that does not function correctly. Defect rates that are “normal” will be corrected within time frames that the project plan allows for rework; however high volumes of defects will stress the rework portion of the project schedule such that other tasks slip, or such that some defects remain in place to be corrected later, exposing the next phase of the project to proliferation.

One way to treat the symptoms is to borrow additional resources to identify and close product defects within the original project schedule.  While this course of action will negatively impact the budget, it prevents proliferation, protects the schedule, and keeps things moving in a positive direction. There are times when this prescription is called for.  However, in most cases I would argue that the patient is still ill, and that more defects will be introduced later in the project because the original root cause for the first set of defects was not addressed.

A prescription of doing nothing in this example may still result in the symptoms being addressed.  Specifically, the PM may turn the open defects back to the project team and require that the team fix them with overtime or some other method.  This will work in some limited number of situations; however it still leaves the root cause of the defects unsolved.

The project manager who schedules time for root cause analysis into their project plan will have time to work with the project team on each defect to determine why it occurred.  Some common root causes of defects are:

  1. Incomplete training (people do not know the technology and/or do not have the business domain knowledge)
  2. Unavailability of system documentation
  3. Inaccurate task estimates (people hurried)
  4. Wrong people assigned (incorrect use of people’s natural talents)

These four items are much more difficult to deal with than the actions above that deal directly with symptoms (overtime, push-back to the project team members).  Adding time and budget for training team members, completing system documentation, or re-estimating tasks is not likely to make the project manager popular with the stakeholders.  Changing the people on the project is not always an easy thing to do either.

However, in a situation where the project manager needs the project team to be successful not only on this project (or phase) but on many more projects to follow, the best course of action is to fix the root cause, re-plan accordingly, and then proceed with caution.  Fixing the root cause is always a conversation that is worth having with the stakeholders of the project.  The stakeholders may not be able to tolerate the impact on this specific project or phase, but they will appreciate the project manager to making the attempt to look out for their long term interests, which will result in increased respect for the PM.

In my next article I’ll discuss health checks and why it is important to understand risks and potential root causes when planning your health checks.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

4 thoughts on “Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

  1. I like the article in general with two comments/concerns: reading through the article it gives an impression that (1) it is acceptable to treat the symptoms ‘sometime’ and (2) we should allow time in the plan to do root cause analysis for problems.

    In our view, yes it is OK to treat the symptom and not the root cause but only in rare situations or at best infrequently. Most problems (unless they are huge organizational system issues and way beyond the control of the project manager) should be dealt with as soon as possible and go after the root cause … in a mega construction project that i was on the team about 13 years ago we learned this lesson the hard way and at a lost opportunity cost of close to 300 million US where we kept dealing with the symptoms and not the root cause; leading to disaster.

    On the other point – allowing time for root cause analysis – two concerns here:
    1. PM should be preventive and not reactive and we should spend the time in planning on risk management.
    2. It should go without saying that for all problems we should deal with the root cause (back to the earlier point).

    • SUKAD, thank you for adding your comments. I agree on all points. You are dealing with very large dollar projects with a lot at stake, all the more reason to get to the root cause quickly. Regarding risk management, again, I agree. I was not attempting to write about risk management though (I think a lot has already been written on that topic). Even with prevention problems are certain to arise.

  2. In response to the question about posting this article on the PM Hut web site, yes, that is OK to do. Please make sure you do the following: Include a link to my bio (http://www.bridge360.com/leadership_team.shtml) along with contact info (philip_smith@bridge360.com) and a link to our blog (https://bridge360blog.com/) and a link to our web site (http://www.bridge360.com/index.shtml). Thank you for taking time to read the article and for your interest in Bridge360.

    Phil

  3. Hi Philip,

    The issue of dealing with ailing projects is a concern for every project manager, and that’s why I would like to republish your article on PM Hut, where a lot of project managers will benefit from it.

    Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

    Note: I have published an article on fixing failing projects a few years ago, I hope you’ll have a chance and read it…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s