[Previous] [Next]
V: Selecting the Solution


Issuing a Request for Information

If the acquisition strategy identified in the steering committee's report is to develop or migrate a system in-house in conjunction with the internal IT organization, the project management team will ask appropriate technology personnel to respond to the project parameters detailed in the requirements document. Assuming their response meets requirements, there will be no need to investigate potential external suppliers, and the team can proceed to establish the measurement parameters and contract for an in-house development project.

If the strategy identified in the steering committee's report is to purchase a product or consider partnering with a vendor and/or other institution(s) to develop a system, the requirements document can be used as the basis for developing a request for information (RFI) to be issued to potential external suppliers. Using the RFI process will facilitate the collection of preliminary information to be evaluated by the project management team in determining potential products for purchase or potential vendor or other partnerships to build a new financial system.

Essentially, issuing an RFI is a way for the institution to say, "Here are our needs; how would you address them?" The document differs from an RFP in that it usually is much less detailed (e.g., it will not include prices or timelines) and is essentially a simpler and less formal way of identifying suppliers who can address your needs, while simultaneously culling out those who cannot.

A good approach to take in developing the RFI is to use a combination of the institution's planning principles and business and technical strategies to produce a three-to-five-page list of critical, priority needs for suppliers to address. These should specify the actual institutional challenges and key functional requirements, as opposed to outlining a proposed solution. In other words, the RFI should take a "just the facts" approach, to encourage respondents to contribute their own key relevant data, eliminating the "fluff" data that can confuse reviewers and impede the evaluation process.

Most of the potential external suppliers and/or partners should have been identified earlier in the project (for example, by the steering committee and the business process teams in their initial environmental scans and the technology team in their "best practices" identification process). This list should be reviewed to eliminate as many unrealistic alternatives as possible, given the specifications in the requirements document. This process is sometimes described as a "knockout process," where particular parameters are used to eliminate one or more alternatives. For example, if the requirements specify that all administrative applications must come from the same vendor, any vendor that does not market a complete suite of applications can be eliminated upfront; if your specifications include client/server configurations, an SQL-supported relational database, a UNIX platform, or DCE-compliant technology, suppliers who cannot address these needs are also readily eliminated from further investigation. In terms of vendors in the marketplace, it is unlikely that the RFI will be issued to more than four to six at this point.

The RFI process will serve as the basis for validating the buy-build-partner decision, while the RFP will serve as the basis for selecting the specific product or partner, as well as a guide for the delivery and implementation of the system.


[Previous] [Next]