Evan,

I wrote the following for a previous question here on LinkedIn, but it seems to apply here as well (actually, better). Obviously, I'm coming at it from the developer perspective :-)

My number one frustration with RFPs is a typical unwillingness to allow a response which suggests a phased approach. I'm in the Web development industry and it IS impossible to specify a system in an RFP response -- unless of course the client wants to be told "no" to every little change thereafter.

I much prefer working on projects where collaboration leads to results which are better than were envisioned in the RFP. That requires that my development team AND my clients say "yes" to changes to the project post-RFP.... and the ability to say yes comes from approaching the project with a realistic understanding of costs and risks.

For example, those buying web services often demand a fixed price from those of us supplying them. And in many cases, the budget is determined well in advance of the project requirements and specifications; what this means is that clients have unfounded expectations for project costs and vendors are already thinking of ways to bait and switch before the project even begins. (Clients often think fixed pricing forces the “risk” of the project onto their vendors backs, but ultimately it means that the vendor needs to sacrifice something in order to meet the budget. It’s no bargain.)

While it’s impossible to know a project’s “total cost and duration” until the project is complete, stakeholders often try to ballpark these figures upfront — even before engaging with a potential supplier. These upfront estimates are typically off by ±400% according to IEEE. Instead, a phased approach could be employed to both limit the risk (to both parties) and ensure that realistic project estimates are gathered before any contracts are signed.

With the successful completion of each phase of the project, the overall uncertainty of the project (and its associated risks/costs) is reduced; as such, a development strategy which focuses on a phased approach is often the best at managing risks and costs.

If you follow the link below, I've provided a diagram using the metaphor of “building a house” to describe the state of deliverables at each stage of the development process. It’s instructive for both developers and clients alike. In addition, it includes some of the common steps we use at Auragen to develop projects from scratch.

http://etailology.com/blog/wp-content/uploads/2007/08/riskdiagram.png

Other best practices I've seen in RFPs?

-- Use an RFI first to thin the field to 5-7 candidate firms. Let participants know if the incumbent firm is included.

-- Provide appropriate response timeline (the idea that the "winning firm" should be able to respond quickest is usually flawed... it's the firm with nothing to do -- no clients -- that has lots of time to reply to RFPs quickly)

-- Provide the answers to ANY question asked by any vendor to ALL vendors.

-- Ensure that you're ready to receive large files by email or FTP.

-- And always always always provide feedback to non-winning firms about why they didn't win.


I hope that helps!

--David

Links:

• http://etailology.com/blog/wp-content/uploads/2007/08/riskdiagram.png

posted September 13, 2007

I've worked on several large RFPs with firms that have outsourced the RFP process, even though they had their own internal RFP shop. Why? Because these were must-win RFPs under very tight deadlines that needed strong proposal and timeline management.

The teams we hired had a rigid process with clear, well-defined artifacts with strong templates and examples at each stage (from initial win themes to early idea capture to storyboards to pink to red to gold teams with multiple intermediate team reviews). Core team members were there 14-5 hours/day throughout the process - often on weekends.

In picking these teams, four things lead to this decision:
1 - previous win rates on similar proposals
2 - previous clients (hopefully my competitors and you won)
3 - insanely positive recommendations (hopefully from a trusted source)
4 - ability to fully own the process based on very deep experience

The agency team generally handle all aspects of proposal management including managing a common proposal repository for artifacts (the company set it up, but the proposal agency managed/organized the content or structure), proposal production for reviews, all scheduling, graphics colors/themes/creation, english proofreading, some tech writers (sometimes optional), and a clear go-to guy that got questions answered and made things happen.

To me, there's tremendous trust one must put into these companies so I think it really requires some personal connection or proof that they can do the job.

I looked through your site and didn't see references - personal or proposals - or a rigid process outside for interactive proposal creation, so it'd be a tough sell - at least for the $50+M RFPs we's consider outsourcing.

Karl

posted September 13, 2007