Defect resolution process–an objective method for evaluation and prioritization
Fixing defects costs money. Fixing the wrong defects costs even more money. Moreover when the latter translates in not fixing what’s really important, the difficulties may transform into trouble. As a result the business is affected by overspending, a product with poor quality or even worse, frustrated customers–all these are consequences of the failure to objectively evaluate and prioritize defects based upon their business impact.

In theory, implementing a reliable SDLC model in conjunction with a good SQA process would minimize the risks for this situation to happen.

However, in reality this type of failure is experienced at various levels of severity by any software project irregardless of the SDLC model or the quality of its people. And there is a simple explanation why the defect resolution process usually fails in accomplishing its ultimate goal–"Spend the right amount to fix the right thing".

When it comes to evaluate and prioritize defects wrong reasons come in handy. Overconfidence in development's fixing capacity, misunderstanding of the way a defect impacts the feature or how the feature impacts the business, overstating the fixing priority based on previous non-related experiences–all of these are usual examples of how people can apply judgment based upon ignorance, biased or bounded rationality.

Also, when everything is important nothing really becomes of importance. In fact, when revenue, quality of features, customer's satisfaction and sometimes one’s professional pride are simultaneously at stake, usually we find no separate objective methods of evaluation within the reach of our judgment or our tools. Instead we’re using a global approach with the help of Severity or Priority fields created in our defect tracking system.

However this generates even a bigger problem. These fields have singular values of state thus they will generate only ranking establishing urgency levels rather than evaluating events. As a result applying this method to a list of defects will only show which one goes first but not which one hurts business the most.

Last but not least, there are other factors negatively influencing this process.

Like the natural inclination of people to take more risks to mitigate another risk or our dependence to objective reference points in understand gains or losses.

In fact, no matter how bad this may sound, it seems the source of these problems is deeply embedded in the way we design, implement and execute the defect resolution process. Hence the question: is there a method to prevent its failure?

Yes, there is and here are some of its highlights.

First target is to make the evaluation process objective and apply its rules consistently across the board.

The goal would be to transform uncertainty into measured risk. This can be achieved by introducing objective evaluation points into the requirement and defect structure instead of ranking defects based on subjective evaluators.

Also introducing separate measurements for each affected business area will allow broader and objective views from development to the finance.

Finally this will allow decision makers to be part of the solution giving them an objective tool to support their decisions.

As peculiar as it may sound the success of this method lies in the capacity of your organization to be objective in making decisions.

In fact, most of the defect tracking tools will adapt to the changes with minor customization. Processes can be easily re-designed. And the main goal will be achieved when people will understand that being objective is actually doing the best they can in dealing with uncertainty.