[gnso-wpm-dt] Update from 23 Nov Prioritization Call

["Ken Bour" <ken.bour@xxxxxxxxxxx>]

Jaime and Team:

 

Prior to our call this afternoon (3 Dec; 2000 UTC), I thought it might be
helpful to address a few of Jaime's comments (see below) to the Work
Prioritization tasks ahead:  

 

Step 1:  It was our intention to capture "complexity" within the currently
defined axis labeled Difficulty/Cost.   In terms of establishing a minimum
time horizon or cost that would qualify a project to be ranked/rated on the
official list, may I suggest that the question be deferred to a future stage
in the team's process?   Since we already have 20 or so active candidates on
the table to be prioritized (the current workload), it seems most urgent to
agree upon the X,Y scale definitions, rating/ranking methodology, outputs,
and decisions.   It is also reasonable to expect that we might learn
important lessons about how to establish minimum criteria after working
through these exercises.  

 

Step 3:  As I mentioned on the last call, I think it will be more
instructive, at the start, to treat ALL projects as though they can be
stopped - at least theoretically.   Whether any particular project should be
continued or stopped is, ultimately, a management decision that should
derive from the rankings and prioritizations.   To do otherwise, in some
ways, defeats the purpose of the exercise.   Once all projects are plotted
and prioritized, that would be the time for the Council to decide whether
any efforts should be suspended or closed, which teams are under- or
over-resourced, and which projects are wandering, have lost momentum, or
need an infusion of energy/impetus.    In other words, Jamie's (b) and (c)
strike me as implementation concerns that presumably would only be asked for
projects that are rated/prioritized high enough to warrant such attention.
Looking at it another way, would we conclude that a project with low value,
high cost, and high momentum should be rated/prioritized higher than one
with identical value/cost ratings but low momentum?   The progress of any
project, at a snapshot in time, is mostly a function of the leadership
and/or team effort applied by the participants, but does not seem like it
should influence the assessment of its overall priority, which we are
currently expressing as value/benefit compared to difficulty/cost.   

 

Step 4:  The team previously considered adding a 3rd dimension (e.g. time or
size) and determined that it would not substantively add to the analysis and
might overly complicate the picture.   I went a step further on the last
call and suggested that, if the Council could effectively rank the active
projects in priority order without employing a two-dimensional
rating/ranking system, that would be the easiest and simplest approach!   I
believe that the sentiment was to stay with the Value/Cost idea at least
until we see how it works in a test scenario.

 

Comments welcome.

 

Ken

 

 

From: owner-gnso-wpm-dt@xxxxxxxxx [mailto:owner-gnso-wpm-dt@xxxxxxxxx] On
Behalf Of Jaime Wagner
Sent: Tuesday, December 01, 2009 9:41 PM
To: gnso-wpm-dt@xxxxxxxxx
Subject: RE: [gnso-wpm-dt] Update/summary from today's prioritization call
Importance: High

 

First of all I must apologize for my absence until now but it was
involuntary.  I was a victim of three technology problems in parallel. I'm
very sorry for that.

 

I read every message on the subject during the last three days and I'm very
well impressed by the evolution. Congratulations Olga, Chuck, Liz and Ken.

 

Even as a latecomer I would like to add some comments.

 

Step 1

Project, task, action item, all these terms have the same meaning of work to
be done. What varies is complexity. I agree with Wolf-Ulrich that we should
define a minimum time span or cost to consider some work to be done to
constitute a project in the future. I think the outcome of this group will
be a valuable tool to instruct Council decisions not only now but also in
the future.

 

I think the most difficult part of the job is to inform the newcomers as
myself about the whole set of 20 or more projects at stake.

 

Step 2

1)      In regard to the refinement of the definition of the value axis I
would amend as follows.

Y - Value/Benefit . this dimension relates to perceptions of benefit to: a)
the Internet global community; b) ICANN; c) its stakeholder groups, in this
order; in terms of internet growth/expansion, enhancing competitiveness,
increasing security/stability, and improving the user experience.
Qualitative factors might include:  extent/breadth of Internet community
impacted and criticality of project in resolving serious problems or in
opening new opportunities of growth. 

 

Step 3

In my opinion the categories proposed by Chuck in fact reflect a third (or
first) priority axis that we could call Momentum. This axis could have only
three grades as proposed:

a.       Projects that cannot stop or will move per se;

b.      Projects that have a good momentum right now but can lose it.

c.       Projects that are wandering at a low or intermittent pace

 

So I would like to come back to Chuck's proposition of firstly ranking or
classifying the projects in this Momentum Category axis. Then we could
follow with the prioritization of  all three categories in the two other
axis, which I think should be numerical with weights unevenly spaced (1, 2,
4, 8, 10, for instance).

 

I don't think this prioritization task would take more than two 2 hour
meetings once everybody is informed about every project (refer to my
observation in step1). 

 

For these meetings I favor the Delphi approach Liz mentioned in an earlier
message and which was not recalled. This same approach is used to assign
complexity ratings in SCRUM but with an internal facilitator (scrum master,
in this case). I my experience it converges relatively fast.

 

Step 4)

We would then have a three dimensional map (a cube) or three two dimensional
maps (one for each category).

 

Step 5)

With this picture in hand we should ask the question if the exercise was
indeed valuable to instruct a final one-dimensional prioritization. Because
priority, in the end, means just precedence in time, in other words, order.

 

 

 

 

Jaime Wagner
j@xxxxxxxxxxxxxx             

+55(51)8126-0916
skype: jaime_wagner

 

From: owner-gnso-wpm-dt@xxxxxxxxx [mailto:owner-gnso-wpm-dt@xxxxxxxxx] On
Behalf Of Gomes, Chuck
Sent: segunda-feira, 23 de novembro de 2009 23:10
To: Liz Gasster; gnso-wpm-dt@xxxxxxxxx
Subject: RE: [gnso-wpm-dt] Update/summary from today's prioritization call

 

Thanks Liz and Ken.  Please note my comments below.

 

Chuck

 


  _____  


From: owner-gnso-wpm-dt@xxxxxxxxx [mailto:owner-gnso-wpm-dt@xxxxxxxxx] On
Behalf Of Liz Gasster
Sent: Monday, November 23, 2009 6:56 PM
To: gnso-wpm-dt@xxxxxxxxx
Subject: [gnso-wpm-dt] Update/summary from today's prioritization call

 

Work Prioritization Drafting Team (WP-DT):

 

This email summarizes the action items from the teleconference today.  

 

As a precursor to developing a prioritization of GNSO's discrete project
work, in principle, the team supports a 2-dimensional model comparing
Value/Benefit to Difficulty/Cost as presented by Liz/Ken in an email to the
list dated 20 Nov 2009.   This construct may undergo additional refinements;
but, for the purposes of moving forward, it is accepted as a starting point
for further team discussions.    

 

The following six action steps are proposed by Staff so that the team can
finalize the design elements and begin testing/prototyping a specific
approach before it makes a final set of recommendations to the GNSO Council.


Step 1)           Finalize the actual project list and acronyms (3-4 letter
abbreviations) [Gomes, Chuck]  or (2-4 letter abbreviations)  [.see starting
table below pulled from the GNSO project (action) list].   Via the email
list, the team should confirm the listing, identify any other missing
projects (e.g. this one?), and approve the abbreviations.   The sequence
numbers are for identification and reference purposes only.  

Target Completion Date:  Tuesday, 1 Dec 2009  (finalize at next
teleconference-TBD)

 


Seq No.

Name

Abbreviation


1

WHOIS Studies

WHO1


2

New gTLDs-Special Trademark Issues

STI


3

Fast Flux 

FF


4

IDN Fast Track Implementation Plan

IDNF


5

Geo Regions Review Communitywide WG

GEO


6

Travel Policy 

TRA


7

Post-Expiration Domain Name Recovery

PED


8

Registration Abuse Policy WG

RAP


9

Joint ccNSO-GNSO IDN WG

JIG


10

PPSC-PDP Work Team

PDP


11

PPSC-WG Work Team

WGT


12

OSC-GNSO Operations Team

GCO


13

OSC-Constituency & Stakeholder Operations Team

CSG


14

OSC-Communications & Coordination Work Team

CCT


15

GNSO Constituency Reconfirmations

GCR


16

IRTP - Part B PDP

IRTB


17

Synthesis of WHOIS Service Requirements

WHO2


18

Registrar Accreditation Agreement

RAA


19

Internationalized Registration Data WG

IRD


20

Registry/Registrar Vertical Integration

RRVI


[Gomes, Chuck] I don't think the following are projects for prioritization,
at least not yet: #4 - IDNF;  #15 - GCR; #17 - WHO2.  And I am not sure #1 -
WHO1 is ready for prioritization. Finally, it is not clear that #20 - RRVI
is a GNSO project, at least not yet. 

 

Step 2)           Solidify the definitions for the two axes/dimensions (X,
Y).   The definitions below incorporate Chuck's recent additions and are
submitted to the team for further refinement and improvement.  

X - Difficulty/Cost . this dimension relates to perceptions of complexity
(e.g. technical), intricacy (e.g. many moving parts to coordinate), lack of
cohesion (e.g. many competing interests), length of time needed/expected;
availability/scarcity of resources and, therefore, overall cost to develop a
recommendation.  
 

Y - Value/Benefit . this dimension relates to perceptions of benefit to
ICANN and its stakeholders in terms of internet growth/expansion, enhancing
competitiveness, increasing security/stability, and improving the user
experience.  Qualitative factors might include:  extent/breadth of Internet
community impacted and criticality of project in resolving serious problems.


 

Target Completion Date:  Tuesday, 1 Dec 2009  (finalize at next
teleconference-TBD) 
[Gomes, Chuck] Good start on this. 

 

Step 3)           Utilize this drafting team to exercise and test the
ranking/rating methodology as a proof-of-concept:  

a)      Ensure that the process is user-friendly and straightforward to
execute

b)     As a byproduct of testing, realistic outputs will be created to show
what they might look like once the process is actually completed by the
entire Council; that is, results/outcomes will be easier to comprehend than
a "conceptual" or "hypothetical" model. 

Staff suggests that the WP-DT use exactly the methodology that it will
recommend to the Council, that is, if each Council member will be asked to
rate/rank individually, then the drafting team should do the same in its
test.   If, instead, the team thinks that the Council should form sub-groups
to produce consensus rankings/ratings, then Staff suggests that the WP-DT do
likewise.   Incidentally, this team could choose to execute one or more
different approaches and, after comparing the pros/cons of those various
trials, decide which one combines the best features.   

If only one option will be tested, then, this team needs to choose:  

a)      Should projects be rated (relatively) with a scale such as H, M, L
or ranked numerically?  If the latter option is selected, should ties be
permitted, that is, can two projects be ranked the same (e.g. 1-1-3-4-5-5-7
.)?  [Gomes, Chuck]  I prefer numerical rating because it allows for more
differentiation.  Ties are fine in my opinion. 

b)     Should Council members rate/rank individually or should sub-groups be
formed to discuss and recommend a single consensus answer from each one?   

Target Completion Date:  11 Dec 2009  (??? -- to be discussed at next
teleconference-TBD)[Gomes, Chuck]  Couldn't we finish these latter two by 1
Dec and then the former two by 11 Dec? 

Step 4)           Develop the results matrix/chart based on the
rankings/ratings produced in Step 3.  

Target Completion Date:  14 Dec 2009  (1-2 days after data have been
received by Staff)  

Step 5)           Team assessment of the construct and process/methodology
and recommendations.  

Target Completion Date:  21 Dec 2009   

Step 6)           Assuming no changes after Step 5, the team could then
focus on HOW it might utilize the data in terms of developing a
prioritization (the ultimate goal of this effort).   Prior to this stage,
Staff will prepare some guidance for consideration.  

Target Completion Date:  11 Jan 2010  (depending upon team meeting
schedules) 

 

The target complete dates above are meant to be suggestive only.  We expect
that they will be discussed/revised at the team's next meeting.  [Gomes,
Chuck] It would be great if we could finish before the 17 Dec Council
meeting but that may not be possible.  At the latest we should try to finish
before the first Council meeting in January. 

Once these six steps are completed, the WP-DT should have a clear product
and methodology to present to the Council.   

Staff stands ready to continue assisting in this effort in whatever ways you
deem productive.   

Regards,

Liz Gasster

Ken Bour