In order to effectively manage the post-implementation period, there are three measurements that you need to know and track:

• Problems or defects reported;
• Problems or defects corrected;
• Problems or defects outstanding.

The third item is actually derived from the previous two items and information from the previous reporting period. Defects outstanding for this period equal the defects outstanding from the last period plus the defects reported this period minus the defects corrected this period. Depending on the size of the project, this period can range from a day to a quarter, but generally these figures are best tabulated weekly.

In a typical large software implementation, defects reported will peak in the first reporting period after the implementation and diminish over time. Defects corrected, on the other hand, is a very flat trend line and is representative of the repair capacity of the support team. While there are a number of things that an IT manager can do to increase this statistic, generally speaking, such actions create temporary bursts of activity that are not sustainable for the duration. While the numbers of defects and numbers of weeks will be different for every project, the following general trend is fairly universal:

• At first, the number of reported problems exceeds the number of repaired problems, so the number of outstanding problems continues to rise;

• At some point, the problem reports diminish to the point that they're relatively equal to the number of problems that can be repaired, so the number of problems outstanding remains relatively constant; however, even though the trend has leveled out, the number is still quite high because of the initial backlog created when more problems were being reported than were being repaired;

• Eventually, the number of problems being reported will be less than the number that can be repaired, and the support team will then begin to reduce the backlog of problems.

Figure B depicts one example of the typical results found during this process.

FIGURE B

This chart illustrates the typical pattern of defect statistics after a major software product has been deployed. Click picture for a larger image.

Successfully managing the "dip" in productivity caused by the introduction of the innovation (new system) means the intentional reduction of this time period in which the new system or method detracts from the end user's ability to perform so as to enter that period in which the new system or method enhances the end user's ability to perform. The efficient, systematic elimination of defects, whether they be defects in concept, design, or construction, is the sure way to accomplish this, and the accurate measurement of this process is the only way to keep everyone on task and ensure the rapid completion of this objective.

Size does matter
Planning, training, testing, and other quality assurance efforts all go a long ways towards limiting the impact of a new software implementation. But the biggest factor of all in determining the potential negative effect on productivity is the size of the change. The bigger the change, the more potential there is for significant negative impact. No matter how much planning and training and testing and related activities have taken place, the implementation of a large information systems project has a huge and long-lasting impact on the productivity of the operations that it's intended to support.