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

Request For Proposal (RFP)

In the area of computer hardware/software/services

Yulia Andriyanets

Main Topics What is RFP? High level stages of RFP. Composition of “ideal RFP”. The weak points of the RFP. Agile RFP process: *Agile methodologies & XP

* Optimizing RFP

* RFP Specification

*RFP Evaluation process

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.

In the Industry the RFP belongs to a family of documents which have structure resemblance.

RFB – Request for Bids. RFI – Request for Information. RFQ – Request for Quotation.

A Simplified List Of The High Level Stages In The RFP Business Process Include:

Specification: Company specifies the hardware/software/services requirements and general project constraints (time, cost, process etc) and issues an RFP document to candidate vendors.

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).

A Simplified List Of The High Level Stages In The RFP Business Process Include:

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.

Implementation: Company and vendor implement the solution.

The difference between RFPs- and the need in “Ideal RFP.”

Each student will get a copy of two documents (RFP):

1.Request For Proposals (RFP) Number 2003-1- “Pilot Multi-state Information Sharing System (Pegasus)”.

http://www.iacptechnology.org/RFPInfo/PegasusRFP.pdf

2. CLARK COUNTY REQUEST FOR PROPOSALS (RFP) Number 218 – “COUNTY WEB SITE DESIGN CLARK COUNTY, WASHINGTON.”

http://www.mrsc.org/rfps/C52rfpweb.pdf

The difference between RFPs- and the need in “Ideal RFP”/ effective.

The students will have to answer if they see differences?

If they can understand what are the important “main sections” in those documents?

Do they think that some information is missing? Or maybe they got to much information that made them “get lost” in the document?

What are the main difficulty in writing RFP?(system requirements & evaluation)

MAIN SECTIONS OF THE “IDEAL” RFP (1) / Dr John Maniotes & Charles Winer

SectionSection TitleTitle I Administrative & Procedural

Information to the Vendor. II Background Information on the

Company III System Functional Requirements

Defined by the Company IV Proposal Instructions & Technical

Questionnaires for the Vendor

MAIN SECTIONS OF THE “IDEAL” RFP (2)

AppendicesAppendices TitleTitle A Programming Standards of the Company B System, Program, & 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

ADMINISTRATIVE & 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 & process used to select the winning vendor Any special contractual terms or conditions required by the

company

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, PC’s, operating systems, networks, database systems, applications software, etc.

SYSTEM FUNCTIONAL REQUIREMENTS DEFINED BYTHE COMPANY (1)

Detail description & profile of the current system to be replaced Transaction volumes, activity, & other statistics associated with

the system to be replaced General functional system requirements & 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, programming language, report generators, etc.

SYSTEM FUNCTIONAL REQUIREMENTS DEFINED BYTHE COMPANY (2) 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, CD’s, DVD’s,

& on-line manuals Installation, maintenance, & support requirements for the

proposed equipment & software Performance evaluation & acceptance criteria

PROPOSAL INSTRUCTIONS & TECHNICAL QUESTIONNAIRES FOR THE VENDOR (1)

Description of the written proposal format that ALL vendors must follow

Cover letter format Requirements that vendor can & cannot satisfy Proposed hardware configuration, systems software, applications

software, etc. Proposed installation, maintenance, conversion, education &

training schedules Project organization schedule for de-installation of existing

systems & installation of new system

PROPOSAL INSTRUCTIONS & TECHNICAL QUESTIONNAIRES FOR THE VENDOR (2)

Proposed vendor support services & backup facilities Cost figures for all items proposed such as: purchase costs,

rental, & lease with purchase options Vendor’s standard contracts for items proposed Description of technical questionnaires that vendors must

complete. Short question, short answer type/style Yes – No type/style Questions dealing on the requirements identified in Section III

The weak points of the RFP

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.

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.

The weak points of the RFP

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.

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.

An Agile RFP Process Jennitta Andrea

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.

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.

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.

From now on we going to use this example to understand better how we can make an agile RFP

Specification of a small system thatis used by hospitals to archive inactive patient records(called volumes). A patient is identified by a chartnumber, and may have one or more volumes. A volume isessentially a file folder that contains treatment details for apatient. If a patient has not received treatment for five ormore years, their volume is considered to be inactive.Before boxes of inactive volumes are physically sent to anoff-site storage location, a user enters the data associatedwith each volume into the system.

Optimizing the RFP Specification Stage 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.

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.)

Optimizing the RFP Specification Stage 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:

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.

Optimizing the RFP Specification Stage (Identity Level)

Identity Level: This level identifies the system behavior. this level contains enough information to allow the reader to unambiguously

recognize the requirements. The use case consists of the following elements: 1.Description of the users goal 2.Expected system state before the use case begins 3. Expected system state after the use case succeeds or fails

For Example: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.

Optimizing the RFP Specification Stage (Identity Level)

For Example Identity Level:

Optimizing the RFP Specification Stage (Outline Level)

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.

The use case consists all the elements we saw in the identity level and the following elements:

1.The full main scenario to one level of details

2.The list of important failures, without resolution details

3.The list of important alternatives, without details

Optimizing the RFP Specification Stage (Outline Level)

For Example Outline Level:

Optimizing the RFP Specification Stage (Outline Level)

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.

Optimizing the RFP Specification Stage (Detail Level)

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.

The use case consists all the elements we saw in the identity level and the following elements:

1. All of the failures, with resolution details

2. All of the alternatives, with details

Optimizing the RFP Specification Stage (Detail Level)

For Example Detail Level:

Optimizing the RFP Specification Stage (Detail Level)

Optimizing the RFP Specification Stage (Test Level)

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.

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.

Optimizing the RFP Specification Stage (Test Level)

For Example List of Tests For Create Volume:

Optimizing the RFP Specification Stage (Test Level)

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.

Optimizing the RFP Specification Stage (Test Level)

For Example Acceptance Test:

Optimizing the RFP Specification Stage (decision making strategy)

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.

A number of different forces should be considered: familiarity, uniqueness, complexity, business criticality and life criticality of the requirements.

Each RFP process must review the forces relevant to their circumstances and define a decision tree.

The driving force behind the decision making process is ensuring that the vendor has enough information to respond with accurate estimate.

Optimizing the RFP Specification Stage (decision making strategy)

For Example Custom Development Decision Tree:

An Agile RFP Specification Process.

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:

Step 1: Sketch- Define the breadth of the system’s capabilities at a high level.

Step 2: Prioritize- Assign relative business value to each of the requirements as a way to prioritize the rest of the work.

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.

Step 4: Complete- Finish writing each requirement to the target level of detail. This work proceeds in priority order during time-boxed iterations.

An Agile RFP Specification Process.

Business value determines when a requirement will be captured, level of detail determines how much of the requirement is captured.

An Agile RFP Evaluation Process.

This section provides some high level guidance for optimizing the evaluation stage when the RFP is focused on selecting package software.

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.

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.

An Agile RFP Evaluation Process.

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.

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.

The End