Subject: Re: Consensus? #733 Outsourcing principle

From: "John Loughney" <[email-masked]>
Date: Wed, 12 Jan 2005 15:32:42 +0200

"Minimum staff required" seems uncomfortably worded to me. I am not sure we need to go into this detail, for the reason Scott listed. If we do need to have this leel of detail, could we say 'sufficient staff' or something along those lines?

John L

------------------- Original message -------------------
Subject: Re: Consensus? #733 Outsourcing principle
From: "Scott W Brim" <[email-masked]>
Time: 01/12/2005 7:29 am

On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote:

> In principle, IETF administrative functions should be
> outsourced. Decisions to perform specific functions
> "in-house" should be explicitly justified by the IAOC
> and restricted to the minimum staff required, with these
> decisions and staffing reviewed by the IAOC on a regular
> basis and against a "zero base" assumption.
>
"Minimum staff required" is a little difficult.  One can do anything 
with existing staff if quality and timeliness don't matter.  The IAOC 
has to determine those parameters as part of deciding staffing levels.  
I suggest "minimum staff required to perform the functions 
satisfactorily as determined by the IAOC", or something along those lines.

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Jan 2005 21:21:01 +0100

> --On torsdag, januar 13, 2005 10:37:22 -0500 John C Klensin 
> <[email-masked]> wrote:
> 
> > *footnote: I think the document may be confusing (I hope not
> > confused, and I trust it isn't deliberate) as to whether all of
> > these pointers to "outsourcing" imply
> >
> > 	-- hire an organization, with its own staff, etc., to
> > 	perform a particular function, or
> > 	
> > 	-- hire a collection of individuals, but on a putative
> > 	independent contractor basis, rather than employees
> >
> > I have generally assumed that we are talking about the first
> > model
> 
> So had I.
> 
Same here.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Jan 2005 21:21:02 +0100

Whether you call it RFP or RFI (sorry I don't do these things, so
I may be mis-using terminology), the result is (I think) that 
if bidder A says they can do it with 2, Bidder B with 5 and Bidder C
with 15 people, then I Think one would find the number for C to
be bloated (for whatever reasons).

Anyway... enough about this as far as I am concerned

Bert

> -----Original Message-----
> From: Carl Malamud [mailto:[email-masked]]
> Sent: Thursday, January 13, 2005 20:16
> To: John C Klensin
> Cc: Wijnen, Bert (Bert); EKR; Brian E Carpenter; [email-masked]
> John makes a very good point.  I prefer to think of these types of
> documents as a "Request for Information" (RFI), which is a common
> contracting mechanism.  It allows vendors to make general 
> presentations
> about their capabilities, and that allows the host institution to
> put together a "short list" of potential contractors with whom
> they can engage in serious discussions.  Those discussions then
> result in negotiations and, hopefully, the selection of a vendor
> and the execution of a contract.
> 
> The RFI ensures that everybody knows this opportunity is there.
> That's different than a binding RFP where criteria for selection
> (e.g., "10 points for lowest cost, 10 points for technical
> aptitude") are published in advance and then applied based on
> the proposals submitted.
> 
> Regards,
> 
> Carl
> 
> > 
> > 
> > --On Thursday, 13 January, 2005 17:42 +0100 "Wijnen, Bert
> > (Bert)" <[email-masked]> wrote:
> > 
> > >> We definitely do want to discourage egregious bloat of direct
> > >> staff posts, but we also want to discourage egregious bloat
> > >> at the contractors we outsource to. I'm not sure why people
> > >> think there is more risk of one than the other.
> > >> 
> > > 
> > > With the outsourcing model, my underastanding is that we want
> > > to do it via an RFP process, and so that would help (I hope)
> > > reduce bloat.
> > 
> > Bert,
> > 
> > It is not easy to write really good RFPs.   Indeed, it is
> > generally quite hard.  Perhaps more important in this context,
> > normal RFPs are good at explaining to would-be bidders or
> > contractors what will be expected, but don't necessarily provide
> > good explanations of why we would want it done or how we justify
> > it.   If poor RFPs go out, or poor contracts are written, we end
> > up with contractor-management or renegotiation problems that are
> > typically more difficult than employee job descriptions and
> > contracts, since the latter usually include "such additional
> > tasks as required" clauses.  No sensible external contractor
> > agrees to such a clause without the ability to renegotiate the
> > agreement, demand additional fees, etc.  A comitment to an RFP
> > process does ensure that the IASA puts resources into
> > RFP-writing, RFP-evaluating, and similar activities that may be
> > useful but may not, for a given situation be, to use EKR's term,
> > efficient.
> > 
> > If we get multiple bidders on the same well-written RFP, we can
> > perhaps expect them to compete to produce the lowest price or
> > fewest staff needed to meet the RFP/contract provisions.
> > However, the Internet community had not had wonderful
> > experiences with "low bid" contracting, especially if the RFPs
> > are not exceptionally well written: getting the job done well is
> > often more important than getting the job done at the minimal
> > level needed to conform to an RFP or contract.
> > 
> > So, with or without "an RFP process", we are back to needing to
> > trust the judgment and skills of the IAD and IAOC, with the
> > remedy of firing the latter if they screw up often enough.  An
> > RFP process followed by an outsourcing contract does require
> > that expectations be written down.  That is a good thing, but
> > there might be other, more efficient, ways to accomplish it in
> > some cases.   And, again, it doesn't help much to assure us that
> > sensible decisions are being made about bloat-minimization: that
> > is a program analysis and evaluation function, not an RFP one.
> > 
> >     john
> > 
> >

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Jan 2005 19:04:18 -0500

--On Thursday, 13 January, 2005 21:21 +0100 "Wijnen, Bert
(Bert)" <[email-masked]> wrote:

> Whether you call it RFP or RFI (sorry I don't do these things,
> so I may be mis-using terminology), the result is (I think)
> that  if bidder A says they can do it with 2, Bidder B with 5
> and Bidder C with 15 people, then I Think one would find the
> number for C to be bloated (for whatever reasons).
> 

Bert, let me take a last shot at explaining why the problem
isn't just about terminology (and why you may have missed the
key problem) by changing your scenario a little bit.    

(1) Suppose one puts out a document soliciting proposals and
price quotes on some activity X (that falls into the range of
what is usually called an "RFP").  And let's assume you get
proposals offers back from five entities, with proposed head
counts of
     A  2
     B  3
     C  15
     D  16
     E  18

Now, one hypothesis is that C is bloated and D and E are even
more bloated.   Another hypothesis is that A and B fundamentally
don't understand the problem or, even worse, one of them is
clueless and the other has gamed the situation and concluded
that, by the time the IAOC figures out that the job cannot be
done with 2 or 3 people, it will be too expensive to recompete
the deal so they will have no choice by to renegotiate the
contract to cover C's headcount at E's price.

Note that (other than the fact that I moved the A and B numbers
closer together for clarity), the scenario above cannot be
distinguished from a variation of your scenario in which D and E
read the RFP, concluded that it was poorly-written enough to
attract clueless low bids, and decided it was worth making
proposals about, so all you would see would be the A, B, and C
bids.

This is where a proposer qualification process of some sort (RFI
or otherwise) comes in.  It functions at least to reduce the
odds of someone clueless making a proposal, but may not
eliminate fraudlent or "gamed" bids.  An even more complex
process may involve a dialogue with potential bidders (usually
RFI-driven), followed by generating a very specific RFP that
everyone agrees covers the work and collecting what then become
simple competitive bids (from among those who participated in
the drafting process) from the proposers.  That sometimes works
well, but is very complicated to administer and is rarely
appropriate for small contracts (if only because proposers can
rarely be persuaded to play).

(2) _However_, none of the helps with what is really the key
question, which is whether X needs doing.  Perhaps some much
smaller project, Y, would do the job instead.  And that was the
problem I was trying to comment about earlier today.   No RFP,
RFI, or equivalent process will help with the problem of whether
the IAD and IAOC makes good decisions about how to define the
tasks and scope that are optimal for the IETF.  Our protection
there is to make it clear that optimality and efficiency are
important, that we put high value on defining tasks to require
the minimal headcount and money needed to get them done well,
that we make sure those decisions are visible to the community,
and that the IAOC is held accountable for them.  IMO, those
principles should be shown clearly in the BCP.   Anything else
-- outsourcing versus hiring, RFPs versus RFIs, and so on-- are
all issues that the IAOC should work out (and review regularly)
but are distractions (or handcuffs) if they appear in the BCP.

     john