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 - Please Help me Understand - Authorizing the Change
Joined: Jun 02, 2009 Posts: 4 Location: Indianapolis, IN
Posted: Fri Jul 16, 2010 10:44 pm Post subject: Please Help me Understand - Authorizing the Change
4.2.6.2 Create and Record the Request for Change
4.2.6.3 Review the Request for Change
4.2.6.4 Asses and Evaluate the Change
4.2.6.5 Authorizing the Change
4.2.6.6 Coordinating change implementation
4.2.6.7 Review and close the change record
The problem that I am having: if the change involves a enterprise wide software development effort then there are two situations (at a minimum) to assess. The first is changes to customized software. The second is the implementation.
The two may be months apart. So my problem is, based on 13 years of experience in the software industry, it is impractical to pretend that the assessment of the customization and the assessment of the rollout can happen at the same time.
So I suggested to my Manager that, upon completion of the software development process, the RFC should move back through change management (back to 4.2.6.2) for release.
He was a bit upset with that idea.
However, letting the software rollout without a complete evaluation of the impact by a CAB (4.2.6.4) places us at a higher level or risk.
Joined: Sep 16, 2006 Posts: 3597 Location: London, UK
Posted: Fri Jul 16, 2010 11:18 pm Post subject:
rmlx
you need to separate the sdlc process from the change / release process
once the solution / package has been developed by the developers - and then the CM for deployment starts
This may include test deployments before the approval, etc - which maybe part of evaluation section _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Sep 16, 2006 Posts: 3597 Location: London, UK
Posted: Sat Jul 17, 2010 1:54 am Post subject:
rmlx
what i said is that the software development process - whether for in house apps or what ever is outside of Change Management
CM is ultimately concerned with the protections of the production environment
therefore it exists to manage / control / vett any work that will change production - to include software deployments
The CM process has input feeds and output feeds
please look through the threads in the cm forum for more details - you can even search for mine _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sun Jul 18, 2010 6:23 pm Post subject: Re: RFCs
rlmx wrote:
So a change to an in-house, custom software package is not a valid topic for an RFC?
Correct.
Except for bug fixing (response to incidents).
And except for the special case where the software package in question is part of the service delivery process because then the request for change will have been a request to modify service delivery rather than the functionality of the delivered application service.
Even in these cases, change management does not need to take a hand beyond validating the specified requirement.
actually, as I write this, I come to the conclusion that the answer is that it depends on the relationship with the customer. If all service requirements are managed through the Service Management function, then even application change requests to a third party will be controlled in this way.
However, developing software does not impinge on service. Implementing it does. So the validation of the change in functionality would be passed to the applications development and support function and the implementation would be under ITSM change management. Thus, it is not a case of doing the same thing twice. The first is done largely by a consultation between customer and developer (although the developer has to look to service delivery with respect to performance, capacity and scheduling implications for example). The second is done by consultation between service management, customers and applications support under the firm gaze of the change manager.
It's Sunday. I'm rambling again. Still, I've written it now. You may as well suffer. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
