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 PROTECTED] > Sent: Thursday, January 13, 2005 20:16 > To: John C Klensin > Cc: Wijnen, Bert (Bert); EKR; Brian E Carpenter; ietf@ietf.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)" <[EMAIL PROTECTED]> 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@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
