itSMFI 2017 Forum Focus - June Forum Focus ITSMFI | Page 25

A Post Implementation Review should be conducted
to document if there was approval granted during
the change and how it can be avoided for future
changes. A problem ticket may also be raised to
investigate if the deployment was different in the
test environment.
There may be circumstances where you want the
engineer to do the correct work to make it
successful. If this is a recurring case, the process may
not be supporting the organisation as per
expectations.
problem ticket should be raised from the incident to
investigate the root cause; this ticket can also be raised
against the change.
The reason for this, is that impact is not always known
at the time of the change. Once a change is closed,
most ITSM solutions will not allow the status to be
changed, however relationships between tickets can
still be achieved. The reporting logic of this will be
discussed further in the article.
Scenario 4
Scenario 3
As the change script was followed and according to
process, the change would be closed as “successful.”
As the technical outcome was also achieved,
the implementation status is also deemed
“successful”. However, as there was an unexpected
impact, an incident ticket should be raised and
related to the change. Once service is restored, a
The deployment of the change is successful as the
technical outcomes were achieved; however
the change status is unsuccessful due to the change
completing outside of the approved change
window. When a change is completed outside of a
change window, it can cause further risk and
unexpected impact which was not assessed due to the
window asked for.
Report Logic
In applying the above logic in the way different statuses are used, reporting can be consistent allowing a black and
white picture of how change management is supporting business services.
25 itSMFI Forum Focus—June 2017