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

Greg Shatan gregshatanipc at gmail.com
Tue Jul 28 20:54:32 UTC 2015 

Great!  Glad we are back on the same page.

Best regards,

Greg

On Tue, Jul 28, 2015 at 4:53 PM, Carlos Raúl Gutiérrez <crg at isoc-cr.org>
wrote:

> No prob Greg!
>
> I truly believe Budget should remain in WS2 in any case as you proposed.
> We need to delve much deeper into the financial aspects of all this.
>
> cheers
>
> 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 28, 2015, at 2:51 PM, Greg Shatan <gregshatanipc at gmail.com> wrote:
>
> Carlos,
>
> I read what you said originally ("financial BALANCE  of the day to day
> operations (yes, balance because ICANN purpose is non for profit") as
> being based on the incorrect idea that a non-profit can't have a profit (a
> common misunderstanding).  Clearly, that's not what you were saying, and
> you understand that "non-profit" is not quite so literal a term.  Sorry I
> misunderstood you.
>
> Greg
>
> On Tue, Jul 28, 2015 at 4:45 PM, Carlos Raúl Gutiérrez <crg at isoc-cr.org>
> wrote:
>
>> 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
>>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150728/77b2b42e/attachment.html>

More information about the Accountability-Cross-Community mailing list