Rick, Having "parent" or "master" changes that have days or months for implementation may not be a good idea, because it is going to mess up your change calendars, whether your OOTB ITSM change calendar, or any other calenda (BTW, take a look at the Kinetic calendar, it is awesome and really simple to set up), unless you filter out this "parent" changes by the change type or something else. Other things that will be messed up are is the new 7.5 collision detection and impact analysis. I am running into this specific situation right now and it is not clean... it is actually cludgy. I advise you to stay away from that scenario as much as possible from day one.
I agree with Roger that these kind of parent changes should find their place in the release module somehow, and not in the change module. This implies of course using another module, training,etc, but in the end it will be much cleaner from a process, data and reporting perspectives. Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Thursday, July 22, 2010 11:36 AM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** We intend to log the actual work in Release, but we want local RFCs to track the scheduling of the change, which would have different acceptable maintenance windows at each location. So the parent change would give, say, a 30 day window for implementation, and each child RFC logs where within that window the individual location will do their change. Does that seem like a sound structure, Roger, or should everything underneath the parent RFC be based in Release? Rick On Thu, Jul 22, 2010 at 11:30 AM, Roger Justice <rjust2...@aol.com<mailto:rjust2...@aol.com>> wrote: ** This would be better handled by Release. I know that the parent in either case cannot be closed until the children changes are completed. -----Original Message----- From: Rick Cook <remedyr...@gmail.com<mailto:remedyr...@gmail.com>> To: arslist <arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>> Sent: Thu, Jul 22, 2010 11:26 am Subject: Change Management question ** We are looking to use CM (7.5) like this: One Project or Release RFC that would dictate what needed to be done at multiple locations. Then subordinate RFCs would be created at each location to handle the exact scheduling and implementation. My question is whether the Parent/Child RFC process works like the RFC/Task process, in that closing the last task in an RFC auto-closes it and/or if the Parent RFC is prevented from being closed until all of the children are closed. Just trying to get a handle on the degree of dependence or control the parent RFC has on the subordinate RFC, and vice versa. Rick _attend WWRUG10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com<http://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"
