Thanks for all of your replies. They have been very helpful in clarifying this issue. In particular,
* our needs assessment process lacks adequate input from stakeholders outside of our IT division. This is a difficult problem to solve because most people tend to ignore requests for input on these issues. If the process we followed was as thorough as the process described by Heidi at her institution, it would both more accurately reflect our real needs, and I think that as a result our RFPs would indeed tend to be more solution focused as opposed to product focused. * Matthew's suggestion to "[l]ook to strategic planning documents and institutional mission statements if you're looking for language that will let you help shape how RFPs are generated/replied to" is absolutely brilliant. I think this kind of rhetoric that can be very powerful in a committee like this - campus initiatives are exactly the level at which such planning documents and mission statements often most clearly apply. One problem I've noticed that complicates the issue is the large set of cultural differences between central IT and faculty. E.g. they often talk in terms of customers, shared services, enterprise products, business processes, return on investment and industry standards - the language, I guess, of corporate IT. I'm sure it somehow translates to the academic environment, but I'm not sure that either group is exactly sure how it does. It clearly has at least something to do with why it is easier to get $120,000/yr to pay the annual licensing fee for a proprietary product than it is to get a competing open-source product for free and use that $120,000 to pay salary and benefits of an in-house developer to support it. Thanks again for all of your input, Jason 2011/2/18 Edward R. Swiderski III <eswider...@greencanyon.net> > I led Microsoft's public sector consulting services group for the Midwest > for a few years, and have lots of experience being one of the "big 3" you > mentioned above. That said, I'm long-standing advocate of open software and > platforms. > > However, because I was in Microsoft's consulting division, we responded to > RFP's with *solutions, *not products. The proposals I went after were > typically built for a particular product company in mind, and in fact it > was blatantly obvious at times. In those cases, there isn't much you can do > as there is usually a political force behind it. As a vendor, I prefer an > equal playing field when selecting RFP's, and I only went after the RFP's > that were as vendor agnostic as possible. Additionally, I would not specify > individual products in my high level overview--again, focusing on the * > solution*. > > The truth is, the product focused RFP's are becoming less popular (in my > experience). I would suggest to the committee that they should focus more > on the business solution, rather than a product. > > My $.02 > > Hope it helps! > > Ed > Edward R. Swiderski III > GreenCanyon | Business Technology Solutions > 312-622-1127 > 200 South Wacker | Chicago | IL | 60606 > <http://www.greencanyon.net> > On Thu, Feb 17, 2011 at 6:48 AM, MJ Ray <m...@phonecoop.coop> wrote: > >> Chris Tyler wrote: >> > I agree with Nicholas here: if an organization is looking for a >> > fully-supported solution, responding with an unsupported (or >> > community-supported with no SLA) DIY open source solution is a >> > non-starter. >> > >> > However, a competent consulting and support company can come in with a >> > FOSS solution [...] >> >> But if you mean a community-developed FOSS solution (rather than one >> developed mainly by the company but is also FOSS), then if the >> organisation insists on a guaranteed Service Level Agreement which >> puts all risk on the support company, the guarantee costs can make it >> uncompetitive. Guarantee companies cough up their skulls when you're >> trying to guarantee stuff you didn't make yourself. >> >> There are three possible ways round it: >> >> 1. you find new guarantee companies which I haven't discovered that >> offer better prices for FOSS; >> >> 2. you give a guarantee which is only backed by your company, which I >> feel is a bit morally grey unless you've got deep pockets, probably >> not what the requestor really wants and not really a good option for a >> co-op - but I think this is what a lot of people are doing and it'll >> cause much pain whenever any one organisation calls on service to the >> point where the support company collapses; >> >> 3. you persuade the organisation to reword the SLA. >> >> Which is most probable? >> >> So I guess my advice would be to make sure the wording of the target >> SLA doesn't effectively prevent honest FOSS bids. :-) >> >> Or maybe this cold is making me crazy this morning. :) >> >> Regards, >> -- >> MJ Ray <m...@phonecoop.coop> >> Kewstoke, Somerset, England >> _______________________________________________ >> tos mailing list >> tos@teachingopensource.org >> http://teachingopensource.org/mailman/listinfo/tos >> > > > _______________________________________________ > tos mailing list > tos@teachingopensource.org > http://teachingopensource.org/mailman/listinfo/tos > >
_______________________________________________ tos mailing list tos@teachingopensource.org http://teachingopensource.org/mailman/listinfo/tos
