Rick, This is a great discussion, one that trully reflects the intent and purpose of this list. One thing that IMHO you need to stress to the client if you go that route, is that if somebody for the client organization reads the Change Mgmt user guide, and finds what the OOTB use of the release mgmt module is intended to be, he/she may question the implementation that you are leading. That will be specially true if they intend to develop their training material based on the OOTB documentation, which is a common thing.
David Easter, Any reason why the BMC choose such a poor name for this release mgmt module? From a marketing and even ITIL perspective, it seems backwards.... It seems to me a name like Change Project Mgmt, or something along thosee lines would have been more appropriate, since the intention was, presumably, to have a module that would manage a collection of changes (that require approval) and activities (that don't require approval). Having a poor name is rather counterproductive.... Guillaume ________________________________ From: Action Request System discussion list(ARSList) [[email protected]] on behalf of Rick Cook [[email protected]] Sent: Monday, July 26, 2010 8:02 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
