Scope of Change Management

[bnetra]

Of the below what can be considered as Change?

1) Change of a user's password
2) Change to an existing report
3) Change in server hardware
4) Addition of new network point
5) Applying latest patches to Windows desktops
6) Increasing the bandwidth of point-to-point WAN link
7) Uninstalling existing software on a server

My questions are:

a) do all the above changes should go through the Change Management process?
b) If there is no existing Change Management in place then how it should be treated?
c) How to define the scope of Change Management - what is to included / excluded?
d) Do all the above Change requests should initially go through Incident management.

Thanks.

[dboylan]

To give the broad definition of what a Change is may give you a better understanding of how I am approaching these questions. A Change is defined as any change in Status or Attribute of a Configuration Item. In theory, if you have no Configuration Management process in place, then there no reason to submit Change Requests. Practicality speaking, most organizations do not have a fully implemented Configuration Management process and as such have Changes submitted that are unrelated to CIs.

The correct way to define what a Change should be is by thinking "If I lived in a perfect world and did have a fully implemented Configuration Management process, would the Infrastructure I am about to affect be included in the Configuration Management Database?"

Having said that, let's look at each scenario you posed:

- 1) Change of a user's password

Most definitely not. The Configuration Item associated with passwords would be the security systems in place to manage passwords. Are you changing the Status of the security system? No. Are you changing an Attribute of the security system? I would also say no. Changing an attribute of the security system would be like setting the account lock out to occur on 3 tries rather than 10.

Is the request for a password change an Incident? Kind of. It is considered a Service Request. An Incident is an event that causes or may cause the interruption of a service. The service in question here is the security service. Does the fact that a user has forgotten their password affect the ability of the security service to continue to function? No. In fact, the only way it would be an Incident would be if the security service failed to lock out the user's account.

A password reset is considered a Service Request (which in ITIL are tracked in the Incident Management process). A Service Request is a request for information or documentation. The information in question here would be the user's password.

- 2) Change to an existing report

Is that report considered a Configuration Item (in a perfect world)? Probably not. If you tried to track all Reports as CIs, then your Configuration Management process would crumble on the required number of updates. But perhaps this report is the version controlled, financially mandated, most god-important report your company produces. Then maybe this report is a CI. In which case any change to it's status (it won't be available during the update) or attribute (it will change from a monthly to quarterly report) would require a Change Request.

- 3) Change in server hardware

The same answer as above except that most organizations would say that core infrastructure should most definitely be tracked in the Configuration Management Database. So a change in the status or attribute of a server would require Change Requests. Unless you were making a change on a server that was not an Attribute tracked in the CMDB. Let's say that you don't track the mouse connected to server. You decide that the current mouse doesn't have all the buttons you want or a scroll wheel. If the mouse isn't tracked as an attribute, then throw the old mouse away and hook up the new one. No official Change required. That change will probably be recorded in some other system such as Inventory or Asset. Remember that Configuration doesn't replace Inventory or Asset, it is a subset/superset of Inventory or Asset.

- 4) Addition of new network point

Think of this in terms I have already discussed. In a perfect world would you track the nodes of your network in a Configuration Management Database? Would adding a network point change the attribute (network diagram) of the CI? If so, then you will need a Change Request.

- 5) Applying latest patches to Windows desktops

Will the patch level be tracked as an attribute of PCs in Configuration Management? Will you bother to scope you CMDB to include every PC/laptop in the organization? If not, then changes to the desktop configuration do not require Requests for Change.

I will skip the last two since I think it is pretty obvious where my logic is going.

As far as you final questions:

a) do all the above changes should go through the Change Management process? I think I addressed this in my comments above

b) If there is no existing Change Management in place then how it should be treated? Time to invent a RFC form and plan for an Awareness Campaign on when the RFC form should be used and the repercussions of implementing non-approved changes

c) How to define the scope of Change Management - what is to included / excluded? If you don't already have a Configuration Management process, try and think of what you would include in a Configuration Management Database in your environment

d) Do all the above Change requests should initially go through Incident management. No. Some Changes, such as the mouse on the server, have nothing to do with a service interruption. Only events that cause, or might cause, a service interruption AND require changes to the Status or Attribute of a CI would start their life as an Incident and then have a Change Request opened to resolve the Incident.

Hope this helps,
Don

[matrejekm]

Although dboylan gives something I can call a perfect answer...

In my case because of lack of security officer - password management is treaten as a Change Management is some part.
Accounts were divided into the ones which has impact on CIs - e.g. administrative passwords, passwords used by applications, etc...
I don't care about user passwords - these changes are done as Service Requests or Incident Management.

In many cases it is a matter of agreement on what is included or what is not in change management scope as discussions can last forever
(even if you consider ITIL definition - it is always related to IT Service - and IT service definition is dependent on your organization).

I am working with something I called a Change Catalogue - I put there not only a Standard Change Types, but all types to clearly identify what is in my scope as Change Manager. That solves most of responsibility issues between me and Incident Management.

regards,
Mariusz M.

[UKVIKING]

User passwords should be just a service request - in order to track those who suffer from Operator Headspace

However, I and the system and network people would use Change mgmt for tracking system passwords. However... we would not put the password in the ticket. That would so wrong in many ways
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[dboylan]

[matrejekm]

If you oversee an account which is not related to exact person and is used on e.g. several servers and this servers can be maintained (e.g. hardware changes) independently then this account becomes a CI with relation to selected servers. This makes it to be in scope of Configuration Management.

cheers,
Mariusz

[jpomales]

Let's not forget that there is such a thing as 'routine' changes that do not need to go through the complete rigor of the CM process. I designed a standard form in our chosen tool, back in the day, for user password resets. This form would come prepopulated and my Service Desk reps would only enter the unique user id, along with start and stop times.

I wouldn't consider changing a user's password a 'Standard' Change, unless it's a password reset for a sysadmin/essential service; notice I said 'service' not 'server' and this for a purpose. If we define as a service Databases, for example, something that report writers and designers hit with a set of defined credentials that should go through a rigorous CM process, along with a defined Release Management structure.

Everything else on your list should go through CM.

Cheers.
_________________
audentes fortuna juvat

[raroa]

Please do not start from some idealistic position of what "should" be controlled. Be pragmatic. Look at People Process Technology.

Always start with the people: what is culturally acceptable and politically possible? is the place ready for CM? is there a "wind of change"? if you lock up all of the above do you have the power/mandate to do so or will you be ignored as a bureaucratic idiot (it happens). What will you do to tell people of the new regime and get their acceptance (or at least acquiescence)?

Process: can you cope if all the proposed objects become controlled CIs? how will people know what is controlled and what isn't? how much can you get moved into Standard change and how quickly? will the business still function?

Technology: how will you track all the changes? How will you manage workflow? measure compliance? enforce compliance? Detect subversion? If you can't do these things, then what is the point of CM?

Only once you have addressed these questions (and others) can you then plan what is under CM control.