Request For Proposal (RFP) In the area of computer hardware ...

8,902 views

Published on

Published in: Technology

Request For Proposal (RFP) In the area of computer hardware ...

  1. 1. Request For Proposal (RFP) In the area of computer hardware/software/services Yulia Andriyanets
  2. 2. Main Topics <ul><li>What is RFP? </li></ul><ul><li>High level stages of RFP. </li></ul><ul><li>Composition of “ideal RFP”. </li></ul><ul><li>The weak points of the RFP. </li></ul><ul><li>Agile RFP process: </li></ul><ul><li>*Agile methodologies & XP </li></ul><ul><li>* Optimizing RFP </li></ul><ul><li>* RFP Specification </li></ul><ul><li>*RFP Evaluation process </li></ul>
  3. 3. What is an RFP? RFP is the business process a company executes in order to find the vendor and/or product that best meet their criteria.
  4. 4. In the Industry the RFP belongs to a family of documents which have structure resemblance. <ul><li>RFB – Request for Bids. </li></ul><ul><li>RFI – Request for Information. </li></ul><ul><li>RFQ – Request for Quotation. </li></ul>
  5. 5. A Simplified List Of The High Level Stages In The RFP Business Process Include: <ul><li>Specification: Company specifies the hardware/software/services requirements and general project constraints (time, cost, process etc) and issues an RFP document to candidate vendors. </li></ul><ul><li>Proposal: Vendor assesses the requirements and delivers their response, witch includes their proposed solution, constraints, and cost estimate. (sometimes a customization of an existing vendor product may be proposed). </li></ul>
  6. 6. A Simplified List Of The High Level Stages In The RFP Business Process Include: <ul><li>Evaluation: Company evaluates the responses and select a vendor based on a consideration of how well their proposal meets the requirements and satisfies the project constrains, notably time and cost. </li></ul><ul><li>Implementation: Company and vendor implement the solution. </li></ul>
  7. 7. The difference between RFPs- and the need in “Ideal RFP”. <ul><li>Each student will get a copy of two documents (RFP): </li></ul><ul><li>1.Request For Proposals (RFP) Number 2003-1- “Pilot Multi-state Information Sharing System (Pegasus)”. </li></ul><ul><li>http://www.iacptechnology.org/RFPInfo/PegasusRFP.pdf </li></ul><ul><li>2. CLARK COUNTY REQUEST FOR PROPOSALS (RFP) Number 218 – “COUNTY WEB SITE DESIGN CLARK COUNTY, WASHINGTON.” </li></ul><ul><li>http://www.mrsc.org/rfps/C52rfpweb.pdf </li></ul>
  8. 8. The difference between RFPs- and the need in “Ideal RFP”/ effective. <ul><li>The students will have to answer if they see differences? </li></ul><ul><li>If they can understand what are the important “main sections” in those documents? </li></ul><ul><li>Do they think that some information is missing? Or maybe they got to much information that made them “get lost” in the document? </li></ul><ul><li>What are the main difficulty in writing RFP? </li></ul><ul><li>(system requirements & evaluation) </li></ul>
  9. 9. MAIN SECTIONS OF THE “IDEAL” RFP (1) / Dr John Maniotes & Charles Winer <ul><li>Section Title </li></ul><ul><li>I Administrative & Procedural </li></ul><ul><li>Information to the Vendor. </li></ul><ul><li>II Background Information on the </li></ul><ul><li>Company </li></ul><ul><li>III System Functional Requirements </li></ul><ul><li>Defined by the Company </li></ul><ul><li>IV Proposal Instructions & Technical </li></ul><ul><li>Questionnaires for the Vendor </li></ul>
  10. 10. MAIN SECTIONS OF THE “IDEAL” RFP (2) <ul><li>Appendices Title </li></ul><ul><li>A Programming Standards of the Company </li></ul><ul><li>B System, Program, & Operation </li></ul><ul><li>Documentation Standards of the Company </li></ul><ul><li>C Map of the Company’s Campus </li></ul><ul><li>D Current Forms/Reports used by the Company </li></ul><ul><li>of System to be Replaced </li></ul><ul><li>E Glossary of Technical Terms </li></ul><ul><li>F Suggested Contractual Agreements by the Company </li></ul>
  11. 11. ADMINISTRATIVE & PROCEDURAL INFORMATION TO THE VENDOR <ul><li>Purpose of the RFP </li></ul><ul><li>Office or Department responsible for the RFP </li></ul><ul><li>How inquires are to be handled </li></ul><ul><li>Major pertinent dates and deadlines </li></ul><ul><li>General format and content for the submitted proposal by the vendors </li></ul><ul><li>How vendor presentations and demonstrations are to be handled </li></ul><ul><li>Evaluation criteria & process used to select the winning vendor </li></ul><ul><li>Any special contractual terms or conditions required by the company </li></ul>
  12. 12. BACKGROUND INFORMATION ON THE COMPANY <ul><li>Description of the company, such as products produced, location, geographic area, company organization chart, number of employees, etc. </li></ul><ul><li>Company’s present computer systems, PC’s, operating systems, networks, database systems, applications software, etc. </li></ul>
  13. 13. SYSTEM FUNCTIONAL REQUIREMENTS DEFINED BY THE COMPANY (1) <ul><li>Detail description & profile of the current system to be replaced </li></ul><ul><li>Transaction volumes, activity, & other statistics associated with the system to be replaced </li></ul><ul><li>General functional system requirements & company location of proposed system </li></ul><ul><li>Hardware requirements for the computer systems, printers, scanners, communication access devices, networking hardware, etc. </li></ul><ul><li>System software requirements for the operating system, programming language, report generators, etc. </li></ul>
  14. 14. SYSTEM FUNCTIONAL REQUIREMENTS DEFINED BY THE COMPANY (2) <ul><li>Application software functional requirements for each module and security considerations. </li></ul><ul><li>Education and training requirements for executives, managers, supervisors, programmers, operators, and clerical users. </li></ul><ul><li>Documentation requirements such as hard copies, CD’s, DVD’s, & on-line manuals </li></ul><ul><li>Installation, maintenance, & support requirements for the proposed equipment & software </li></ul><ul><li>Performance evaluation & acceptance criteria </li></ul>
  15. 15. PROPOSAL INSTRUCTIONS & TECHNICAL QUESTIONNAIRES FOR THE VENDOR (1) <ul><li>Description of the written proposal format that ALL vendors must follow </li></ul><ul><li>Cover letter format </li></ul><ul><li>Requirements that vendor can & cannot satisfy </li></ul><ul><li>Proposed hardware configuration, systems software, applications software, etc. </li></ul><ul><li>Proposed installation, maintenance, conversion, education & training schedules </li></ul><ul><li>Project organization schedule for de-installation of existing systems & installation of new system </li></ul>
  16. 16. PROPOSAL INSTRUCTIONS & TECHNICAL QUESTIONNAIRES FOR THE VENDOR (2) <ul><li>Proposed vendor support services & backup facilities </li></ul><ul><li>Cost figures for all items proposed such as: purchase costs, rental, & lease with purchase options </li></ul><ul><li>Vendor’s standard contracts for items proposed </li></ul><ul><li>Description of technical questionnaires that vendors must complete. </li></ul><ul><ul><li>Short question, short answer type/style </li></ul></ul><ul><ul><li>Yes – No type/style </li></ul></ul><ul><ul><li>Questions dealing on the requirements identified </li></ul></ul><ul><ul><li>in Section III </li></ul></ul>
  17. 17. The weak points of the RFP <ul><li>System Requirements : It is very hard to know if the writer described in his RFP all the needed requirements that vendor needs to make his proposal. There must be a balance between ensuring that all requirements were account for, and that the level of details is good enough. </li></ul><ul><li>Evaluation of the project: Wrong description of the system requirements or to many/less details about the requirements can make the evaluation of the project to very complicated not only to the company that writes the RFP but also to the potential vendors which going to read the RFP. </li></ul>
  18. 18. The weak points of the RFP <ul><li>As a company are goal is to make the RFP which will enable making the best product choice while optimizing two resources: time and money. The way to achieve this is to specify requirements just in time and containing just enough details. </li></ul><ul><li>So how can we write the RFP even more efficient and describe the requirements in the best way ? We going to discuss and describe one of this ways soon. </li></ul>
  19. 19. An Agile RFP Process Jennitta Andrea
  20. 20. Agile Methodologies Companies are experiencing the benefit of agile methodologies as a way to help reduce risk and successfully keep up with the pace of changing business requirements and priorities. When priorities and requirements are in state of flux, it pays off to be more reactive. Any work done beyond the current release horizon could end up wasted because tomorrow, brand new requirements may replace the ones that were important today. This is the hart of the philosophy behind agile methods.
  21. 21. Extreme Programming (XP) This is one of several agile methodologies, and a strategy for minimizing the amount of work required in order to deliver a high quality, highly valued software product. XP can be summarized by its four core values: 1.Communication 2. simplicity 3. feedback 4. courage. These values are supported by a set of practices: the planning game, small releases, metaphor, simple design, testing, pair programming, collective ownership, continuous integration, 40 hour week, on-site customer and coding standards.
  22. 22. What will happen if we will combine RFP with Agile methodology like XP? The RFP process can be made more cost effective through the application of agile practices.
  23. 23. From now on we going to use this example to understand better how we can make an agile RFP Specification of a small system that is used by hospitals to archive inactive patient records (called volumes). A patient is identified by a chart number, and may have one or more volumes. A volume is essentially a file folder that contains treatment details for a patient. If a patient has not received treatment for five or more years, their volume is considered to be inactive. Before boxes of inactive volumes are physically sent to an off-site storage location, a user enters the data associated with each volume into the system.
  24. 24. Optimizing the RFP Specification Stage <ul><li>The RFP issued to the vendors must contain all the system requirements that the company expects the vendor to support. Use Cases are a common form of documenting functional requirements for an RFP. A Use Case captures the essence of a users interaction with the system. Use Cases are tend to be developed I waterfall fashion. </li></ul><ul><li>XP introduces the concept of Stories as a form of functional requirements – specification that easily adapts to changing business priorities. Stories are sketchy. The requirements for a Story will be explained to the level of detail necessary to enable the developer to implement and test the story.( Stories are effective for planning.) </li></ul>
  25. 25. Optimizing the RFP Specification Stage <ul><li>We can “combine” them together-Instead of specifying all use cases to the same level of detail we can use decision-making strategy to determine the minimum detail needed for each use case in order to base a credible estimate upon it. story can be embedded within a use case to facilitate a finer grained decision-making process. Lets look on the different levels: </li></ul><ul><li>In our example the use case is “create volume”. Other use cases associated with this system support the correction of data entry errors, and the tracking of the location of the volume and box as it moves from point to point. </li></ul>
  26. 26. Optimizing the RFP Specification Stage (Identity Level) <ul><li>Identity Level : This level identifies the system behavior. this level contains enough information to allow the reader to unambiguously </li></ul><ul><li>recognize the requirements. </li></ul><ul><li>The use case consists of the following elements: </li></ul><ul><li>1.Description of the users goal </li></ul><ul><li>2.Expected system state before the use case begins </li></ul><ul><li>3. Expected system state after the use case succeeds or fails </li></ul><ul><li>For Example: </li></ul><ul><li>Create Volume : A Volume is entered into the system for the first time. The user is prevented from creating a duplicate volume. If the box and/or chart specified by the user do not already exist, the system will create them as side effect. </li></ul>
  27. 27. Optimizing the RFP Specification Stage (Identity Level) For Example Identity Level:
  28. 28. Optimizing the RFP Specification Stage (Outline Level) <ul><li>Outline Level: This level provides a sketch or outline of the requirement. Typically this level is useful for facilitating a quick estimate when there is significant prior experience in the subject area. </li></ul><ul><li>The use case consists all the elements we saw in the identity level and the following elements: </li></ul><ul><li>1.The full main scenario to one level of details </li></ul><ul><li>2.The list of important failures, without resolution details </li></ul><ul><li>3.The list of important alternatives, without details </li></ul>
  29. 29. Optimizing the RFP Specification Stage (Outline Level) For Example Outline Level:
  30. 30. Optimizing the RFP Specification Stage (Outline Level) <ul><li>The main scenario represents a single story. For completeness, all steps for the main scenario are described, even though some are optional (e.g. steps 3 and7). One or more alternate / failure scenarios are grouped together into a story. </li></ul>
  31. 31. Optimizing the RFP Specification Stage (Detail Level) <ul><li>Detail Level: This level provides the reader with the full details of the system behavior. Typically this level is useful for facilitating an estimate when there is some prior experience in the subject area. </li></ul><ul><li>The use case consists all the elements we saw in the identity level and the following elements: </li></ul><ul><li>1. All of the failures, with resolution details </li></ul><ul><li>2. All of the alternatives, with details </li></ul>
  32. 32. Optimizing the RFP Specification Stage (Detail Level) For Example Detail Level:
  33. 33. Optimizing the RFP Specification Stage (Detail Level)
  34. 34. Optimizing the RFP Specification Stage (Test Level) <ul><li>Acceptance Tests Level: This level adds specific acceptance test cases for each story contained in a use case specified at detail level. This level is valuable when assessing a system’s compliance with a requirement. This is the recommended level for estimation of custom development. </li></ul><ul><li>The number of acceptance tests for a story is a function of the number of input parameters and the number of different pre-condition states that apply. </li></ul>
  35. 35. Optimizing the RFP Specification Stage (Test Level) For Example List of Tests For Create Volume:
  36. 36. Optimizing the RFP Specification Stage (Test Level) <ul><li>An acceptance test should be written declaratively, as it is a specification for setting up the preconditions and verifying the expected results. It should not include any details relating to how these activities are done. </li></ul>
  37. 37. Optimizing the RFP Specification Stage (Test Level) For Example Acceptance Test:
  38. 38. Optimizing the RFP Specification Stage (decision making strategy) <ul><li>Acceptance tests level represents much more detail and several orders of magnitude more effort than identity level one, so it is important to have an effective strategy for assigning a target level to each use case. </li></ul><ul><li>A number of different forces should be considered: familiarity, uniqueness, complexity, business criticality and life criticality of the requirements. </li></ul><ul><li>Each RFP process must review the forces relevant to their circumstances and define a decision tree. </li></ul><ul><li>The driving force behind the decision making process is ensuring that the vendor has enough information to respond with accurate estimate. </li></ul>
  39. 39. Optimizing the RFP Specification Stage (decision making strategy) For Example Custom Development Decision Tree:
  40. 40. An Agile RFP Specification Process. <ul><li>The agility of the RFP process can be further increased by marrying the concepts of use case and story and by applying XP planning game concepts to the requirements specification stage. A high level summary of the Agile RFP Specification Process is: </li></ul><ul><li>Step 1: Sketch- Define the breadth of the system’s capabilities at a high level. </li></ul><ul><li>Step 2: Prioritize- Assign relative business value to each of the requirements as a way to prioritize the rest of the work. </li></ul><ul><li>Step 3: Evaluate- Assign target level of detail to each requirement in order to develop the requirement to just enough detail for the purposes of the RFP. </li></ul><ul><li>Step 4: Complete- Finish writing each requirement to the target level of detail. This work proceeds in priority order during time-boxed iterations. </li></ul>
  41. 41. An Agile RFP Specification Process. <ul><li>Business value determines when a requirement will be captured, level of detail determines how much of the requirement is captured. </li></ul>
  42. 42. An Agile RFP Evaluation Process. <ul><li>This section provides some high level guidance for optimizing the evaluation stage when the RFP is focused on selecting package software. </li></ul><ul><li>The evaluation stage of an RFP for selecting package software can be time consuming, as the vendor system is evaluated for compliance against the stated requirements. In these cases, it is advisable to take advantage of the business value and target level of detail assigned during the specification stage. </li></ul><ul><li>Use cases /stories with high business value are evaluated first. These requirements are frequently associated with go/no-go decisions; the remainder of the evaluation may be terminated if the vendor does not satisfy one or more of these key requirements. </li></ul>
  43. 43. An Agile RFP Evaluation Process. <ul><li>Business value also determines who does the assessment: the company typically assesses high business value requirements; the vendor may be asked to self-assess medium or low business value requirements. </li></ul><ul><li>The results of the assessment are recorded according to whether there was a fit (full compliance of the requirements), or a gap. The gaps for the highly valued requirements are examined first. These requirements must be met, thus time is allotted to considering if they can be satisfied. Some complete or partial gaps may have to be filled by custom development. </li></ul>
  44. 44. The End

×