By Dave Chambers
Measuring IT Change
By Dave Chambers
One of the biggest debates when it comes to IT Change Management, is what constitutes a successful change. The reason why this is still a hot topic is that the purpose of measurement is not always clearly understood; measuring a process should simply give statistics which:
• show how well the process is supporting business services, and
• help identify service improvement opportunities.
People are often hesitant to mark a task or an outcome as unsuccessful as they believe it will be viewed as failure and a cross against their name, whereas this should never be the case. Processes are created to help people deliver consistent reliable services in the most efficient manner possible. Too often change managers take personal offense when a change process is not followed and engineers often feel targeted by change managers and see the process as red tape. All of this can be easily avoided by clearly defining process measurements and to an extent de-humanising the measurements.
Unexpected Impact( Related Incident caused by change- was there unexpected impact).
Ticket Statuses The following scenarios are four examples of change ticket statuses. Scenario 1
Although the change did not achieve the expected outcome, it has been marked as successful as the change script that was followed was approved.
A problem ticket should be raised and linked to the change ticket to investigate the root cause of the unsuccessful deployment, allowing the investigation to be documented for when the change is re-submitted for review.
Scenario 2
Measuring change can be broken up into three parts
1. Process( Closure Status- was the process followed?)
2. Deployment( Implementation Status- was the technical outcome achieved?)
24 itSMFI Forum Focus— June 2017
The deployment was successful as the technical outcome was achieved, however by not following the approved change script, unassessed risk has been introduced.