ietf
[Top] [All Lists]

RE: Consensus? #733 Outsourcing principle

2005-01-13 13:37:45
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:carl(_at_)media(_dot_)org]
Sent: Thursday, January 13, 2005 20:16
To: John C Klensin
Cc: Wijnen, Bert (Bert); EKR; Brian E Carpenter; ietf(_at_)ietf(_dot_)org
Subject: Re: Consensus? #733 Outsourcing principle


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)" <bwijnen(_at_)lucent(_dot_)com> 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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>