ICANN ICANN Email List Archives

[gnso-wpm-dt]


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

[gnso-wpm-dt] RE: WPM-DT: Step 3a (Rating Test #1 - In Progress)

  • To: "'Ken Bour'" <ken.bour@xxxxxxxxxxx>
  • Subject: [gnso-wpm-dt] RE: WPM-DT: Step 3a (Rating Test #1 - In Progress)
  • From: "Jaime Wagner" <jaime@xxxxxxxxxxxxxxxxxx>
  • Date: Tue, 15 Dec 2009 00:14:39 -0200

Thanks Ken,

 

I agree that if we?re aiming just at prioritization and not at scheduling
there?s no need for capacity estimation.

 

But even so, in my case, I have just a faint idea of relative resource
consumption. My estimate will be very poor and I will be led by any opinion.

 

I was just now listening to the record of your conference on the 10th and I
collected some points to comment.

 

1)      Ken said: 

what we will do when we have all the individual ratings and all the
individual rankings or however we finally decide it we will aggregate them
all into a single chart.

 

Why not use directly the  <http://en.wikipedia.org/wiki/Wideband_Delphi>
Wideband Delphi technique that you referenced below and that is used in
SCRUM

1.      Coordinator (Ken) presents each expert (us) with a specification and
an estimation form. 
2.      Coordinator calls a group meeting in which the experts discuss
estimation issues with the coordinator and each other. 
3.      Experts fill out forms anonymously. 
4.      Coordinator prepares and distributes a summary of the estimates 
5.      Coordinator calls a group meeting, specifically focusing on having
the experts discuss points where their estimates vary widely

What we do here at UOL is: those participants that gave the extreme
differences have to justify and defend their reasoning before the whole
group 

6.      Experts fill out forms, again anonymously, and steps 4 to 6 are
iterated for as many rounds as appropriate. 

Could we try this approach in our meeting on the 17th? I think we are 7:
Olga, Chuck, Stéphane, Wolf,  Ken, Liz, Jaime. We could drop the requirement
for anonymity.

Note that the aim is not to come up with consensus (which often occurs). The
process finishes after a set amount of iterations (typically 3).

 

2)      Chuck said

when you form groups do you want those groups to be homogeneous or
heterogeneous?

 

There?s another kind of heterogeneity besides the interest group
represented. I?m talking about seniority and ?juniority? in GNSO.  Here I
think that an heterogeneous group would be beneficial, mixing new councilors
(as is my case) with more experienced ones (as Chuck, for instance).

 

3)      During wrap-up Ken said something I didn?t understand:

 

We?re obviously going to drop from four (unintelligible) mutations to just
three, or actually just two, maybe three, we?ll see. 

 

 

Regards

 

Jaime Wagner
j@xxxxxxxxxxxxxx             

+55(51)8126-0916
skype: jaime_wagner

 

From: Ken Bour [mailto:ken.bour@xxxxxxxxxxx] 
Sent: segunda-feira, 14 de dezembro de 2009 18:13
To: 'Jaime Wagner'; 'Gomes, Chuck'; 'Stéphane Van Gelder'
Cc: gnso-wpm-dt@xxxxxxxxx
Subject: WPM-DT: Step 3a (Rating Test #1 - In Progress)

 

Jaime:

 

In my view, the X-axis should not be about capacity, but about your
perception of how much resource a project will consume relative to the
others.

 

Perhaps an example might help.

 

Let?s say that I have 3 things on my TO DO list:

1)      Have my car battery checked

2)      Fix a leaking house faucet

3)      Put up exterior holiday decorations

 

On Value/Benefit, I rate them as follows:

1)      Average or 4

2)      Slightly Above Average or 6

3)      Moderately Below Average or 2

 

On Resource Consumption, I rate them as follows:

1)      I rate 5 due to the time commitment and inconvenience of driving to
dealership and waiting.

2)      I rate 1 because it?s simple, I have tools and spare washers.

3)      I rate 7 due to freezing temperatures, difficulty climbing on a
ladder, and danger of electrical wiring.

 

Note that my capacity to do than is not a factor, at this stage, only the
resource that will be consumed.

 

Now let?s assume that I only have capacity to do just one of the above
activities today.   One way to determine priority is to divide Y by X
yielding a benefit/consumption ratio:

1)      4/5 = .9

2)      6/1 = 6

3)      2/7 = .3

 

If I follow my own rating system, I would work them in this order:  2 ? 1 ?
3.   Project 2 delivers 6x more benefit per resource expenditure than
Project 1, so fixing the leaky faucet gets worked on first!

 

I hope that helps?

 

Ken

 

 

From: Jaime Wagner [mailto:jaime@xxxxxxxxxxxxxxxxxx] 
Sent: Monday, December 14, 2009 2:01 PM
To: 'Gomes, Chuck'; 'Stéphane Van Gelder'; 'Ken Bour'
Cc: gnso-wpm-dt@xxxxxxxxx
Subject: RE: [gnso-wpm-dt] WPM-DT: Step 3a (Rating Test #1 - In Progress)

 

In fact I tend to agree with Stéphane with respect to the resource
consumption axis estimation.

 

For me the difficulty is very close to impossibility.

 

What brings about my suggestion of uneven weights, which in view of the
situation, should be discarded. 

 

We do this when we have a good sense of resource capacity, which is not the
case, at least in my case.

 

So let me pose some questions: 

 

1)      how could we have an estimate of capacity?

 

2)      Which capacity are we talking about? Staff?s work hours?
Councilors?? Budget?

 

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, 14 de dezembro de 2009 13:49
To: Stéphane Van Gelder; Ken Bour
Cc: gnso-wpm-dt@xxxxxxxxx
Subject: RE: [gnso-wpm-dt] WPM-DT: Step 3a (Rating Test #1 - In Progress)

 

Please see my responses below.

 

Chuck

 


  _____  


From: owner-gnso-wpm-dt@xxxxxxxxx [mailto:owner-gnso-wpm-dt@xxxxxxxxx] On
Behalf Of Stéphane Van Gelder
Sent: Monday, December 14, 2009 9:40 AM
To: Ken Bour
Cc: gnso-wpm-dt@xxxxxxxxx
Subject: Re: [gnso-wpm-dt] WPM-DT: Step 3a (Rating Test #1 - In Progress)

Thanks Ken, 

 

Please find attached my contribution.

 

A few comments:

 

- I did not deem it necessary or even desirable to take the time to go back
to the RrSG in order to get feedback on rating. I consider this a test and
the points awarded only reflect my own personal judgment or experience.

- For the X axis, I consider the higher the number of points, the less
desirable the project (as it is consuming more resources).
[Gomes, Chuck] Not sure I agree with this if I correctly understand.  New
gTLDs would have been an undesirable project using this logic. It certainly
would have been rated very high on the X axis and rightly so but that would
not make it undesirable.  Maybe it is just a matter of not suggesting that a
high X axis rating does not mean desirable or undesirable projects.    This
is reversed for the Y axis (the more points awarded, the more a project is
worthy of the GNSO's attention).[Gomes, Chuck]  Again, I am not sure this
will always be true.  If this is consistent with everyone else's
understanding, it may be worthwhile making this very clear once the
definitive rating instructions are sent to the Council.

- I found the X axis very difficult to rate. It is impossible for me to have
a clear idea of the amount of budgetary resources a project requires without
having some kind of figure in front of me from staff. Would it be worthwhile
thinking about putting such a figure next to each project description listed
in the word document that came with Ken's email?[Gomes, Chuck]  Keep in mind
that budgetary info is just one aspect and that it may be very difficult to
get reasonable budgetary estimates early in the game.  For existing projects
it will be much easier to estimate budget impact; for new ones, it will be
more challenging.  If we ask for budget estimates from Staff to perform this
exercise, it will take us too long to do it. At the same time, each
Councilor should be able estimate resources required on a comparative basis
at a high level so as to be able to complete the exercise.

- I was surprised when rating to find that projects that tended to be of
lower value (according to me) also tended to require less resources (less
man hours spent on them, less expensive). I think there's something in that,
still trying to work out what it is ;)[Gomes, Chuck]  I think this
illustrates what I tried to say above.  Just because something requires
smaller amount of resources doesn't mean we should do it. 

 

Thanks,

 

Stéphane



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

Privacy Policy | Terms of Service | Cookies Policy