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 On Sat, Jul 24, 2010 at 10:59 AM, Guillaume Rheault <[email protected]>wrote: > ** > For the complex situation you described, I think the following scenario > is the best: > > Release --> Change/Activity --> Task > > Approvals can be configured for releases, so you won't be missing that > initial approval. > > Also as you know, you can relate task templates to change templates, to > "standardize" the work to be done > > Guillaume > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [ > [email protected]] on behalf of Rick Cook [[email protected]] > *Sent:* Friday, July 23, 2010 3:59 PM > > *To:* [email protected] > *Subject:* Re: Change Management question > > ** Well, having Release at the top allows things to flow Release --> > Change/Activity --> Task. Putting Release below Change eliminates the > ability to use Tasks, since they can't be directly subordinate to a Release. > > > So our options for a dependent (i.e. Parent/Child) flow are: > > Release --> Change/Activity --> Task > --OR-- > Change --> Task > --OR-- > Release --> Change(s) > > Do I have that right? > > Rick > _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"
