Where does an RFC come from and go.

[Flipper]

We are having a disagreement concerning which process provides initial input to whom between Change Management and Release Management. From a Release Management perspective I say that we receive an RFC from Change Management as input and that starts our process. Change Management disagrees stating that the RFC comes from somewhere else to Release Management and Release Management submits a RFC to Change Management. Who is right?

[mrcasal]

well, I think that RFC came from:

a/customer. He ask for some change in the infrastructure, in order to improve the business indicators.

b/problem management. Once you've identified and fixed a problem, you have you have to use a RFC, in order to solve the problem into the live enviroment.

RFC must be managed with change management process, once the RFC get the CAB approval, the release management have to deal with the RFC, overall in order to update the CMDB.

[blackbeard]

RFC's should be able to come from anywhere in the business, they would then go to the change manager for reviewing, filtering, prioritising and submission to the CAB. Only once the CAB have given approval would they then go to Release Management or out to a Project Team to move on to the Test and Build phases.

[rjp]

It helps to think of an RFC as something that has varying levels of definition and clarity at its inception, depending on where it is raised.

As an output of Problem Management and RFC will be quite well defined, it will specify a change that has been identified as a solution to an error or other type of problem. An RFC may also be a request for new features, tachnolgies or processes coming from and end user or customer. At the point it is raised it would likely be unsuitable for direct input into the Change Management process - it may need to be coordinated with the development cycle of an application, or assessed against the budget, and the current IT plan. A service level management team would work with key technical staff to scope, and cost the change in negotiation with the customer.

Once it has been 'firmed' up it would go to a CAB for approval.

Of course some 'RFC' are trivial in that they are really Service Requests, or a like for like - ie replacing a failed CI with exatly the same - these are usually 'pre-approved' and implemented immediately - though it is critiacl that Change Management tracks them and ensures that Configuration Management process record the activity.

So change management identifies, defines, assesses and approves changes. That means in practical terms it identifies, defines, assesses and approves RFC - it doesn't 'change' anything. That's an 'operational' activity.

But there are usually a lot of related changes going on all the time - some based on RFC, but many based on project to continually develop the infrastructure, as well as application development for major services.

These changes have to be continually managed in a continual deployment cycle where the disruptions, dependencies, impacts, resource allocations etc are efficiently balanced - enter release management, which plans and coordinates the deployment of changes as a cycle of releases, which will include the testing, accpetance, rollback, etc plans and activities.

So release management doesn't take RFCs per-se as it's inputs - by the time they get to Release management they should really be called just 'changes' or perhaps 'approved' or 'planned' changes.

Depending on how the realtionship between production and development is set up, release management would be accepting 'changes' from the development cycle - but these would have had CAB involvment anyway, so would still be going from change to release management.

It is however a little counter-intuitive that 'change management' doesn't actually 'change' things

[blamblam]

Ok... my two cents worth...

For Release scheduling and implementation, the only input into and out of Release Management is Change Management, in the form of approved RFC's.

[Ian]