Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: AYoung
New Today: 0
New Yesterday: 64
Overall: 146093

People Online:
Visitors: 52
Members: 1
Total: 53 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Agile Service Acceptance/Introduction to BAU Support
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Agile Service Acceptance/Introduction to BAU Support

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Service Delivery
View previous topic :: View next topic  
Author Message
Finton
Newbie
Newbie


Joined: Sep 01, 2010
Posts: 2
Location: UK

PostPosted: Wed Sep 01, 2010 8:45 pm    Post subject: Agile Service Acceptance/Introduction to BAU Support Reply with quote

Hello All

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....
Back to top
View user's profile
YorkshirePudding
Newbie
Newbie


Joined: Oct 26, 2009
Posts: 15
Location: Sheffield, UK

PostPosted: Mon Oct 04, 2010 8:02 am    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail Visit poster's website
Caleb
Newbie
Newbie


Joined: May 22, 2014
Posts: 9

PostPosted: Thu May 22, 2014 6:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Service Delivery All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.