Abstract: Tracking and controlling changes are important parts of configuration management and a specific CMMI goal. However, documenting changes many times is not used effectively, if at all, during the course of a project. Why is there such reluctance to document problems or design changes? How often have you heard the following? "It will take more time to document the problem than it will to fix it". "If I document this bug I found it may reflect poorly on my work", "I don't want our customer knowing what our problems are." And "Stop writing all these problem reports so we can release." All of these statements are excuses for not seizing an opportunity to improve your process and product.

During the course of a project there are many tools available to managers. A problem reporting process is perhaps one of the easiest processes to utilize and offers a quick insight into the status of the project at any given time. A problem reporting process is also an effective project communications tool allowing project team members to know what needs to be done, and clients to know what to expect.

This presentation will address these issues by discussing what problem reporting is, how it should be used, how it should not be used and how to interpret metrics that can be easily collected from a well implemented problem reporting system.