Assignment: Informatics Organizations
Assignment: Informatics Organizations
Permalink:
Write a 1,400- to 1,750-word paper. In your paper, include the following:
- The purpose of an RFI
- The purpose of an RFP
- Include at least four references.
- Format your paper consistent with APA guidelines.
- Click the Assignment Files tab to submit your RFI and RFP Paper assignment.
HCI 500 WEEK 6 Informatics Organizations
In a 750 – 1,000 word summary:
Compile a list of five to seven national and regional informatics organizations.
Describe each one in at least 100 words.
Explain which organization you think could be most useful for you and why.
- Include at least five references.
- Format your paper consistent with APA guidelines.
Click the Assignment Files tab to submit your RFI and RFP Paper assignment.
RFI
Short for “request for information,” the RFI is really a preliminary document used by companies that don’t understand the marketplace they’re about to enter. In the case of a company searching for a CRM, for instance, it would use an RFI if it had no prior experience with CRM and wanted to gain an understanding on the range of options in the CRM space.
Because the RFI is more of a fact-finding document, you’ll want to ask open ended questions, ones that allow the vendor to talk about its full range of offerings. Typically, the RFI will state the broad business challenges you’re having, and then the vendor can tailor its response within the context of those challenges. Often times, the vendor will explain its position in the marketplace (for instance, what industries it specializes in), how it licenses its product, and what other fees you can expect.
RFP
An RFP, “Request for Proposal,” is a document that asks vendors to propose solutions to a customer’s problems or business requirements. An RFP is usually what follows an RFI; in fact, it’s rare that a company will go from an RFI to an RFQ (for reasons that will become clear below). An RFP should contain much more specificity in terms of what a company’s needs are by outlining the business goals for the project and identifying specific requirements that are necessary for the work being requested. The key to this document is that there is sufficient detail to give vendors the context they need in order to propose a valid solution, yet it still needs to allow enough leeway for the vendors to apply creativity and best practices to fulfill those needs.
RFQ
Short for “request for quotation,” the RFQ is an even more detailed document that drills down to the exact specifications required by the company. In a situation where an RFQ is used for a b2b software project, the company knows enough about its current system and exactly how it wants to change or improve it in the future.
Unlike the RFP, which allows for the flexibility of the vendor to suggest creative solutions to the problem, a company deploying an RFQ isn’t looking for creativity, but rather for the vendor to deploy the software using predetermined specifications. Typically, the RFQ contains a table that lists each requirement and then asks the vendor to assess its ability to meet that requirement. The vendor then will specify whether it can meet the requirement out of the box, whether it will require some configuration, whether it will require some custom code, or whether it will require leveraging a third party vendor.
Which one is best?
As a vendor, I come to this issue with certain biases, but I prefer the RFI-RFP route as opposed to an RFQ. Why? Typically, clients that come to us with an RFQ tend to be closed-minded in their approach. Because you’re not opening yourself to the creativity and the accumulated institutional knowledge of the vendor, you’re basically signaling that you don’t want to learn anything new, nor do you want to open yourself up to new approaches.
In my experience many customers mistakenly name their RFQ’s as an RFP’s, but when you go to respond you are not allowed to “propose” a variety of solutions and have subsequent conversations about your proposed options, which is the purpose of an RFP. In these cases, you are simply asked to fill out a list of requirements and give detailed costs for each line item, which by its definition is simply an RFQ. An RFQ is appropriate for a project in which you are adding on to or augmenting an existing system. I believe this approach is inappropriate for a project in which you are planning on implementing an entirely new system, as you can easily fall into the trap of requesting that vendors provide you a system that does exactly what your current system does. If that is the case, then you need to take a hard look at why you are implementing a new system in the first place and make sure your business goals are in line with your project goals.
Typically, you are looking to implement a new system because what you are using today doesn’t meet your needs. If that is truly the case, how can you know what systems out there will meet your needs unless you give the vendors the flexibility to discuss your current business processes in a collaborative manner? If you simply put out a list of detailed needs based on what you do today, you will get responses in which vendors try to shoehorn their solutions to meet that list and miss the opportunity to truly change your business for the better.
The RFQ mentality, in short, undercuts some of the positive changes you can see in your business processes as a whole. And turning a blind eye to change is the quickest path to a company’s obsolescence.
