Posted: Fri Jan 29, 2010 2:30 am Post subject: Change Management: Past Due CRs - How to Manage Them?
I have now joined a new organization where I realised that the a standard Change Management (ITIL) process has been introduced here just 5 months ago. So now what is achieved is raising the CRs (Change Requests) - little different from RFCs as the lifecycle of a CR is less than an RFC (Planning, Resource allocation etc happens outside the CR window but the impact analysis and clash for change schedule etc is taken care by the CR schedule) for every change, review for all production changes through CAB and thus availing their approval in CAB.
One major challenge that I am facing now is: Past Due CRs
Past Due CRs as I call it are Change Requests whose deployment end date has already crossed however the change ticket is still kept open in the ticketing tool. The Change Supervisor has not minded to ensure that the ticket status is updated as "Change Completed" once the implementation is complete and business is satisfied with the implementation.
I have a huge count of over 300 past due CRs many of which are months old. and also what is very alarming is considerable percentage of the new change requests becomming past due once their deployment date is completed.
We have trainings on change management module scheduled thrice every month but the situation still persists. How do I address this urgently?
Joined: Sep 16, 2006 Posts: 3190 Location: London, UK
Posted: Fri Jan 29, 2010 4:30 am Post subject:
What is the underlying reasons that the CR in the system are past due
Was the Change implemented successfully but a post implementation or review not taken or scheduled
Is it a issue of whom is assigned the cr in the system ? wrong person, team etc
Is the change not successfully implemented or unsure that the change was implemented successfully or even not on the scheduled date or have to be reschedule
whose responsibility is it to close the cr down - change mgmt team or the implementation team or the owner or a combination thereof
Also, if the ticket is closed, can it be updated by any or is it locked forever
I have a lot of CR left in completed but not closed state as i review them for all of the missing data - followup - notes, clarifications, minor issues as when they get closed.. it is rather time comsuming to re-open for editing purposes _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Fri Jan 29, 2010 5:15 pm Post subject: Answering the queries....
Reason for the CRs becoming past due?
Change Management is defined recently here and is being rolled out - like in phases. The first priority being, making people understand the importance of a standard change management process and the necessity to follow it (meaning which raise a CR, avail approval in CAB for production CRs)
Concepts like Post Implementation Review are still not being initiated, as - there is lot more to focus-on or streamline before we reach a PIR stage.
It works this way, the requester (from business or IT) requests for a change via e-mail or even could raise a change ticket.
If the requester sends across his Request for change via an email, it reaches the implementer group and they would raise a change ticket on their name for the requester.
The Change Management tool is an in-house built tool and currently does not have many fields and facilities - that is a huge challenge here
The tool does not have any specific field for Change Supervisor but show the implementer group name. So most of the changes in the system - are raised by the implementers from the change implementer group and few changes are raised directly by business requesters
The time I joined the organization, what I realized is, we have reached a stage were the organization is only aware that a Change Request Ticket need to be raised for any changes in IT environment that affects the CI (again CMDB is just at its basic stage where the CI's very basic info is the only thing captured - so wont be of any assistance)
We are as an organization still to mature in implementation of chnage management process. The implementers were for last five months not even aware that tif they raise a change, it is very mandatory to avail approval for them.
Now, once i have joined, i have concentrated on this area educating people (requesters and implementers) on the necessity to avail approvals for all Change Request raised in CAB
they now represent changes in CAB and answer questions asked in review to avail approval.
But they consider that availing approval in CAB solves it and the process ends there.
The implementers are the ones who will have access to chnage the status of a chnage from WIP to Resolved, but they weren't aware that they need to resolve each CR post the implementation of change and thus arised a huge backlog of Past Due Changes
Now to address this, I have identified SPOCs from most change implementer groups and have asked them to chase their teams to identify whether of not the past due changes which was over 450 were implemented or not
also i have been educating many implementers on the functionality that the tool provides and the workflow of it
Many implementers weren't aware of how is the workflow of CRs configured in the tool and how to perform the actions in the tool that are required by the requesters/implementers
with one and half months effort of work, we cleared 150 CRs from backlog. For the rest of the CRs, the SPOCs claim that either the specific individual implementer name is unknown for this change or the implementer does not remember whether the changes were performed in the system as they are months old
I do not want to Resolve all CRs blindly as that would mean not accurate reflection of the implementation status. Nor do I want to reject all as that would not be correct if they changes were already implemented
My purpose is to ensure that the documentation is kept correct for all past dues - meaning which if the change was implemented, we proceed the workflow to move it to resolved. If they were not implemented, we reject the CRs
On the new CRs that gets created, even after I send reminders only 50% of the CRs follow the complete workflow in the tool and the rest still are causes for making the recent CRs turning into Past Due
I am not sure how to go from here.. I have addressed 200 amongst the 450 Past Due CRs and the rest is still in with apporx 40% new CRs piling up as Past Due
It is a challenge here from how it was handled at my previous organization. But, it is good time to learn as there is lot to streamline.
Posted: Fri Jan 29, 2010 5:24 pm Post subject: More work done
In addition to all this, I have also worked with the team here and we have provided a list of requirements as changes to be made to the Change Management tool. This was done two months back and is approved and being worked on. This new version of the tool is scheduled to get rolled out in June '10.
But again, it is just one step leap, there are still more enhancements required and I plan to perform it in small chunks as that way I can realize minor benefits within smaller time period
So we can easily blame the tool, but as we fix it, we still need a good journey in process front
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Fri Jan 29, 2010 8:38 pm Post subject:
everything you are discussing is at ground level and, clearly, that is where much of your effort needs to be focussed. However it does sound as if your organization has not paid sufficient attention to the development of policy in this field. You might want to look at enshrining some of your ideas into policy and getting that agreed at the top and understood throughout the organization.
It is much better to be able to rely on policy than on the ITIL books in explaining and enforcing procedures and rules.
From a quality perspective, it can be asked if there is a point in creating a change record if you do not record the outcome. The purpose of change management is "to ensure all changes are assessed, approved, implemented and reviewed in a controlled manner" (ISO20000). Rework that into a policy statement and elaborate on the components and you will have a sound basis to work on. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum