Want to start a heated discussion with an ITIL Expert? Ask them to define the term “Change”.

ITIL v3 defines a Change as:

The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.

By that definition, if I swap out a user’s monitor, I need to open a Change, because during the time the monitor is disconnected, the user’s ability to access all services (email, CRM, ERP, etc.) will be affected.

I actually had a heated discussion with another ITIL Expert on this very subject. We were going to be teaching a class together and wanted to be on the same page regarding some of ITIL’s basic concepts. After discussing the topic for a while, we finally went to one of the ITIL v2 authors (who happened to be in the office down the hall) and posed the question to him. The author agreed with my definition of a Change:

Any modification to the status, or tracked attribute, of a Configuration Item (CI) contained within the Configuration Management Database (CMDB).

Using this definition of a Change, you can answer just about any question that comes at you regarding “Is this a Change?”

Does rebooting a server require a Change?

Is the server tracked as a CI in the CMDB? Yes.

Does rebooting the server cause it to change states? Yes, it goes from on-line to off-line, and then back to on-line.

Then yes, this requires a Change.

Does allocating more memory to a server VM require a Change?

Is the server tracked as a CI in the CMDB? Yes.

Is the server’s memory tracked as an attribute of the CI? No.

Does allocating the memory require a reboot? No.

Then no, this does not require a Change.

Does updating the firewall port blocking require a Change?

Is the firewall tracked as a CI in the CMDB? Yes.

Are the ports that the firewall blocks an attribute of that CI? No.

Then no, this does not require a Change.

But you may have to dig a little deeper regarding the firewall port blocking…

Is the configuration of the firewall documented? Yes.

Is that documentation a CI in the CMDB? Yes.

Will you be updating the version number of the document? Yes.

Is the version number of that document a tracked attribute of the document’s CI? Yes.

Then yes, you will need to open a Change. Not for the addition of the blocked port on the firewall, but because you are updating the version number of a controlled document.*

Configuration Management’s job is to keep the key parts of the infrastructure in a controlled state. The mechanism by which it achieves this goal is Change Management.

One of the primary purposes of Change Management is to keep the Configuration Management Database as accurate as possible.

The other primary purposes of Change Management are reduction of Incidents due to multiple conflicting Changes (also called Collision Avoidance or Change Control), approval from Business/Financial/Technical representatives, and oversight of the Release Management process.

But what if my organization doesn’t have a Configuration Management Database?

Many, if not most, organizations don’t have a CMDB. In these situations, you have to ask yourself if the element you are going to affect, in a reasonable world, would be tracked as a CI in a CMDB. If you think that the item is of significant value (or has significant risk if things go badly), then it should be in a CMDB and it should be considered within the scope of Change Management.

But my organization’s CMDB is an auto scanning program that has every attribute of every computer, down to the version of every laptop’s mouse driver.

Then you don’t have a CMDB, you have an asset/inventory tool. If you were to define this inventory list as your CMDB, then you would have to open a Change every time you swapped out a user’s mouse and had to install different drivers.

In this way, Configuration Management sets the scope of Change Management, and Change Management sets the scope of Configuration Management.

If an IT asset is in the Configuration Management Database, then it is covered by the Change Management process, but improper scoping of Configuration Management will break Change Management. If the Change Management process crumbles under the volume of Changes due to the number of Configuration Items or the level of detail in the CMDB, then you need to re-scope your CMDB to have fewer CIs or track fewer attributes.

By the way, if you follow this practice, you can audit your Change Management process by comparing the physical state of tracked CI’s with what is recorded in the CMDB. Any difference shows a failure of the Change Management process.

In a perfect world, updating a Change record to Completed would automatically set the new value of the Configuration Item. This would require that the information about the CI being updated be recorded in the Change record. Once the Change is successfully implemented, the Change Management system would automatically update the CI to the new value. Wouldn’t that be ITILrific?

*By the way, I would hope that updating the version of a controlled document would be a Standard Change.