Joined: Jul 20, 2006 Posts: 7 Location: East Midlands, UK
Posted: Fri Mar 27, 2009 10:38 pm Post subject: Service Acceptance Criteria
I have just started a new job and have been asked to produce a Service Accetance Criteria for a new Service that the Service Management team need to take on and manage as Business as Usual (BAU). I guess we will need to make sure that all Monitoring is robust, Config items registered, Continuity plans in place etc, but just wondered if anyone had any experience of this type of document? I have done various ITIL related stuff but never actually had to produce an Acceptance Criteria, so any help would be gratefully received!
Joined: Mar 10, 2008 Posts: 401 Location: Sunderland
Posted: Mon Mar 30, 2009 9:13 pm Post subject:
It needs to cover all of the things that you need to be able to effectively manage the service:
* Service Desk Fully briefed and supplied with appropriate information for their knowledge base.
* Defects no more than X amount.
* Demarcation of responsibility for technical groups.
* SLAs, OLAs and UCs signed off and in place.
* Appropriate comms issued to users
* Maintenance schedules in place.
* Operating instructions handed over to Ops Bridge.
The list can go on and on depending on your particular circumstances/requirements which to some extent may be shaped by previous experience of handover into production, often moreso by the bad experiences where the handover was inadequate.
To steal an answer from a fellow correspondent "It depends".
put the thinking hat on. A lot of good information has been provided here. Think about what is needed in order for the service to supported and maintained through out its lifetime.
Ask yourself Who needs What information When and How will they get the information, Make sure that sufficient training and information has been handed over before the service goes live. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Jun 18, 2007 Posts: 10 Location: Adelaide, South Australia
Posted: Thu Apr 15, 2010 10:05 am Post subject:
The SAC should work in line with the project methodology to ensure Functional Requirements and Non Functional Requirements are met during the project lifecycle. Ideally, the project lifecycle will have "gated" stages (such as Requirements, Design, Build, Test, Deploy), these should have their own SAC against them to ensure compliance to the overall engagement model (the interface between the project lifecycle and service delivery).
The SAC should cover people, process and technology for the functional and non-functionals.
The aim of the SAC is to minimise the consequences of IT unavailability to the business by conducting service assurance.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum