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.
|