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: cazaredubova
New Today: 4
New Yesterday: 74
Overall: 142297

People Online:
Visitors: 63
Members: 2
Total: 65 .

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 - Change, Release and Application Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change, Release and Application Management

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


Joined: Jan 31, 2007
Posts: 9

PostPosted: Thu Sep 17, 2009 9:32 am    Post subject: Change, Release and Application Management Reply with quote

We have just implemented a new Change Management process. Our primary users have been our Infrastructure folks and people who support applications that are in production.

Our Application Development folks now want to know how their Release Management process integrates into this new Change Management process. They use their own process and tools to track requests for enhancements and application bug fixes. When they are ready to start working on a Release, they decide which of these enhancements and bug fixes will be part of the Release and start working on it. When they are ready to go to production, they put in an RFC. This appears to be backwards from the way that ITIL defines Change Management and Release Management.

To apply ITIL processes to our Application Development model, it seems that each request for enhancement would be an RFC. The bugs would be Known Errors that are documented by the Problem Management process, and presumably RFCs would be raised for these as well. The RFCs would be individually reviewed, approved/denied and eventually bundled into a Release.

The Release then goes through the approval steps and eventually implements all of the RFCs in the Release bundle.

Am I on the right track? This would mean that the backlog of application enhancements/fixes (prioritizing, analyzing risk, etc.) which is being managed externally to our IT Service Management system would now be RFCs managed by the Change Management process. Is this even practical?
Back to top
View user's profile
DYbeach
Senior Itiler


Joined: May 25, 2008
Posts: 413
Location: Sydney, Australia

PostPosted: Thu Sep 17, 2009 10:17 am    Post subject: Reply with quote

You can do that, but in reality the result could be many RFCs for the one release, which is overkill imho.
If you have access to the V2 or V3 texts on release management, why don't you revise the sections on release management.

My personal approach is to have 1 RFC for a release package
_________________
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell
Back to top
View user's profile Send e-mail
editil
Newbie
Newbie


Joined: Sep 15, 2009
Posts: 1

PostPosted: Thu Sep 17, 2009 7:26 pm    Post subject: Reply with quote

I recognize myself in what cdugas writes.

We also have the development people working with requirements, in their own tool, and another tool and process for implementing what has been developed into our different environments. I'm struggling with how to fit these two parts together to have a continuous process.

I'm also confused about when the CAB is actually supposed to make their decision and what their decision should be about. Today, we have one forum making decisions on which requirements to accept and develop for each product. The CAB comes in just before the implementation into the production environment, and can only advise on whether the planned implementation dates seem suitable.

Does anyone have any advice on how to pull it all together, to have the change process cover the whole chain and the CAB come in at the correct time?
Back to top
View user's profile
cdugas
Newbie
Newbie


Joined: Jan 31, 2007
Posts: 9

PostPosted: Fri Sep 18, 2009 12:38 am    Post subject: Isn't a release a budle or batch of related sets of Changes? Reply with quote

Thanks for your reply DYbeach. Your statement that many RFCs for one release is overkill seems to contradict the V2 text.
V2 states: "Release Management should be used for: ...bundling or batching related sets of Changes into manageable-sized units." Also it states: "the term Release is used to describe a collection of authorized Changes to an IT service. A Release is defined by the RFCs that it implements."
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Sep 18, 2009 1:39 am    Post subject: Reply with quote

cdugas

Release is the method for deploying a change into an environment
Change is the control method for allowing releases into the environment

If you are going to nitpick out of the book. please look at the section on ful package, Delta release pacakge

if the change request is for a microsoft W2k3 server update (service pack)
and there are 200 individual patches to install as a package

One change request for one release package is good enough. I dont want to raise 200 RFCs for each patch

ITIL is not a BIBLE or exact standard. It is a guideline and you have to be pragmatic about the process

To coin a phrase - dont spend a dollar chasing a penny
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Jan 31, 2007
Posts: 9

PostPosted: Fri Sep 18, 2009 3:05 am    Post subject: Reply with quote

Sorry if I offended. I wasn't trying to nitpick, just trying to understand. The reason it's confusing to me is that I see 2 different groups of changes.

1. The changes (enhancements) that are initiated by end users or customers of a service that are bundled into Releases and implemented by our App Dev. Are these submitted as RFCs?

2. The changes to infrastructure that are initiated by vendors (in your example - Microsoft) that comes to us as an already-defined Release that is implemented by our Infrastructure team. I agree that a single RFC for this type of release is the way to go.

I'm trying to use the same process to manage both types of changes. Maybe that's my mistake.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Sep 18, 2009 4:30 am    Post subject: Reply with quote

No you were not beign offensive at all. You were asking the right questions

Change Management is a discipline.

I am the change manager for a EMEA company. I primary control application change management - which has the highest impact - as well as the network and infrastructure areas as well

On the net side.. there are no issues.. open close f/w by changing rules - one change one action

On the application side, I have two feeds for changes - hot fix or defect / patch mgmt and new features..

BOth must filter through the change board.

both are handled by the change in the same way by how the work is going to be deployed into production

A RfC is a Request for Change. It means I want to do something. If I want to fix a couple of existing defects or add 3 new features . The RfC is one Change Request before the Change Board

Key points -
are all the pieces deployed together in a QA/test environment
are all the pieced tested in that environment together
are the pieces going to be deployed together into the production

the together may mean some deployment into an wintel environment, unix or mainframe at the same time or just one piece of work into one sysem

1 change

it may be made up of many pieces of work

Please NOTE I have not said a thing about the tools. Frankly I dont care how your tool works or does not as long as it meets your requirement

so the pragmatic approach is the one I take

I have to see one person present the change - whether it has 50 parts or 1 parts that are direcltly linked to gether as part of a package

the board speaks to one person to ask all the questions and concerns. that person deals with alll of the various teamsand comes back if the board is not satisfied
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Jan 31, 2007
Posts: 9

PostPosted: Fri Sep 18, 2009 6:35 am    Post subject: Reply with quote

OK, got it. So, what process do you use to manage that list of application changes before you submit the RfC? Don't you need a process to prioritize the fixes and enhancement that will become part of the next Release/Change and manage the backlog that is not being actively worked on at this time? Is that Release Management?
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Fri Sep 18, 2009 10:05 am    Post subject: Reply with quote

cdugas wrote:
OK, got it. So, what process do you use to manage that list of application changes before you submit the RfC? Don't you need a process to prioritize the fixes and enhancement that will become part of the next Release/Change and manage the backlog that is not being actively worked on at this time? Is that Release Management?


1. IMHO I would say there is no particular process for list of application changes. What we do in our company is that when an application is ready for deployment (from the Project's perspective), the Project Manager will consult the Change Manager for bundling, pre-CAB matters, etc.

2. The process to prioritize fixes and enhancements would definitely be within the scope of Change Management Process, as stated in the handbook.

3. I found out that Release Management in V2 is different from V3. I couldn't tell if the differences are significant or just slightly.
F.e. in V2, it is said that one of RM usage is for "bundling or batching related sets of Changes into manageable-sized units", while in V3 this point is not mentioned (sorry if i'm mistaken. Made a quick search and failed to find it).
Another difference is that in V2, RM is part or under control of Change Management Process. RM starts with approved RFCs. It didn't mention that RM can raise RFC for bundled approved RFCs. In V3, this happens.
So, as usually stated, it would depend on how you build your release management process. How it works, how this and that ..
After all, it is a matter of commitment, right?

Hope this helps.

Cheers,
Asril
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Sep 18, 2009 4:10 pm    Post subject: Reply with quote

cdugas

to be honest... the defect mgmt process does the classificationof the defects and the timeline for devel;oping the solution

the controls - testing in non prod, sign off - help determine whether the board will approve

the operations / support side determines the priority / severity / urgency of the change

the ops support determines the urgency of the defects/hot fixs
the project / application developement determines the urgency of service enhancements

note: and the board is made up of ops people - mgmt
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Sep 18, 2009 4:46 pm    Post subject: Reply with quote

UKVIKING wrote:


note: and the board is made up of ops people - mgmt


Just to add to what John is saying, - I would insert 'mainly' between 'is' and 'made'. Don't forget that interested parties like Project Managers could be included in the CAB and therefore the discussion as Business pressures could well have a bearing on whether a change is approved or not.
_________________
Regards

Ed
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Sep 18, 2009 5:47 pm    Post subject: Reply with quote

Ed 's absolutely correct

The ulitmate arbitery is the business owner / management

If they want something in - it will get in - as long as process and procedure is followed

the Project mgrs would do the mom / dad routine with the business owners and the ops support owners

What happens then is the cm processs is there to minimize the damage / outages caused by poorly planned implementation

not that this ever happens IRL/the RW
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Jan 31, 2007
Posts: 9

PostPosted: Sat Sep 19, 2009 3:29 am    Post subject: Reply with quote

Thanks everyone for your input. It sounds like application/product enhancement projects are typically managed outside the ITIL change/release processes, so we'll need to work with those folks on developing their own process.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Sat Sep 19, 2009 4:05 am    Post subject: Reply with quote

cdugas

YES!! and no. The only discipline ITIL wise is Release management

u should use RM to manage the deployment of the final development package into the test environment. Which should be under the control of the RM process

the dev environment should managed ligtly by RM

the o/s and patch level and the core versions of the application should come from prod --> test to dev
so that dev is always working on the latest version of prod to duplicate the errors/faults with the applciation and try to fix them

CMMi and other S/W development lifecylces come to mind
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
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.