Branimir Valentic 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.
Service Acceptance Criteria
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:
- all customer requirements are met
- we are ready and able to support a service
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:
- Are all service requirements documented and agreed on with the customer?
- Is there a list of test cases that will ensure the customer that all functional requirements are met? Is it agreed on with the customer?
- Are all hardware and software components defined, purchased, and implemented? How about licenses?
- Do we have written agreements (Service Level Agreement (SLA)/Operational Level Agreement (OLA)/Underpinning Contracts (UC)) with all involved parties?
- Is the release and deployment plan present and agreed on?
- Is the end-user documentation ready and distributed?
- Is the go-live date agreed on with all relevant parties?
- Do we have measurement in place (e.g., for SLA purposes)?
- Are internal tests performed and completed successfully?
- Are operational procedures defined and ready? Are all process responsibilities defined and in place?
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).
Lifecycle and ownership
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.
So, why is it important?
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.
You can check out the Service Validation and Testing (SVT) process to learn more about SAC.
