[Previous] [Next]
[Previous] [Next]
The eventual contract to be signed by the institution and the selected supplier may incorporate the RFP document and the supplier responses to that document. In this way, all of the work that has been expended to develop the RFP and to evaluate actual supplier responses can be used as the basis for ongoing monitoring of contract obligations of both parties. This also underscores the importance of accurate statement of requirements and careful documentation of supplier responses on all points in the RFP.
The RFP is considered to be such a basic element in the evaluation of proposed systems that it is worthwhile to consider how the traditional RFP is composed. Appendix C describes a traditional form of RFP for a selection process concerned with specifying needs, measuring the relative value of these needs, evaluating responses to these measured requirements, and negotiating contracts based on these results. Your institution can adapt this model to your situation, depending on your institutional culture and level of sophistication, based on the key elements in this description.
Just as most RFPs are issued without containing any clearly stated goals and objectives for the performance of the desired system, i.e., what successful performance will look like to the user, they rarely contain any cost limitations either. Stating cost and resource limitations is interpreted as "tipping" the institution's hand to the supplier. It is recommended that cost expectations and considerations as well as human resources limitations and time considerations (e.g., how urgent the situation is with the present system) be obtained from all functional departments and conveyed to potential suppliers. Again, these should be stated in requirement terms rather than as proposed solutions.
It will probably simplify the selection team's task to consider the alternative of developing or migrating in-house systems in partnership with internal IT staff in the same light as external partnership alternatives--the strategies and requirements of the institution are the same for these alternate approaches. While this may seem to overformalize a process that involves people who know each other and who may in fact be members of the team, adopting this approach and establishing equal measures for each alternative will result in a much more informed and objective decision. Thus, although the RFP is usually developed primarily to deal with external suppliers, the process can also be used to validate proposals for in-house development.
Some emerging nontraditional RFP approaches are also worth considering, particularly where the primary goal is to establish a partnership that is based not so much on specific measures, but in the alignment of vision, mission, and common agreements on the value of entering into the partnership. An RFP developed in this way might actually include less in the way of technical specifications and more in the way of defining the outcome expected and requesting the parameters of a partnership that will result in the desired outcome. (See Appendix D for sample partnership criteria used by California Lutheran University in a recent acquisition.)
What is key in this approach is the articulation of the parameters of the partnership itself and gathering information about the values and strategic directions of the partner. This kind of partnership can occur between institutions, between the user office and the IT development personnel within an institution, between a consultant and an institution, between an institution and a supplier with a system product, and so forth. To enter into such a project will require careful analysis of the culture of both the institution and the intended partner(s), development of some measures that will identify how closely the partners are matched, and a method for identifying potential costs and time frames.
[Previous] [Next]