ICANN ICANN Email List Archives

[gnso-wpm-dt]


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

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

  • To: "'Adrian Kinderis'" <adrian@xxxxxxxxxxxxxxxxxx>, <gnso-wpm-dt@xxxxxxxxx>
  • Subject: [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)
  • From: "Ken Bour" <ken.bour@xxxxxxxxxxx>
  • Date: Sun, 14 Feb 2010 10:14:54 -0500

Hi Adrian:

 

Thank you for your candid observations.  In my opinion, consulting to this
effort, I don't believe it is perfection we seek, but applicability and
defensibility.  ICANN projects have many unique characteristics (e.g.
competing goals, staff +volunteer workers, lack of resource/expense
accounting) presenting uncommon challenges that we did not anticipate at the
outset of this undertaking.  We have tried and discarded a few
ideas/approaches that work well in other industries; but, after deeper
consideration, we uncovered holes in the underlying logic or some
inapplicability that we could not resolve.  We are mindful not to have the
entire Council spin through multiple iterations searching for a workable
process, so we are trying to be careful, thorough, and challenge our
conclusions along the way.  We are also aware that a "Red Team" is going to
review our final outputs/products and ask tough questions.  J

 

For comparison purposes, I wonder if you would be willing to share the
criteria that are used in developing your company's prioritization list and
the methodology that creates it or keeps it up-to-date?  We are always
looking for useful ideas.

 

Thanks,

 

Ken Bour

 

From: Adrian Kinderis [mailto:adrian@xxxxxxxxxxxxxxxxxx] 
Sent: Saturday, February 13, 2010 10:23 PM
To: Ken Bour; gnso-wpm-dt@xxxxxxxxx
Subject: RE: [gnso-wpm-dt] WPM Summary & Action Items-Step 6 (In Progress)

 

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