Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Sat Mar 10, 2007 1:12 am Post subject: Change Manager Role
The company I work for is just starting to talk about ITIL. We are currently transitioning to a new Change Management tool. We have an IT organization that is about 1500 people (1/3 of the company). We are talking about instituting "Change Manager's" across the enterprise by lines of business (there will be about 25 - 30 Change Managers. Their responsibilities would be:
1. Coordinate the overall planning and scheduling of changes
2. Interacting with stakeholders and monitoring progress throughout the change lifecycle.
3. Verify quality of information in change request (CR)
4. Request additional information or clarification from requester if needed
5. Perform initial analysis of change requests:
- Is this a duplicate of an existing change request?
- Can the change be consolidated with another change or changes?
- Impacted asset(s) identified?
6. Reject or defer CRs, as appropriate, based on the initial review
7. Working with Project and Production Support Managers prioritize all Change Requests (CR)
8. Qualify the CRs for a Change Control Board (CCB) me
9 . Convene and Chair CCB
10. Update the Change log with all progress that occurs
11. Participate in Physical & Functional Configuration Audits
12. Coordinate change implementations with Release Management
13. Review all implemented Changes and outstanding CRs for appropriate status
14. Produce regular and accurate management reports
15. Monitoring for process improvements and communicate improvements to organization as they are deployed.
Do these responsibilities listed above align with the Change Manager role defined in ITIL?
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Sat Mar 10, 2007 7:32 am Post subject:
I dont know where to begin
First why do you need so many Change Managers ?
Second, what is the change management tool. ?
Third, does the tool integrate with the Service Desk, Incident, Problem and the Configuration Management areas
Fourth, Who in the company has any ITIL training and at what level - Foundation, Practioner, Manager
Now to the tasks 1 - 15.
I was going to talk about each one but I wont. Because it would in my eyes it would be consulting not advice or opinion and i am an IT Prostitute - consultant. grin
I think you are mixing the role of a person who raising changes, the people who manage / control the process and the people who need to approve the changes.
I worked for a telco which had 6 change managers total. myself for managed hosting and voice applications and an internal IT team of 2-3 who dealt with desktop etc issues. and a core network and telco change team
In a nutshell you need the following
a common defined change management policy
a centralized team who manages the change..... manages does not mean write, edit, check, approve, implement, test and close.... it means manage the process so that those responsible for each phase does their respective roles
and change management for internal IT changes - desktop - needs to be managed separately from IT Operations - servers, network etc for the services you provide
I think you are mixing the change manager with the following roles
project manager
service support manager
service / account/ service level manager
IT Director / Manager
Configuration Manager
Config Librarian
Release Manager
Development manager
Product manager
Change Approvers
I await your input/commentary _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
We are using Remedy Problem and Change Management. We are not using the Remedy asset management (CMDB) system yet. We do not have auto-discovery tools, except for desktops. We are using Rational ClearCase/ClearQuest for configuration management. We do not have automated deployment tools. We write our own build/deploy scripts. We do not have the ability to detect unauthorized changes (no tool in place to monitor).
We have a staff of 40 people responsible for the change, configuration and release management processes, standards, reporting, customer support and tool administration.
We support about 700 business applications around 800 - 900 servers. We make between 800 - 1200 changes per month (business application and all infrastructure (servers, desktops, network, etc.)
We have issues with change impacts since we don't have a reliable means to determine upstream/downstream impacts. We were hoping to place these Change Managers into each business unit to coordinate and communicate with each other to deduce these impacts.
Maybe there's a better way. I'm new to this discipline. Thanks for the help and comments.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Mon Mar 12, 2007 2:14 am Post subject:
AllanT
This came straight from the Service Support Blue Book
Change Manager
The main duties of the Change Manager, some of which may be delegated, are listed below.
Receive, log and allocate a priority, in collaboration with the initiator, to all RFCs. Reject any RFCs that are totally impractical.
Table all RFCs for a CAB meeting, issue an agenda and circulate all RFCs to CAB members in advance of meetings to allow prior consideration.
Decide which people will come to which meetings, who gets specific RFCs depending on the nature of the RFC, what is to be changed, and people's areas of expertise.
Convene urgent CAB or CAB/EC meetings for all urgent RFCs.
Chair all CAB and CAB/EC meetings.
After consideration of the advice given by the CAB or CAB/EC, authorise acceptable Changes.
Issue FSCs, via the Service Desk.
Liaise with all necessary parties to coordinate Change building, testing and implementation, in accordance with schedules.
Update the Change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve service quality.
Review all implemented Changes to ensure that they have met their objectives. Refer back any that have been backed out or have failed.
Review all outstanding RFCs awaiting consideration or awaiting action.
Analyse Change records to determine any trends or apparent problems that occur. Seek rectification with relevant parties.
Close RFCs.
Produce regular and accurate management reports. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Mon Mar 12, 2007 2:45 am Post subject:
AllanT
While there are some similarities between what you wrote and what is in the definition, your role puts too much hope and responsibility on the donkey that is change management. and It will fail most probable.
As you had said
' We have issues with change impacts since we don't have a reliable means to determine upstream/downstream impacts. '
This per se is not a change management problem but a configuration management and CMDB issue. Change Management depends on an accurate assessment of the risk and impact of the change. This is more normally done through a CMDB (actual) or some sort of database where certain pertinent information is kept and can be gather together.
I see the following from what you have written, what I can infer, and what I know from the 'real world'
Your company suffers from the effect of poorly planned and implemented changes - both from an application world and from the system and network world.
The effect shows in the service quality or lack thereof and it impacts on your $$ generating capabilities.
Some senior management heard about ITIL in a seminar, conference, etc and figured that implementing ITIL will save his butt because it is his realm which being blamed
The rest of management ... went ... yea ... ITIL will save us.....
They listened to sales types and got a halfassed solution for a big chunk of change - even with the 'discount'.
Why do I think what you bought was half-assed ? Easy
In order for change mgmt to work, you need a Service Desk - staff and tool - who would handle incident management. The incident mgmt piece feeds into problem mgmt those issue that prolem mgmt should consider trying to solve. The incident mgmt will deal with the restoration of service and the problem mgmt will deal will finding and fixing the root cause if possible.
then change mgmt will make sure the solution is rolled out (through Release mgmt) in a planned considered way so the solution does not impact on the services / customers / users too badly
Throughout the process, configuration mgmt and the cmdb is touched to make sure that the data therein is used, linked and updated. Incidents will be linked to specific services, device etc. Same for problem. THe change / release process will ensure that the bad/updatable CIs are dealt with properly. Then config will deal with the after effects
====
The only thing that I see that has been accomplished by having 30 change managers is that there is no responsibility or ownership of anything. Additionally the 30 change managers will be held accountable for things that are most likley not their responsibility or fault.
And the plan is doomed to fail from the start or wil lnot accomplish what the senior mgmt expected.
===
So what advice can I give you without dipping into the free consultation which cuts my own throat.
First
Separate the following areas involving
IT Support for Desktops
Application Releases - desktop and server
Architecture Support (Servers, networks)
Second
separate the operational environment from the Development UAT & Testing environment
third
follow a Service Improvement Plan for each
Fourth
Get senior operational types ITIL qualified.. start with foundation etc
Lastly,
If you dont have any one internally who has the knowledge of ITIL to do #3, hire some consultants to help you along
PS: Any tool that is out there is NOT ITIL COMPLIANT. Aint no such animal. ITIL is People, Process and Tool. If the people and the process aint there.. the tool aint going to do anythin but cause grief _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Thank you very much for the information and comments.
I am in the US.
We do have people that are Foundation Certified. I don't know of anyone that has Practioner or Manager.
We have Issue/Problem Management, Configuration and Change Management and we are just starting Asset Management. The problem is these processes were developed in silo's and not from an end-to-end approach. Different management teams and Turf Wars.
We are just starting to talk ITIL and it is from the bottom-up. Senior Management hasn't committed to anything yet.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Tue Mar 13, 2007 1:52 am Post subject:
AllanT
There is no real point to start something from the bottom if the top aint going to go along with it.
You would be doomed to fail because part of the implementation of ITIL says.... you need the buy in and support of upper mgmt
i dont see service desk mentioned any where...... do you have a service desk/noc/front desk etc ? _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Any tool that is out there is NOT ITIL COMPLIANT. Aint no such animal. ITIL is People, Process and Tool. If the people and the process aint there.. the tool aint going to do anythin but cause grief
Or as I have said over years " NO tool is going to fix a process/organisation problem"
Also, implementing ITIL is time and resource consuming: you better get top management approval first.
I understand the focus on Change Management, as I tend to consider it the most important process...as long as you have something in place for the others.
However Change Management is not just another way of managing changes, it is a way of CONTROLING changes which means that the change is accurate, effective, secure ,... Part of the added value of ITIL's change management, is that all changes are evaluated in terms of costs/benefits of course bu also in terms of impacts and risk assessements. The key is, you cannot asses impact and risks without a good Configuration Management, based on a real CMDB.
As Change Management is rather complex, you need to have the capability to learn and improve the process, which requires to be able (at least) to identify incidents that follow a change , which means have Incident and Problem Management processes in place.
With so many changes per month, I'd bet you've quite a lot of fixes in them . Without proper incident and problem management I am not sure you will be able to significantly reduce the number of incidents that are created with and will follow those changes; so you potentially generate as much incidents as you solve (pessimistic view but sometime realistic though).
Lastly (so I do not cut my throat either) : I would (personnally) never consider or advise to start / implement Change Management on such a large scale from the beginning.... _________________ JP Gilles
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Mon Apr 02, 2007 11:43 pm Post subject:
I totally agree with both John and JP. I would add that having implemented Change on it's own without a tool, and without any form of asset control, it is extremely hard work.
I think you need to scale down people's expectations, with regard to what ITIL can do for your company - It is not a magic bullet to kill all the werewolves and vampires with.
I would try and get at least some of the Senior Management Team onto the foundation course, this way you will have far less pain.
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Thu Apr 26, 2007 7:48 pm Post subject:
Hopefully a bit of hard earned experience will help here. Excuse the slight digression.
In any significantly sized environment implementing ITIL (or any other formalised process framework) is difficult without tooling, and there is a real chicken and egg problem here: which comes first processes or tooling?
Before we all jump up and shout 'processes you fool' let's look at the real world.
Selecting tooling is a tough thing because every tool is different, and implements their vision of ITIL (or some other framework) differently. As everyone states there is no such thing as ITIL compliant tooling. So how do you select?
Well as ever the answer is: it depends (on your goals).
If you want a quick implementation of the tooling you select, you must be prepared to adapt your processes to how the tooling works. Otherwise you need to select an extremely adaptable tool, and will spend many 1000s of hours with expensive consultants to make your vision work.
If that's not bad enough, remember also that if you try and change the way people currently work too significantly you will encounter serious resistance, and it will take longer than you expect, and your quality of service will go down during that period. That's a fact of ICT life.
Most of us live in a world of purchase driven IT. In other words senior management may listen to IT and other experts on what kind of tool should be purchased, but they will then go and purchase a tool based on other (possibly political) criteria that may or may not match your requirements at all.
So whilst in a perfect world you would adapt ITIL defined processes to match your organisation (and yes that is a perfectly reasonable thing to do), then go find the tool that matches your requirments, implement and all go home for tea and medals - it will not happen.
So as usual it will be a compromise.
Yes define your processes, but try and ensure that they do not change your current way of working too significantly (unless you are currently an IT basket case). At the same time look at tooling and try and find something that matches your vision.
Once the tool has been selected (or been selected for you) if you really want to make it work, review your processes and see if they match the workflow that the tooling will almost inevitably impose. If they do not, but there are only slight differences, consider changing them to match the tool. If not - pray, change job, or struggle on with a doomed project;-)
Yes, I know I am preaching gloom, doom, and insurrection here, but unfortunately that is how the real world works.
There are inherent dangers in this approach in that you may adapt too much and diverge from ITIL; but you are not implementing ITIL for ITIL's sake, you implement to improve your organisation's service delivery.
The bright side is that the success of ITIL means that tools will eventually make an ITIL implementation easier, but remember still ITIL is only the framwork - and 20 'ITIL' tools will still all be different.
The change manager (also known as the change supervisor) is a person or a
group usually within your organization’s support department. In large
companies, the change manager’s main responsibilities usually involve
planning and oversight. But in small companies, the change manager can
function as the change assignee who is actually performing the change. To be
eligible to be the change manager, a user must have the functional role of
Infrastructure Change Manager.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Sat Jul 28, 2007 12:53 am Post subject:
Bootwhile
I dont know where you are going or coming from with what you wrote
Can you explain what you mean
my notes
-----------
The change manager (role) should manage/control the changes that are raised in the environment that is under his(her) control.
The ChMgr does not have to be a tech head.. but he should be able to spell IT without spotting any vowels.
The CAB members should be the technical experts for their area
System (o/s)
S/W
Network
etc
The Change Manager should not be the person to raise the change, approve the change, implement the change and complete the change.
[unless it is a really really really small company]
The changes should be raised by someone who knows what the change is about or PM
There is a BIG difference between change supervisor/clerk/analyst & manager. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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