Average Response Time
This metric tracks the average time that elapses between change request submission and when it is either approved or rejected.
Main Description

Purpose

Average Response Time is an indication of how well the team's change management process is functioning. When a change request is submitted either to correct an identified defect or to add an enhancement, it must be reviewed as soon as possible to determine if it will be approved or rejected. Approved changes will impact project planning so quick triage is essential. It is also important to respond to the submitter in a timely manner, so that they will understand the status of their request.

Definition

For each submitted request in the reporting period, count the number of days that elapsed between the date the change request was submitted and the date of response stating that the request is either approved or rejected. Group by severity.

Average Response Time = Total Number of Days Elapsed / Total Number of Change Requests

Analysis

A good way to monitor Average Response Time over time is to use a trend line. Plot Average Response Time on the Y axis and iterations on the X axis. Group change requests by severity and type (enhancement request or defect). It is also useful to produce a drill down report showing the percentage of requests with response turnarounds of 3 days or less, 3-5 days, and more than 5 days.

Expected trend - Targets are typically established to measure progress. A common target is to achieve an Average Response Time of one business day. Ideally, the trend line will remain steady at this level.

High average turn-around time - This occurs when the team takes a long time to respond to most submitted change requests. This can occur when the team has not implemented a consistent tool and/ or efficient process for change management. Change requests might be getting lost or the team may not be alerted when new requests are submitted. This trend can also occur when the process to submit a change request is not clear. Stakeholders may not be providing the right information so impact analysis is taking too long. Adopt a change management practice suitable for the team and type of project. Clearly communicate processes to the team and stakeholders. Implement an automated tool to support the process and improve efficiency.

If the team's process and tools are working efficiently, long response times can be the result of:

  • an overly complex system architecture, or poor quality architecture (requiring additional time to perform impact analysis)
  • no resource(s) dedicated to impact analysis

Long average response times can result in:

  • Low customer satisfaction levels
  • Delays in deploying needed changes, and higher costs
  • Duplicate effort when change requests are lost and then rediscovered

Use this metric to monitor the adoption of Formal Change Management and Team Change Management practices.

Frequency and reporting

Change request states are tracked throughout the lifecycle as they occur. The project manager should monitor trends, and when problems arise should review with the team during iteration assessments.

Collection and reporting tools

Data is captured in IBM® Rational® ClearQuest®.

Assumptions and prerequisites

  • Change Requests are tracked, with dates captured for each state change
  • Clear change management procedures are communicated, describing all data that must be provided for change request review, and roles responsible for reviews
  • Targets are set for change request response time

Pitfalls, advice, and countermeasures

  • Very small projects may not need to track this metric. Project scale, complexity, cost, and time constraints should be taken into account when determining the need to track Average Response Time.
  • A team may have a good Average Response Time, but if follow-through is poor (changes take too long to implement, or are never implemented) overall customer satisfaction will suffer.