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

Tue Jul 28 20:45:57 UTC 2015

Thank you Samantha!

Xavier was very clear on the Reserve funds strategies during his last 
presentation to the GNSO Council in Buenos Aires and I praise him for 
that. I don´t consider creating those reserve funds outside the good 
practices of Non-for-Profit corporations, like Greg Shatan tried to 
imply in his reply.

Carlos Raúl Gutiérrez
+506 8837 7176
Skype: carlos.raulg
On 28 Jul 2015, at 13:20, Samantha Eisner wrote:

> Carlos, as a point of reference, ICANN has an investment policy in 
> place
> (https://www.icann.org/resources/pages/investment-policy-2014-07-30-en)
> that is regularly reviewed by the ICANN Board, which includes 
> principles
> on how funds held by ICANN are managed, as well as the size of the 
> reserve
> fund.
>
> On 7/28/15, 10:13 AM, 
> "accountability-cross-community-bounces at icann.org on
> behalf of Carlos Raúl Gutiérrez"
> <accountability-cross-community-bounces at icann.org on behalf of
> crg at isoc-cr.org> wrote:
>
>>
>>
>> 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
>>>>
>>>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community