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: Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)
  • From: Olga Cavalli <olgac@xxxxxxxxxxxxxxx>
  • Date: Sun, 14 Feb 2010 12:18:42 -0300

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