>What vital information is lacking from RFP's you receive? What annoys
>you about typical RFP's that you receive? Are there specific issues that
>should be more fully developed in the RFP's than others? What is a
>"complete" RFP to you?
1. This is what we want to do.
2. Here's a rough description of what we want.
3. This is how we want to do item #1 with item #2.
4. Here's a description of the information we plan to
put into the system, and how we want to put it in.
5. Here's a description of the information we want out
of the system, and how we want to get it out.
6. The following is a rough, user-level description of the
feature set we want.
7. Here's a prioritized list of features from item #6,
ranked by order of need, from "make or break" to "trivial".
8. This is our timeline for implementation and rollout of the "make
or break" features in item #7.
9. This is our timeline for implementation and rollout of all features
ranked "necessary" or higher in item #7.
10. This is the date by which we will close the project's development,
regardless of what features have not yet been implemented.
11. Here's how much we plan to ding you if you miss item #8, #9, or #10.
the answers to these questions are essential to any development project,
but it's amazing how many projects begin without being able to answer any
of them.
at a bare minimum, you need to be able to define the inputs, outputs, means
of input, means of output, and feature set. if you can't do that, the
project will almost certainly fail. those decisions are also the ones
where you tend to see the most internal bickering, politically. the
traditional way of handling such bickering is to write a spec that's so
vague it doesn't offend anyone. that effectively passes the buck to the
developer, who's supposed to come up with a solution that satisfies
everyone.
in a word: unlikely.
general tip for anyone reading RFPs and project specs: if you can't
identify the inputs, outputs, and feature set after reading the thing,
don't bid on it. if you really want to give the project a shot anyway,
start by asking the client for specific information in those three areas.
if they still won't give you a straight answer, run like hell. if you
don't, you may as well be standing on the brink of an alligator pit,
rubbing yourself down with Cajun blackening spices.
matching tip for anyone starting a project and looking for developers: if
you can't give specific details for the inputs, outputs, and feature set,
you're not ready to hire developers. you need to spend more time deciding
what you actually want. if you can't do that, you need to find a way of
clearing up the communications among the people involved with the project,
or you're never going to make it.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
