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

Tue Jul 28 19:20:59 UTC 2015

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