The number of problems opened and closed shows information about the work being done for long(er) term solutions to common incidents. In itself it doesn't mean anything to know how many problems have been logged and closed, because the fact that you logged 15 more problems than in the previous month won't tell you that your software has become less stable. Perhaps your software has become more stable and the support engineers have more time to report more problems. This metric should be used in combination with other efforts and in very specific scopes.

Let's say that you are supporting 25 software packages and one of these packages is going to get a major overhaul. You might decide to look at the number of problems reported to figure out how many real issues are encountered. In this example you would only report about the problems related to the software package being updated. First you would need a baseline for the number of problems logged the month before your update. Then you would have to log the month right after the update, this will tell you about problems with installation and in the software package. Finally you would log the problems for another month to find out if the number of problems has been reduced or higher in the new version of your software.

In organizations where few problems are reported this metric is not useful, because the statistical variances will be larger than the results in most cases, especially when looking at specific categories of problems reported. Be skeptical about this metric if it is used in your organization. Does your organization log enough problems to gather metrics about them? What can you use these metrics for?