Ken Turbitt Blog
Aidan Lawes Blog
Paul Gostick Blog
Dr Jenny Dugmore Blog
Shirley Lacy Blog
Alim Ozcan Blog
Juan Jimenez Blog
Ian Clayton Blog
Nas Ozcan Blog
Aidan Mills Blog

The General Data Protection Regulation Benchmarking Survey
How are organisations facing the challenge of complying with the most radical overhaul of data protection laws in a generation?...

Ten Strategic Technology Trends for Government
Technologies that enable new service models for digital government must be at the top of the list for government organizations as they prioritize technology investments...


The Robots are Coming: Are CEOs Ready for the Era of Automation?
CEOs agree that robotics is going to make their companies more efficient, with 94% of those who've already adopted robotics saying that it's increased productivity in their business...


The 2015 Chief Digital Officer Study
More companies are appointing a Chief Digital Officer to join their C-suite - but are they doing it quickly enough?...


18th Annual Global CEO Survey
The United States has overtaken China as top target for growth for the first time in five years...

20 December 2010 | Juan Jimenez Blog
Send to a colleague | Add to MY ITP

Standard Changes Are Anything But Standard
This week Juan looks at the common issues that organizations face when dealing with the Change Management process...

  Juan Jimenez

The concept of the Standard Change is in my opinion one of the outstanding points of the ITIL® presentation of Change Management (CM) best practices. In just about every organization that has approached me for guidance on CM, one of the most common issues is the perception of the staff that the process is a bureaucratic hindrance to operational efficiency and effectiveness.

The Standard Change is a great tool to help mitigate this perception because it allows the Change Manager to issue pre-approvals for changes that are well-documented, well-defined, low risk and low cost.

The problem with the concept, however, is that once the IT staff find out they can get pre-approvals for Requests for Change, they flood the Change Manager with requests to assign Standard Change status for everything they think should be classified as such.

This presents the Change Manager with a Catch-22 situation. Many of these requests will obviously qualify for Standard Change status. Many will not. But the vast majority will lie squarely in that nebulous grey area where the Change Manager will have doubts, but knows that if he/she turns these down the CM process will be confirmed as a bureaucratic boondoggle.

In thinking about how to address this situation, I came to the conclusion that something else is needed that is not covered in the ITIL core guidance. To address doubt, the solution is to assign expiration dates to the Standard Changes.

Here’s how it would work. Each Standard Change has to be reviewed in the CM process. If the result of the evaluation is that the situation the Standard Change will address is very low risk, such as a password change, then the request is granted with no expiration date.

If the result of the evaluation is that the change will be high risk, or high cost (which usually translates to high risk) then the request is denied.

However, what if the result of the evaluation is somewhere in between? There is doubt, but not enough to warrant an outright rejection? In that case, the request should be granted with an expiration date. The higher the doubt, the shorter the expiration date.

The requester would then be told that the Standard Change has been granted, but only for X number of days or weeks. Between now and then, the Standard Change can be used when the situation arises that calls for it. Once the Standard Change expires, it can no longer be used, and X number of days later – I suggest one week as a default – the Change Manager will convene a meeting with the requester of the Standard Change to review all instances in which it was used. (This can also be included as agenda items in regular Change Advisory Board meetings.) The idea is to determine the number of times the Standard Change was invoked, the number of times it was successful and the number of times it failed. The information will then provide you, through a simple calculation, the rate of success for the Standard Change.

Once the information has been reviewed and the success rate is calculated, a decision needs to be made as to whether the Standard Change should receive an extension or be canceled. My default for the minimum success rate a Standard Change must produce in order to receive an extension is 90%. Anything at or above that gets an extension or permanent approval status, depending on how many reviews have been performed. Anything below 90% but above 75% means the Standard Change is reviewed to see if the reasons for the failures can be mitigated by modifying the authorized process for the change. If so, the Change Model is modified and another opportunity is given with the same period of validity. If the success rate is below 75% the submitter is informed the change is not reliable enough to receive an extension and will have to be handled through the Normal Change process.

Obviously, you can adjust as you see fit. The percentages I mention above are my preferences, but they are only suggestions. Only you can determine your levels of comfort for something like this. You get the idea, no?

As always, the point of my blogs is to get readers to think, rather than provide ready-made answers, because I will be the first to admit I do not always have them.

Feedback on my blog entries is always welcome!


28th December 2010

Sounds like sensible fine-tuning to me.

But wouldn't it be better to review the standard change depending on the rate of usage, rather than a fixed time period? Something that is used 365 times a year probably needs to be reviewed fairly soon; something that is used once a year probably doesn't need to be a standard change after all.

Jack Whittaker


31st December 2010

Hi Jack,

A Standard Change request should include enough information for the Change Manager and Change Advisory Board to review the request and give it proper consideration. The requester should include all relevant information to justify the request, including the historical and expected rate of usage, as you very correctly point out. That said, how you decide on the timing of the review is up you. If you wish to set the review timing on the basis of usage as opposed to a calendar period, that's fine. The important thing is for you to feel comfortable with the decision, and that boils down to evaluating and mitigating the risk.

Juan Jiménez


(ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.)


Juan Jimenez Email to a colleague | Add to MY ITP

terms & conditions