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

Digital Health Technology Vision 2018
Health organizations are embracing intelligent technologies but must do more to prepare for societal impact...

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...

2 August 2011 | Juan Jimenez Blog
Send to a colleague | Add to MY ITP

Can a Process be as Polymorphic as an Object?
This week Juan explains how one of the processes in the new 2011 edition of ITIL v3 is also a polymorphic process...

  Juan Jimenez

One of the basic concepts anyone who wants to learn object oriented programming must master is that of polymorphism. Essentially, it means that an object can be told to behave in different ways depending on how it is invoked.

For example, polymorphism allows me to create an object named “AnimalSpeaks” which can receive different types and number of arguments. I then create two more objects called “Cat” and “Dog” and, through polymorphism, tell the AnimalSpeaks object that if it receives a “Cat” as its input, it should make a meowing noise, and if it receives a “Dog” object, it should bark.

This concept differs from the definition of traditional arguments in that they can vary in form and quantity. For example, the AnimalSpeaks object could be invoked with breed type of cat in one form, and with the number of dogs and whether or not their tails are wagging in the other. If I wanted to accomplish this in a non-object-oriented language, I would have to use much more complex constructs, types of variables and algorithms to accomplish this. In an object oriented language, it is all taken care of for me in the background. The concept is significantly more technical than that, but for the purposes of this blog, this definition should suffice.

I was recently studying one of the processes in the new 2011 edition of ITIL® v3 and realized that it is a polymorphic process as well. The process is “Change Evaluation,” and as the name implies, it resides in the Service Transition phase and is associated with the Change Management process. In the 2007 edition, this process was named “Evaluation,” and was new to ITIL’s definition of ITSM best practices.

Much of the wording in this process implies that change evaluations occur after a service change has been completed but before the change is formally closed. For example, ST 4.6 (2011) states “Before each authorization the change should be evaluated to ensure that risks have been managed and that predicted and actual performance match the business requirements.” This statement is reinforced in other places in the process definition, and we all know that predicted performance of a service is normally defined in its Service Design Package, but actual performance can only be determined through testing. Unless we are talking about a proof of concept commissioned by management to determine if a proposed service or service change is feasible, this can only be formally accomplished in the Release and Deployment process – after the service change has been built and tested and before it is deployed into the live environment.

As such, it is quite reasonable to reach the conclusion that Change Evaluation is the process to be used for the Post Implementation Review (PIR), right?

As it turns out, this is not the case. The key here is to understand that Change Evaluation should take place “Before each authorization…” The core guidance lists these examples of such authorization points:

  • Before service design activity takes place
  • After service design is complete to authorize check-in of the Service Design Package (SDP) and start of release planning
  • After release planning, to authorize release build and test
  • After release build and test to authorize check-in of the release package to the Definitive Media Library
  • Before each deployment, to authorize the deployment
  • After deployment to authorize activating the release in the target environment
  • Before closure of the change to accept the final configuration

As you can see, the only bullet point on this list that could be interpreted as the PIR is the last one. In fact, some of the bullet points fall entirely outside of the Service Transition phase. If the change evaluation is being performed “Before service design activity takes place” that implies the service is still in the conceptual stage and in the Service Strategy phase, and validation of the feasibility of strategic goals is what is being sought. Because the service is still conceptual, the evaluation is also conceptual, and will most likely involve an analysis to determine if the predicted performance can be designed, constructed, tested and deployed successfully to the production environment, and ultimately to the customer.

That is but one example of the polymorphic nature of the Change Evaluation process. Other possibilities involve what can be described as a sanity check of the SDP before the service is prepared for release. Further applications of Change Evaluation are performed along the same lines at other key points in the lifecycle of the service as it moves towards deployment, essentially functioning as key review points to ensure the work has not strayed from the customer’s definition of value for this particular service. The reason the Change Evaluation process is polymorphic is that the activities, procedures, work instructions, key metrics and critical success factors can change on the basis of the inputs to the process and where in the Service Lifecycle it is invoked.

Think about it… how many times has a project to introduce a new or modified version of a service fails because what is finally delivered is not what the customer asked for? If you have been there and done that, all of this makes perfect sense.

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!  


17th August 2011

Hi Juan ,

I think your blog posts are great.  They always make me think.  Thanks for sharing on the ITIL 2011 stuff.  Haven’t seen any of it yet.

I own the change process.  The whole process is polymorphic depending on which team is running the change.  And release just about makes me crazy.  I appreciate the analogy.  What are the parameters to the process and how does that affect the activities required to make it to the other side successfully.

Jennifer Rice


(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