How to implement Standard Changes

By ITIL® from Experience©

ITIL® states that “Standard Changes

(ITIL® Service Transition) 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 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

" should be identified early on when building the Change Management process to promote efficiency. Otherwise, a Change Management implementation can create unnecessary high levels of administration and resistance to the Change Management process.”1

As a result, may organizations start implementing Change Management by pre-authorizing changes even if they are not documented or that the criterion for authorization are not yet defined. This approach is thought to be a win-win. First, it avoids causing authorization delays since simple and frequent Request For Change (RFC) are pre-authorized. It also helps with the adoption of the new process as people feel some form of freedom since some changes can be done without waiting for an authorization. The thinking goes: “If my changes are pre-authorized I have no problem with this Change Management process idea.” The other benefit is that at least changes are being recorded.

The problem with this strategy is that it has a tendency of becoming the norm unless it is made clear to all, right from the start, that this approach will change over time. Therefore, it is important to communicate that each standard change will need to be documented and re-authorized as the process matures. Failure to communicate this expectation at the onset will make it difficult to implement improvements. This also enables the organization to align to ITIL® which states that: “Once the approach to manage standard changes has been agreed, standard change processes and associated change workflows should be developed and communicated. A change model

(ITIL® Service Transition) A repeatable way of dealing with a particular category of change. A change model defines specific agreed steps that will be followed for a change of this category. Change models may be very complex with many steps that require authorization (e.g. major software release) or may be very simple with no requirement for authorization (e.g. password reset).
Source: ITIL® glossary and abbreviations, English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx

would normally be associated with each standard change to ensure consistency of approach.”1 This is nice, but how do you get there?

We recommend that a roadmap meaning “a detailed plan to guide progress toward a goal”2 be identified up front and communicated.

Here is a typical roadmap to implement or to mature standard changes:

Agree that the regular Change Management process will be used to authorize standard changes since at the beginning, the same criterion can usually be used to authorize a normal
(ITIL® Service Transition) A change that is not an emergency change or a standard change. Normal changes follow the defined steps of the change management process.
Source: ITIL® glossary and abbreviations, English, 2011 www.itil-officialsite.com/InternationalActivities/TranslatedGlossaries.aspx
or a standard change.
Prepare a document template for the change. It is our experience that using the concept of the Standard Operating Procedures (SOP)3 greatly helps people understand standard changes (see What is the content of a standard change).
Document the criterion that are, or should be used, to approve a standard change. To make it easier this can be done over a period of time where the Change Manager documents the criterion he/she used to approve each RFC. Over the course of a couple of weeks or a month a good list can usually be produced. The Change Manager should consult CAB members for input to ask them what they assess and evaluate to recommend or not the authorization of RFCs (this consultation helps buy-in!).
Once the evaluation criterions are documented, review the Standard Change document template or SOP to ensure that it provides most of the information to authorize an RFC.
Now that a standard change framework is in place communicate to all stakeholders that the process to request that a change be pre-authorized (aka standard change) is to submit an RFC with a completed template (e.g. SOP)
If the organization pre-authorized standard changes early on, instruct each standard change owner to submit their change through the new process – yes this means that they will need to: a) document their standard changes using the new document format, b) submit an RFC and, c) have it evaluated to see if they are worthy of keeping their designation based on the criterion and new ways of the process.
Consider developing automated workflow for high-volume changes (see How to identify workflows to develop first)
To continuously improve the quality of standard changes, implement a maintenance process so that each standard change is reviewed periodically to comply with the new demands of the change management process (see Why a process to maintain standard changes should be implemented).

With these elements in place the organization has a good foundation to build on since there is a process to evolve the process. Over time, the evaluation criterions to authorize a standard change usually evolve. This can come as a result of situations where a standard change should not have been authorized. Release Management artifacts such as a test plan, test past/fail results and approvals can be included as a condition for authorization.

Eventually, applying to have a change pre-approved should include evidence that it can be “standardized” and be of an acceptable risk. To standardize means: “to bring into conformity with a standard.”4 . Thus, the same change implemented multiple times should yield a predictable outcome meeting a pre-established standard. Thus, an application for a standard change might need to demonstrate that it conforms to the standard by providing statistics on it’s past success and failure rate and incidents it caused before being approved. To reach this level of maturity the organization would benefit from a Quality Management framework.

This is an example of a high-level roadmap. When developing your roadmap ensure that every phase delivers benefits and address pain-points or a challenge faced by the organization. Each step of the roadmap should also be supported by a detailed project plan considering people, process and technology as well as how the newly implemented elements will be governed.

Related:

Category:
ITIL Process > Change Management > Standard Change

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>