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 .