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
188.8.131.52 Create and Record the Request for Change
184.108.40.206 Review the Request for Change
220.127.116.11 Asses and Evaluate the Change
18.104.22.168 Authorizing the Change
22.214.171.124 Coordinating change implementation
126.96.36.199 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 188.8.131.52) 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 (184.108.40.206) places us at a higher level or risk.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sun Jul 18, 2010 6:23 pm Post subject: Re: RFCs
So a change to an in-house, custom software package is not a valid topic for an RFC?
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