What Is a Distressed Project?
,Whenever the performance of a project falls outside nominal values, it is judged to be a project in distress. How it got to that state is a question that needs answering. Most important is knowing how to establish an early warning system and prevent a project from becoming distressed. But understand that even the best efforts will not be 100 percent effective, and a project can still become distressed. The question then becomes: How can it be returned to a state of normalcy — if at all? The following characteristics are symptomatic of a distressed project;
The project has exhibited a performance trend that, if continued, will result in its failure. I define two metrics in this chapter that capture the cumulative history of the project with respect to progress against time. Whenever the cumulative history of one or both of those metrics exhibits certain trends, it suggests that the project is out of control, and the reason for the trends needs to be identified and a decision needs to be made as to how to proceed. If left unchecked, the trend will continue, and failure is almost a certainty. A growing schedule slippage is one such trend that, if continued, will lead to failure. For a software development project an unresolved bug list that continues to grow and/or whose average resolution time increases is a signal that the project may be heading toward a distressed condition.
The project's performance has exceeded one or more metric values and is a high risk for failure. I will define several metrics and trigger values that can be used to track the general health of a project. When any one of these metrics exceeds its trigger value, the project is at high risk for failure. That sets off a series of activities designed to identify the source of the anomaly and the corrective action that needs to be taken. A significant schedule slippage due to a bad estimate, a mistake, and serious vendor delays are three such events that may result in project failure.
The project has recently experienced some significant change that may result in failure. Oftentimes these changes are related to personnel or other major organizational shifts. Even though the project performance metrics do not indicate any problem, the environmental change may be sufficient to throw the project off course. A change of sponsor and a loss of critical resources are two such changes that may result in a distressed condition and eventual project failure.
If any of the preceding situations happen, it should immediately trigger a project intervention process designed to discover the reasons for the distressed condition, fix the condition, and re-plan the project going forward. That process is discussed in detail later in the chapter.
Why Projects Become Distressed or Fail
Many studies have been done over the years that attempt to discover the reasons for project failure. The failure rates for information technology (IT projects) are documented to range from 70 percent and higher! That level of performance has persisted for several years with no sign of any meaningful change for the better. The industry hasn't found an effective strategy for reducing that failure rate. I believe that many of the reasons for this are related to the methodology that is being used. Traditional project management (TPM) is the default approach and seems to be outside the mainstream of contemporary project types. Data that I have collected from all corners of the globe suggest that only 20 percent of projects fall into the TPM quadrant, but the approaches to managing the projects remain relatively unchanged. TPM approaches are forced upon such projects for lack of an alternative, which is not much more than a failure waiting to happen.
From interviews conducted with my clients and my own consulting experiences with them, a number of factors emerge repeatedly as possible reasons why their projects become distressed or fail. The following subsections discuss these reasons.
Poor, Inadequate, or No Requirements Documentation
As I discussed in several previous chapters, it is impossible to generate complete requirements documentation at the beginning of a project. That is no excuse for doing a sloppy job. Once requirements have been generated following the definition I suggested in Chapter 2, ask yourself what your level of confidence is that you have done the best job possible. You should be reasonably certain that you have identified the necessary and sufficient set of requirements and only their detailed decomposition is suspect. You can employ a number of Agile Project Management (APM) project management life cycle (PMLC) models if requirements documentation is less than satisfactory or if you expect a high rate of change.
Inappropriate or Insufficient Sponsorship
Some sponsors take their job of sponsorship seriously. Others do not. As project manager, you should keep the project very visible to your sponsor. Sending an e-mail once a week is not sufficient. I would try for face-to-face meetings if there is any doubt about your sponsor's attentiveness to the project. You will certainly sense inattentiveness when they are sitting across the desk from you. Sending them informal notes of project happenings just to keep them connected is another tool I have used on occasion. You have to keep them excited about the project and how it is going to contribute value to the organization. If there is some way for you to make them look good to their management as a result of this project, doing so would be a smart move on your part. I look for added value opportunities and communicate those face to face with the sponsor.
Complexity of Requirements Not Recognized
Don't assume that the project is simple. That thinking leads to a sloppy job of requirements gathering and documentation. You are heading for trouble if you can't get requirements done correctly, realize what you have or don't have, and then choose the best-fit PMLC model.
Your risk management plan must anticipate the unusual and have the appropriate mitigation plans in place. As requirements become more complex or less complete and clearly documented, the risk of the project becoming distressed goes up.
Unwillingness to Make Tough Decisions
How easy it is to get a project approved, and how hard it is to pull the plug on the most distressed of projects. If you want to get the sponsor's attention, recommend terminating their hopelessly distressed project. But be careful that you don't hurt your own reputation in the process. You needn't be defensive, just honest.
Some projects have a very powerful sponsor. They may defend the project beyond reason, but few are willing push back or take them on. The president of your company will often be the major culprit here. If you are going to take him or her on, you had better do your homework. A good example of this situation would be my experience with the president of a company where I was the CIO. We had a very complex hardware implementation project underway, and it was in trouble mostly due to vendor delays. I presented two alternatives to the president. He was a tough boss and told me that I didn't do my homework. There was a third alternative I had not considered. He told me to combine the two alternatives I had proposed into a third and report back. I later learned that this was merely a stalling tactic on his part because he wasn't comfortable making a decision at that time. There was no feasible third alternative. We later decided to follow the first alternative I had presented.
Lag Time between Project Approval and Kick-Off
Getting a project approved is one thing. Getting it started is another. If the time between approval and startup is too long and the completion date is firm, project risk goes up. Any date-dependent tasks are compromised by the delay, so avoid using those in your project schedule if possible. You are also at some risk of losing team members due to the delay, especially those who have scarce skills that you need but so do others.
No Plan Revision after Significant Cuts in Resources or Time
Budget cuts, staff cuts, and shorter deadlines are not unusual. Under those circumstances, many project plans are not changed. Despite your pleas, senior management says something like this: “You'll figure out how to do it anyway. You always have.” Most project managers are helpless to do anything here except keep quiet. Many do not have the tools to push back with an intelligent business argument.
Estimates Done with Little Planning or Thought
Far too many project managers don't take estimation seriously. They throw some numbers at the plan, and if no one objects, the numbers stay. The correct strategy is to get estimates from staff members who have done the tasks before or will be assigned to do the task on this project. Unless they have been a credible source in the past, you will want some validation of the estimates they provide. Getting a second opinion from someone who is not on the project can be a good validation strategy.
Overcommitment of Staff Resources
This continues to be a major problem. Projects are often approved without assessing staff availability. You may have the skills needed, but the people with those skills are already committed to other projects and cannot work your project into their schedules. Dealing with this situation effectively requires a Human Resources Management System (HRMS) with skills inventories and staff scheduling capability.
Inconsistent Client Sign-Off
Some clients will fully participate in acceptance procedures and not be forced to sign off until they are completely satisfied that their requirements have been met and expected business value achieved. If they have been meaningfully involved throughout the project, that's a good sign that they will be meaningful participants in the acceptance procedures, and their signature is testimony that requirements have been met. Not all clients are like this, however. Some might sign off simply to get the project out of the way and get on with their business. Others might not really understand the project and sign off in ignorance rather than risk being exposed.
No Credibility in the Baseline Plan
If the baseline plan has undergone several revisions and changes at management's and the client's request, there may be serious doubt that it can be achieved. Estimates that are made and then changed to accommodate a tight deadline are sure signs of a weak plan and one that is destined for trouble. What may have been a solid and well-thought-out plan initially has undergone so many changes and patchwork fixes that it is now a jumbled mess and lost its credibility with the team.
Unmanageable Project Scope
APM projects expect change and are structured to accommodate it, but there still must be vigilance over scope change. Tracking the frequency and cumulative number of additions to the Scope Bank are two metrics you should have in place. Over the cycles of the APM, a healthy project will show convergence. If changes are requested at an increasing rate, that is a sign of a project out of control. TPM projects do not expect scope change requests, so some control over the number and frequency must be in place. Management reserve is an effective tool and should be included in every TPM project plan.