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
:* 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
: 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
]
*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
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
:* 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
: 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
: 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
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
, 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
.
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
*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
.
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
, 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
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
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
: 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
--
*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
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
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
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 remedyr...@gmail.com
To: arslist arslist@ARSLIST.ORG
Sent: Fri, Jul 23, 2010 1:34 pm
Subject: Re: Change Management question
** Thanks, Guillaume
*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
.
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
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
...@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
:* 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
]
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
), 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
And you can do it the way we did it before Release.
Change - Change(s)- Task
-Original Message-
From: Rick Cook remedyr...@gmail.com
To: arslist arslist@ARSLIST.ORG
Sent: Fri, Jul 23, 2010 3:59 pm
Subject: Re: Change Management question
** Well, having Release at the top allows
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
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
know that the parent in
either case cannot be closed until the children changes are completed.
-Original Message-
From: Rick Cook remedyr...@gmail.com
To: arslist arslist@ARSLIST.ORG
Sent: Thu, Jul 22, 2010 11:26 am
Subject: Change Management question
** We are looking to use CM
32 matches
Mail list logo
