Wednesday, February 20, 2002

 
Posted by Mike Tarrani 9:48 AM
Agree With One, Disagree With the Other. I just finished two Sticky Minds articles that got my attention.

I Agree. The first article, by Johanna Rothman is one that every software quality team member and manager, as well as business process owner and governance member should read: What Does It Cost to Fix a Defect?. Ms. Rothman steps you through the cost analysis and decision points for determining if a defect should be fixed or lived with. It is, after all, a business decision, and her approach will help to determine if it makes sense to fix a problem or not.

I Disagree. The second article, by Brian Beaver, is titled Categorizing Defects by Eliminating 'Severity' and 'Priority'. In essence Mr. Beaver proposes that severity and priority be replaced with a single category: business impact.

Severity is too fine-grained of an attribute to be cast aside. In fact, a definition of severity is the degree of impact a problem has on business operations.

For example, the following are severity levels that are defined in a typical problem management process:

• Severity One - Loss of application, or critical performance degradation, with no workaround. Incident affects an entire workgroup.
• Severity Two - Moderate application degradation incidents. Severity One workaround. Incident affects several customers.
• Severity Three - Minor application degradation incidents. Incident or request has medium to high impact on single customer's ability to work.
• Severity Four - Incident or request has a low impact on single customer's ability to work.

Severity without priority would mean that a mission-critical application falling into the Severity Two classification would be given the same business impact rating as one that is less critical. How does one prioritize in that case? See the gap?

The gap can be closed by assigning a criticality rating to each system, application and service in an enterprise's portfolio. Linda and I developed a spreadsheet for determining criticality. Criticality does not replace severity definitions, but is useful for arriving at a system of priorities that is based on how important an application is to an enterprise.

Where Mr. Beaver's premise and mine differ is in our viewpoints. He is on the technical side, concerned with fixing defects, and I am on the service level management side ensuring that tools and services are there when users need them to meet business objectives. We're both right.

In an issue management scenario that requires coordination between applications and service delivery, life would be simple if we could assign a single rating. However, IT should not be the group that determines what gets fixed and when it gets fixed - that's up to the business. It's their systems and applications. We're the custodians. Without a priority rating, which is determined by the business (ideally under the cognizance of governance), the judgement would be [wrongfully] left to IT.

Assuming all else equal, there is no way to assign a business impact without severity plus criticality. Even then there needs to be arbitration for competing requirements sharing the same business impact, and priority is the way to fairly arbitrate.

That said, I do admire the fact that Mr. Beaver is thinking in terms of business impact instead of IT impact. I also admire the way he has developed a line of thought and has taken the time to document it and share it with his peers. That is what fostering professionalism is all about.

End Note. I also downloaded an interesting paper by Dave Lutzker titled, Testing Is a Phase, Quality Is an Approach. In a single page Mr. Lutzker captures the essence of quality vs. testing. It's a quick read and well worth the time to download. The paper is from Sticky Minds, which is one of the best software QA resources on the web. Most of the articles take a business approach, and the content is first rate.