How to Write an RFP
Part I: Defining your needs
The first step to writing an RFP for an
information system — whether it be an enterprise system or niche application
— is to decide what you want and need the new system to do. Often referred to
as a
needs analysis, needs definition, or requirements definition process, this
phase of the selection project helps ensures your Request for Proposal will match the actual needs of
your organization.
Some organizations take a "short cut" and copy an RFP from another
group that may
have different requirements or constraints. Though it's tempting to save
yourself the work of creating a custom RFP, that strategy is more likely to
result in your purchasing a "solution" to someone else’s problem.
The needs assessment phase of the RFP should begin
with an in-depth survey of your company’s needs, a process that can be likened to a
brainstorming session. The selection project manager divides users into teams
by application area, including both management and staff level users. A series
of small group meetings are then scheduled so each team can discuss what
they’re looking for in the new computer system.
Users can become familiar with features and functions
that should be included in their new system through vendor demonstrations,
professional seminars, trade journal articles, and conversations with
colleagues at other organizations.
The selection project manager can also prompt users
to think about what they like and dislike about their current system.
Important features of the current system should be added to the requirements
list because they are not necessarily included with every software package.
Conversely, desirable features that are lacking in the current system should
also be added to the list.
Access to a current and detailed list of functional
requirements specific to your application can also be a tremendous help in
identifying your users’ needs. Functional requirements for a variety of
applications can be obtained from
On-Line Consultant Software
,
which specializes in helping
organizations create and evaluate RFPs for selecting computer systems.
A good requirements list will spark new ideas for
features and functions that may otherwise be overlooked by your users. RFPs
supplied by vendors can also be helpful, but they should be viewed cautiously
as they may favor the vendor’s product.
|
►
Don’t overlook the obvious |
When defining your needs, it can be difficult to
decide which requirements should be included in the RFP. For instance, if you
were to write an RFP for a new house, it might be ludicrous to include "roof"
as a requirement… but what about "central air conditioning?"
Some key features you might assume would be included
may not be available from every vendor. While surprises may be fun on your
birthday, no one enjoys the surprise that occurs when users discover their new
software cannot perform important functions.
Once you’re satisfied with your requirements list,
every item should be ranked by importance. Some features may be considered
mandatory, while less critical items might be ranked as desirable.
Each requirement should then be coded by priority (e.g. "M" for
"Mandatory") so that during the evaluation phase, systems which include
those features will receive more points. You could also include items that
you’re just curious about by coding them with an "I" for "Information
only." These items would not receive any points in your vendor analysis
phase.
Functional requirements should be written clearly and
concisely so that the vendors’ response teams do not have to guess your
meaning. Choose small words and simple terms (e.g. use vs. utilize)—your goal
is to be clear, not to impress the vendor with your stellar vocabulary.
Instead of vague general phrases, use active verbs to
describe what you want the system to do. A regional healthcare company
recently installed a multi-entity patient information system. Although they
requested general multi-entity capabilities in the RFP, they were not specific
as to what they wanted to accomplish. To their dismay, they learned that
software vendors have different definitions of "multi-entity." The admitting
and medical records staff at one hospital were not able to inquire into a
patient’s records at the sister hospital since the system maintained separate
patient databases. Patients complained that they had to give the same
information at the clinic, surgery center and hospital on the same campus.
Limit each item to only one concept so the vendors’
responses are meaningful. If you bundle a lot of functionality into a single
question, a vendor may respond "yes" if their software can do just part of
what you’re describing.
Here are
some examples of
clearly worded functional requirements for a Human Resources software
selection:
Sample Functional Requirements
 Provide
ability to search for and list employees with specific skills.
Print benefits report of
employees with dental insurance.
Provide ability to synchronize
employee master files in payroll system and time & attendance system.
Allow employee to claim
different numbers of exemptions for federal and state tax deductions.
Print report of employees who
have worked for user-defined periods (e.g. 90 day, six months).
Track productive and
non-productive hours for pension reporting.
Interface FTE data to the
general ledger system as statistical journal entries.
Provide ability to simulate the
financial impact of potential contract salary changes and project the impact
based on differing salary increases for different positions, job classes, etc.
Allow real time changes in
employee work status including movement among cost centers, changes in
position, etc.
Provide option to have badge
reader also control access to restricted areas within the facility. |
Finally, be sure to include features in your requirements list that will
show clear distinctions between competing systems. Going back to the house
analogy, you can assume most houses will have floors and ceilings. But what
about sun rooms, ceiling fans, Corian countertops, dual pane glass windows or
intercom systems. If any of these amenities are mandatory or desirable for
you, you want to know which homes have these features and which do not.
Likewise with computer systems. Chances are your organization will be
living with your decision for the next five years. Be sure to take the time to
meet with users and identify all of their needs. Not only will this help you
select a better software package, it will also involve your users in the
selection process and increase their "buy in" after the new computer
system is implemented.
See Part II article:
"How to Write an RFP: Everything you always wanted to
know about vendors and weren’t afraid to ask…."
Copyright On-Line Consultant Software
|
Searching for a new
information system? |
| Use the
ON-LINE CONSULTANT
—
the electronic RFP (Request For Proposal) software with pre-loaded questions that can be modified and prioritized. The software automatically compares functionality, cost, support, training and other important factors. |
Mailing address:
On-Line Consultant Software
2828 Upshur St., Suite 125
San Diego, CA 92106 |
Call: (619) 223-2024
Fax: (609) 939-1611
E-mail us now |
