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> 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> > To: arslist <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 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"
