• release
  • version
  • package
  • module
  • (maybe even session)

Check and ask questions

To take the reported defect on board, you need to be able to answer the following questions all with "yes":

  • Do I understand the problem mentioned in the reported defect?
  • Is there a clear and concise reproduction description available?
  • Is the impact of the error clear?
  • Are the expectations of the customer valid?

Always question yourself after your first analysis of the available material if you understand the raised issue. If not, question yourself on what is not clear to you. Formulate questions that, when answered, should provide you with enough insight to get the analysis on an higher further. The formulation of the questions you raise is enormously important. An easy example to explain to you how important:

When does the first train leave the station? The answer is: at 8.00 am. But is that the answer you are looking for when you need to know how late the first train to London leaves the station on Saturday July 12th 2008. The answer could be 9.00 am instead of 8.00 am? So make sure all relevant data to get the correct answer back is put into your questions.

When you send your questions to your Support colleague always propose to go thru them together so you have the opportunity to explain a bit more about them but also to provide your colleague the opportunity to asks questions.

Close reported defect

When, after one week, no answer is received from Support, close the request. Apparently it is not that important for Support. Add clearly a comment stating that no answer was received. This method sounds hard but it keeps focus on what really matters. Keep waiting time for a customer as low as possible.

Another reason to close a reported defect when from the first premature analysis done it is obvious that the problem mentioned in the reported defect does not relate to a bug but to an enhancement request or a lack of knowledge of the Support Engineer. When you close the reported defect always explain with more then one sentence why it relates to a lack of knowledge or an enhancement request. See such a closure as a small Knowledge Transfer. Put in the effort that relates to such a Knowledge Transfer.

Duplicates need to be closed as soon as possible to have a clear view on what is on hand to solve. When you close a reported defect provide the other defect number to Support so they can follow up in the reported defect that goes thru the whole maintenance process.

Assign reported defect

When all information to start solving is available assign the reported defect to an engineer or waiting queue. What you decide to do depends on the usage of a pull or push mechanism.

The pull mechanism uses a queue people pull off the reported defect they are going to solve.

From this waiting queue reported defects should be picked up based on age to limit waiting time for the customer. Be aware of cherry picking else all difficult issues remain in the queue. The general policy should be that the Issue at the top (Oldest issue of the queue) should be picked up first. The only reason not to pick it up if, after reading, the Maintenance Engineer concludes that he has no knowledge of the area the reported defect occurs in.

Picking up the eldest defect helps in getting more satisfied customers. The longer a customer has to wait the more unsatisfied he becomes. By taking the eldest you create the shortest waiting time possible for a customer.

The push mechanism uses an queue owner pushing reported defects to Maintenance engineers based on their knowledge level.

A combination of both mechanisms can be used at the same time but for different level of Maintenance Engineers. For experienced Engineers the pull mechanism works fine. For inexperienced Engineers the push mechanism works better.

Support has it's own view on an assigned defect

When a reported defect is assigned to an engineer, Support might (and will) think that the reported defect is accepted by Maintenance and a solution can be expected. By closing a reported defect as soon as possible, especially when no solution will be provided, avoids wrong expectations, especially on the customer side. The analysis, needed as basis for a solution, must be done as soon as possible. A high turn-over in the analysis phase of reported defects will help you to increase customer satisfaction.