[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 20:53:49 UTC 2015


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 <mailto: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 <tel:%2B506%208837%207176>
> 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 <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 <mailto:accountability-cross-community-bounces at icann.org> on
> behalf of Carlos Raúl Gutiérrez"
> <accountability-cross-community-bounces at icann.org <mailto:accountability-cross-community-bounces at icann.org> on behalf of
> crg at isoc-cr.org <mailto:crg at isoc-cr.org>> wrote:
> 
> 
> 
> Carlos Raúl Gutiérrez
> +506 8837 7176 <tel:%2B506%208837%207176>
> 
> 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 <mailto: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 <mailto:crg at isoc-cr.org>
> Skype: carlos.raulg
> +506 8837 7173 <tel:%2B506%208837%207173> (cel)
> +506 4000 2000 <tel:%2B506%204000%202000> (home)
> +506 2290 3678 <tel:%2B506%202290%203678> (fax)
> _____________________
> Apartado 1571-1000
> San Jose, COSTA RICA
> 
> 
> 
> 
> 
> 
> 
> On Jul 27, 2015, at 9:30 AM, George Sadowsky
> <george.sadowsky at gmail.com <mailto: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 <mailto:Accountability-Cross-Community at icann.org>
> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
> 
> 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org <mailto:Accountability-Cross-Community at icann.org>
> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
> 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org <mailto:Accountability-Cross-Community at icann.org>
> https://mm.icann.org/mailman/listinfo/accountability-cross-community <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/9ef757b7/attachment.html>


More information about the Accountability-Cross-Community mailing list