[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one
Carlos Raúl Gutiérrez
crg at isoc-cr.org
Tue Jul 28 17:13:59 UTC 2015
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
>>
>>
More information about the Accountability-Cross-Community
mailing list