Docstoc

Request For Proposal _RFP_.ppt

Document Sample
Request For Proposal _RFP_.ppt Powered By Docstoc
					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
   Section         Title
   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)
   Appendices               Title
   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 BY
THE 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 BY
THE 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 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.
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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:50
posted:5/5/2012
language:simple
pages:44
suchufp suchufp http://
About