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.
(ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.)