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.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - RFC - When to RFC, that is the question
Posted: Wed Feb 07, 2007 5:49 am Post subject: RFC - When to RFC, that is the question
Hello, how do people handle this situation, and this is based on software development.
You have application xyz running in production version 1.0.
An incident is reported (defect), xyz is not displaying a report correctly. Problem Management finds out the root cause and determines there needs to be a programming change in the application xyx 1.0.
Here are my questions:
Do you write up one RFC to state you need to change application xyz 1.0?
If yes, how do you track the promotion of the new version of xyz 1.1 through Dev, Test, Staging, and finally production?
Or does change management just act as gatekeepers and wait for the new version of xyz 1.1 to be deployed into testing, and an RFC is then enered stating why they want to deploy into testing, and then same process up to production?
Joined: Feb 12, 2007 Posts: 27 Location: Minneapolis, MN, USA
Posted: Mon Feb 19, 2007 8:13 am Post subject:
Seems like there is a mix here of Change and Release Management. The RFC is opened once a change is determined to be needed. Change management is responsible for assessing change and making sure it gets all the approvals needed, gets scheduled, gets implemented, and assesses its success or failure. Release management is responsible for overeseeing the different stages of promotion in test environments, testing etc.
At least that's how I see it.
Oh, and 1 request for change may spawn multiple change orders, or child RFCs, or whatever you want to call it, especially if you are tracking changes in your lower environment.
The confusion arises because when ITIl talks about Chnage Mangement it is talking about production only, not SDLC.
The way i handle it is to let development track everything they need to track in their own SDLC tool. The RFC gets raised from the problem, it gets sent to dev, they open a ticket in SDLC, they track everything there with occasional updates to the RFC on status, when the fix is released to prod staging by SDLC the RFC picks it up again for prod implementation.
Automatic synchronisation between Change Management and SDLC tools is unnecessary as there is major translation required between the two systems anyway: one speaks business, the other speaks geek. _________________ The IT Skeptic
see you at itskeptic.org
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