Re: [council] Staff utilization report

[Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>]

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@xxxxxxxxx] 
> 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@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] 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é :
> 
> 
> 
>  
>