Posted: Thu May 11, 2006 12:43 am Post subject: Change management questions?
My assignment is to develop a operational change management policy and procedures in IT department. I have started preparing procedures and policy related with change management process in IT operations on the basis of ITIL principles. In the company, IT operations deals with system, network, and helpdesk management. IT operations is not responsible for softare and system development.
While doing this, I encountered several issues on which I am seeking your help and expertise. Would you please kindly answer my questions below? I would really appreciate your big help.
1)Who can be change originators that trigger change management process? My first impression was all of users; but later I thought, they will not provide sufficient information when filling out RfC form. Could that be only change coordinators that initiate operational change management process?
2)I plan to dedicate a change coordinator for a certain IT infrastructural change. Would that be good idea? OR, one coordinator is enough?
3)When forming CAB, is it wise to get middle managers or specialists who have certain expertise?
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Thu May 11, 2006 11:57 pm Post subject:
Remeber that the 'R' in RFC stands for 'request' - if there isn't an objective way to say 'No' then you are processing work orders not RFC. So...
1) Your first inclination is correct. It is good policy to allow anyone to submit an RFC. The Change Management process model distinguishes between the 'acceeptance' and 'approval' of RFC. Both should be explicit states. The 'sufficient information' problem is managed with the 'accepted' state. There are a number of simple mechanisms, most of which are versions of formal requirements: Forms that have to be 'completely' filled in, the requirement that a business case be included, the requirement that submission requires the submitters manager to 'second; the submission, etc, etc. Any submitted RFC is easily reviewed and rejected as 'not accepted' on the basis of these checks. Yes you may get a bunch of vexing or trivial RFCs, but these can be quickly filtered out, and provide a useful record of the 'state' of the end-user community. Pressure for change does come from the floor also.
2) Depends on what you see as a 'co-ordinator's' duties. Change management is an administrative control process - it's not a change building or technical supervision activity. So if you mean co-ordinating the build - then make the explicit assignation of a 'change-cordinator' a pre-requisit for 'approving' any non-standard change. If you mean assisting the change manager then the duties will be with managing, scheduling and distributing resources and commitments. In which case it depends on the size of the organisation as to how many, but these would be 'positions' as well as roles.
3) Yes it is: Again, the 'A' stands for advisory, not 'Approval' The Change Manager approves - in consultation with the director, the customer, and the service manager. The CAB advises and revises. So given the complexity of you average IT site it is wise to have a quorum of 2 or more people and an 'invitation' list ensuring the appropriate expertise is available. And it may not just be technology expertise. Some changes may lead you to include staff from business units like finance, purchasing, HR, or even legal from time to time. (Do however make sure you get people efficeintly and appropriately briefed - and remeber a fair ammount can be done 'virtually'.)
Having said all that, don't forget that change is by nature complex and there isn't a one size fits all approach - so make sure you have developed your change models effectively, are deploying streamlined standard change methods for small and frequent changes, and delegating appropriately.
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