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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ubyfevu
New Today: 31
New Yesterday: 34
Overall: 231603

People Online:
Visitors: 129
Members: 1
Total: 130 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Software deployments as changes
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Software deployments as changes

Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message

Joined: Oct 15, 2012
Posts: 1

PostPosted: Tue Oct 16, 2012 1:36 am    Post subject: Software deployments as changes Reply with quote

Hi all, hoping for a bit of advice Smile

So, we are looking to amend our process to bring Software deployments under the change process. At the moment, we have a very distinct dichotomy - Change for infrastructure - release for software. This goes back to before my time here.

In my opinion, Software changes is a type of change like all others - and thus should be a part of a planned release (but as an approved change).

We are changing a large amount of software every day, with very quick turnaround, and as things stand, i cant possibly see how software could realistically be subject to the same change process to allow the speed of turnaround required by the customer.

Does anyone have any experience with this - i.e. how software changes are assessed, and how you have avoided massively slowing down the required release velocity by over-assessing the component changes.
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Tue Oct 16, 2012 2:11 am    Post subject: Reply with quote

Without prejudice as to the nature of "changing a large amount of software every day", you must always design your change process to meet all your requirements, including timescales, authorisation, documentation, testing, validation verification, regression planning and so on. It should be easy to make things like authorizarion, verification and regression palnning very slick with that kind of frequency. With the rest it is down to balancing risk against benefit and that is what you need to agree with your customer(s).

Some of the areas you have to accomodate are:

errors in released code
errors in the release process
changes not delivering the desired benefit
changes impacting on other services and systems
changes that require an environment change (e.g. additional OS patch - with its impact on other systems)
changes that affect capacity or performance
impact on other planned changes

This is not complete by any means, but it is a good bit of what you have to design into an expeditious change process - or any change process for that matter.

The answer to your last sentence is that you do not over-assess component changes, you appropriately assess them and you define what is appropriate. There is nothing heavyweight about change management; it is always about doing things the right way for your requirements. It is all about protecting the stability and integrity of the service environment, the services [and the change manager] and managing the risks.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management 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

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.