The following is an excerpt from a book written by Sanjiv Purba and Joseph Zucchero, published by McGraw-Hill/Osborne, 2100 Powell Street, 10th Floor, Emeryville, California 94608 U.S.A. Sanjiv has over 20 years of experience managing large projects, and many years engaged in rescuing ailing projects.




The presence of any of these symptoms in your project does not necessarily indicate your project is in need of rescue, but requires further investigation to ensure it doesn't.

Symptom	Modifier	Considerations
Missing deadlines or no deadlines	Without good or compelling reason(s) being articulated	Are people just lookiong to justify bad managment practices?
Changing Requirements	Without reflecting changes in the budget, timeline, or the project scope	Are people trying to hide a lack of discipline in really deciding what they want built, integrated, or constructed? Is there an effective change management process?
Final decisions are not being made	Is this because there is no clear ownership or is no one stepping up to the plate to make the important decisions?	Is there enough information to make a decision with any degree of certainty?
Project completion is stuck at 90 percent done	There has been no corresponding change to scope, budget, or timeline. There is a lack of continuous progress regardless of the percentage complete.	Can you relate completion percentage to interim, measurable deliverables? Can each team member accurately articulate the "estimate to complete" for outstanding tasks?
No problems being reported	No deliverables are being signed off either	Problems and issues are normal on projects. Does the team have a handle on the true requirements? Is there an agreed on acceptance management process?
Lack of key project deliverables	A good rule of thumb is to produce measurable deliverables during frequent intervals to allow tracking of progress and reduction of risk. Relying only on a major deliverable at the end of a long project (anything over three elapsed months) is an enormous risk, which should be mitigated by interim delivery points.	Are deliverables being created but without explanation on where they are going to be used or how they are going to influence the final result? This is a serious waste of time and can ruin the motivation of the project team.
Interpersonal problems	People issues and interpersonal tensions are overwhelming the project schedule. The extended project team members do not appear to put the interest of the project ahead of their personal needs.	Are too many personal needs of team members being sacrificed for the project? Is there a risk that key people will leave the company before or at the conclusion of the project?
Excessive quality problems	This is even after testing cycles (for example, unit functional, system) have been completed and a test plan has been executed	Begin the project with a clear definition of the quality expected, number of errors that are tolerable, and the tests required to prove that the solution is acceptable. Is there an effective quality assurance process in place?
Unknown factors	Constantly hearing the terms "will find this out", "we are assuming", "to be determined", or "to be confirmed". Each of these terms are imprecise, making accurate planning impossible	Not every unknown can be identified, but the plan should be robust enough to accommodate surprises by identifying clear check points. There is a danger of analysis paralysis if you try and go too deep in this analysis. Is there an effective risk management process in place?
Lack of management reporting tools	Specifically a lack of an integrated project plan that is being used regularly to track progress, as well as clear communication channels to all the team members.	Is there too much overhead involved in complying with management reporting? Conversely, are people just trying to document and report everything to protect themselves? Are project status reports fact-based or opinion based?

"Projects do not suddenly get out of control; there are always early warning signs that indicate a project is in jeopardy. In 1975 in The Mythical Man Month: Essays on Software Engineering, Frederick Brooks asked the question 'How do projects become two years late?' and answered it 'One day at a time'. This is true of all runaway projects, whether they are IT-related or not. To identify a runaway project (or one that can potentially become a runaway project) you must recognize the early warning signs that precede project failure."

"Just like a major disease against the body, the key to correction is early detection and a proven treatment plan. Let's take the disease analogy a little further and say that the earlier the detection the less radical the treatment. Usually when a project is in trouble there is iether too much data about the project being collected and distributed, often to hide the problems, or worse yet, too little data being collected and shared. Each of these possibilities contains its own set of problems. With massive amounts of project data flowing in, cutting through the clutter to get to the important data takes a trained eye and often a lot of time. On the other hand, hunting down project data can be time-consuming, especially if the project team members have not been trained to accurately track their time on each task they've performed. The goal is to understand a project is off course long before disastrous career and financial costs occur."

In the following pages we'll identify some key symptoms and the subsequent key questions to ask if you suspect the symptom is present in your project.

Spending More Time

Project Definition Documents

Quick Acid Tests

When You Should Ask

The Project Notebook