Change, Release and Application Management

[cdugas]

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?

[DYbeach]

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

[editil]

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?

[cdugas]

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."

[UKVIKING]

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

[cdugas]

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.

[UKVIKING]

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

[cdugas]

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?

[asrilrm]

[UKVIKING]

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

[Ed]

[UKVIKING]

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

[cdugas]

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.

[UKVIKING]

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