RE: [council] Staff utilization report

[Liz Gasster <liz.gasster@xxxxxxxxx>]

All,

Just a few clarifications in response to Jeff's email:


1.       I have not been asked whether the executive team is aware of the 
workload problem among GNSO policy staff.  But, since I've now been asked, yes, 
they are aware.


2.       Nowhere does staff recommend that the GNSO not take on any further 
work.  We simply say that staff cannot take on new work and continue with all 
of the existing work, managed/handled in the same way.  This is NOT the same 
thing.  I suggest that if the Council, for whatever reason, chooses not to 
delay or postpone some portion of current work, then there simply is no 
resource bandwidth to start new work.  So we are not making a recommendation, 
we are suggesting options under the circumstances just in case the Council 
concludes that certain new projects are more pressing than certain existing 
projects. If the Council wants to initiate new work without staff support, that 
is also an option of course.



3.       Jeff's points with regard to "freeing up hours" assumes that the hours 
indicated in our report are average hours that are constant. The hours/project 
report are not average hours for each project, they are actual hours for the 
week we studied. Jeff's analysis assumes too much regarding the utility of the 
data in the report.   The report is useful to show that staff worked 348 hours 
that week and what we did during those hours. It helped me validate that staff 
workload overall is still excessive.  In some cases the hours spent might be a 
useful guide of future work, in many cases it will not.  That is why I suggest 
Step 5 - where staff helps the GNSO Council estimate the resources that might 
be freed up if we handle projects differently.


We are happy to respond to questions, including detailed questions like those 
that Jeff raises about specific projects. On Whois, even if the Council rejects 
further studies, I am still implementing one study which will take some smaller 
number of hours to support.  The OSC may be on hiatus, but its work is not 
done.  The new constituencies work is pursuant to the Board mandate, I 
definitely think the amount of hours could be reduced over time, but there were 
Board deadlines to be met that staff was working on during the week of the 
study.  I am spending many hours personally on prioritization with the 
preparation of this report and this dialogue, and also the time I spent 
studying those new tasks, and how I think they might best be supported, so I do 
not think "prioritization" time will be eliminated.

I must also respectfully express grave concern about Jeff's proposal to 
consider 45 hours/week as the baseline work hours for staff.  We all strive to 
excel in our work and will likely work more hours.  Frankly that is a given, 
and is proven out by the crazy hours we've been working for years now.  The 
GNSO Council cannot dictate staff work hours, these are negotiated with our 
employer and subject to applicable employment laws.

Lastly, staff should be represented on any committee that is formed on this 
issue.

Best, Liz


From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On 
Behalf Of Neuman, Jeff
Sent: Wednesday, March 09, 2011 5:55 AM
To: Stéphane Van Gelder; Council GNSO
Subject: RE: [council] Staff utilization report

I would also like to add some of my own personal comments to Stephane's on some 
of the issues I see with this Utilization studies and the conclusions drawn 
from it.

1.  First, the utilization rate is drawn from a 40-hour work week which I 
understand is "ideal", but I would venture to say that none of us only work 40 
hours a week.  I wish this were the case, but unfortunately it is not 
especially when "admin" time is figured into the equation.  With "admin time" 
in the equation, most of us work at least 45+ hours per week.  If you were to 
figure in 45 hours per week per FTW (as opposed to 40), then the utilization 
rate drops from 126% to 112% (348/310.5 X 100)(assuming 6.9 FTEs).

2.  ICANN policy staff is recommending that the Council not assign any further 
work as a result of them being over capacity.  GNSO Council leadership has 
tried over and over again to figure out why this is the case and this report 
points out that some of the reasons staff is overworked have little if anything 
to do with the activities of the Council.  Yet the requests to reduce staff 
workload to my knowledge is ONLY going to the Council.  I have asked ICANN 
policy staff if this study and their requests to reduce work load has been sent 
to ICANN Executive Management and the ICANN Board, but have not gotten a 
response.  As a council, we have zero insight or control into the work that is 
assigned to ICANN Policy staff by the Board or by ICANN executive management, 
or for that matter any request that comes in from a constituency or stakeholder 
group for support.  From my estimates of the time as indicated in the snapshot, 
50 hours of its work comes from the Board and/or Executive team while another 
26 hours came from the request of new groups wanting to be constituencies.  
Combines that is nearly 2 full time employees (of the 6.9 that have been 
allocated to the GNSO).  The GNSO Council has absolutely no insight nor control 
over this work by ICANN Policy staff.

3.  I want us to engage in a constructive dialogue on this as I believe it is 
critical.  I had hoped not to have to drill down on individual hours and 
numbers in this utilization study, but because ICANN policy staff is making the 
recommendation that we take up no new projects as a Council, I think we need to 
start getting into the weeds a little, so here it goes. This is not meant to 
question the hours spent to date on the work, but rather an eye towards looking 
to the future.

a)  This study states that new Constituencies Support/Process is 26 hours per 
week.  I really do not believe that this will be (or even should be) the amount 
of this will require on an ongoing basis.  That is more than ½ of a full person 
in man hours and that seems really high.  Even if it were 10 hours, that would 
seem high, but lets assume for arguments sake that this could be reduced to 10 
hours per week.

b)  The OSC seems to be winding down its activities, correct, which is another 
14 hours.

c)  Unless a motion is approved at this Council meeting, the Whois studies 
would not be ongoing work, that would be another 10 hours.

d)  Registration Abused Policy WG is now closed and has morphed into Best 
Practices and UDRP, which is another 6 hours per week.

e)  I believe the GCOT work is completed or almost complete.  Another 2 hours.

f)  PPSC is down in the study at 6 hours a week, but I do not see more PPSC 
work in the next several months making way for the Standing Committee (which 
has a separate time allocation).

g)  With all luck, this work prioritization I think can be eliminated and 
become a burden for the Council and its leadership - another 14 hours.

Just looking at this quick math, making these changes would save us 68 hours of 
ICANN policy staff time.  Even if we went to the 100% level at 40 hours per 
week (But see #1 above), that would still leave us with 18 hours to play with, 
which is where I would put the new WHOIS studies which look like one or more 
may move forward and some other items the Council wants to achieve.

4.  So, if we commit to making even these small changes, what reductions can we 
expect from the Board and ICANN's Executive Team as that takes up nearly 2 
persons' time?  If even we can reduce that to 1.5 persons' time, that would 
give us another 20 hours to play with.

5.  Conclusion:  I do not believe it is fair to recommend that new projects be 
taken on.  I believe there is still room to play with AND I would like to see 
the ICANN Executives and the Board make the same commitments we are making in 
helping to achieve realistic workloads. This is a problem, but not just a 
problem for the Council.  This is a problem that needs to be handled with ICANN 
Executive Management and the Board.  As such, I would like to explore with the 
Council the formation of an exploratory committee comprised of GNSO Council 
members, ICANN Executive Management and ICANN Board members to look into this 
issue and figure out the best path forward.   The answer cannot be on a going 
forward basis that no more work can be done.

This is all my personal opinion and does not reflect the views of my company, 
my stakeholder group or others in Council leadership.


Jeffrey J. Neuman
Neustar, Inc. / Vice President, Law & Policy
________________________________
The information contained in this e-mail message is intended only for the use 
of the recipient(s) named above and may contain confidential and/or privileged 
information. If you are not the intended recipient you have received this 
e-mail message in error and any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately and delete the original message.


From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On 
Behalf Of Stéphane Van Gelder
Sent: Wednesday, March 09, 2011 7:14 AM
To: Council GNSO
Subject: [council] Staff utilization report

Councillors,

I wanted to get this out to you asap and hopefully you will have time to read 
this by the time we start our weekend discussions in SFO. To that end, I would 
like to thank Liz for providing a short format for this report that makes it 
easy and quick to read.

As you all know, we as a Council have been struggling with prioritization for a 
while now. Since the start of the year, we have stepped up our efforts. We have 
already deleted several projects that were either no longer active or just 
plain finished. We are also now looking at a pending project at each Council 
meeting (this is normally set for agenda item 2, except for SFO because of a 
scheduling conflict).

On top of those efforts, the Leadership team has been engaging in discussions 
with staff so that we can understand the resource issues that are coming to the 
fore more and more often.

At my request, Liz has provided some key data to help us in our understanding 
of the situation. This is summarized in the report below.

I want to thank Liz and all the policy and support staff for the outstanding 
work they provide for both the GNSO and the community as a whole. I personally 
feel very fortunate and privileged to be working with such talented people, and 
I continue to be humbled by staff's ability to take on such an intense workload 
without flinching.

Continuing with the personal comments, I feel that our (the ICANN community in 
general I mean) inability to manage our workload is one of the greatest dangers 
we face. It has been my experience, while on this Council, that there seems to 
be more interest in launching new projects, whatever those may be, than 
completing existing ones. And obviously, this way of doing things is not 
sustainable in the long run.

I am therefore not surprised to see staff raising an insistent red flag lately. 
But I also think it is unfair to ask the Council to tackle this by itself. We 
have no control over, and no clear vision of, the way staff is assigned to each 
project, be they GNSO or otherwise. As the recent consumer choice issue shows, 
we also don't have control over how the Board may send work our way. And I am 
sure, although I am happy to be corrected on this, that the Board does not look 
at current staff utilization levels before assigning a new project to ICANN's 
SOs and ACs. If they did, I don't think the Cartagena consumer choice 
resolution would have been made in the way it has.

So I think it is crucial that we as a community continue to look at this in 
great detail to try and find a way to improve. Currently, staff are basically 
telling us as a Council that we should no longer initiate new projects. Line 
that up with the tentative agenda for our SFO Open Council meeting, on which 
there are at least two motions that if adopted could add to the existing 
workload, and you can see we clearly have a problem.

Thanks,

Stéphane



Début du message réexpédié :