ICANN ICANN Email List Archives

[gnso-wpm-dt]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)

  • To: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
  • Subject: Re: [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)
  • From: Olga Cavalli <olgac@xxxxxxxxxxxxxxx>
  • Date: Mon, 15 Feb 2010 13:04:31 -0300

Stephane,
I think that the group has gone through a process that has been long but
constructive, if it was not made by the group the same questions and thougts
would have been raised by the GNSO council as a whole when presenting a
first approach.
This is why I think it is constructive.
I understand that it may sound frustrating from a private company
perspective, but this is a group with multistakeholder views and processes
are longer.
As I said to Adrian, we are open to other suggestions and ideas. I know he
will be the "read team" but in the mean time perhaps you or him can give us
other ideas to move forward.
As a group we should present our conclusions and outcomes in a face to face
meeting in Nairobi.
Others are also welcome to comment about Adrian an Stréphane´s concerns.
Regards
Olga



2010/2/15 Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>

> Olga,
>
> As group leader, what is your response to the issues raised by Adrian and
> myself?
>
> Do you feel the group should carry on along its present path?
>
> Stéphane
>
> Le 14 févr. 2010 à 22:59, Stéphane Van Gelder a écrit :
>
> Adrian has joined us. He volunteered to red team the work.
>
> His latest comments make a lot of sense to me. The effort that's been put
> into this work by this group has been immense. But it's not because someone
> is working as hard as he can that he's working in the right direction.
>
> I've lately dropped back from the work being done on this group simply
> because it has become, to me, unmanageable. The reason for that being the
> extremely high level of complexity of some of the emails on this list and of
> the proposed models. While we shouldn't shy away from complexity in our
> search for the best solution, I think Adrian's point about how
> prioritization works in an SME and about the length of time it is taking
> this group to propose a method for prioritization should ring alarm bells
> with us. When we started on this work in Seoul, did we really expect it
> would take up to half a year to complete. I know I certainly didn't.
>
> We asked Adrian to red team. Part of doing that is putting his finger on
> the things that we may not be seeing simply because we've got our noses
> pressed against the problem all day while he is able to take a more distant
> look.
>
> I think we would do well to heed his alarm bells.
>
> Stéphane
>
> Le 14 févr. 2010 à 16:18, Olga Cavalli a écrit :
>
> Thanks Adrian.
> We have been working as a group and trying to see all different points of
> views and ideas.
> You are welcome to join us an perhaps bring another perspective.
> Regards
> Olga
>
> 2010/2/14 Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>
>
>>  Team,
>>
>>
>> Just watching from afar...
>>
>>
>> I am very concerned that we are not making progress here. As a CEO of a
>> medium size company we are prioritising work all the time. New tasks/
>> projects come in all the time and changes are make dynamically. Nothing is
>> set nor perfect. My Executive Management team provide input and the CEO
>> makes the final decision. To me, that is why we have a GNSO Chair; to be the
>> CEO.
>>
>>
>> It has now been 4 months since Seoul and we have not seen any outward
>> progress. I really think you have aimed for perfection and this has caused
>> delay. Inexact prioritisation will not result in business lost, nor staff
>> becoming unemployed. We may have small delays but the consequences are not
>> critical.
>>
>>
>> Let’s pick a process and roll forward, understanding and accepting its
>> flaws.
>>
>>
>> I know I haven’t been heavily involved and perhaps my comments aren’t
>> helpful but I am seeing this process become more and more ICANN like...
>> something I thought we were trying to avoid.
>>
>>
>> Thanks.
>>
>>
>> *Adrian Kinderis*
>>
>>
>>
>> *From:* owner-gnso-wpm-dt@xxxxxxxxx [mailto:owner-gnso-wpm-dt@xxxxxxxxx]
>> *On Behalf Of *Ken Bour
>> *Sent:* Saturday, 13 February 2010 9:54 AM
>> *To:* gnso-wpm-dt@xxxxxxxxx
>> *Subject:* [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)
>>
>>
>> WPM Team Members:
>>
>>
>> Following is a summary of the WPM teleconference held on 9 February 2010
>> (1700 UTC):
>>
>>
>> *Team Decisions: *
>>
>>
>> 1)      *Urgency*:  Jamie and Ken reported on their email exchanges
>> between sessions and, after additional consideration during this
>> teleconference, the team agreed that, although “urgency” represented an
>> intriguing potential modeling concept, to make use of it properly would
>> require an *objective* measurement which does not appear feasible.  The
>> team agreed that urgency/criticality should become a natural part of the
>> Value/Benefit assessment and the definition will be enhanced to include that
>> concept (see Action Items below).
>>
>>
>> 2)      *Resources Needed*:  Ken recommended dropping this dimension as
>> well as the 4-quadrant model for reasons provided in his earlier email (8
>> Feb 2010).  After discussing the pros/cons, the team agreed to simplify its
>> model to a one-dimensional rating of Value/Benefit.  There was also
>> consensus that, rather than discard Resources Needed entirely, it could
>> serve as a potential tie-breaker if a decision had to be made between two
>> projects that were otherwise tied on Value/Benefit.  The process would be as
>> follows:
>>
>> *Step 1*:  Rate all projects using the 1-7 scale on Value/Benefit
>>
>> *Step 2*:  If *needed* as a tie breaker, rank any tied projects using
>> Resources Needed
>>
>>
>> *[Note:  Jamie suggested that the team reconsider the terminology/title
>> of “Resources Needed” preferring a return to the original concept of
>> perceived “Difficulty.”  Ken will include this question in a separate email
>> transmitting revised definitions for team review.]  *
>>
>>
>> Once these decisions were concluded, the team took up another important
>> Step 6 question, “How will the Council actually utilize a prioritization?
>> *  *
>>
>>
>> As framework for this discussion, Ken posited that a work prioritization
>> exercise presupposes that there is some limitation of a scarce commodity
>> (e.g. resource capacity).  If there is an abundance of time and resources
>> and no real constraints, there would be no obvious need for a project
>> ranking.  The underlying assumption is that, due to immovable constraints
>> (in the short run), all project work cannot be undertaken simultaneously.  A
>> prioritization, then, presumes that hard decisions are expected based on
>> competing interests for scarce resources, e.g. perform A instead of B or
>> move staffing from one project to another.  If it turned out that, after
>> developing a prioritization, no project ever slowed down, stopped, or had
>> its resources altered, a reasonable question might be:  what was the purpose
>> or value in generating the prioritization?
>>
>>
>> Chuck acknowledged that we cannot assume that projects can be eliminated
>> or postponed simply because they have a low position on relative priority.
>> Looking at the bottom projects test-ranked by the WPM team (e.g. GEO, TRAV),
>> he was able to articulate convincing reasons why they probably can and
>> should be continued even though they occupy the lowest positions on the
>> ranking list.
>>
>>
>> This discussion led to a hypothesis that, perhaps, the model may not be as
>> useful in making stop/pause decisions about existing work, but may be more
>> useful in deciding what to do with *new* projects that are introduced
>> after the initial prioritization is performed (e.g. Vertical Integration).
>>
>>
>> The first question considered was:  how should a new project be
>> rated/evaluated and placed into the prioritization mix?  The team reached
>> agreement on an approach to placing a new project into the ranking.
>> Assuming that the Council will complete a full prioritization at least
>> quarterly (TBD), it would never be more than 3 months between rating
>> sessions.  Presuming that Councilors could readily recall what they did the
>> last time, if a new project surfaces in the interim and cannot wait until a
>> new quarterly reprioritization, the Council would employ the same technique
>> that generated the most recent list.  For example, 4-5 small groups of
>> Councilors would meet and collectively vote/decide on a rating from 1-7
>> considering the same “average project” that was used at the last rating
>> session.  Once a median rating is computed from the group consensus scores,
>> the new project would take its appropriate slot in the ranking.  *[Note:
>> Ken will flesh out this procedure when we get to the point of preparing
>> Council instructions.]*
>>
>>
>> Once a new project is placed into the prioritized list, Chuck suggested
>> that there might be a sequence of questions that should be asked/answered by
>> the Council in deciding what to do with it.  Perhaps the team could create a
>> map or process that the Council would use in evaluating a new project *vis
>> a vis* the existing workload.
>>
>>
>> In addition to assessing a new project, Jamie ventured that there might be
>> a political value in performing the prioritization even if there is not a
>> clear decision-making role related to stopping or postponing existing work.
>> He commented that a project prioritization can establish for the entire
>> organization (top to bottom) an understanding as to how all work relates to
>> the GNSO’s primary mission and goals.
>>
>>
>> In thinking about this political implication, Ken wondered if there might
>> be a potential drawback to publishing a project ranking.  Taking the worst
>> possible scenario, hypothetically, might certain teams working on the lowest
>> ranked projects perceive that their time/effort is not worth continuing?
>> The WPM team should think carefully through possible morale implications to
>> be certain that a new problem isn’t created, unintentionally, that wasn’t
>> there before this exercise began.  In response to this question, Olga
>> thought that it would be possible to underscore that projects ranked at the
>> bottom do not necessarily imply a fundamental lack of worth.  On the other
>> hand, following Jaime’s concept of political prioritization, a project
>> ranking does communicate overall importance.  The Council may not want to
>> suggest, subtly or overtly, that volunteers should know or even think about
>> any project’s relative value in deciding which team(s) to join – only their
>> interest and expertise concerning the work itself.
>>
>>
>> *Action Items:*
>>
>>
>> In addition to the above summary, Ken agreed to complete the following
>> tasks between now and the next meeting (16 February, 1700 UTC).
>>
>>
>> 1)      Suggest draft changes to both Y and X definitions for team
>> discussion and approval at the next WPM meeting.
>>
>>
>> 2)      Identify additional Step 6 questions (e.g. group/individual
>> methodology) that the team needs to consider.
>>
>>
>> 3)      Continue discussion, as challenged by Jaime:  What is/are the
>> real outcome(s) of the prioritization?  Can the team provide concrete and
>> persuasive answers to this question that would satisfy others who have not
>> been deeply involved with the process (e.g. “Red Team”)?
>>
>>
>> 4)      Ken proposed that the team also consider making a recommendation
>> related to the implementation of desperately needed project management tools
>> for both Staff & Community to assist with the Council’s new “managerial”
>> role in the policy development process.
>>
>>
>> Since this summary is already long, the above topics will be included in
>> one or more separate emails so that the team can focus on the topics more
>> efficiently and effectively.
>>
>>
>> Prepared by:
>>
>>
>> Ken Bour
>>
>>
>
>
>
>


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy