Todd C. Williams, author of “Rescue the Problem Project,” recently spoke with Anita Bruzzese about how to save a project that appears headed for disaster.

AB: In your experience, what’s the most common way a project runs into trouble?

TCW: The biggest issue is lack of alignment to the strategic goals of the organization. This can take many forms. For instance, the most common form is a project trying to add some new capability or product for a company, but they are trying to build everything into the delivery—boiling the ocean, so to speak. They will run out of allotted time. Project proponents argue that the project is critical to the strategy, but they ignore the actual goals. If you have “extra” scope – functions and features that are non-essential to the delivery – the risk in the project increases and it will overrun its budget and delivery date. The project should be trimmed to the essential deliverables.

Projects also can be misaligned if they are someone’s pet project and were part of the strategy at one time, but then the company was bought by another company. Or business conditions change, obviating the need for the project.

It is really the responsibility of management to see and correct this. When they don’t, the problems get out of hand. Someone needs to make sure projects are focused on what is critical. Once you start adding a “little thing” here and a little “thing there,” you are stealing resources from other projects. It slowly amplifies and the scope is out of control, hurting the entire organization.

AB: Why does it seem that projects get into such serious trouble before anyone reacts?

TCW: There are two primary causes for this phenomena: 1) project team members are slow to report issues, usually because they think they can fix it or they fear reprimand; and 2) executives wait too long to declare the project in trouble, usually because they are not monitoring the project or their ego gets in the way and do not want to admit the problem. In general, people are optimists and feel they can do anything.

When the project is finally declared a “red project” – one where the numbers around the projects are all negative – then too little is done to fix it and the project founders. The project needs an audit. Someone that is neutral about the project needs to assess and develop a recovery plan. Usually this entails cutting scope – drastically. This could be an objective executive that understands that organization’s goals or an outside contractor that specializes in this process.

One important clue provided by the lack of executive attention is that it probably is not important to them. Executives pay attention to initiatives and projects that drive their bonuses. Bonuses are focused on strategic goals. Ergo, if the executives are competent, a very likely reason they are ignoring the project is because it is not aligned to the strategic goals.

AB: What’s the first thing someone should do when they realize a project is running into some real problems?

TCW: Make sure that it is aligned to the strategic goals and remove all scope that is not critical to the project’s success. In attempting to reduce scope, it could be that the project gets broken into two or more deliveries (phased delivery). The most critical items delivered in the first phases followed by other functionality in subsequent releases. Essentially this decreases the size of each release and reduces risk.

If you find that the project does not support a strategic goal of the company, cancel it and apply the resources to other projects.

AB: Once they do that, what’s the next step?

TCW: The three things to do in order involve:

People: Make sure the people on the project have the required skills. There is no room in any project’s budget for on-the-job training. In a project recovery there is less. You need the right skills. As the project leader you need pull these people together as a team. This is absolutely essential.

Process: We love process and, there is no doubt, it is critical in running projects. Process, however, cannot replace intelligence. If you put too much process on a project, it will sink under the weight.

Technology: Technology is a means to an end. It is a tool. Too many people wrongly see technology as the answer. It cannot be implemented in a project or its product without first having the right people or process. Too many people want to implement the software to solve a problem. That will fail. It has hundreds of times.

AB: Can all projects be rescued? If they can’t, what’s the first sign that they’re beyond help?

TCW: I am sure there are projects that cannot be recovered, but I have not seen one. It all depends on how much money you would like to spend. The practicality of recovering the project is the hard question to answer. I have recommended killing a number of projects based on the cost of recovering them. Occasionally, a client will reject that option for less tangible reasons, such as potential damage to their reputation. At that point, the goals of the project change and you need to add “save face” to the deliverables.

I cannot stress enough that the goals and value of the project must always be tracked and evaluated. Even on those projects that have to save face, I am sure these projects can reach a point where cancelation is the only reasonable option.

AB: What are some critical ways that project managers can ensure a project doesn’t get into trouble in the first place?

TCW: Be objective and realistic about what the project and the team can accomplish. Your job is to make friends by delivering a successful project, not to make friends through compromising the project or its value. Also:

Limit scope to the essentials. Make sure that the project does not move away from the organization’s strategic goals. Remember that since goals change, the project may need to change to stay aligned.

Ensure that you have the right resources to complete each task on the project. If you do not have them, get them. If you cannot get them, make sure you communicate and document the risks and associated costs.

Build a team and lead them. If you have to manage them, you do not have the right people and go back to that step. Talk to everyone on your team – preferably face-to-face. Obviously in large teams this can is difficult, but people need to know you are there to help them.

Make sure only essential processes are in place. Change management, specification signoff, acceptance, and compliance processes are essential. They define what you are building and whether it is delivered. If your project ends up in court, these three will save your skin.

Get rid of excess process. My pet peeve is when my team members are required to write weekly status reports for their bosses. I usually remove that and return a couple hours per person per week to the project and improve morale at the same time. Think of the value with a 40-person project team. If you are leading your project you should know what they are doing and where they are having troubles. You can write one status report for the project and their bosses can use that.

Its the right combination of the right people with right soft skills and right technology with right tools like ProofHub.com that can help. Thank you for the post, it lists down all the possible failure reasons, and I could relate to some as well!!