Teaching the Development of Effective Requests for Proposals (RFPs) in the Area of Computer Hardware/Software/Services Selection John Maniotes and Charles R. Winer Computer Information Systems & Information Technology Purdue University Calumet Hammond, Indiana 46323, USA Abstract A fundamental task for IT educators is to help students understand the importance, composition, and legal issues involved in the development of effective RFPs. We present a proven methodology for achieving this goal, using a combination of lectures and student participation in teams, made up of groups of three students each. These student teams are involved in researching vendor companies and preparing detailed RFPs for either computer hardware, application software, IT networks, and/or IT services. Keywords: requirements analysis, RFBs, RFPs, selection approaches 1. INTRODUCTION Purdue University Calumet has offered for the past two decades a senior level course titled, CIS483 Computer Hardware/Software Selection, which has been described by (Maniotes 1999). A major component of the course includes the following topics: 1) Surveys of the computer and IS market places 2) Current trends in IS 3) Future trends in IS 4) Organizational and administrative considerations in the selection process 5) Analysis of needs (requirements analysis) 6) The composition of the Request for Proposal (RFP) 7) Vendor’s responses to the RFP 8) Case studies 9) The student team RFP project 2. INSTRUCTIONAL MATERIALS Instead of using a textbook, we have opted to make available on the Web and place on reserve in the library, articles, papers, and RFPs, dealing with the identified topics. Many of these materials are also available on the course’s Web site (http://bb.calumet.purdue.edu), accessible by all enrolled students of the class. Also, whenever possible, we have given the students, the URLs of these publications, so they may access the articles via the Web. Various companies, businesses, local government agencies, school districts, and organizations have contributed sample RFPs, Request for Bids (RFBs), Request for Information (RFIs), and Request for Quotation (RFQs) that are also placed on reserve in the library for the students to examine. During the past 20 years, we have also served as consultants to a variety of businesses, industrial organizations, local governments, and school districts. We have applied many of the fundamentals covered in the nine topics. As an integral part of these consultations, we have researched, designed, specified, evaluated, and implemented computer hardware, applications software, networks, and services. From these consulting experiences, we bring in a variety of real-world examples, not commonly found in textbooks. 3. TOPICS Anyone who engages in the art of selection must know the current market place and the trends occurring in the IS field (Topics 1, 2, and 3). Early in the semester, definitions of the computer and IS markets (vendors) are discussed. We have found that the annual market surveys published in The Wall Street Journal, Datamation, Software, Red Herring, and Upside magazines are very helpful and provide useful statistics on the composition of the market place as well as the market leaders. From these survey results, each student is assigned a case study (Topic 8) on a different vendor in the IS field. The students give three short in-class updates on their progress in developing their written short report describing the vendor’s main products or services, financial condition, R&D effort, market strengths, their competition, etc. Furthermore, students are required to make recommendations on whether it is advisable to do business with the assigned vendor and why or why not. The organizational and administrative considerations in the selection process (Topic 4) and requirements analysis (Topic 5) have usually been covered in great detail in other CIS courses. We simply conduct a review of these topics. We also review important feasibility tests and criteria used to determine when a manual application should be or not be automated. Topic 6, the composition of the RFP, covers the format of a typical RFP, the classification of the system requirements as mandatory vs. desirable or as general vs detail, the make-up of technical questionnaires for the RFP, and the ground rules and proposal instructions for vendors to follow in replying to an RFP. Sample RFPs and RFBs in the library are used as examples for students to examine. (Topic 6 is explained further in this paper.) Topic 7, vendor’s responses to the RFPs is best handled by either placing sample vendor responses on reserve in the library or inviting a vendor in to discuss this topic from the vendor’s perspective. Items dealing with a vendor’s support, pricing strategies and discounts, shipping and installation considerations, contractual terms and conditions, as well as how sales representatives are remunerated, are particularly helpful to students. Other topics include performance measurement approaches, which have been described by (Maniotes 2000). Feedback from various industry/academic advisory committees and from our IT alumni has convinced us of the need to establish these various topics. Topic 9, the student RFP project, involves each team of three students to create their own “company.” Each company is defined by the respective team to have specific assumptions that will guide its needs for specific hardware/software and/or IT services. The instructor then identifies additional specifics that all teams use in developing their specific RFPs for their own “company.” 4. THE RFP METHODOLOGY One of the most challenging aspects of this course is teaching RFP concepts and fundamentals to senior students, many of whom have never seen or heard about an RFP before. Fortunately, we have placed on reserve in the University library sample copies of RFPs, RFBs, RFIs, and RFQs which have been donated from many organizations. This enables students to peruse these documents at their leisure. We have also placed on reserve textbooks, such as (Haag 1998) and (Jessup 2002), which describe the RFP process. We also encourage students to surf the Web, particularly in the government information technology marketplace, where RFPs are frequently posted. Federal and state agencies encourage vendors to download, review, and reply to their RFPs electronically, eliminating paperwork and streamlining their receipt of vendor proposals. Students will see that the composition of these RFP documents varies and there isn’t a clear format/pattern that is followed. Selected Web site URLs that have examples of RFPs, etc are: http://www.mrsc.org/rfps/C52rfpweb.pdf, Clark County, Washington; http://doit.nv.gov/contracts-main.htm, Department of Information Technology, State of Nevada; http://www.cdc.gov/od/pgo/rfp/FinalRFP2000N00120.htm, Centers for Disease Control and Prevention, Atlanta, Georgia. A question often asked by many students is what are the important “main sections” of an RFP and what kind of information should the RFP contain. From our consulting experiences and past work with the University’s computer center, we have developed an easy to use outline for the composition of the “ideal” RFP as described in Table 1. It consists of four sections and six appendices which are further described in Tables 2 through 5. In short, the RFP is a document that clearly states a company’s business problem and the technology infrastructure of the company. Table 1. Main Sections of the “Ideal” RFP Section Title I Administrative and Procedural Information to the Vendor II Background Information on the Company III System Functional Requirements Defined by the Company IV Proposal Instructions and Technical Questionnaires for the Vendor Appendices Title A Programming Standards of the Company B System, Program, and Operation Documentation Standards of the Company C Map of the Company’s Campus D Current Forms/Reports used by the Company of System to be Replaced E Glossary of Technical Terms F Suggested Contractual Agreements by the Company In the following Table 2, the contents are to clarify information to assist the vendors in the preparation of their proposals. Table 2. Section I – Administrative and Procedural Information to the Vendor * Purpose of the RFP * Office or Department responsible for the RFP * How inquires are to be handled * Major pertinent dates and deadlines * General format and content for the submitted proposal by the vendors * How vendor presentations and demonstrations are to be handled * Evaluation criteria and process used to select the winning vendor(s) * Any special contractual terms or conditions required by the company Table 3 materials are used to give the company’s current information and environment as an aid to better inform prospective vendors who may make a proposal. Table 3. Section II – Background Information on the Company * Description of the company, such as products produced, location, geographic area, company organization chart, number of employees, etc. * Company’s present computer systems, PCs, operating systems, networks, database systems, applications software, etc. * Telecommunications vendors that company uses for telephone services, wireless communications, frame relay services, T1 communications, etc. * Internet service providers to the company As an aid to clarify the needs of the company, the contents of Table 4 are used to help prospective vendors better address the requirements of the company. Table 4. Section III – System Functional Requirements Defined by the Company * Detail description and profile of the current system to be replaced * Transaction volumes, activity, and other statistics associated with the system to be replaced * General functional system requirements and company location of proposed system * Hardware requirements for the computer systems, printers, scanners, communication access devices, networking hardware, etc. * System software requirements for the operating system, DBMS system/programming language, report generators, etc. * Application software functional requirements for each module and security considerations. * Education and training requirements for executives, managers, supervisors, programmers, operators, and clerical users. * Documentation requirements such as hard copies, CDs, DVDs, and on-line manuals * Installation, maintenance, and support requirements for the proposed equipment and software * Performance evaluation and acceptance criteria In order to better enable the company to compare vendor’s proposals, Table 5 gives specific ground rules that all vendors must follow. Table 5. Proposal Instructions and Technical Questionnaires for the Vendor * Description of the written proposal format that ALL vendors must follow * Cover letter format * Requirements that vendor can and cannot satisfy * Proposed hardware configuration, systems software, applications software, etc. * Proposed installation, maintenance, conversion, education and training schedules * Project organization schedule for de-installation of existing systems and installation of new system * Proposed vendor support services and backup facilities * Cost figures for all items proposed such as: purchase costs, rental, and lease with purchase options * Vendor’s standard contracts for items proposed * Description of technical questionnaires that vendors must complete. o Short question, short answer type/style o Yes – No type/style o Questions dealing on the requirements identified in Section III After the case study (Topic 8) is completed, each team of three students spends several (3) weeks defining their hypothetical company and developing assumptions on their company’s needs for either computer hardware, networks, applications software, IT services, etc. In other words, they are performing a requirements analysis on their fictitious company. Based on that information, the students compose an RFP document, using the format described in Tables 1 through 5 that explains in precise terms what their company needs are. Students define their company’s existing workflow, business processes (business model), and technology infrastructure. Students also create a detail blueprint of their company’s technology infrastructure. Regarding the needs of their company, students are asked to identify all mandatory needs and then all desirable needs. We assign several short exercises (Maniotes 2002), which makes the concept of mandatory and desirable needs clearer to all students. During lectures, we share real-life scenarios and discuss problems that we have faced in the actual development and administration of RFPs. We also inform students that based on superior RFPs, the proposals they elicit from vendors minimizes possible company/vendor misunderstandings in the future. RFPs and vendor proposals can also be incorporated into the final contract that serves as the legal criteria against which each side’s obligations can be judged. With the information contained in Tables 1 through 5, we feel students will leave the course with a clear understanding of the composition of a good, functional RFP. 5. THE STUDENT RFP All students in the course participate on this project, commonly known as the RFP Project (Topic 9). Students are allowed to select their own team members, three per team. Each team then chooses their Project Leader. Furthermore, each team faces the following challenges for the project: research, both technical and legal, and documentation. Over the past several years the following RFP projects have been dealt with: 1) A medium size company in need of payroll and financial application software including hardware considerations. 2) A municipal water billing system. 3) A high school district grading, scheduling, and attendance system and its corresponding financial applications. 4) A county law enforcement system. 5) A manufacturing company in need of a human resource system. 6) A payroll system for a small business. 7) Outsourcing services for a school system. 8) A network for a 10 member law firm. 6. PRESENTATIONS During the last week of the semester, a one hour appointment is scheduled with each team so they can present their work accomplished during the semester. The presentations are open to faculty of our department, school, and the university. Students from other teams are not allowed to participate in each others team’s final presentations. The instructor and faculty ask the questions. Students are expected to "defend" their RFP according to the specifications and their assumptions. The presentations take place in a large electronic classroom equipped with PCs. Their PowerPoint images and results appear on a large 6' by 6' screen for viewing. Prior to the final presentations, four checkpoints are used for the teams to get feedback from the instructor regarding their progress. An ongoing iterative version of their progress in completing the RFP is placed in the team’s project notebook. 7. PROJECT NOTEBOOK All teams are required to keep all their pertinent RFP activities in a project notebook. Furthermore, they are required to submit their project notebook each time they present a checkpoint to the instructor. After each presentation, the project notebook is graded and returned to the team with appropriate suggestions for improvement. The teams are also expected to prepare a professional formal report and place it in their project notebook The documentation in the formal report contains: 1) A cover page consisting of suitable information identifying the team and its members, course, institution and project. 2) A table of contents 3) An abstract of the RFP project 4) Gantt chart of the project 5) A list of assumptions made pertaining to their RFP and company 6) An introduction, including purpose, scope, etc 7) The RFP that the company will issue 8) A description of any innovative/unique solutions 9) Recommendations and conclusions regarding the RFP project 10) Bibliography of references 8. FEEDBACK FROM CIS ALUMNI The seniors who are enrolled in this course are system/networking, application programming, or systems analysis and design majors. They invariable ask, during the course, if they will prepare RFPs, RFBs, RFIs, and RFQs. Our reply is always an emphatic YES! However we caution the students that it will depend on where they work and in what capacity. Furthermore, we inform the students that in their professional IT lifetime, they will be involved with RFPs. etc., so they need to know as much about RFPs as possible. Some of our more mature students, who have been working in the Information Systems field for many years have said, “I wish I had taken this course earlier.” Many of our CIS alumni who have entered the ranks of IS management, have told us how valuable the topics and experience gained in this course has been to their careers. Many of these alumni are engaged in the art of preparing RFPs for computer hardware, software, networks, and IT services. Some of these alumni have even contacted the authors to have them assist in the development of comprehensive RFPs and to serve as their consultants on large corporate projects. Graduates who have completed this course have made comments to include, “This course should be mandatory for all CIS graduates” and “I wish that I would have completed this course two years ago, when I was involved in preparing an RFP for my company.” 9. CONCLUSIONS The following are some conclusions and recommendations to those faculty members thinking about teaching a course like this. Be prepared to spend extra time with your students. It is important that close supervision be maintained over the teams and the student RFP Project. Also, be prepared to update the papers and articles on reserve in the library, as well as your lecture notes. Develop a Web site to keep and post current information for your students. If possible, bring in guest speakers such as: 1) A MIS/IT director, who can discuss the RFP process from his organization’s perspective. 2) A vendor, who can discuss the RFP process from a vendor’s perspective. 3) A Chief Financial Officer (CFO), who can discuss his organization’s recent procurement decisions and what role the RFP played. 4) A lawyer, who can discuss the important clauses necessary in computer-oriented contracts and how to tie in the RFP and the vendor’s proposal to their contract. In many ways, tomorrow’s IT managers will be those who master their IT fundamentals in school, including how to develop effective RFPs. We endorse the concepts covered in this course for any CIS curricula. This should be a senior level, capstone, course taken by CIS majors. 10. REFERENCES Haag, S., M. Cummings, and J. Dawkins, 1998, Management Information Systems for the Information Age, Irwin McGraw-Hill, Boston, MA. Jessup, Leonard and Joseph Valacich, 2002, Information Systems Today, Prentice Hall, Upper Saddle River, NJ. Maniotes, John and Charles R. Winer, 1999, “Integration of Field Experiences in Computer Hardware/Software Selection: A Senior Capstone Course,” Proceedings of the 5th World Multiconference on Systemics, Cybernetics, and Informatics (SCI), 1999, July 31 –August 4, Vol. 8,, pp 464-470. Maniotes, John, Charles R. Winer, and Sam A. Maniotes, 2000, “A Computer Performance Course for an IS Program,” Proceedings of ISECON 2000, November 9-12, Paper 122. Maniotes, John, Charles R. Winer, and Sam A. Maniotes, 2002, Computer Hardware/Software Selection Omnibus, Purdue University Calumet, Hammond, IN.