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.
The Itil Community Forum: Forums
ITIL :: View topic - Standard Change on mission Critical Servers?
Posted: Wed Feb 24, 2010 6:23 am Post subject: Standard Change on mission Critical Servers?
I'm confused about the ITIL V3 concept of Standard Change because it seems like certain kinds of "Standard Changes" may require authorization and scheduling.
Let's say that one of your typically Standard Changes (Antivirus Update) is impacting a mission critical server. Would you take this Change through the Assessment and Authorization phases of your Change process? Would you at least take this Change through the Scheduling phase? Would you consider this to become a Normal Change (instead of a Standard Change) if you did decide that it needed these additional levels of Change process?
What about Standard Deployment Requests of a new service (i.e. well understood deployments)? What type do you set your Change to? Do you set it to "Standard" or "Normal"? It appears according to ITIL that you should take this Standard Deployment Request through Assessment, Authorization and Scheduling.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Feb 24, 2010 5:40 pm Post subject:
Why do people think ITIL is a bunch of formulae?
"Standard Change" is a term used to describe a concept. The term is inadequate and the concept is imprecise.
Okay, the underlying premise: all change must be managed to ensure it is properly done to minimize risk.
For the most part, the best way to do this is to run it through a defined procedure following specific steps that ensure it is properly planned, executed, tested, reviewed and authorized but not in that order.
Some changes, however, lend themselves to a different procedure, one specifically designed for that change. This is because they are understood to have predictable and repeatable characteristics, because they are done more than once.
By running these under their own procedure, time is not wasted pretending we don't know what they are about. This procedure will however ensure that they are authorized, planned etc. in their own right. It may be that elements of authorization, planning etc. are predetermined in these cases but their procedure will specify that. They are still managed as a change; they still take into account of what else is happening around them (i.e. they go on the schedule of changes); risk is still assessed; people are still consulted and notified appropriately; testing is still done; etc. etc. etc.
Nothing is given up by making something a "standard change". Some things are easier because the planning may already be done, some levels of approval may already be in (but not the scheduling in many cases for instance), the test environment and specification may already be in place; much of the risk evaluation may already be done.
A "standard change" procedure is simply a change management procedure streamlined for a type of change that is well understood. It still does everything necessary to manage the change. _________________ "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
I think this is exactly my confusion. From the ITIL V3 docs, it seems pretty cut and dried that Standard Changes are considered to be Preauthorized and also that Standard Changes are considered well understood processes.
However, it seems to me that there are certain types of well understood processes that would still require additional risk assessment and authorization.
So is the concept of whether a Change is preauthorized separated from the concept of whether a Change is Standard? For example, could I have a Standard Change that was not preauthorized?
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Thu Feb 25, 2010 1:03 am Post subject:
Swift foot
Then it is NOT a standard change
Standard changes would be those that the Change Board (yours) deem to be standard changes as they are repeatable, etc etc etc and meet the standards / requirements of what your company policy says
Also, ITIL is a guide, not a rule book _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
It seems like I'm getting two opposite responses to my question here.
One approach would be to change the Change type to "Normal" during the Accept and Categorize step based on the server criticality and then take this Change through the Assessment and Authorization and Scheduling phases. This same Change has been done a million times before so is a well-understood process, but due to the enhanced risk, has changed from a "Standard" Change to a "Normal" Change.
The other approach would be to consider this Change Type to be "Standard", since it's still a well understood process and came from a template but flag it somehow as still needing authorization and scheduling.
I'm curious in taking a poll to see how many people follow each path. I know this is just a conceptual question since in either case, the higher risk Change is taken through the more detailed process, but I'm trying to understand exactly what the concept of a Standard Change is according to ITIL.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Feb 25, 2010 9:03 am Post subject:
swiftfoot,
you are talking as if you want just two processes, a "normal" change and a "standard" change. For me, each "standard" change needs its own process. This is the crux of pre-approval, not that it is known, but that it is documented. And it is in this process documentation that you deal with how it treats risk.
However John is totally correct. If you have a "well known" change that recurs frequently and you want to treat it differently from other changes, all you have to do is define how you want to treat it; i.e. write a procedure for it. It goes without saying that you will remain within your Change Policy in doing this and that your procedure will meet your quality requirements for changes.
This is not ITIL because nothing is ITIL. It is just sound service management to design processes to meet your requirements.
There is another approach, which is to predefine the communications, test and implementation plans, and have the change go through CAB for approval and scheduling. That saves time because Change Management has pre-validated your plans.
Actually there are probably a hundred other ways as well. The point is to find the best way for you. This will be the one that minimises effort/cost and time without compromising on risk and service disruption. _________________ "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
Posted: Sat Mar 20, 2010 5:45 am Post subject: Standard Change on mission Critical Servers?
Swiftfoot
An activity even if it is tried and tested, i wold not consider it a standard change IF the change has a Potential impact or risk.
In your case if the change was applied to a normal PC, i would consider it a standard change since i am aware of the result and also the fact that potentially the impact would be only over that PC and no body else would be impacted, BUT if a change however simple needs to be implemented on a mission critical service i would take a different approach, i would prefer it is tested and verified in a Dev, UAT environment, observe its effect and then would consider implementing, even then i would take some precautions performing it during a maintenance window.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sat Mar 20, 2010 6:04 am Post subject: Re: Standard Change on mission Critical Servers?
anthonymq wrote:
An activity even if it is tried and tested, i wold not consider it a standard change IF the change has a Potential impact or risk.
1. Why would you waste time making a change that had no impact?
2. How can you make a change without taking some level of risk?
Take your "normal" PC. Suppose that the change goes wrong and further suppose that that PC at that point in time contains the only current version of a document that is needed in ten minutes for a high impact business process? Impact is not about numbers affected, it is about what it does to, or fails to do for, the business.
The real point is not that a standard change lacks impact and risk, but that it's area of impact and risk has been clearly identified and it has its own process that deals with them appropriately. _________________ "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
Posted: Mon Mar 22, 2010 11:20 pm Post subject: Standard Change on mission Critical Servers?
Hi Diarmid,
1. Why would you waste time making a change that had no impact?
I beleive assessing a change should not considered as a waste of time, infact my efforts would escertain that none of my systems/services are impacted due to a change.
2. How can you make a change without taking some level of risk?
Any change is associated with potential risk, a change manager is appointed in order to analyze that risk and minimise its effects to nil/minimum. If a change is having potential impact on a PC having crucial info, then i would not consider it as a standard change.
What i was trying to point out to swiftfoot is that any change which has a potential impact should be analyzed before hand, and changes which have set proceedures or whose impact and risk is known and can be beared by the organization could be determined as standard.
But again its the perception of each individual organization.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Mon Mar 22, 2010 11:31 pm Post subject:
Anthony,
perhaps I overspoke. (made that word up, never mind)
My point was that you still assess impact and risk when managing a standard change, because in fact, it is the scope of impact and risk that is already known rather than the measure of it, since this varies with time and place among other things.
Perhaps I'm being a little pedantic, but I believe that a procedure designed for a specific "standard" change will include impact and risk assessment activities. And will also include threshold criteria beyond which that procedure must not go. _________________ "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