I've been search for ages for info/guidance on Service Acceptance (or as we call it in my company, Service Introduction).

I have been a Change Manager/Service Acceptance Manager for the last 7 years and without doubt, the most troublesome aspect of the role is ensuring that Service Acceptance for major new developments/projects is undertaken by the Project team to allow our Support guys a chance to 'support'...

I have read posts about Service Acceptance criteria and what needs to be covered from SLAs, monitoring, Service Desk training etc etc (all of which we have or had in the past), but where I really struggle is the enforcement of this process.

Our project teams are under constant pressure from Business Stakeholders to deliver quicker and cheaper so things like Service Acceptance tend to fall by the wayside. Coupled with this we have recently moved from a 'Waterfall' delivery approach to an 'Agile' approach (via SCRUM) which means we have even less time to do the necessary handover etc.

Does anyone have any experience of Service Acceptance in agile delivery and if so, how do you ensure that work is done in reduced/fluid/agile timescales? Any ideas, advice or help would be very much appreciated....

Hi Finton – you have my sympathy on this one – you have a major Culture issue to address.

There really should be no difference whatsoever in the Service Acceptance criteria that Projects have to address – be they using Agile, Waterfall or “back of a fag-packet” methodologies. If new Products or Services are being deployed into Live the project must cater for the non-functional Service Management & Systems Management requirements.

The Business & Project focus appears to be totally on Cost & Delivery - with Quality, Supportability, Operability & Maintainability being afterthoughts, or deemed to be “acceptable casualties” in the quest for getting “something” delivered. It would be interesting to understand how happy the Business is with the products/deliverables they finally receive from the project teams.

The Business & Project teams are totally deluding themselves if they think this approach is making them more efficient & cost-effective. There are 3 major issues with this mentality:
1. They are simply passing a significant proportion of the overall project costs away from the project budget and into the BAU/Operations budgets.
2. They are only achieving rapid deployment objectives by blatantly ignoring their responsibilities to incorporate Service Acceptance Criteria requirements in the project lifecycle.
3. They are constraining their ability to deliver more projects, and to meet more Business demands, by tying-up so many key technical resources. Technicians are spending more time fire-fighting issues with poorly deployed projects and therefore are not available to perform revenue-generating project activities.

I suspect that your organisation is pretty clued-up on what it costs them to deliver projects in this fashion i.e. the costs of Design, Build & Test of the Functional requirements (half of the picture).

Just how aware are they of the costs of Deployment and Post-Deployment Support & Operation? I suspect that these are the costs that are picked up by the BAU & Support teams – very convenient for the Project as it makes it look like they are delivering “more-for-less” and can make it look like there is a better ROI being achieved by the project and it’s business case. Smoke & Mirrors.

As a Change Manager you should stick to your guns in requiring the projects to demonstrate that Service Acceptance Criteria have been addressed before there is any possibility of them being granted a Go-Live approval.

In order to combat your unpopularity in taking this stance I would suggest that you do a post-mortem on a particularly poorly implemented project. Gather the facts and publish the “disguised” costs associated with that one project.
Try and put some real values on the actual costs of:
• The Service outages it caused
• The forward-fix costs after it went live (Tools, Training, Procedures, Licences etc.)
• The number of post-live RFC’s raised and processed
• The costs of re-deployment and re-releases to correct inoperability or supportability issues
• The number of man-days spent on post-implementation corrective support
• The number of days of lost project effort – due to fire-fighting
• The number of associated Incidents handled by the Service Desk, and the time spent on them
• Third Party on-going support & maintenance agreement costs

An exercise to calculate the real cost of a failed delivery would be a real eye-opener for many organisations and should provide the justification for investing in a Service Introduction process that mitigates these risks.

A Service Introduction Process should ensure that Project & ITSM teams are working collaboratively throughout both the Project lifecycle & the Service lifecycle stages.
Good Luck._________________Best Regards,
Terry

Currently the situation is different i mean through the learning process of Agile things are quite much necessary to be performed in the right way and this is how it does matter.
If someone keeps it that way surely a certain section will start performing it in a big amount.