Category Archives: Project Rescue

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. Continue reading →

Project planning is an exercise in forecasting. The idea is to take the variables you can account for and try to anticipate any issues that might rain on (or dry up) your project’s progress toward a smooth conclusion. Forecasts are rarely perfect, which is why we have project managers still assigned to projects even after the plans are built. We need the PM’s there to lead teams through time and change and keep the project in scope.

That’s why the real mark of a good PM is discernment on the fly. PM’s, while leading their teams, must be able to distinguish the difference between normal variation from plan and real trouble–and be able to recognize the difference between the two in time to mitigate and control. Sometimes re-planning is required, but the goal in most instances should be to return to the original plan whenever possible.

So how do you know the difference between normal variation and real trouble in a project? A textbook answer would involve the use of metrics plans. If defects (severity, volume), schedule variation, budget, or productivity reach beyond established thresholds, then corrective action must be taken. The metrics required to monitor the project are expensive, and we don’t all have them available to us. So many PM’s are working without formal metrics, and must diagnose real trouble before it is too late. Fortunately, there are some general rules of thumb. Ailing projects have some common symptoms, many of which formal metrics account for and an observant PM can easily identify. Here’s what to watch for: