Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: JSPL
New Today: 79
New Yesterday: 63
Overall: 139408

People Online:
Visitors: 61
Members: 0
Total: 61

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Reducing Urgent Change Volumes
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Reducing Urgent Change Volumes

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
cheddarpaul
Newbie
Newbie


Joined: Feb 09, 2006
Posts: 3

PostPosted: Tue Jul 07, 2009 5:52 pm    Post subject: Reducing Urgent Change Volumes Reply with quote

Hi All

I work with a partner IT organisation who are responsible for managing our change management process. Over the past few months we have been trying to reduce the % of Urgent changes as they inherently are more risky, push an additional burden on the Ch mgmt team and can be seen as a get out of jail free card by teams who want to quickly recover from a problem (they may have caused) without feeling much pain.

The past 6 months have seen the % at 11%, 9%, 7%, 7%, 9% and in June 11% again

We send out comms to all teams responsible for raising changes and the chg team do challenge Urgent changes as part of the process, but this doesn't seem to be having much impact on the %.

Luckily, we are not experiencing any incidents or problems as a result of these urgent changes. However, we do want to challenge the teams to bring the numbers down as it causes a lot of additional work and as I said, is being abused by techie and application development teams.

Has anyone got recommendations as to how this can be achieved?

Many thanks
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Tue Jul 07, 2009 6:22 pm    Post subject: Reply with quote

I have several questions

1 - How is the change board set up
2 - what is documentary evidence for policy, procedure, etc
3 - why is the change board authorizing these 'urgent' changes

If the policy document is clear as to what is acceptable as an urgent change and these changes meet that criteria.... review the policy
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
cheddarpaul
Newbie
Newbie


Joined: Feb 09, 2006
Posts: 3

PostPosted: Tue Jul 07, 2009 8:12 pm    Post subject: Reply with quote

There is a CAB which has very clearly defined rules, processes, etc and an eCAB process for Urgent changes, owned by our internal IT supplier and includes representation from supplier, service management, infrastructure and application development teams who are all part of the approval process.

The reason they are authorising these urgent changes is they 'appear' to fit the criteria - which is to avoid an outage/production incident, correct a production issue or to recover from an outage

This may be more of a behavioural change that is needed - especially from development teams implementing application and infrastructure changes which then need Urgent changes to correct production issues which they have either introduced or have found after implementation
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Tue Jul 07, 2009 9:39 pm    Post subject: Reply with quote

I see board members but the final arbiter in the CM process is the Change Manager

The eCAB is for Emergency Changes that are production impact, live changes

it appears that Project have hijacked the Urgent / emergency

where is release management
where is software development lifecycle
where is the change manager
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
cheddarpaul
Newbie
Newbie


Joined: Feb 09, 2006
Posts: 3

PostPosted: Tue Jul 07, 2009 9:50 pm    Post subject: Reply with quote

Hi and thanks for the response

Release Management is split across a number of teams - another bug bear of mine is lack of accountability for releases. They also are reactive to projects pushing through these changes, as much as change management is

eCABs are also used for Urgent and Emergency changes - something we could do to differentiate between to a greater detail (one battle at a time)

Software development does follow a lifecycle but, in my belief, is let down by poor testing, hence light production issues (not all are service affecting and may be regulatory or functional changes) being pushed through as urgents...

The change manager challenges these urgents but doesn't get much support from service managers or the business
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jul 07, 2009 11:51 pm    Post subject: Reply with quote

cheddarpaul,

a few suggestions some of which might be possible for you.

Use the stats from changes following release to hammer the testing issue (i.e. require an improvement program for testing process). That is all changes whether urgent or not that identify as a correction to recently released code.

Analyse reasons for all urgent changes and set up improvement programmes where this analysis takes you.

After each urgent change, inspect the project plan (or other work schedule) to determine when the change request could first have been submitted. If you find much here, then you have to look at a remedy; perhaps a requirement for Change Management inspection of all project plans at the outset, key stages and whenever the plan is amended; certainly an improved project management procedure.

Set all relevant section/project team managers a KPI of under x% or x [number] urgent change requests per rolling month/six month/year whatever (and haul them before the Spanish Inquisition when they fail).

Reject urgent changes where the perceived cost of waiting is fairly low on the grounds that the risks are too high ( a hurried change can damage more than it is intended to fix).
_________________
"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
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Wed Jul 08, 2009 12:16 am    Post subject: Reply with quote

One more thing

Cheddarpaul

Who does the Change Manager report to ?

your phrase
'The change manager challenges these urgents but doesn't get much support from service managers or the business'

indicates to me that the change manager is NOT in charge of the Change Management process. That the CM is a spectator in his own change board.

If the IT mgmt wants to have stable environment where the environment is not chock full of poorly planned, hurried changes that have the potential to cause major impact to the production environment, then the CM is the final arbiter. The rest of the Board members advise the CM

His manager should be the only one who can over ride his decisions

That is one issue

The other is as follows

If there is an urgent change... require proof.
If the application is failing or faltering, get the incident tickets associated
ask what is the impact if the change is scheduled and planned more detailed.

Also, if a change is deemed urgent and implemented
and the presenter verified that the change was urgent .
The CM does a Post Implementation Review and confirms that the change was in fact urgent - according to the policy standard for urgent

If not, then require more proof and sign off from that person and his/her manager

and tighten up defintion for urgent changes
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
pac666
Itiler


Joined: Sep 15, 2006
Posts: 22

PostPosted: Wed Jul 08, 2009 9:50 pm    Post subject: Reply with quote

First, Clearly Define your criteria for Emergency Change status e.g.

Likelihood of Service Loss, Imminent Service Loss, Possible Service Loss, Unacceptable Service Degradation, Security Vulnerability etc

Then define your criteria for Urgent Change status (I would suggest Wink)

Poor planning, Poor Communication, Poor Project Management


Keep challenging the Project Managers\Team Leaders and explain to them that urgent requests are to be discouraged. If you see no improvement in urgent requests rate then have a word with their line manager.
Back to top
View user's profile Send e-mail
DYbeach
Senior Itiler


Joined: May 25, 2008
Posts: 413
Location: Sydney, Australia

PostPosted: Fri Jul 10, 2009 9:06 am    Post subject: Reply with quote

Is there an option to tie the issue to performance management? Twisted Evil
_________________
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell
Back to top
View user's profile Send e-mail
rikofold
Newbie
Newbie


Joined: Aug 10, 2009
Posts: 1
Location: United Kingdom

PostPosted: Tue Aug 11, 2009 1:20 am    Post subject: Reply with quote

cheddarpaul wrote:

The reason they are authorising these urgent changes is they 'appear' to fit the criteria - which is to avoid an outage/production incident, correct a production issue or to recover from an outage


The urgent change process is there precisely to enable this type of change, so the question is whether your analysis of these changes reveals that they do or do not qualify.

If they do and the volume is too high to manage, then perhaps the urgent change process has become too cumbersome.

If they don't, then you need to manage that directly with those initiating the changes. It might be that a policy (such as the performance management system as someone already mentioned) would help to 'encourage' compliance with process.

All that said, there is rarely good reason for projects to implement urgent changes, that smacks of a lack of planning and diligence so if that's the main source you need to talk to whoever owns the PM process.

Overall though, the driver will be business need - and us ITILers can often forget that real life is a more compelling argument than best practice. The change process must be an enabler of the business, and many organisations accept this type of situation as reasonable because it enables their objectives.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.