Charged with the nominal responsibility for ensuring that a service change is acceptable, Evaluation extends far beyond a single process performed during a service implementation and checked off on a task-completed list. In fact, it is performed several times, and unlike a checked-off task, it never goes away.

This DITY explores what the Evaluation process is, when to use it, and – most importantly – what to do with the evaluation results.

Evaluation and the Service Transition Phase.

Evaluation is a natural fit with Service Transition. Even ITIL V2 addressed Evaluation – only it did not call it that, preferring the more benign term 'Assessment' within Change Management.

Evaluation wraps around the entire Service Transition phase, but it plays an especially critical role at three points within Service Transition:

Service Design Evaluation – ITIL recommends that the Service Design phase 'borrow' a bit of Service Transition’s evaluation expertise to ensure the effectiveness of the Service Design Package's (SDP) Acceptance criteria.
Release and Deployment – This step evaluates the release and deployment processes prior to release of a service change. In essence, it ensures that these processes will foster an effective deployment.
Acceptance – This is the final step in the Change Management process. Previously known as the Post Implementation Review, this step evaluates the service change against the Service Acceptance Criteria (SAC) prior to closing out the Change Request.

What Goes into an Evaluation?

It is always easy to specify an event that will trigger an evaluation, but by following these rules you can also ensure that it is an effective evaluation:

Start early. This is not really a 'what' rule, but a 'when' rule. Build the evaluation into the Service Design or Change as early as possible.
Different points within the evaluation require different evaluations. One size does not fit all. Change Management's evaluation to decide whether to proceed with a change is far different than Release and Deployment’s evaluation of whether its processes are appropriate for a particular change.
As always, do evaluations in the context of the customer by defining interactions, responsibilities and deliverables.
Define the scope of the evaluation. Be setting boundaries, you can more easily see what other processes and services interact with these boundaries and better understand the scope of both intended and unintended consequences of the change.
Do a risk profile to understand what risks the business must accept as part of the change.
Do a deviation analysis of the differences between the change’s predicted performance and its actual performance.
Qualify the environment and IT infrastructure. Are required elements in place?
Use the Service Validation and Testing Process to validate that changed application or service can go into production.
Recommend the action to take based on the evaluation.
Update the Knowledge Management Database with the results and recommendation. That makes it easier to travel this route in the future.

Now That You're Here, What Do You Do?

As simplistic as it may seem, the Evaluation process can only lead to three possible courses of action, but only the customer can best define how the change's Utility and Warranty levels will lead to the creation of Value to the business.

The possible outcomes are:

Accept the change;
Reject the change;
Require a new change with revised predicted performance

Summary

The objective of the Evaluation process is to build an environment that enables the Customer and IT to make informed decisions about the merit of a service change in the context of its actual vs. projected performance in the IT Service Portfolio.

Evaluation and the Service Transition Phase.

What Goes into an Evaluation?

Now That You're Here, What Do You Do?

Summary

Related programs

Related articles