Well, ITIL 3 is an ancillary requirement, but that's kind of moot, since according to our ITIL guy, who actually writes the ITIL policies and proofs the books and holds every cert there is, BMC did not construct this in an ITIL v2 or v3-compliant way. He says that Change should be the overarching app, and that Release should be able to act as either a peer or subordinate entity to Change. When he explained why to me, I have to admit that it made sense. I think it may be that Change --> Task relationship, with which we are all very familiar over several years/versions, has become too deeply ingrained in our minds as an inseparable combination, and we have to open our minds to the idea of doing things another way that doesn't use that structure.
With all respect and appreciation to Chris and the quotes he gave taking the opposing POV, it seems that BMC kind of took the lazy way out when they gave us Release, in that they didn't want to upset the CM/Task application combination, so rather than put Release in the middle where it belongs, they put it on top. So now we have to tell our customers that they can modify the tool, modify their process, or accept the limitations of living in the middle. Rick On Mon, Jul 26, 2010 at 12:15 PM, Guillaume Rheault <[email protected]>wrote: > ** > The way I would phrase it like this: Release Mgmt is the controlling > application of Change Mgmt > One benefit of using the release module is that you can have activities > that do not require approvals; example of activities could be training, > development of documentation, sending out communications, etc. > > Using the release module allows you to take advantage of the release app > permissions, such as release viewer, release user, release master, and > release configurator. > You can have different reports specifically targeted for releases > > Think of the release module as a sort of project mgmt module built on ARS, > with approvals, with access to the change records, etc. > > The other benefit would be to be compliant with ITIL v3, which may or may > not be a big deal... it would be a bigger deal if your client wants to > implement ITIL v3 as part of its program to improve its internal processes. > > Guillaume > > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [ > [email protected]] on behalf of Rick Cook [[email protected]] > *Sent:* Monday, July 26, 2010 12:03 PM > > *To:* [email protected] > *Subject:* Re: Change Management question > > ** So the question boils down to this - please correct me if I'm wrong: > > > If Change is being implemented to act as the master application to Release, > what does that bring to the table functionally that using multiple levels of > Change by itself doesn't do better? > > Rick > > On Mon, Jul 26, 2010 at 11:39 AM, Guillaume Rheault > <[email protected]>wrote: > >> ** >> I guess the problem relies on the fact that in ITIL v2 Release Mgmt was >> below Change Mgmt, and in ITIL v3 it's the other way around.... >> I would have to verify this in ITIL v2 literature, which in my case is >> somewhere gathering dust :-) >> >> On the web, I found this quite interesting: >> >> http://www.itlibrary.org/index.php?page=Release_Management >> >> Release Mgmt mission statement: >> >> "Implement changes to IT services taking a holistic (people, process, >> technology) view which considers all aspects of a change including planning, >> designing, building, testing, training, communications and deployment >> activities." >> >> http://www.itlibrary.org/index.php?page=Change_Management >> >> Change Mgmt mission statement: >> >> "Coordinate and control all changes to IT services to minimize adverse >> impacts of those changes to business operations and the users of IT >> services." >> >> So in this sense, BMC has adopted the proper naming of the module, i.e. >> Release Mgmt. Still, I would have preferred something like Change Project >> Mgmt, since that immediately denotes a function/process that has a >> controlling/managing nature....and implementors would not have to butt heads >> with ITIL v2 experts out there, on terminology. >> >> Guillaume >> >> ------------------------------ >> *From:* Action Request System discussion list(ARSList) [ >> [email protected]] on behalf of Rick Cook [[email protected]] >> *Sent:* Monday, July 26, 2010 11:30 AM >> >> *To:* [email protected] >> *Subject:* Re: Change Management question >> >> ** So you guys can imagine my dilemma - I have one group of very >> experienced, respected and trained people (you guys) telling me something >> that is 180 degrees apart from what another group of experienced, respected, >> and trained people (my ITIL experts) are telling me. And how the tool is >> set up, although it supports what you guys are saying, is deemed to be >> somewhat irrelevant by the other guys. >> >> >> Welcome to ITIL, huh? >> >> Rick >> >> On Mon, Jul 26, 2010 at 11:06 AM, strauss <[email protected]> wrote: >> >>> ** >>> >>> As near as I can tell, Change Management is the process for continuous >>> improvement (or evolution) through corrective changes to a service, and >>> works at the component level of the services (CIs, assets, processes). >>> Release and Deployment Management is more the process for quality assurance >>> of all existing and planned services - with a more strategic approach. >>> >>> >>> >>> A few quotes from references on Change and Release Management might help, >>> since the ITIL v3 diagrams and texts generally seem to place Change >>> Management and Release Management adjacent to each other under Service >>> Transition: >>> >>> >>> >>> Van Bon, Jan, ed. Foundations of IT Service Management Based on ITIL V3 >>> (2007): >>> >>> “Changes can be bundled into a release.” P.238. >>> >>> >>> >>> Klosterboer, Larry, Implementing ITIL Change and Release Management >>> (2009): >>> >>> “Release management is like an orchestra conductor, and change management >>> is like the musicians.” P.6 >>> >>> “Change management provides a disciplined approach to implementing IT >>> changes. Decommissioning a service, upgrading an infrastructure component, >>> and adopting a new delivery process are all examples of changes that should >>> be tracked by the change management discipline. Each change is considered >>> in isolation and flows through a set of steps, including identification, >>> documentation, assessment, authorization, execution, and evaluation.” P.6-7. >>> >>> “Release management provides a strategic approach to implementing an IT >>> service.” P.7. >>> >>> “…an IT service is a set of components and service assets that work >>> together to provide a unique benefit to the organization. Before ITIL V3, >>> many organizations used the term “IT system” instead of “IT service.” >>> “System” places the focus on IT components, whereas “service” emphasizes >>> value to the organization. P.7. >>> >>> “Service transition consists of the short-term view of change management >>> and the long-term view of release management.” P.7. >>> >>> >>> >>> So, Release Management is Strategic, and Change Management is >>> Operational. IMHO, the ITIL V3 model has now added so many overlapping >>> functions to the V2 model, probably to meet new oversight requirements, that >>> it is no longer comprehendible. It’s no wonder that the software vendors >>> are finding it hard to instantiate the ITIL defined “processes” into >>> coherent application modules. I hate to say it, but ITIL is probably >>> overdue for a complete redesign, with consolidation and simplification as >>> its goals. >>> >>> >>> >>> Christopher Strauss, Ph.D. >>> Call Tracking Administration Manager >>> University of North Texas Computing & IT Center >>> http://itsm.unt.edu/ >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *Rick Cook >>> *Sent:* Monday, July 26, 2010 7:03 AM >>> >>> *To:* [email protected] >>> *Subject:* Re: Change Management question >>> >>> >>> >>> ** I was talking to our local ITIL folks about this this morning, and >>> their opinion was that BMC constructed the Release/Change relationship >>> backward - that Change should be above Release. I have heard others say the >>> opposite, so maybe that's true, maybe not, and there was agreement about >>> there being sufficient wiggle room that a company could use it either way, >>> but that got me wondering why BMC did it the way they did it. >>> >>> >>> Then it hit me. If they put Release between Change and Task, it would >>> have broken up the Change module. So they put it on top of Change. The >>> problem with that is that the way they have constructed the relationships >>> limits the customer's ability to use it in a Change --> Release scenario, >>> due to the fact that while Releases can be related to RFCs, they cannot be >>> dependent upon them - the Parent/Child scenario only works when Release is >>> on top. That makes the process of monitoring completion of all Releases >>> under a Change a manual one. It also makes Tasks almost unusable. That's >>> not a major problem for us due to some other process and tooling issues, but >>> it will be for many. >>> >>> So against my better judgment, and with the understanding that it is not >>> optimal from a scaling and efficiency perspective, I feel that we will end >>> up using a Master RFC controlling one or more Releases, which would then >>> optionally control one or more subordinate Changes. I will submit an RFE to >>> BMC to enhance the relationship options, but I don't see them changing that >>> any time soon. >>> >>> Rick >>> >>> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
