[council] Staff utilization report

Fri Mar 11 02:52:31 UTC 2011

To be honest Andrei, yes, I am even more puzzled than before.

I thought your comments were about the way the Council manages its projects in general. Now it appears you are linking that to the implementation work currently being done on new gTLDs.

The Council is not involved in the day-to-day implementation of the program. Further, it is my understanding that Staff has also carried out most of the work they deem necessary in preparing the AG. Delays to the program are probably more attributable to the current talks between the Board and the GAC than anything linked to ongoing GNSO Council projects.

So I have to admit I don't really see the point you are making. But I'm sure we'll have lots of opportunity to discuss more over the weekend. Safe trip coming here and see you soon.

Stéphane

Le 9 mars 2011 à 22:15, Andrei Kolesnikov a écrit :

> Stephane, thank you for the prompt response. My proposal is positively in the interest of the sizable part of the internet community interested in obtaining a new generic top level domains. They don't care much about restructuring, setting internal processes and other issues. They want ICANN (and sequentially gNSO) to give opportunity to further extend the address space. They don't see the connection between desired .blablabla and PDP WT.
> It is a privilege to work in such intellectual and diverse environment in our Council. The hard work and results won't disappear! However there is a problem with acceptance of the PPSC importance over CCTC issues for example.  As a matter of experiment I would recommend to postpone administrative issues until new gTLD process will be open for the first applicants. Council can always return to it with much bigger practical data in hands in the future.  Is it still sounds puzzling and extreme?
>  
> --andrei
>  
> From: Stéphane Van Gelder [mailto:stephane.vangelder at indom.com] 
> Sent: Wednesday, March 09, 2011 11:27 PM
> To: Andrei Kolesnikov
> Cc: 'Council GNSO'
> Subject: Re: [council] Staff utilization report
>  
> Hi Andrei,
>  
> I find it slightly puzzling that as a Councillor, you would propose to simply stop and kill off projects that the community has asked the GNSO to work on, like our restructure for instance.
>  
> These projects were born out of reviews of previous processes which highlighted what were perceived as areas of improvement for us. It is the Council's responsibility to see them through.
>  
> I am not sure we would be sending the right signal by just saying, after asking many people to work hard on them and committing to carrying this work out, that we are simply going to stop dead in our tracks and cancel everything.
>  
> Although I understand the allure of a simple kill-switch solution, in this case I find it a little too extreme.
>  
> Thanks,
>  
> Stéphane
>  
>  
>  
> Le 9 mars 2011 à 21:04, Andrei Kolesnikov a écrit :
> 
> 
> Dear colleagues, this is a great work, thanks Liz & staff and I don't want to get into much details - there is no need to, just count numbers. This is a reflection of gNSO councilors work.
> I don't agree with Stephane, Council is not struggling with prioritization. Our problem is endless "process on how to manage process" discussions, tones of "process definition" documents, peculiar "texting" and arguing over easy to agree issues. Sometimes it gets worth and above mentioned used as a tool to slow down baby projects.  Look, the real matter starts from the row #7. I found  44 hrs in non-procedural projects from total 212 hrs in first table. Simple logic says to look into how we stop / outsource / give away the internal process projects.  This will give us a lot of time to focus on real gNSO matter: whois, raa, geo, competition, abuse, transfer, jas, etc. My proposal is to kill / hold for a few months the following projects/process/work teams
> New Constituencies Support/Process - freeze the process of review, don't expand! Let ALAC or Board do it!
> Policy Development Process Work Team - stop for 10 months, nothing will happen
> Operations Steering Committee - kill it, don't steer
> Work Prioritization - don't need if we have time
> GNSO SG/C Charter Reviews/Reconfirmations - stop for 10 months
> Standing Committee Drafting Team - don't start it
> Policy Process Steering Committee - kill it
> Working Group Work Team - kill it
> GNSO Council Operations Team - kill it, hire external company to audit
> Constituency & Stakeholder Operations Team - kill it
>  
> From now my only vote for the internal processes will be to stop it or no vote.  Join me, comrades! :)
> Many years ago there was a company called Digital Equipment Corporation... DEC. We bought equipment for many millions of dollars. It didn't help DEC to survive after the fact they were spending 80% of working hours defining a processes.
>  
> --andrei
>  
> From: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org] On Behalf Of Stephane Van Gelder
> Sent: Wednesday, March 09, 2011 3:14 PM
> 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é :
> 
> 
> 
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20110311/85055ba5/attachment.html>