Every change to a CI vs Change Policy

[Scooter]

I’ve been doing change management on a fairly large network/account. I have been enforcing the general rule that any change to a CI requires change management including a formal change record in the change management system and not in a separate record in a request management system. I have been running into some resistance. There are certain changes where this approach is not practical. They argue that there are environments where user ports are constantly being changed to accommodate business user movement. For example, simply activating a user port.

I have recently been assigned to do change management on another fairly large account, which previously had no dedicated change manager and where many simple preapproved/standard changes are not recorded in the change management system. Changes like activating a user port, assigning the user port to a VLAN and even firewall rule changes are recorded only in a request management system.

Would continuing as such just be an issue of change policy, or would it be a basic violation of the intent of change management? Is there some documentation that supports either view?

[UKVIKING]

Scooter

You hit upon the bugbear of CM ..

How much should you control and why or why not ?

What first has to be done is always a CM Policy

The policy should define the types of changes and controls to be used

ITIL model examples

Emergency, Immediate, Normal, standard

the Emergency / Immediate I classify usually as emergency

The difference is when I write policy an Emergency is a retrospective fix to production. Immediate are fast tracks - usually the Oh F.... when the planner didnt and then wants in it

The vast majorit of work iss in the normal type - where risk and impact can not be 100% defined.

then the lowest. - standard. These are those changes that are so low risk and so low impact as they are neglible

The issue / plan is that the Cmgr and the CAB defines which changes are standard or become standard

Also, you have to reach a happy medium of control (see as paperwork) with the department

To coin a phrase from one of my accounting professors.

Do not spend a dollar chasing a penny
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Diarmid]

Scooter,

to look at your example where user ports are constantly needing to be changed. There are other examples of this type of condition - some develop quite a but of heat on the fora.

My take is that you can happily take such activities away from Change Management (note the capitals) but not away from management. Something that is being done "all the time" is an operational activity, and it needs to be managed as such. Design a procedure for carrying it out and take into account, inter alia, the risks, and the importance of keeping the documented system up-to-date. Have the procedure approved/audited by Change Management, Security Management as well as the more obvious operational and customer parties, and you will have a sound system. The lightness or heaviness of the procedure you develop will be commensurate with the risks involved in the activity.

The change management process is for all the things that do not already have change management built into their procedures, But the Change Manager is responsible for seeing that all change is well managed.

It may not look ITILish, but it will meet the requirements of ISO20000 if done right.
_________________
"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

[Scooter]

Thanks to UKVIKING and Diarmid - I will consider your input.