| If we are searching for a concise definition of | | | | The ITIL describes a Standard Change as "...a |
| 'change' - in conformity with the ITIL Change | | | | change to the infrastructure that follows an |
| Management principles- then here it is. It means | | | | established path, is relatively common, and is the |
| addition, modification or removal - which can be | | | | accepted solution to a specific requirement or set |
| termed as de-registration -of an authorized ( or | | | | of requirements." The standard changes, which |
| base-lined), planned and supported configuration | | | | are pre-authorized, can be implemented under |
| item/service or service component and | | | | established procedure, in other words, a standard |
| associated elements or documents. The | | | | operating procedure(SOP). Its risk and impact |
| circumstances often can be confusing in identifying | | | | profiles are low and known. It should have a |
| 'change'. Requests for password reset, new | | | | tested set of Release-to-Production document |
| access, server installation, rebooting a server, new | | | | templates - build and test plans or scripts, support |
| hire setup may not be termed as 'change' per se, | | | | plans, implementation plans and back-out plans. |
| but they may generate change-management | | | | CAB can pre-authorize the standard changes |
| activities. Many IT organizations often get caught | | | | based on risk and impact and CAB can also |
| up in bureaucratic frenzy that they get | | | | delegate responsibility for accountability of delivery |
| programmed to label any service request as | | | | of the change to the change owner. |
| change. One just needs to bear in mind, just | | | | What is a 'Normal' change? The ITIL version 3 has |
| because it needs approval, tracking and | | | | introduced this concept. It follows the full-blown |
| documentation, it is simply not a change. Just | | | | ITIL Change Management process- assessment, |
| because it needs approval, tracking and | | | | authorization, CAB approval, scheduling before |
| documentation doesn't mean it is a change. | | | | implementation. Based on the scope, complexity |
| Similarly, requests for administration are not | | | | and impact, a normal change can be further |
| requests for change. The IT organizations need to | | | | categorized as minor, major and significant ones. |
| be aware and cognizant of these factors to | | | | An ITIL emergency change is the highest priority |
| successfully drive the change management | | | | change that can be defined in an organization. |
| process within the boundary of the definition. | | | | Emergency changes are defined as changes that |
| The major object or the entity that instantiates a | | | | need to be evaluated, assessed and either |
| change, is the Request -for-Change (RFC). What is | | | | rejected or approved in a short space of time. In |
| a change request? It is a formal communication | | | | other words, emergency Change is reserved for |
| seeking an addition, modification or removal | | | | changes intended to repair an error in an IT |
| (deregistration) to base-lined Configuration Item(s). | | | | service that is negatively impacting the business |
| We should not follow a straight jacket approach in | | | | to a high degree. Simply defining a change as an |
| defining change and we might need multiple | | | | emergency does not automatically entail the |
| templates to capture different types and flavors | | | | change should be implemented. The Emergency |
| of change. A change request should be | | | | Change Advisory Board (ECAB) will assess the |
| exhaustively descriptive of the change details, its | | | | change and provide advice to the delegated |
| purpose, risks and impacts on other CIs and at | | | | person responsible for approving or rejecting |
| the level of the organization at large, the | | | | emergency changes. |
| implementation plan, the back-out plan if it fails, | | | | In the context of ITIL, 'change priority' needs to |
| post-implementation review plans. | | | | be properly computed before scheduling the |
| Next, the important question is how do we | | | | requests. The formula for determining Change |
| categorize the change requests. The guideline is to | | | | Priorities is: Priority = Business Impact + Urgency. |
| categorize them, broadly speaking, based on | | | | Truly speaking, determination of 'priority' is not |
| business impact and complexity. We know that in | | | | purely a matter of quantitative computation, |
| the simple scheme of categorization, we have | | | | because impact and urgency are not numeric |
| three categories - Standard, Normal and | | | | entities. But at least we can arrive at some ordinal |
| Emergency Changes. | | | | ranking of the priorities. |