Re: [council] Staff utilization report

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

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é :
> 
> 
>