Standard Change on mission Critical Servers?

[swiftfoot]

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.

Thanks
Scott

[Timo]

It's all about how much risk your organization can tolerate. Decide on that and write it out in your policy. Voila - problem solved.

[Diarmid]

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

[swiftfoot]

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?

Thanks,
Scott

[UKVIKING]

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

[swiftfoot]

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.

Thanks for the discussion so far,
Scott

[UKVIKING]

no you are not

itil defines a standard change...but the ultimatedefinition comes from your own change mgt policy that defines what is and is not a standad change

your company change board/ chamge manager is the authority to determine if a change that neets the criteria is going to be a std change

not itil

not any one here

again itil is a guide not a rule book
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]

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

[anthonymq]

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.

I hope this would give u a better idea. cheers

[Diarmid]

[anthonymq]

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.

[Diarmid]

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