Business Case for Change Management

[c4ss]

I want to install an ITIL Change Management. But i have several economical questions.

Where i can find a business case ??
How can i calculate the ROI or TCO ??

and i have problem with the kind of Changes.Where can i find a list with some practice examples for standard and normal Changes.
I know theoretical difference.

[UKVIKING]

C4SS

First off. YOU CANT INSTALL Change Management. It is not a product nor software etc.

Second. SOX Compliance

Third. A proper CM process protects the Production environment from the idiots (general description of IT types - system, application, network and all others - staff) from messing the production environment. If your production environment is down. your company is down

lastly:

obviously, from your post, I dont thinkyou even have a clue as to what ITIL is ?
Please do your self a favor and google ITIL or look at the WIKIpedia site for an explanation of ITIL

In addition, if you really want ITIL CM installed, spend tons of cash on products / applications from sales type and not have a clue what you are buying

Get training on ITIL
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Diarmid]

c4ss,

These are not simple questions and I'm not sure I can offer much without knowing something about your organizational and business context. I'm sure it is possible to derive a generic business case from the ITIL manuals and you might get additional points from itSMF sites and from vendor sites that want you to buy their software and consultancy.

As for ROI. you need to be ina position to know what the costs are going to be before you can start on that and a large part of it is likely to be reduced risk and very difficult to prove.

TCO sounds more straight-forward, but again you have to find all the costs. for example how do you cost a CAB meeting?

Having said all this there may well be people here who can flesh out some of the things you want, at least in general terms.

My view on "standard and normal Changes" may be a little more helpful, but you may not like it.

For me "standard changes" should emerge from your activities rather than be predefined when you set up a Change Management System. doing it this way both ensures that you have the right candidates for standard change and that you understand fully the implications of performing those changes before you finalize the procedure for each of them.

I know you say that you understand the theoretical position, but let me emphasise that a "standard change" does not by-pass approval. It may have pre-defined criteria which, combined with rigorous procedural regulation, mean that it does not have to pass scrutiny within the "normal" change Management" process. They still need managed and they may still be subject to some forms of approval such as timing.

A couple of examples;

O/S patching. On the surface a good candidate. But you need a rigorous method for predicting the impact, testing the change and rapidly regressing when something unexpected occurs. In some environments this may be fairly easy to control, but in others the scope to be covered could be so wide as to make the "standard change" little different from a copy of the "normal change" process.

Server reboots. some people regard this as a prime candidate. Others, including myself, do not consider a server reboot to be a change atall. But it is a very good idea to have formal procedures describing how you manage server reboots.

Personally I don't think there is a clear and universal entity that can be called "standard change" and therefore I don't think there can be a clear theoretical position on the subject. Activities that will be performed many times in the lifetime of a service are always candidates for having their own carefully designed procedures. In some cases these procedures will in effect be modules to be invoked under Change Management and in others they will contain the entire requirement of change Management within them and will interface to the Change Management system in ways described within themselves.

Some organizations have looked on the concept as a means to circumvent a perceived straight-jacket, implicitly assuming that things done frequently require less rigour.

But consider that you cannot effectively manage change with two processes, a "normal change" process and a "standard change" process because there can be no such thing as a generic "standard change" process. The best you can have is a protocol which individual processes (one for each "standard change") are required to adhere to.

PS
and what John said while I was writing this is also correct and to the point.
_________________
"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

[Timo]

If you can't obtain or don't know the costs, then hopefully you have history of incidents that we cause by uncontrolled changes. Your business case could be simply then "See, this clusterf$%@ wouldn't have happened if such and such controls were in place..."

Determine what's important for your management and the organization.