[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one

[Carlos Raúl Gutiérrez]

Carlos Raúl Gutiérrez
+506 8837 7176
Skype: carlos.raulg
On 28 Jul 2015, at 11:02, Greg Shatan wrote:
> One other note -- there seems to be a misunderstanding of what a
> "non-profit corporation" (and why it is called "non-profit").

No problem with reserves, contingencies, etc. ICANN has to big ones of 
80 million each. But still a problem with unrealistic income 
projections, and optimistic spending just because we have more money 
coming in tomorrow.

> A
> "for-profit" corporation pays out net profits to its owners 
> (shareholders
> or other types of owners).  A non-profit does not have owners or
> shareholders, so it does not pay out profits to anybody.  While an 
> entity
> can be " non-profit," this does not mean it is "non-surplus." 
> "Non-profit"
> does not mean that it is not supposed to run an excess of revenues 
> over
> expenses, or have no more assets than it has liabilities.  So, this 
> idea of
> "balance" is misplaced.

A healthy finial balance is always in place under the assumptions as per 
above.

> A non-profit, like a for-profit, needs to balance
> its books in an accounting sense, but that does not in any way mean 
> that
> there is a prohibition or even a presumption against having a surplus 
> of
> cash over expenses.

agree. Two sets of reserves of $80million/each is quite alright

> Greg


cheers
Carlos Raul
>
> On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez 
> <crg at isoc-cr.org>
> wrote:
>
>> Dear George,
>>
>> I agree with you that a cumulated budget veto is a pretty useless
>> accountability tool (independently of how difficult it would be for 
>> the
>> sole member to exercise it…)
>>
>> Moreover, I think the community on the one hand should take care that 
>> the
>> public interest objectives (policy development and compliance 
>> functions)
>> are properly funded. It would be much more effective if those 
>> separate hose
>> budgets (policy development and compliance functions) would be 
>> developed in
>> a bottom up fashion, based on the needs of the community, and through 
>> the
>> communities direct involvement. No need for a veto then since the 
>> SOs/ACs
>> would be DIRECTLY responsible for their budgets.
>>
>> On the other hand, it is up to management to guarantee the financial
>> BALANCE  of the day to day operations (yes, balance because ICANN 
>> purpose
>> is non for profit), as well as guarantee the demands of the community 
>> for
>> proper funding of the public interest functions (independently of the 
>> line
>> overseer of the functions, which is another black box altogether).
>>
>> This would be in my view a much more effective system of so called 
>> “checks
>> and balances”  than an absolute veto over the cumulated budget, 
>> where the
>> community has little knowledge on the different objectives under it 
>> was
>> produced, and remains in my eyes will very obscure, independently of 
>> the
>> overall sum in relation to the size of the business.
>>
>> Best
>>
>>
>> Carlos Raúl Gutiérrez
>> _____________________
>>
>> email: crg at isoc-cr.org
>> Skype: carlos.raulg
>> +506 8837 7173 (cel)
>> +506 4000 2000 (home)
>> +506 2290 3678 (fax)
>> _____________________
>> Apartado 1571-1000
>> San Jose, COSTA RICA
>>
>>
>>
>>
>>
>>
>>
>> On Jul 27, 2015, at 9:30 AM, George Sadowsky 
>> <george.sadowsky at gmail.com>
>> wrote:
>>
>> All,
>>
>> These are my personal opinions.
>>
>> I suspect that the reaction to this post will be, "we are way past 
>> this,
>> we've discussed this, and now just help us work on the implementation
>> details."  If so, I think that's a mistake, because what I'd like to 
>> do is
>> question one of the fundamental assumptions behind what this group is
>> doing.
>>
>> When this process started, there was general agreement that it was 
>> more
>> important to do this right than to do it quickly  Unfortunately, this
>> feeling appears to have reversed, with the current sense that it is 
>> more
>> important to get it done quickly in the name of the transition than 
>> to
>> spend the time needed to do it right.  This process is going beyond
>> accountability to a fundamental redesign of ICANN, with IMO 
>> inadequate
>> concern for assuring inclusivity of support as well as lack of 
>> concern for
>> unanticipated consequences.
>>
>> So here's what I'd like to contribute ...
>>
>> I've been uncomfortable with the notion of budgetary control/veto 
>> since
>> the idea was first presented.  I think that I now know why: in my 
>> opinion
>> it solves the wrong problem, and it is the wrong solution to the 
>> right
>> problem.  Let me explain.
>>
>> In general, budgetary control is exercised by groups who want to 
>> control
>> an aggregate budget, whether for reasons of limiting growth or 
>> ensuring
>> that aggregate expenses for a budget do not exceed some measure of 
>> income.
>> I don't think that's the case here, although I suppose that under
>> exceptional circumstances it might be.
>>
>> The alternative is that the control the group appears to want must be 
>> by
>> program or even by line item, even though you're planning to use a 
>> very
>> blunt instrument  --  control over approval of the aggregate budget  
>> --  as
>> your tool to accomplish this.  If that's the case, then what you 
>> really
>> want is programatic control, not budgetary control.  If the program 
>> is
>> accepted, then subject to resource constraints, it's up to the staff 
>> to
>> deliver, and any specific line item or similar objection, however
>> expressed, interferes with the execution of the activity.
>>
>> If the disagreement is with the program, with the objectives to be
>> accomplished, and how the objectives are to be accomplished, then 
>> that is
>> where the control should be exercised.  Any budgetary control after 
>> that is
>> micromanagement.  The response to that is if you don't trust the
>> organization to implement a rather well defined activity, then change 
>> the
>> management/staff, don't restrict their resources and let them 
>> continue
>> anyway.
>>
>> I suggest pursuing this line of argument further.  In my opinion, our
>> fundamental problem has two components: (1) a persistent inadequate 
>> level
>> of trust between groups within the ICANN community, and (2) our
>> inability/unwillingness to create and use structures to deal directly 
>> with
>> this situation and improve it.   I see the mechanism as starting with 
>> a
>> lack of trust   --  in Board, management, staff, as well as the ACs 
>> and the
>> SOs and their constituent parts  -- that generates not only suspicion
>> regarding motives, non-transparent actions, and actions that are not
>> equally favorable to all groups involved, but also the sense that the
>> process is not serving "me" (whoever I am) well and is therefore out 
>> of
>> control.
>>
>> In other words, IMO we have a fundamental problem of trust, and we 
>> don't
>> have an effective way to talk about it or to otherwise address it, 
>> much
>> less solve it.
>>
>> The budget rejection process that is being defined by the group is 
>> IMO
>> based more upon defining ultimate ("nuclear" if you like) 
>> confrontation
>> mechanisms than upon finding cooperative mechanisms to identify and 
>> resolve
>> potential conflicts at an earlier stage.  It does not address the 
>> trust
>> issue, and to the extent that my hypothesis is correct, if not 
>> addressed
>> the trust issue will continue to bedevil ICANN activities, in other
>> probably equally destructive ways.   Should not this group be equally 
>> or
>> more concerned about mechanisms to identify issues and encourage
>> cooperative-based and trust building processes to solve problems as 
>> they
>> arise?   It does not appear so to me.
>>
>> In summary, the current approach, gaining more control over budget
>> approval, is based upon a model of checks and balances, and that may 
>> be
>> legitimate to some extent.  However, I sense that is not the way in 
>> which
>> it is planned to be employed.  If so, it solves the wrong problem, 
>> nad it
>> does not address the real problem.   We need a different approach, 
>> one of
>> getting to the root of disagreements, real and perceived, that is 
>> early and
>> based upon increased cooperation and trust, and we need a way to
>> communicate that encourages this to happen.  This is not an easy 
>> problem to
>> solve, but IMO it's the real problem that we have to solve, rather 
>> than
>> some well meaning but inaccurate proxy representation of it.
>>
>> Please consider these thoughts in your discussions.
>>
>> George
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>