I have often been asked to take charge of projects that are in deep trouble. I am no longer surprised that almost universally, the stage when a project is generally acknowledged to be in trouble is during the late stages of testing and rolling out the first release. Never does it happen during the requirements and design stages at all- for reasons that are obvious- there is nothing tangible that the end users actually see during  these phases except perhaps a stream of documents.

While I will write a set of posts on my experience in turning around projects, I would like to illustrate here how metrics can be used to analyze the depth of the problem and also provide a very quick plan for stabilizing the project very quickly.

A simple defect analysis based on the cause of the defects can shed light on what are the key areas that need to be addressed.

In the following diagram from an actual web- based application development project, for example, it is very clear that the process for regression testing needs to be improved as defects because of its inefficiency are 22%. It is also clear that the substantial numbers of defects (23%) are on account of requirements (missed + ambiguous) and another 17% of the defects pertain to insufficient test cases. Addressing these three areas would have an immediate impact on the quality of testing. Given cost and schedule constraints, it may not be required to address all the causes and instead concentrate only on these three factors that address 72% of the defects.