From the white paper:
Defect management involves logging reported defects in deliverables (usually integrated, executable code) and tracking their status. Information about the defect, such as reporting party, steps to reproduce, workarounds, severity, and so on, is entered. You can then assign the defect to an engineer for repair. Possible values for defect status include unassigned, open, fixed, closed, and deferred.
Defect management serves several functions. It provides a set of development metrics, including total defects reported, total defects repaired, defect reporting rate, and defect repair rate. It helps ensure that each defect is reported and repaired only once. It allows you to rank defects by severity and priority. It tracks responsibility for repairing a given defect and the status of that effort. And it provides a common repository about defect information for test engineers, development engineers, and management.
Defect management is also a tool to identify where the bottlenecks are. These could be development defects that you need to fix, and that are holding up testing. Likewise, there could be defects that have been fixed and that are waiting to be retested and the fixes verified.
You can numerically or graphically summarize this to give project management a better idea of how things are going. A high number of serious defects indicates that you still need to do a lot of work. A low number of defects that are minor and cosmetic (and thus deferrable) means the project may be ready to deploy. The project may be find-rate limited, indicating that the testers (or lack thereof) are a bottleneck in finding defects; or it may be fix-rate limited, indicating that the developers (or lack thereof) are a bottleneck in fixing defects. And clustering of defects in a given subsystem may reflect problems in the design and construction of that subsystem