Most of you have experienced a situation where a service is released, and then a lot of time is spent on fulfilling “details” of customer requirements or issues related to internal organization. For example: are all users informed about the new functionality, are they trained to use the new service, are all Configuration Items (CIs) identified and entered into the Configuration Management System, are all customer requirements met and tested… etc.
It sounds like a lot of potential for a mess, doesn’t it? There are two documents that could help you avoid this mess: Service Level Requirements and Service Acceptance Criteria. For the time being, I will focus on the latter.
ITIL defines Service Acceptance Criteria (SAC) as “A set of criteria used to ensure that an IT service meets its functionality and quality requirements and that the IT service provider is ready to operate the new IT service when it has been deployed.” (ITIL Service Design volume)
Why do we need something like SAC? As a service provider, we need to ensure that:
So, we need to ensure that in order for us to provide a service, certain requirements must be met. Which requirements? That depends on the service and service provider, but let me give you few examples so that you get the idea:
You may have noticed a question mark at the end of each sentence. Yes, the SAC act like a checklist. Such a checklist has to ensure that we (as a service provider) are ready to deliver a new service (as required, i.e., agreed on with the customer).
The next logical question is: “Who owns the SAC?” That also depends on your organization’s setup; but, if we stick to ITIL, that would be the Design Coordination Manager, or, as I experienced, some organizations have a Service Design Manager. Such roles are involved in the early stages of the service lifecycle and have strong ties with the strategy and transition phase of the service lifecycle, so they are in excellent position to control the build-up of the SAC.
The SAC is one of the documents that “live” throughout the service lifecycle. Namely, the SAC needs to encompass all necessary steps needed for an IT service to be deployed and operated. In order that we get to the operational stage of the service lifecycle, many processes are involved and contribute to the success of the service implementation. Each of those services must be included in the SAC as well. For example, Service Asset and Configuration Management (SACM) defines Configuration Items and the place where software media will be stored (i.e., DML – Definitive Media Library). The entry in the SAC could be “Are all software media present? IS DML defined and in place (in case that physical storage is needed)?” etc.
The SAC is related to two other documents: Service Level Requirements (SLR) and Service Design Package (SDP). The SLR will provide the criteria needed to say “Yes, now we fulfill all customer requirements,” and changes in the SLR will impact the SAC (e.g., the requirement regarding number of transactions that a database should support increases dramatically – that is a requirement to change a technical solution, which requires more hardware and licenses, so the SAC needs to be updated due to these new requirements). The SDP details all aspects of the service and its requirements throughout the service lifecycle and, usually, the SAC is a part of the SDP.
Figure: SAC is built throughout the service lifecycle.
For many reasons. Just imagine, as you build the service throughout the service lifecycle, you build the SAC document. At the end of the transition phase there is no need to go back and try to gather all the details that need to be checked, i.e., tested. For one project in the telecommunication area, I was engaged to build an SAC document and prepare customer acceptance tests. It took me several weeks to finish this task. I started from scratch by learning the basics about the service and continued with the business part, i.e., what was agreed on with the customer. Finally, the SAC was finished, the acceptance test ran well, and we didn’t forget anything. Afterwards, I couldn’t help but think: “Couldn’t that be done more efficiently?” A few years later I ran into ITIL, learned about the SAC, and answered my own question.
Branimir is an expert in IT service management (consultancy, training and tools), IT governance (training and consulting), project management and consultancy in IT and telecommunication. He holds the following certificates: ITIL Expert, ISO 20000, ISMS Lead Auditor and PRINCE2.
