Re: Change Management question
Thanks Doug for taking the time to craft this reply. You are confirming my thought process. I believe this is the first time your reply is not about ARS, but about an application, so we are breaking new ground here :-), so thanks again for your participation. About the name for the Release Mgmt module, I guess we'll have to get used to and adapt to this terminology, and get rid off old conceptions. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Mueller, Doug [doug_muel...@bmc.com] Sent: Tuesday, July 27, 2010 6:10 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Everyone, Given that this discussion has wandered around for a while and in several different directions, I wanted to put together a response. I chose to remove the history of the discussion since there were several different sets of includes with different depths and just start with a clean slate for the reply. Issue 1 -- ITIL is a set of guidelines not an absolute Step one in any discussion -- not unique to this discussion -- is to remember that ITIL is a set of guidelines and is not absolute. It does not have an answer to everything. In the real world, there are things that are simply not practical and it is important to interpret and allow for deviation. It is a good set of guidelines and the goal is to follow the basic principles and directions that it encourages. However, there are also times to deviate. Let's take a specific example with the CMDB. In ITIL v2, the CMDB specs said that things like Trouble Tickets and SLAs and the like all belonged within the CMDB. The problem is that these things are not configuration items (well, we could talk about SLAs, but for sure Trouble Tickets). BMC decided that the CMDB was for CONFIGURATION data and did not model Trouble Tickets in the CMDB and insisted that they did not belong there. I know we ran into a number of customers with "ITIL police" who insisted that we were doing things wrong because Trouble Tickets did belong in the CMDB. "It says so right here.". I was involved in many discussions around this topic. Well, it turns out, that by the time ITIL v3 came along, there was an understanding that Trouble Tickets really didn't belong in the CMDB and you will find that they are not items that ITIL v3 advocates are in the CMDB. There is now the CMS which BMC always called the Extended CMDB and Trouble Tickets are there but stored in a Trouble Ticket data store. This interpretation of what a CMDB is and is about is what BMC had advocated from the start and as it turns out ITIL agreed and adjusted where if we had just followed the ITIL rules at the time, it would have been the wrong direction. Now, I am not indicating that there is the same issue going on in this situation (and in fact I don't), but I always want to start any conversation with this note whenever there is a battle that forms up along the lines of "ITIL SAYS". Yes, but. Issue 2 -- What are we trying to accomplish? Now, let's return to this situation. What are we trying to do? What is the problem we are trying to solve? -- Need to request, plan, and have the steps to execute a change to the environment -- Need to request, plan, and orchestrate a set of changes and other activities in the environment If I take these things, there is a difference in scope and process in these two goals. The first is about making a very specific change. To interact with the environment and change the configuration in some way. There are a specific set of steps that need to be performed. You may need to be aware of other changes to the same object and want to coordinate them. But, in general, you are worried about a point change to a specific object and not about the bigger picture of coordination of the entire environment or infrastructure. The second is about really more complete planning and coordination of one or more changes and potentially other things in the environment to have a larger scope process. You many need to make a series of changes and have things like training or data conversion or any number of other things involved and scheduled and synchronized. There is the concept of a rollback plan (not part of change by the way) if there are problems. There is a concept that you may or may not get all changes and what to do about that (if one thing out of 50 is not done are you OK or is that a failure). Notice that the second item here is "bigger" than the first. There is an entire layer of planning and coordination that is not part of the first. They don't intermix. One is about "performing" the update. The other is about "coordinating" the update(s) and other activity. If there is not some distinction between what is going on, why would there be a need for differe
Re: Change Management question
Everyone, Given that this discussion has wandered around for a while and in several different directions, I wanted to put together a response. I chose to remove the history of the discussion since there were several different sets of includes with different depths and just start with a clean slate for the reply. Issue 1 -- ITIL is a set of guidelines not an absolute Step one in any discussion -- not unique to this discussion -- is to remember that ITIL is a set of guidelines and is not absolute. It does not have an answer to everything. In the real world, there are things that are simply not practical and it is important to interpret and allow for deviation. It is a good set of guidelines and the goal is to follow the basic principles and directions that it encourages. However, there are also times to deviate. Let's take a specific example with the CMDB. In ITIL v2, the CMDB specs said that things like Trouble Tickets and SLAs and the like all belonged within the CMDB. The problem is that these things are not configuration items (well, we could talk about SLAs, but for sure Trouble Tickets). BMC decided that the CMDB was for CONFIGURATION data and did not model Trouble Tickets in the CMDB and insisted that they did not belong there. I know we ran into a number of customers with "ITIL police" who insisted that we were doing things wrong because Trouble Tickets did belong in the CMDB. "It says so right here.". I was involved in many discussions around this topic. Well, it turns out, that by the time ITIL v3 came along, there was an understanding that Trouble Tickets really didn't belong in the CMDB and you will find that they are not items that ITIL v3 advocates are in the CMDB. There is now the CMS which BMC always called the Extended CMDB and Trouble Tickets are there but stored in a Trouble Ticket data store. This interpretation of what a CMDB is and is about is what BMC had advocated from the start and as it turns out ITIL agreed and adjusted where if we had just followed the ITIL rules at the time, it would have been the wrong direction. Now, I am not indicating that there is the same issue going on in this situation (and in fact I don't), but I always want to start any conversation with this note whenever there is a battle that forms up along the lines of "ITIL SAYS". Yes, but. Issue 2 -- What are we trying to accomplish? Now, let's return to this situation. What are we trying to do? What is the problem we are trying to solve? -- Need to request, plan, and have the steps to execute a change to the environment -- Need to request, plan, and orchestrate a set of changes and other activities in the environment If I take these things, there is a difference in scope and process in these two goals. The first is about making a very specific change. To interact with the environment and change the configuration in some way. There are a specific set of steps that need to be performed. You may need to be aware of other changes to the same object and want to coordinate them. But, in general, you are worried about a point change to a specific object and not about the bigger picture of coordination of the entire environment or infrastructure. The second is about really more complete planning and coordination of one or more changes and potentially other things in the environment to have a larger scope process. You many need to make a series of changes and have things like training or data conversion or any number of other things involved and scheduled and synchronized. There is the concept of a rollback plan (not part of change by the way) if there are problems. There is a concept that you may or may not get all changes and what to do about that (if one thing out of 50 is not done are you OK or is that a failure). Notice that the second item here is "bigger" than the first. There is an entire layer of planning and coordination that is not part of the first. They don't intermix. One is about "performing" the update. The other is about "coordinating" the update(s) and other activity. If there is not some distinction between what is going on, why would there be a need for different processes and flows -- whether ITIL or not. There seems to be agreement that there are two different things going on here and there needs to be a clear line between what is going on and why I would want to use one process or the other. Issue 3 -- What has BMC done? With the distinction between the roles of the process above, it is pretty clear that there is a hierarchy in the two items -- one is about "performing" and the other is about "coordinating the performing". So, there needs to be two different processes because they are doing different things. Performing is Change Management Coordinating is Release Management Note that BOTH solutions are tied together into the single overall concept of managing change within your environment. This is much like
Re: Change Management question
That would be nice, wouldn't it! I believe that there would be some areas of disagreement between us and him. I have no problem engaging in discussions with people with opposing points of view, because I always feel I can learn something. If the Product Manager has the same attitude, we would love to engage in some discussion here with him for the mutual benefit of BMC and its customer base. I won't call him out by name, but if someone at BMC is watching, let him know we'd like to hear from him, OK? Rick On Tue, Jul 27, 2010 at 9:25 AM, Guillaume Rheault wrote: > ** > I still hope that the Change Mgmt product manager at BMC would chime in > this discussion, in the same way that David and Doug have when questions > about ARS pop-up , to at least explain why things were done a certain > wayand what is the recommendation. > As more companies use the OOTB applications and people in those companies > become ITL v3 Foundation certified, this kind of discussions becomes more > and more relevant. > > Guillaume > > -- > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Tuesday, July 27, 2010 9:18 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** The bottom line appears to be that the current construct of Release > and Change is not as ITIL-compliant as BMC believes it to be, so you will > have to choose whether you want to stick with ITIL or use the BMC Release > package. I have been told that no changes to the current product construct > are in anyone's plans for at least the near term (2-3 years), FWIW. > > > That being said, if one wants to use the product line the way it was > constructed (Release --> Change/Activity --> Task), it would probably work > just fine in supporting a company's Change and Release processes. But if > you try to force the ITIL model (Change --> Release --> Task) on it, it will > not support that model very well. A better alternative to that (IMHO) is to > not use Release at all, but stick with the current Change/Activity --> Task > methodology, which will work for most of the companies most of the time. > > Rick > > On Tue, Jul 27, 2010 at 12:03 AM, Mahendra Mahalkar < > mahendra.mahal...@gmail.com> wrote: > >> ** Thanks to all listers participated in this thread as this discussion >> really helped me to clear my concepts. >> >> Thanks & Regards, >> Mahendra Mahalkar >> >> >> >> >> On Mon, Jul 26, 2010 at 8:36 PM, strauss 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.
Re: Change Management question
I still hope that the Change Mgmt product manager at BMC would chime in this discussion, in the same way that David and Doug have when questions about ARS pop-up , to at least explain why things were done a certain wayand what is the recommendation. As more companies use the OOTB applications and people in those companies become ITL v3 Foundation certified, this kind of discussions becomes more and more relevant. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Tuesday, July 27, 2010 9:18 AM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The bottom line appears to be that the current construct of Release and Change is not as ITIL-compliant as BMC believes it to be, so you will have to choose whether you want to stick with ITIL or use the BMC Release package. I have been told that no changes to the current product construct are in anyone's plans for at least the near term (2-3 years), FWIW. That being said, if one wants to use the product line the way it was constructed (Release --> Change/Activity --> Task), it would probably work just fine in supporting a company's Change and Release processes. But if you try to force the ITIL model (Change --> Release --> Task) on it, it will not support that model very well. A better alternative to that (IMHO) is to not use Release at all, but stick with the current Change/Activity --> Task methodology, which will work for most of the companies most of the time. Rick On Tue, Jul 27, 2010 at 12:03 AM, Mahendra Mahalkar mailto:mahendra.mahal...@gmail.com>> wrote: ** Thanks to all listers participated in this thread as this discussion really helped me to clear my concepts. Thanks & Regards, Mahendra Mahalkar On Mon, Jul 26, 2010 at 8:36 PM, strauss mailto:stra...@unt.edu>> 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:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Rick Cook Sent: Monday, July 26, 2010 7:03 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> 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
Re: Change Management question
The bottom line appears to be that the current construct of Release and Change is not as ITIL-compliant as BMC believes it to be, so you will have to choose whether you want to stick with ITIL or use the BMC Release package. I have been told that no changes to the current product construct are in anyone's plans for at least the near term (2-3 years), FWIW. That being said, if one wants to use the product line the way it was constructed (Release --> Change/Activity --> Task), it would probably work just fine in supporting a company's Change and Release processes. But if you try to force the ITIL model (Change --> Release --> Task) on it, it will not support that model very well. A better alternative to that (IMHO) is to not use Release at all, but stick with the current Change/Activity --> Task methodology, which will work for most of the companies most of the time. Rick On Tue, Jul 27, 2010 at 12:03 AM, Mahendra Mahalkar < mahendra.mahal...@gmail.com> wrote: > ** Thanks to all listers participated in this thread as this discussion > really helped me to clear my concepts. > > Thanks & Regards, > Mahendra Mahalkar > > > > > On Mon, Jul 26, 2010 at 8:36 PM, strauss 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: >> arsl...@arslist.org] *On Behalf Of *Rick Cook >> *Sent:* Monday, July 26, 2010 7:03 AM >> >> *To:* arslist@ARSLIST.ORG >> *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,
Re: Change Management question
Thanks to all listers participated in this thread as this discussion really helped me to clear my concepts. Thanks & Regards, Mahendra Mahalkar On Mon, Jul 26, 2010 at 8:36 PM, strauss 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: > arsl...@arslist.org] *On Behalf Of *Rick Cook > *Sent:* Monday, July 26, 2010 7:03 AM > > *To:* arslist@ARSLIST.ORG > *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 > > On Sat, Jul 2
Re: Change Management question
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 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) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Monday, July 26, 2010 12:03 PM > > *To:* arslist@ARSLIST.ORG > *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 > 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 natureand implementors would not have to butt heads >> with ITIL v2 experts out there, on terminology. >> >> Guillaume >> >> -- >> *From:* Action Request System discussion list(ARSList) [ >> arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] >> *Sent:* Monday, July 26, 2010 11:30 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Change Management question >> >> ** So you guys can imagine my dilemma - I have one group of very >> experienced, respected and trained people (you
Re: Change Management question
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) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Monday, July 26, 2010 12:03 PM To: arslist@ARSLIST.ORG 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 mailto:guilla...@dcshq.com>> 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 natureand implementors would not have to butt heads with ITIL v2 experts out there, on terminology. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Monday, July 26, 2010 11:30 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> 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 mailto:stra...@unt.edu>> 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,
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 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 natureand implementors would not have to butt heads > with ITIL v2 experts out there, on terminology. > > Guillaume > > -- > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Monday, July 26, 2010 11:30 AM > > *To:* arslist@ARSLIST.ORG > *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 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 >> Ope
Re: Change Management question
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 natureand implementors would not have to butt heads with ITIL v2 experts out there, on terminology. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Monday, July 26, 2010 11:30 AM To: arslist@ARSLIST.ORG 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 mailto:stra...@unt.edu>> 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:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Rick Cook Sent: Monday, July 26, 2010 7:03 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> 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 Chang
Re: Change Management question
That's why I included the citations. 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:arsl...@arslist.org] On Behalf Of Rick Cook Sent: Monday, July 26, 2010 10:31 AM To: arslist@ARSLIST.ORG 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
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 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: > arsl...@arslist.org] *On Behalf Of *Rick Cook > *Sent:* Monday, July 26, 2010 7:03 AM > > *To:* arslist@ARSLIST.ORG > *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
Re: Change Management question
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:arsl...@arslist.org] On Behalf Of Rick Cook Sent: Monday, July 26, 2010 7:03 AM To: arslist@ARSLIST.ORG 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 On Sat, Jul 24, 2010 at 10:59 AM, Guillaume Rheault mailto:guilla...@dcshq.com>> 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) [arsl...@arslist.org&l
Re: Change Management question
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) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Monday, July 26, 2010 8:02 AM To: arslist@ARSLIST.ORG 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"
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 On Sat, Jul 24, 2010 at 10:59 AM, Guillaume Rheault 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) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Friday, July 23, 2010 3:59 PM > > *To:* arslist@ARSLIST.ORG > *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"
Re: Change Management question
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) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 3:59 PM To: arslist@ARSLIST.ORG 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
Re: Change Management question
And you can do it the way we did it before Release. Change -> Change(s)-> Task -Original Message- From: Rick Cook To: arslist Sent: Fri, Jul 23, 2010 3:59 pm 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 On Fri, Jul 23, 2010 at 3:00 PM, Guillaume Rheault wrote: ** Chris, good point. In the end, the main issue that needs to br definrd and standardized is the usage of the application. The BMC Remedy Change Mgmt and Release Mgmt are loosely coupled OOTB, so various ways of usage can be defined, and that is usually the most difficult part in change mgmt implementations. Once you standardize usage, you can create business rules to lock down the app (customization really), to enforce such usage. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of strauss [stra...@unt.edu] Sent: Friday, July 23, 2010 2:53 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Could the proper sequence be that an initial RFC would be considered for enterprise application versus local, and if approved for the enterprise you would create a parent Release for it, followed by additional child (to the Release) Infrastructure Changes and Activities for the rest of the enterprise? Or if the RFC was going to stand alone, for local application, then it still might be appropriate to create a parent release and add more Changes or at least Activities that were going to be necessary in conjunction with the action on the original RFC. Larry Klosterboer’s book “Implementing ITIL Change and Release Management” is the newest guide I have found, but it is not specific to BMC ITSM (from IBM Press) so you have to figure out how to apply the generic concepts in your environment. 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:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, July 23, 2010 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Ch
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 On Fri, Jul 23, 2010 at 3:00 PM, Guillaume Rheault wrote: > ** > Chris, good point. In the end, the main issue that needs to br definrd > and standardized is the usage of the application. > The BMC Remedy Change Mgmt and Release Mgmt are loosely coupled OOTB, so > various ways of usage can be defined, and that is usually the most difficult > part in change mgmt implementations. Once you standardize usage, you can > create business rules to lock down the app (customization really), to > enforce such usage. > > Guillaume > > -- > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of strauss [stra...@unt.edu] > *Sent:* Friday, July 23, 2010 2:53 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** > > Could the proper sequence be that an initial RFC would be considered for > enterprise application versus local, and if approved for the enterprise you > would create a parent Release for it, followed by additional child (to the > Release) Infrastructure Changes and Activities for the rest of the > enterprise? Or if the RFC was going to stand alone, for local application, > then it still might be appropriate to create a parent release and add more > Changes or at least Activities that were going to be necessary in > conjunction with the action on the original RFC. > > > > Larry Klosterboer’s book “Implementing ITIL Change and Release Management” > is the newest guide I have found, but it is not specific to BMC ITSM (from > IBM Press) so you have to figure out how to apply the generic concepts in > your environment. > > > > 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: > arsl...@arslist.org] *On Behalf Of *Guillaume Rheault > *Sent:* Friday, July 23, 2010 1:29 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > > > ** > > hi Rick, > > I understand the situation. But that parent change could be a release entry > too. My understanding of the philiosphy behind the BMC Release Mgmt module > is that the release entry is intended to be the parent of changes, i.e. the > actual implementation changes to production... So the starting point is the > release, not the change. From the release, you create child changes that are > scheduled within the release. So it seems we have a terminology/nomenclature > issue here, since most people would think the release is downstream of the > change, when in fact it is not, it is upstream. > > Guillaume > ---------- > > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Friday, July 23, 2010 2:19 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** The customer intends to have the Parent RFC as an initial point of > approval and dispatch. So Parent Company says "All installations need to > patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". > Then when that's approved at the corporate level, each local NOC will create > a child RFC and the related Release records to actually accomplish that and > schedule it at their local level in a way, within the larger approved time > window, in which doing that coordinates with the other planned outages and > maintenance for their installation. > > From an approval level, the Parent approvals only take it up to Scheduled, > and then the Child approvals take over until they all are completed. So > from a corporate level, I can look at the Parent RFC and from it, see the > status of all of the Child RFCs and associated Release records. > > So think of it as having local control and accountability over the > implementation of a global mandate. Make sense? > > Rick > > On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault > wrote: > > ** > > from a process perspective, it seems to me having a a release with the > child changes is sufficient...Release records can have approvals defined too > with the approval server OOTB. > I don't see the benefit of the parent c
Re: Change Management question
Chris, good point. In the end, the main issue that needs to br definrd and standardized is the usage of the application. The BMC Remedy Change Mgmt and Release Mgmt are loosely coupled OOTB, so various ways of usage can be defined, and that is usually the most difficult part in change mgmt implementations. Once you standardize usage, you can create business rules to lock down the app (customization really), to enforce such usage. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of strauss [stra...@unt.edu] Sent: Friday, July 23, 2010 2:53 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Could the proper sequence be that an initial RFC would be considered for enterprise application versus local, and if approved for the enterprise you would create a parent Release for it, followed by additional child (to the Release) Infrastructure Changes and Activities for the rest of the enterprise? Or if the RFC was going to stand alone, for local application, then it still might be appropriate to create a parent release and add more Changes or at least Activities that were going to be necessary in conjunction with the action on the original RFC. Larry Klosterboer’s book “Implementing ITIL Change and Release Management” is the newest guide I have found, but it is not specific to BMC ITSM (from IBM Press) so you have to figure out how to apply the generic concepts in your environment. 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:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, July 23, 2010 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying
Re: Change Management question
Wow, I just read the CM User Guide again, and you're right - Release is designed to be the parent of Changes and Activities. A quote from page 42: "A release is a collection of related authorized changes to an IT service that are tested and introduced into the live environment together." OK, then. We have some paradigm-shifting to do on the part of the customer. I think I will wait until Monday to do that - don't want to spoil anyone's weekend. [?] Rick On Fri, Jul 23, 2010 at 2:29 PM, Guillaume Rheault wrote: > ** > hi Rick, > > I understand the situation. But that parent change could be a release entry > too. My understanding of the philiosphy behind the BMC Release Mgmt module > is that the release entry is intended to be the parent of changes, i.e. the > actual implementation changes to production... So the starting point is the > release, not the change. From the release, you create child changes that are > scheduled within the release. So it seems we have a terminology/nomenclature > issue here, since most people would think the release is downstream of the > change, when in fact it is not, it is upstream. > > Guillaume > > -- > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Friday, July 23, 2010 2:19 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** The customer intends to have the Parent RFC as an initial point of > approval and dispatch. So Parent Company says "All installations need to > patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". > Then when that's approved at the corporate level, each local NOC will create > a child RFC and the related Release records to actually accomplish that and > schedule it at their local level in a way, within the larger approved time > window, in which doing that coordinates with the other planned outages and > maintenance for their installation. > > > From an approval level, the Parent approvals only take it up to Scheduled, > and then the Child approvals take over until they all are completed. So > from a corporate level, I can look at the Parent RFC and from it, see the > status of all of the Child RFCs and associated Release records. > > So think of it as having local control and accountability over the > implementation of a global mandate. Make sense? > > Rick > > On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault wrote: > >> ** >> from a process perspective, it seems to me having a a release with the >> child changes is sufficient...Release records can have approvals defined too >> with the approval server OOTB. >> I don't see the benefit of the parent change >> >> Guillaume >> >> ---------- >> *From:* Action Request System discussion list(ARSList) [ >> arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] >> *Sent:* Friday, July 23, 2010 1:34 PM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Change Management question >> >> ** Thanks, Guillaume. >> >> >> The OOB Change Calendar has already been identified as an issue, due to >> its limitations on time periods. We are looking at options there. >> Collision and Impact aren't really going to be used by the customer at >> first, though as their CM processes mature and their CI data gets more >> complete, they intend to get there. And we intend to attach the affected >> CIs to the child RFCs, not the Parent, though we're open to relating them to >> the Release records instead if that works better. >> >> So is what you are saying that the only subordinate records from a Parent >> RFC should be Release records, not other RFCs? Does using that in a >> 3-tiered scenario cause other problems from a functional standpoint? As >> long as we can tie the records together (which we can) and have Approval >> gates for all of them (which we can), and maintain controls over who updates >> each (which we can), the Change Calendar is of little real consequence, >> since we'll be giving the CAB a printed report anyway. >> >> Rick >> >> On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault >> wrote: >> >>> ** >>> 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 ca
Re: Change Management question
Rick, I found the evidence of my assumption of Release being the starting point, the top object if you will. On page 42 of the "BMC Remedy Change Management 7.5.00 User’s Guide", it is stated: .A release is a collection of related authorized changes to an IT service that are tested and introduced into the live environment together. .. Tracking and managing change and deployment activities . You may want to review the whole process you described in your earlier post Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Guillaume Rheault [guilla...@dcshq.com] Sent: Friday, July 23, 2010 2:29 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** 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 dete
Re: Change Management question
Could the proper sequence be that an initial RFC would be considered for enterprise application versus local, and if approved for the enterprise you would create a parent Release for it, followed by additional child (to the Release) Infrastructure Changes and Activities for the rest of the enterprise? Or if the RFC was going to stand alone, for local application, then it still might be appropriate to create a parent release and add more Changes or at least Activities that were going to be necessary in conjunction with the action on the original RFC. Larry Klosterboer's book "Implementing ITIL Change and Release Management" is the newest guide I have found, but it is not specific to BMC ITSM (from IBM Press) so you have to figure out how to apply the generic concepts in your environment. 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:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, July 23, 2010 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** Rick, Having "parent" or "master" changes that have days or months for impleme
Re: Change Management question
hi Rick, I understand the situation. But that parent change could be a release entry too. My understanding of the philiosphy behind the BMC Release Mgmt module is that the release entry is intended to be the parent of changes, i.e. the actual implementation changes to production... So the starting point is the release, not the change. From the release, you create child changes that are scheduled within the release. So it seems we have a terminology/nomenclature issue here, since most people would think the release is downstream of the change, when in fact it is not, it is upstream. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 2:19 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and >then the Child approvals take over until they all are completed. So from a >corporate level, I can look at the Parent RFC and from it, see the status of >all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** 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<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Thursday, July 22, 2010 11:36 AM To: arslist@
Re: Change Management question
The customer intends to have the Parent RFC as an initial point of approval and dispatch. So Parent Company says "All installations need to patch their Windows OS with patches A, B, and C between Aug 1 and Aug 20". Then when that's approved at the corporate level, each local NOC will create a child RFC and the related Release records to actually accomplish that and schedule it at their local level in a way, within the larger approved time window, in which doing that coordinates with the other planned outages and maintenance for their installation. >From an approval level, the Parent approvals only take it up to Scheduled, and then the Child approvals take over until they all are completed. So from a corporate level, I can look at the Parent RFC and from it, see the status of all of the Child RFCs and associated Release records. So think of it as having local control and accountability over the implementation of a global mandate. Make sense? Rick On Fri, Jul 23, 2010 at 2:11 PM, Guillaume Rheault wrote: > ** > from a process perspective, it seems to me having a a release with the > child changes is sufficient...Release records can have approvals defined too > with the approval server OOTB. > I don't see the benefit of the parent change > > Guillaume > > -- > *From:* Action Request System discussion list(ARSList) [ > arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] > *Sent:* Friday, July 23, 2010 1:34 PM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Management question > > ** Thanks, Guillaume. > > > The OOB Change Calendar has already been identified as an issue, due to its > limitations on time periods. We are looking at options there. Collision > and Impact aren't really going to be used by the customer at first, though > as their CM processes mature and their CI data gets more complete, they > intend to get there. And we intend to attach the affected CIs to the child > RFCs, not the Parent, though we're open to relating them to the Release > records instead if that works better. > > So is what you are saying that the only subordinate records from a Parent > RFC should be Release records, not other RFCs? Does using that in a > 3-tiered scenario cause other problems from a functional standpoint? As > long as we can tie the records together (which we can) and have Approval > gates for all of them (which we can), and maintain controls over who updates > each (which we can), the Change Calendar is of little real consequence, > since we'll be giving the CAB a printed report anyway. > > Rick > > On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault wrote: > >> ** >> 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 wrote: >> >>> **
Re: Change Management question
We are on 7.5 patch 4, and I see "Release" in the Relationship Type on the Change form, and see "Infrastructure Change" in the Relationship Type field on a Release record. Rick On Fri, Jul 23, 2010 at 1:38 PM, Roger Justice wrote: > ** I tried to create a child Release to a Change and it is not lited as an > option on the Change Relationships tab. This was ITSM 7.6 no Patch. > > > > -Original Message- > From: Rick Cook > To: arslist > Sent: Fri, Jul 23, 2010 1:34 pm > Subject: Re: Change Management question > > ** Thanks, Guillaume. > > The OOB Change Calendar has already been identified as an issue, due to its > limitations on time periods. We are looking at options there. Collision > and Impact aren't really going to be used by the customer at first, though > as their CM processes mature and their CI data gets more complete, they > intend to get there. And we intend to attach the affected CIs to the child > RFCs, not the Parent, though we're open to relating them to the Release > records instead if that works better. > > So is what you are saying that the only subordinate records from a Parent > RFC should be Release records, not other RFCs? Does using that in a > 3-tiered scenario cause other problems from a functional standpoint? As > long as we can tie the records together (which we can) and have Approval > gates for all of them (which we can), and maintain controls over who updates > each (which we can), the Change Calendar is of little real consequence, > since we'll be giving the CAB a printed report anyway. > > Rick > > On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault wrote: > >> ** >> 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 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 >>> To: arslist >>> 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. &g
Re: Change Management question
from a process perspective, it seems to me having a a release with the child changes is sufficient...Release records can have approvals defined too with the approval server OOTB. I don't see the benefit of the parent change Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rick Cook [remedyr...@gmail.com] Sent: Friday, July 23, 2010 1:34 PM To: arslist@ARSLIST.ORG Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault mailto:guilla...@dcshq.com>> wrote: ** 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<mailto:arslist@ARSLIST.ORG>] on behalf of Rick Cook [remedyr...@gmail.com<mailto:remedyr...@gmail.com>] Sent: Thursday, July 22, 2010 11:36 AM To: arslist@ARSLIST.ORG<mailto: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 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 mailto:remedyr...@gmail.com>> To: arslist 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<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
Re: Change Management question
I tried to create a child Release to a Change and it is not lited as an option on the Change Relationships tab. This was ITSM 7.6 no Patch. -Original Message- From: Rick Cook To: arslist Sent: Fri, Jul 23, 2010 1:34 pm Subject: Re: Change Management question ** Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault wrote: ** 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 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 To: arslist 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"_ _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"
Re: Change Management question
Thanks, Guillaume. The OOB Change Calendar has already been identified as an issue, due to its limitations on time periods. We are looking at options there. Collision and Impact aren't really going to be used by the customer at first, though as their CM processes mature and their CI data gets more complete, they intend to get there. And we intend to attach the affected CIs to the child RFCs, not the Parent, though we're open to relating them to the Release records instead if that works better. So is what you are saying that the only subordinate records from a Parent RFC should be Release records, not other RFCs? Does using that in a 3-tiered scenario cause other problems from a functional standpoint? As long as we can tie the records together (which we can) and have Approval gates for all of them (which we can), and maintain controls over who updates each (which we can), the Change Calendar is of little real consequence, since we'll be giving the CAB a printed report anyway. Rick On Fri, Jul 23, 2010 at 1:22 PM, Guillaume Rheault wrote: > ** > 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 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 >> To: arslist >> 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"_ > > > _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"
Re: Change Management question
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 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 mailto:remedyr...@gmail.com>> To: arslist 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"
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 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 > To: arslist > 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"
Re: Change Management question
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 To: arslist 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"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
