Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Specifically, the DOI stated upfront in the RFQ that the solution had to be part of the Microsoft Business Productivity Online Suite. Google is making the argument that this is "unduly restrictive of competition,"

I don't actually know what the Microsoft Business Productivity Online Suite is, but if they're already using it for a lot of other stuff, I think it's pretty understandable to want their email system to integrate with it.



Nevertheless, an RFQ that shapes its requirements in such a way as to essentially name the winner before-hand is a serious problem.


This is actually a perfectly legitimate practice - there are various regulations that govern these types of single-vendor/single-product requests. Usually you have to show (based on an analysis of currently available solutions) that no product except the one named could possibly meet your requirements.

In this case, it appears that the DOI actually followed those rules and came to the conclusion that only MS could provide a working solution. Google is essentially saying in the complaint that

a) Their solution meets the stated requirements and the DOI knew about it.

b) It is unclear if Microsoft's solution even meets all the requirements (specifically the security requirements since Microsoft is not currently FISMA compliant and has a bunch of known problems in its exchange server)

therefore the justification for naming Microsoft's solution is invalid and solutions involving Google's product should have been allowed for consideration.

Since I didn't actually read the DOI justification (only Google's summary of it) and I am not familiar enough with the specific regulations that govern this sort of thing to comment on its validity, I simply wanted to point out that "naming the winner" in the RFQ is not enough to invalidate it and is not necessarily a problem if the proper research has been done.


IANAL and I didnt read the DOI paper, but as I think you are mostly right.

I think the DOI can require that a solution must be compatible with or have the same features as Microsoft's solution.

However, they cannot say the solution MUST be the Microsoft product, and I think that is what Google is arguing.


Common practice. When I was involved in doing RFPs for hardware, you were allowed to say "We need a computer. It needs to be 32 bit. It needs to have such-and-such amount of memory, be able to run Unix, and ..." You could even say what color it had to be.

Then they'd print a bunch of copies of these several hundred page documents up and mail them to IBM, Honeywell, Wang, DG and DEC and so forth for bids.

The guy at (say) DG would get this, see that the Govt wanted a Vax, and toss the RFP. IBM might try a bid, but usually the "Unix" bit would cause them trouble. [This was well before any serious IBM effort in Unix].


Are they naming the winner before-hand? A quick Google search seems to indicate that there are companies besides Microsoft that sell Microsoft BPOS. Presumably those companies can bid on this job.


BPOS is a Microsoft-hosted cloud service. There are various "Qualified Microsoft partners" who will essentially act as consultants to asses your needs and point you at the right Microsoft plan, but the per-user-month pricing is the same whether or not you go through any of those or direct to Microsoft, and the fee is always paid to Microsoft. The business model for the partners is just a time-and-materials on the consulting bit; they aren't true vendors who can compete on service price.

Their requirement is a single-vendor, single-source service that can only be obtained from Microsoft. That's naming the winner before you hold the contest.


Agreed. I'm really supprised that language like that made it through to the final RFP. I have been involved with RFPs at government organizations and legal is always supper careful about writing requirements that potentially restrict competition exactly because of risks like this. It is also just poor requirements writing, you should never specify the solution in the requirements, you are just cutting off so many possibilities


Really depends on the department. I have seen some that are almost "we already picked the winner" type stuff.


You don't get how these things things work.

An RFQ (request for quote) by its very nature is a request for specific commodities from an existing purchase contract, which are evaluated on a cost basis.

In it's simplest form related to IT, a server vendor has an part number for a hard drive listed on the GSA contract. Multiple resellers are able to sell that part. A RFQ is a solicitation that says "We would like to purchase 50 units of part #12345". The reseller with the lowest price wins.


Couldn't they ask for "compatible with Microsoft Business Productivity Online Suite" in that case? Or something similar.


Absolutely - but they they should have stated that.

There is a big difference between "should be compatible with" and "must be".


BPOS is now called Office 365.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: