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
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.
Posted: Tue Apr 03, 2007 1:30 am Post subject: Change Windows
Hi Folks
I've been given a task to define a process for implementing RFC's via a change window approach. It feels a bit of a tall order because we have several systems sharing technology/components. So how would you suggest defining the windows?
I can't decide if we should do this by service, or by technology. Either way there will be an overlap, so how do you decide?
We are restricted to weekends for changes, since our customer facing services are available 7.00 til midnight, Mon to Sat, and we do not have the achitecture to build a release on one set of kit, while being operational on another. We also have a 'tradition' of re-testing the implementation in the live environment, just to be sure.
Would you have a rigid routine for these windows, or do you plan a window/release based on the changes you currently have, and the most suitable way of grouping them into a release?
Joined: Sep 16, 2006 Posts: 3118 Location: London, UK
Posted: Fri Apr 06, 2007 6:33 am Post subject:
A couple of questions
DO you have any of the itil disciplines in place ?
Change windows and change freezes are good for any organizations but.. .they should /need to be in synch with any SLAs
For example
If you say that 1 day a month - saturday 10 -1600 is they period when system management can do any system maintenance, then the SLA needs to reflect that the period is not counted against any SLA targets
in addition, the date/time should be only used for any maintenance work
so if you have Change mgmt, if you have plan to set a change window, raise 1 change to explain the change and get the approval of all those affected for the date(s) in the upcoming year.
If you dont have any 'real change mgmt', establish the change window as an operational policy... and have it come from high it mgmt....
the same applies for change freezes however, with freeze you have to consult in more detail with customers (external and internal)
If you support external customers... involve the customer relationship management (SLM) and find out when there are critical time for customers
you will not be able to please all customers....
I with a few other change mgmt types did a survey of our customer base and asked when change windows/freezes were allowed.
If we took every customers' restrictions.. we could on do system maint on july 11 from 10 am - 1015 _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Thanks for the tips.
Yes, we do have Change, Config, Release, Problem, Service Level Management and Service Desk disciplines in place.
The approach historically has been to process and implement each change in isolation, but that clearly isn't very efficient. We've had a change freeze in place while we wait for a major system replacement project to complete, so we have a growing list of other changes backing up, and now is the time to look at grouping these into releases so that they can be implemented methodically, and hopefully logically.
We also need to balance development resources, since they are going to be stretched to deliver all the work, and we've been conducting a prioritisation exercise with the business users to establish which changes are most important/urgent.
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Wed Apr 25, 2007 9:21 pm Post subject:
I read your post and my immediate reaction was that you should always be service driven. Technology is 'only' an enabler for the service.
Whilst sharing a platform may make sense from a technology (and cost) point of view, it is not always a good idea from a service provision perspective. However, that is probably a situation you cannot change, and so you need processes to resolve the problem.
As John points out, the SLA is (should be) the driver for when you can implement changes to the service. But as you have multiple services on the same platform you need to to coordinate your SLAs to ensure you have a common maintenance window. As he also points out you cannot please everyone, so you must ensure that your SLAs allow you make necessary changes if required.
Quote:
The approach historically has been to process and implement each change in isolation, but that clearly isn't very efficient.
Hmm, I'd not be so sure of that, especially in a shared hardware environment. It may not be efficient in terms of changes/maintenance window, but it may be very efficient in terms of providing continuous service.
Because the platform is common you must ensure that a seemingly innocuous change to one service does not affect any or all other services. So implementing multiple changes to multiple services in a single change window might be a very risky process indeed.
Of course it depends on the services you provide, but I've worked in environments (such as space and defence) where no other approach would be allowed. And I've seen a cockup through poor change control render a $300M satellite inoperable.
By the way that's a very strong argument for having a development and staging environment where changes can be tested in isolation. I know it doesn't seem possible in your case, but effectively the cost of changes is higher and the speed at which you can make changes to the live environment is lower because there is no separate test system.
Unfortunately there is a compromise to be made between speed/cost and service availabilty/continuity.
Quote:
We also need to balance development resources, since they are going to be stretched to deliver all the work, and we've been conducting a prioritisation exercise with the business users to establish which changes are most important/urgent.
It seems to me you are doing everything right. ICT is there to support the business, and therefore the business must dictate what the service is, and how it changes (although IT can influence that). Therefore you are service driven, and so any changes to the technology be they hardware or software or whatever should be undertaken from a service perspective.
Put effort into getting your SLAs right, and ensure they a coordinated to allow you to make changes in a reasonable manner.
You might even consider creating a foundation SLA that covers availability, maintenance etc. for the hardware/os platform, and building specific service SLAs on top of that. It may not make your realse programme any faster, but at least you'll know when and how to implement them.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
