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 your 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.