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: FFrame
New Today: 6
New Yesterday: 50
Overall: 146269

People Online:
Visitors: 55
Members: 1
Total: 56 .

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 - Bundling change requests
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bundling change requests

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


Joined: Jun 06, 2010
Posts: 10
Location: Canada

PostPosted: Tue Jan 18, 2011 7:04 am    Post subject: Bundling change requests Reply with quote

Hi everyone,

I'm in charge of change management at our company and have been approached by a project lead regarding a high visibility project our company is working on. The project has been delayed a few times and so far it seems the potential go live date is in May. Through the project life cycle there have been change requests, but now that they are approaching the end they are expecting another 50-100 change requests to be submitted. He is wondering if changes can be bundled together or if each individual change should be a separate RFC (maybe up to 100). We have never done it this way before and I wanted to get an idea of how others have handled a situation like this. As mentioned earlier, this is a high visibility project and is important for our organisation and the service we provide to our customers. Also, whichever way you guys have handled it - how is the communication aspect of it handled (with business units, CAB, other people in the org)?

Thanks!
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Mon Mar 07, 2011 10:31 pm    Post subject: Reply with quote

Dunno if you had any input on this one from elsewhere?

Let me guess that this is some kind of software development project you are in.

I can easily appreciate 100 changes from here and there being necessary.
It would be extremely easy to bundle them, just for the sake of less paperwork.

But: different changes will have different owners, implications (i e risks and benefits), and may or may not be practical/economical or even possible.
WOuld you throw out the whole bundle if ONE change was rejected?

Try to see it differently. Ideally, each change should live its own life.
The best you could do to reduce "traffic" is to bundle them into sub-RFCs, grouped by originator, affected part of the system, cost, ease of implementation (minor/major change) or whatever is most applicable for you.

Or make some of these changes "pre-approved". If you (and the CAB) trust the skills of the project developers that would be no issue. The developers need to document every detail, of course, and provide a rollback possibility.

Most changes in e g a web project are smallish issues that can easily be made "pre-approved".

Concentrate on changes that have large costs, major impact or other significant issues. Treat those on a one-by-one basis.

(The CAB for each of the major changes would probably be different, BTW.
Of course, business bean counters need to be involved in most of these cases, and naturally the project mgmt. I have no ideas about the specifics in your place, these are just general ideas that I would stick to in my place, to simplify matters somewhat.)
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Mon Mar 07, 2011 11:28 pm    Post subject: Reply with quote

This sounds like a release - go speak to your Release Manager.......better still, take the PM with you and they can explain why they're circumventing the Release Management process
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Tue Mar 08, 2011 6:05 pm    Post subject: Reply with quote

Boris -

what makes you think its a release, or even worse - a release mgmt bypass?

And in which post, the OP:s or mine?

(s far as I can see, this is just rationalizing and reducing the tsunami of RFCs a bit, in order to get them through the CM door to begin with, making the flow manageable.)

/R
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Tue Mar 08, 2011 6:54 pm    Post subject: Reply with quote

All

The issue here is NOT Change management per se. The Chaneg manageemnt should be invoked once the project - application, nw versione tc gets released into Production. Until then, it is a project and does not need to follow ITIL BP guidelines. ITIL is for services that are being provided to the users / business

All changes to the project needs to be handled within the project

There should have been authorative body that said - this is the product that is to be built. IT has the following features and the following capabilities. and authorize the money

If the new service is a product like an application, then the application will need to first built, then tested in a production like environment, then all faults (Defects) identified, then the faults fixed and then the applciation is retested to see if the faults have been cleared. This will continue until the # of defects that are found in the application are ata an acceptable level by the authoratative body to be deployed to Production with the faults.

This is all about code management and release management


Once the application goes live, then these faults are production defects and must be tested and deployed to production under Chaneg management rules.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Tue Mar 08, 2011 7:53 pm    Post subject: Reply with quote

True. Of course, the project should deliver a complete result/product and submit it as an RFC.

Good thinking, Mr Viking. Good to know that there are heads with a clear view here. Unlike mine Smile

/R
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Wed Mar 09, 2011 2:30 am    Post subject: Reply with quote

Bluesman wrote:
Boris -

what makes you think its a release, or even worse - a release mgmt bypass?

And in which post, the OP:s or mine?

(s far as I can see, this is just rationalizing and reducing the tsunami of RFCs a bit, in order to get them through the CM door to begin with, making the flow manageable.)

/R


I was reading this as 50-100 changes all as part of the same project - sounds like a release but more details are perhaps needed
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Wed Mar 09, 2011 3:09 am    Post subject: Reply with quote

I too read this a 100 changes to a release / ie Project changes rather than produciton changes
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Hena
Newbie
Newbie


Joined: Jun 06, 2010
Posts: 10
Location: Canada

PostPosted: Wed Mar 09, 2011 4:08 am    Post subject: Reply with quote

It's a brand new application being built by the project. It is going to be our critical app as it will be our customer and billing system. The reason why we will have so many RFCs is because it will have many touch points with current systems (which will either be fully or partially replaced by the new CIS).

The PM wanted me to have a special CAB meeting for the project where all the proposed changes were listed in the meeting (and not as formal RFCs) and the stakeholders would be there and give the approval. I was not in favour of that.

I'm borrowing some ideas from release management and can see some changes get bundled together as release packages:
- changes to same service/ CI can be bundled together only if they have tested successfully
- We will have a limit as to how many changes are bundled as a package
- If a package fails, only the part that failed needs to be rolled back, not all changes that were bundled together (unless there are dependencies)
- Sign-offs as per normal process
- Regular RFC that outlines procedures, risk etc.

This will reduce the number of RFCs that must be created, but the changes must still be documented and approved by all parties before approval from CAB.
Back to top
View user's profile
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Thu Mar 17, 2011 10:10 pm    Post subject: Reply with quote

Hena wrote:
It's a brand new application being built by the project. It is going to be our critical app as it will be our customer and billing system. The reason why we will have so many RFCs is because it will have many touch points with current systems (which will either be fully or partially replaced by the new CIS).

The PM wanted me to have a special CAB meeting for the project where all the proposed changes were listed in the meeting (and not as formal RFCs) and the stakeholders would be there and give the approval. I was not in favour of that.

I'm borrowing some ideas from release management and can see some changes get bundled together as release packages:
- changes to same service/ CI can be bundled together only if they have tested successfully
- We will have a limit as to how many changes are bundled as a package
- If a package fails, only the part that failed needs to be rolled back, not all changes that were bundled together (unless there are dependencies)
- Sign-offs as per normal process
- Regular RFC that outlines procedures, risk etc.

This will reduce the number of RFCs that must be created, but the changes must still be documented and approved by all parties before approval from CAB.


Still sounds like a release to me - and to get all the approvals from stakeholders on this 'CAB' sounds like a hell of a crappy way to engage stakeholders...........they should all be aware that this is coming down the line already.
Back to top
View user's profile
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 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.