Defect Management

A software defect that makes it into the production environment can be a real pain for the Service Desk. Imagine the scenario where your user rings and advises that software is not performing as expected. They want to raise an incident and for you to resolve that with the same speed and rigour that you would an infrastructure failure. You log it and route the incident to the application support team who tell you that it is a code bug and will require development effort to fix.

Defect & the Service Desk   - ad banner

The Defect Backlog

Now what happens next will vary form organisation to organisation and might also depend on the nature of the defect and the state of the software warranty and post go-live support (PGLS) status.

Critical defects – those which cause regulatory compliance breach, consumer harm or risk the company’s financial or reputational standing – might result in an emergency change that is linked to the open incident to track progress. Assuming that is that the development effort is covered by a warranty or PGLS arrangement.

All other defects are likely to be added to a defect backlog and prioritised against the stack of other defects, new requirements and scheduled releases. A small defect in shared module that requires full regression testing is likely to be held until the next scheduled release or bundled with a bunch of other defects for an out of cycle release.

Incident Treatment

So you might now have a low priority defect sat on a backlog waiting for a scheduled release or development effort funding, and an incident open with a customer eagerly waiting an update.

Over the years, I have seen just about every solution deployed for this type of scenario:

  • Leave the incident open waiting the defect fix
  • Close the incident as Defect Raised
  • Place the incident On-Hold waiting defect resolution
  • Link the incident to a problem record
  • Link the incident to a defect record

service desk automation

Each solution has its own pros and cons

Leave the Incident Open

This solution usually gives the best visibility to the customer that raised the incident. However it is likely to lead to SLA breach and will skew the overall reporting metrics for MTTR and aged ticket analysis.

Close as Defect Raised

This gives the best outcome for the Service desk as the incident is closed, usually within its SLA and no longer sits clogging up the view of open incidents. The challenge is how to ensure that your customer has a view of the backlog and when it is fixed.


An open incident that is on-hold will stop the SLA clock and prevent breach but can still pollute aged incident and MTTR reporting.

Link to a Problem Record

This option can be useful as it allows the problem record to be used to count the number of instances that a particular defect is reported and therefore gauge impact and priority. It still leaves the Service Desk with the challenge of tracking the defect and knowing when to close the problem record.

Link to a Defect Record

My personal favourite is to close the incident and link to an open defect record. Many ITSM Service Desk packages now include a defect tracking plugin to manage the backlog. Where they don’t the link can be a hyperlink to an external system.

However you choose to treat the incidents raised, you must remain mindful of how the user will be kept informed, how your service desk reporting is affected (MTTR, aged incidents, open incidents, problem count etc) and how the process integrates into your SDLC and application support arrangements.

Continue Reading

As an Amazon Associate I may be paid commission for qualifying purchases