I am doubtful for tomorrow but I do think this deserves further discussion. I do not like the qualifiers before "Change Management" as I don't think they capture the essence of what it is we are trying to convey. They connote dumbing it down and we're not, this is deadly serious but low ceremony. On today's projects the product backlog is continuously evolving and changing in response to business needs and technology. Defect, enhancement, new feature we don't really care. So I think this practice belongs with other practices creating and prioritizing the product backlog and I don't think right now this is the Shared Vision practice. So my vote is for the status quo (Change Management) until we can fix this and fix it right.
My 0.02d On Thu, Aug 14, 2008 at 2:21 PM, Bruce Macisaac <[EMAIL PROTECTED]> wrote: > > Since *tomorrow *is the last day for making changes, we need to close on > this. > It may be fine to have a sub-optimal name for this release, and continue > the discussion for a follow-on release. > > I propose a meeting to resolve this tomorrow morning 8am pacific time. > Toll-free dial-in: 1-877-421-0014 > Toll/International dial-in: 1-770-615-1376 > Tie-line dial-in: 421-0014 > Participant passcode: 722417 > > > If you can't make the meeting, then please clearly state your preferred > name, and whether you are able to help adjust the text by end of day > tomorrow to fit the new name, > or if you have more than one, then your favorite, next favorite, etc. > > Here is mine, favorite first: > > 1. Informal Change Management > 2. Basic Change Management > 3. Change Management > > Rationale: > > a. It's a bit late in the game for a radical name change - the practice > descriptions have already been written in terms of "change management" and > it's an easy fix to add an adjective. > A more substantial name change means defining some new terms and possibly > rewriting a bigger chunk of text - I think it's late for that - but if those > suggesting the better name want > to do the work... :-) > > b. Several of the other name proposals suffer from the same problem as the > original "change management" name - the name still doesn't separate this > informal variant from how this area is traditionally managed. > > Bruce MacIsaac > Manager - RUP/OpenUP Content > [EMAIL PROTECTED] > phone: (408)463-5140 > > > > *Peter Haumer/Cupertino/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > > 08/13/2008 01:50 PM > Please respond to > Eclipse Process Framework Project Developers List < > [email protected]> > > To > Eclipse Process Framework Project Developers List <[email protected]> > cc > "Eclipse Process Framework Project Developers List" <[email protected]>, > [EMAIL PROTECTED] > Subject > Re: [epf-dev] Renaming "Change Management" practice to "Basic Change > Management" > > > > > > Hi. > For me "Change Management" is a discipline, but not a practice. The > difference is that change management just implies that a solution for > managing change is needed, but not the concrete set of practices and > procedure that are performed to achieve this need of managing change. The > same with Requirements Management or Project Management: Not practices, just > disciplines. Putting an ambiguous adjective such as Basic or Flexible > in-front of it makes it in IMHO even worse as it even becomes less clear > what it means. There is also no value communicated with these words. > > Many of our other practices much better communicate what the practice is > actually about, such as Evolutionary Architecture, i.e. the practice of not > creating an architecture up-front, but evolving it out of the solution > development. > > Hence, better names would be "everyone can request change" or > "state-machine driven change tracking" or "attribute-driven work item list > management". If we do not have a practice for actually managing changes in > OpenUP then the name should also reflect that such as "submitting changes > into a work item list" is all I can see for now. > > Thanks and best regards, > Peter Haumer. > > ______________________________________________________________ > > PETER HAUMER, Dr. rer. nat. > Rational Method Composer | Eclipse Process Framework > Rational Software | IBM Software Group > Tel.: +1 (408) 463-5096 > ______________________________________________________________ > > From: "Ken Clyne" <[EMAIL PROTECTED]> To: "Eclipse Process Framework > Project Developers List" <[email protected]> Date: 08/13/2008 12:51 > Subject: Re: [epf-dev] Renaming "Change Management" practice to "Basic > Change Management" > > ------------------------------ > > > > Good dialog. Bruce I wasn't inferring we were claiming copyright on > "Change Management" but rather those people challenging your use of the term > were. > > I like Ana's suggestion and Maciel's endorsement but also put forward one > of my own that is a bit a narrower but maybe apropos to the limited content > of this practice "Change Request Management". > > On Wed, Aug 13, 2008 at 2:08 PM, Maciel, Eduardo (Brazil R&D) <* > [EMAIL PROTECTED] <[EMAIL PROTECTED]>> wrote: > Hello all, > > > > I´m not sure if contributions are expected from non usual contributors, > such as me, but I´d like to opine about this subject. > > > > I agree with Ana Pereira. In my humble opinion, Scope Management is the > best term. > > > > - For most of people Change Management reminds a very strict and > formal process. > > - By "managing the scope" one can understand it comprehends the > management of changes also. > > - The type of change management most of lightweight processes > implement is a different paradigm if compared to traditional change > management and usually are nothing more than keeping the scope under control > (tracking, creating or removing work items). > > > > Regards, > > Maciel > > > > > > *From:* [EMAIL PROTECTED] <[EMAIL PROTECTED]>[mailto: > [EMAIL PROTECTED] <[EMAIL PROTECTED]>] *On Behalf Of > *Ana Paula Valente Pereira* > Sent:* quarta-feira, 13 de agosto de 2008 14:09 * > > To:* Eclipse Process Framework Project Developers List > > *Subject:* Re: [epf-dev] Renaming "Change Management" practice to "Basic > Change Management" > > > > what about Flexible ? ... Flexible Change or Scope Management? ... > contrasting with traditional change management that seems to be more rigid > ... > > Ana > > On Wed, Aug 13, 2008 at 5:20 PM, Bruce Macisaac <[EMAIL PROTECTED]<[EMAIL > PROTECTED]>> > wrote: > > > Hi Ken, > > I think the point is that without the qualifier, it makes it hard to name > alternative change management practices. > In other words, if we have 3 change management practice alternatives, and > one is called change management, it's hard from the name to know what kind > of change management is being described > by the practice. Also, it may seem unfair for us to claim copyright to > "change management" - by adding some kind of qualifier, at least we are only > claiming our brand of change management. > Another suggestion from Per is "Informal Change Management". > Is that better than "Basic"? > > Note that this practice, as it stands, just has one task, which is to > submit change requests, and otherwise changes are really being addressed as > part of > work item management done by the iterative development practice. It's not > a traditional formal change management approach with a CCB and unique states > for change requests. > > > Bruce MacIsaac > Manager - RUP/OpenUP Content* > [EMAIL PROTECTED] <[EMAIL PROTECTED]> > phone: (408)463-5140 > > *"Ken Clyne" <[EMAIL PROTECTED] <[EMAIL PROTECTED]>*>* > Sent by: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > 08/12/2008 01:11 PM > > > Please respond to > Eclipse Process Framework Project Developers List <* > [EMAIL PROTECTED] <[email protected]>> > > > To > "Eclipse Process Framework Project Developers List" <[EMAIL > PROTECTED]<[email protected]> > > cc > Subject > Re: [epf-dev] Renaming "Change Management" practice to "Basic Change > Management" > > > > > > > > I don't know I think you got it right the first time. Firstly, I don't > think its fair for any one group to claim copyright to the term Change > Management. Secondly the term "Basic" is almost pejorative and somehow > diminishes the importance of the practice (think about Basic Project > Management, Basic Architecture etc). Thirdly, I'm not sure we need a > qualifier, one would think the context would be sufficient if we put "Basic" > before one practice what does that mean about the other practices. > > My $0.03 > > > On Tue, Aug 12, 2008 at 3:46 PM, Bruce Macisaac <[EMAIL PROTECTED]<[EMAIL > PROTECTED]>> > wrote: > > Chris Sibbald and I would like to make this change to address concerns > raised by reviewers. > The basic concern is that they expected from the name that this would be a > formal change management practice, and it's not. > > See bugzilla: > > > > > > > > > > > *243928* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=243928> > > > > I plan to make this change tomorrow, so if there are any concerns at all > with this, please let me know as soon as possible. > > Thanks, > > Bruce MacIsaac > Manager - RUP/OpenUP Content* > [EMAIL PROTECTED] <[EMAIL PROTECTED]> > phone: (408)463-5140 > > > _______________________________________________ > epf-dev mailing list* > [EMAIL PROTECTED] <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> > > _______________________________________________ > epf-dev mailing list* > [EMAIL PROTECTED] <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> > > > _______________________________________________ > epf-dev mailing list* > [EMAIL PROTECTED] <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> > > > > _______________________________________________ > epf-dev mailing list* > [EMAIL PROTECTED] <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> > > _______________________________________________ > epf-dev mailing list > [EMAIL PROTECTED] > **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> > > _______________________________________________ > epf-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/epf-dev > > > _______________________________________________ > epf-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/epf-dev > >
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
