ITIL Change Management - Some Basic Concepts

Document Sample
ITIL Change Management - Some Basic Concepts Powered By Docstoc
					ITIL Change Management principles- then here it is. A change means
addition, modification or removal - which can be termed as de-
registration -of an authorized ( or base-lined), planned and supported
configuration item/service or service component and associated elements
or documents. The circumstances often can be confusing in identifying
'change'. Requests for password reset, new access, server installation,
rebooting a server, new hire setup may not be termed as 'change' per se,
but they may generate IT change management activities. Many IT
organizations often get caught up in bureaucratic frenzy that they get
programmed to label any service request as change. One just needs to bear
in mind, just because it needs approval, tracking and documentation, it
is simply not a change. Just because it needs approval, tracking and
documentation doesn't mean it is a change. Similarly, requests for
administration are not requests for change. The IT organizations need to
be aware and cognizant of these factors to successfully drive the ITIL
Change Management process within the boundary of the definition. The
major object or the entity that instantiates a change, is the Request for
Change (RFC) . What is a change request? It is a formal communication
seeking an addition, modification or removal (deregistration) to base-
lined Configuration Item(s). We should not follow a straight jacket
approach in defining change and we might need multiple templates to
capture different types and flavors of change. A change request should be
exhaustively descriptive of the change details, its purpose, risks and
impacts on other CIs and at the level of the organization at large, the
implementation plan, the back-out plan if it fails, post-implementation
review plans.      Next, the important question is how do we categorize
the change requests. The guideline is to categorize them, broadly
speaking, based on business impact and complexity. We know that in the
simple scheme of categorization, we have three categories - Standard,
Normal and Emergency Changes.


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


Related Articles -
ITIL Change Management, ITIL Change Control,




Email this Article to a Friend!
Receive Articles like this one direct to your email box!Subscribe for
free today!

				
mr doen mr doen mr http://bineh.com
About just a nice girl