What is the content of a standard change

By ITIL® from Experience©

A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction - for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request. See also change model.
Source: ITIL® glossary and abbreviations English, 2011. http://www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

should have enough details to enable the Change Manager to assess the risk of making that change. It must also enable the Change Manager to determine if this change can be done in the future without authorization.

A standard change should not simply be an Request For Change (RFC) declared as a standard change. It should have an artifact or document describing what it does, how it is done, when it is done, who can do it as well as the conditions under which it can be made.

Standard Operating Procedures (SOP)1 greatly clarifies the concept of a standard change. SOPs2 are widely used in the military to achieve uniform outcome for a specific task. Similarly, organizations that implemented quality management frameworks or that are ISO certified use SOPs to standardize processes to produce predictable outcomes.

A standard change procedure document should contain:

Document identifier
Version number
Status of the document (e.g. in development, active, under review, expired, retired)
Author of the procedure
Document owner (e.g. Configuration Item Owner the procedure applies to)
Type of Configuration Items (CI) or list of specific CIs it can be used for (e.g. routers model 1001 and 1004)
Role that can implement this standard change (e.g. Windows Server System Administrators)
Specific release/implementation window(s) when it can be implemented (e.g. time of day, day of week, day of month, maintenance week-end, business cycle)
Service Level Agreement (SLA)
Communication required (e.g. Service Owner, Service Desk, Customers, Users)
Authorizations required3 (e.g. Customer affected, CI Owner)
Date of last revision
Review trigger (e.g. Operating System upgrade, yearly anniversary date of the procedure)
Date of next revision and/or expiry date

It should also contain detailed work instructions and step-by-step procedures for the user to follow when completing the change. This enables the reviewers and the Change Manager the ability to determine the procedure's risk and request that additional steps be added to mitigate the risk (e.g. backup before starting the change).

To be clear, the information above describes the procedure document of the standard change. Every time it is used, an RFC should be logged in the ITSM tool.

"The 4 Ps for Change and Release: Planning Prevents Poor Performance."

More Quotes

Related: