Just a couple points of clarification about how to take the mystery out of 'nebulous' rfp's.
Articles sometimes read a little differently after they've been edited.
1) Understand what those vague words/requirements really mean.
4) Be honest and tell them what they need.
Thnx for taking the time to read the article. Hope it helps!
Discussion on:
View:
Show:
I apppreciate the article, if well documented RFP template is included it would have been great help as guideline. I also would like to ask how detailed the RFP suppose to be (Micro level). Ideally my question is where to stop because some times fewRFP turn out to be a FSD (Functional specification document). Thanks !!!
that's a good question - and one that we wrestle with all the time.
The salesperson answer is - you have a document that's as detailed as it needs to be to win the job.
The developer answer is - a detailed outline of requirements - not a scopeof work doc or a FSD.
Both you and the client need to know what you're proposing -NOT - necessarily exactly how you're going to do it.
On the RFP template question - I actually use a couple of them. Hopefully we can publish them in a followup article.
Thanx for the comments!
The salesperson answer is - you have a document that's as detailed as it needs to be to win the job.
The developer answer is - a detailed outline of requirements - not a scopeof work doc or a FSD.
Both you and the client need to know what you're proposing -NOT - necessarily exactly how you're going to do it.
On the RFP template question - I actually use a couple of them. Hopefully we can publish them in a followup article.
Thanx for the comments!
I liked the article. I kind of sit at the other end. I have been doing software development/General IT work for a client for the past 4 years and they wanted me to write RFPs for new computer systems, copiers, phone system, and ISP (including phone service).
They started out having someone else do the cable RFP (included laying cat5, rgb, and multimode fiber in a new building) and it was 60 pages! I did not think it was necessary to go that far in depth. If I did not have my BSEE, then Iwould not have been able to follow it. (The customer does not care about having a spectral analysis of line degredation at different frequencies) Needles to say, the customer was lost reading through it. I had to read through it a few times to notloose the forest from the trees and all I cared about was what was being run and where.
Anyway, it would be great to have good templates for writing and responding to RFPs and for all kinds of technology purchases.
They started out having someone else do the cable RFP (included laying cat5, rgb, and multimode fiber in a new building) and it was 60 pages! I did not think it was necessary to go that far in depth. If I did not have my BSEE, then Iwould not have been able to follow it. (The customer does not care about having a spectral analysis of line degredation at different frequencies) Needles to say, the customer was lost reading through it. I had to read through it a few times to notloose the forest from the trees and all I cared about was what was being run and where.
Anyway, it would be great to have good templates for writing and responding to RFPs and for all kinds of technology purchases.
Descriptions on how to write a good RFP are usually as vague as those RFP that you are talking about in your article.
I really like to see actual RFP templates.
I really like to see actual RFP templates.
i don't know if you've had a chance to look at the precursor article to this one:
http://builder.com.com/5100-6315-5031142.html
Originally I had submitted some templates to go with that article but they never ended up being published on builder...
http://builder.com.com/5100-6315-5031142.html
Originally I had submitted some templates to go with that article but they never ended up being published on builder...
Scope creep is certainly going to occur when an RFP has no defined limitations. A simple technique to help stop it in its tracks is phased development plans.
Even bad RFPs have the basics of what the client knows they want. Make them the deliverables of Phase 1 - core functionality with good interface design. Recommend at the end of the phase that a review be performed. Determine whether the deliverables are enough to satisfy the client "as is". You're looking at log analysis, user fedback and maybe a usabiltiy lab. If there's no need for more work, you've done your job, saved the client unnecessary cost and not suffered scope creep.
Most changes in scope centre around "interactive and intuitive" navigation. The client knows they want it, but have no idea what they've asked for. That's Phase 2. After Phase 1's review you can tell where efforts need to be concentrated, steering clients toward better business decisions. Your navigation becomes driven by how users react to your Phase 1 delpoyment. Amazon.com didn't just "think up" their navigation, they looked at how customers wanted to find books online.
Again, after deployment, seek feedback. Better still, during the phase run a usability lab, preferably with users of the Phase 1 deployment. Offer them money, t-shirts, coffee mugs, whatever is acceptable, for an hour of their time. It's suprising, but people are willing to help for ?/$25 in cash or goodies. This will help you define how users will use the deliverable. You'll get it almost perfect first time, at least in the client's mind.
If there's still enough left over after Phases 1 and 2, go to Phase 3. You'll usually find, though, that by this time Phase 3 will be tweaking your work to the client's complete satisfaction.
This approach could go on ad infinitum (or ad nauseum, depending upon the client), but it's a great way of imposing control over a woolly requirement.
Even bad RFPs have the basics of what the client knows they want. Make them the deliverables of Phase 1 - core functionality with good interface design. Recommend at the end of the phase that a review be performed. Determine whether the deliverables are enough to satisfy the client "as is". You're looking at log analysis, user fedback and maybe a usabiltiy lab. If there's no need for more work, you've done your job, saved the client unnecessary cost and not suffered scope creep.
Most changes in scope centre around "interactive and intuitive" navigation. The client knows they want it, but have no idea what they've asked for. That's Phase 2. After Phase 1's review you can tell where efforts need to be concentrated, steering clients toward better business decisions. Your navigation becomes driven by how users react to your Phase 1 delpoyment. Amazon.com didn't just "think up" their navigation, they looked at how customers wanted to find books online.
Again, after deployment, seek feedback. Better still, during the phase run a usability lab, preferably with users of the Phase 1 deployment. Offer them money, t-shirts, coffee mugs, whatever is acceptable, for an hour of their time. It's suprising, but people are willing to help for ?/$25 in cash or goodies. This will help you define how users will use the deliverable. You'll get it almost perfect first time, at least in the client's mind.
If there's still enough left over after Phases 1 and 2, go to Phase 3. You'll usually find, though, that by this time Phase 3 will be tweaking your work to the client's complete satisfaction.
This approach could go on ad infinitum (or ad nauseum, depending upon the client), but it's a great way of imposing control over a woolly requirement.
Thank you, Mark, for starting what I was going to say. Unclear requirements are inevitable when there are TOO MANY requirements, especially when they interrelate. My scope creep horror story comes from a 3 year project converting a manual process to an automated decision control system. (First danger sign: manual to automated always means ten times as complex as you thought!) -- numerous requirements for handling encountered conditions mixed with how they wanted it to appear on reports. Continuaous cycles of changes in the decision tree, followed by changes in the reporting module, resulted.
So I would modify Mark's good comments about phases with a suggestion to attempt to define and deliver separate COMPONENTS (via new projects or phases) -- this requires the user to buy into the whole package of components first, which tests the relationship, of course, and requires separation of requirements into functional groups served by the separate components, but this exercise should have a clarifying benefit. The components would be built either concurrently (or bought from vendor?!) if the project is pressed for time, or in the order of greatest immediate benefit to the user. A good way of handling scope creep is getting a component done and in production -- users intuitively understand that desired improvements are a separate project and are much more likely to 'live with' what they have when they have to pay for changes (until production, users 'intuitively' feel all changes are free!)
Also, components geared toward functionality may easily lead to RE-USABLE components -- an additional benefit. In fact, the possibility always pressures me toward generic and simple components (user parameter or table driven even), avoiding the complications of 'tweaking' to serve a single purpose.
Bottom line: Phases or components are advised whenever you sense the customer won't really know what they want until they see it up and running. -Tom
So I would modify Mark's good comments about phases with a suggestion to attempt to define and deliver separate COMPONENTS (via new projects or phases) -- this requires the user to buy into the whole package of components first, which tests the relationship, of course, and requires separation of requirements into functional groups served by the separate components, but this exercise should have a clarifying benefit. The components would be built either concurrently (or bought from vendor?!) if the project is pressed for time, or in the order of greatest immediate benefit to the user. A good way of handling scope creep is getting a component done and in production -- users intuitively understand that desired improvements are a separate project and are much more likely to 'live with' what they have when they have to pay for changes (until production, users 'intuitively' feel all changes are free!)
Also, components geared toward functionality may easily lead to RE-USABLE components -- an additional benefit. In fact, the possibility always pressures me toward generic and simple components (user parameter or table driven even), avoiding the complications of 'tweaking' to serve a single purpose.
Bottom line: Phases or components are advised whenever you sense the customer won't really know what they want until they see it up and running. -Tom
It sounds like I'm the very type of person who
would deliver a nebulous RFP- I have no
qualms whatsoever in asking my retained
developer to incorporate his or her own
creativity in making up my website. It also
seems to indicate how carefully the developer
should define his job parameters.
would deliver a nebulous RFP- I have no
qualms whatsoever in asking my retained
developer to incorporate his or her own
creativity in making up my website. It also
seems to indicate how carefully the developer
should define his job parameters.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
