Responding to Requests for Proposals for Learning Projects

We get lots and lots of proposal requests from current and prospective clients…and I’ve been writing a ton of proposals lately. Some are much easier to write than others, and the ease/difficulty is 100% dependent on the quality of the request.

Some of the RFPs – requests for proposals – we receive are very good requests with detailed information; others give us the opportunity to do lots of follow-up. We find ourselves asking a lot of questions as we attempt to accurately pinpoint the scope of the project and provide concept, price, and time line information. We end up spending quite a bit of time formulating questions and then talking these questions through with the client. I often wonder how many hours a client might save himself or herself if their RFP had been put together a bit more carefully. I do recognize the difficulty of communicating clearly about a project in which you’ve probably been immersed for a long while. It comes difficult to discern what’s obvious -and what needs to be explicitly explained for a vendor to understand your needs.

If you are someone who outsources work to vendors, you can make your job easier – and your vendors’ job easier by assembling a solid RFP – or request for proposal. The information that follows is straight from a document we created titled, “Creating a Good RFP.” We provide it free-of-charge to customers who don’t have any experience creating RFPs…or who’ve provided us with RFPs in the past that lead to lengthy Q&A sessions to understand what they want/need. Most of them tell us it’s a really helpful guideline.

Company and Logistical Information

Sounds stupid, but a lot of companies forget to put basic contact information in their proposal. Be sure to include:

• Company name and address
• The name and contact information for the person making the request. If YOU aren’t the one to answer questions, then please include the name/contact info for the person who is supposed to answer questions.
• Any parameters we need to follow in submitting questions or requesting additional info.
• The due date of the response. (Please make this very clear and easy to find!!!)
• The anticipated decision date and how you will communicate this decision.

Project Information

• Description of your project. Tell us what the project is and who it is intended for: “We need a training course on XYZ developed for XYZ audiences.” Or…”We need help in analyzing what we DO need because we have no idea.” (I’m being a bit sarcastic here, but truly, so many customers aren’t really sure what they do need – and we end up looping back to do some needs assessment before we can ever move forward. They jump to solution before they’ve fully thought about what the problem truly is.)
• Give us background on your intended audiences – what do they already know? Where are they located? What entry-level attitudes or behaviors should be considered as we bid the project? What is their education level and language skills? What unique traits should we consider? (e.g. The need to eventually  translate a finished solution into multiple languages is something that’s nice to know when we bid the project since it affects the way we might program a solution. This, in turn, affects time required.)
• List of deliverables and services you need. Services may include needs analysis, curriculum or course design, graphic design, performance analysis, etc. Deliverables might competency model, analysis report, curriculum design, course design, course materials, e-learning course, webinar, job aids, etc. If you don’t know what deliverables you want, we’ll have a very hard time giving you a price. When you are really unsure of what the deliverables should be….strongly consider requesting support for analysis and design – with no other deliverables. Once analysis and design work have happened, you can request a proposal that focuses exclusively on development and testing of your solution.
• Anticipated project time line that factors in the review cycles required on the project. Here is where many clients stumble a bit. They request a completion date that cannot logistically be accomplished ON THEIR END.
• Description of the available resources. This includes source content and subject matter experts. Depending on the project, it may include other, very specific resources as well.  Remember: “source content” is only source content if it exists on hard copy or electronic copy somewhere. Telling a vendor you have all the content…and then surprising them in the kickoff with an intro to a SME who is going to tell them everything they need to know is NOT good.

Budgetary Constraints or Timeline Constraints

Please, please don’t withhold budget information because you worry that the vendor will use every penny of what’s available to spend. The worst scenarios are when someone only has $10K to spend – and describes a project that clearly requires $50K to produce.  You are NOT going to get audio, complex Flash animation, and a full-branching scenario in 4 weeks and for less than $10K.

If you can give budget parameters or expectations upfront, we can help guide you and tell you what features/functionality/services are typically part of a $10K, $20K, $50K, or $100K solution. We can also probe for the outcomes you’re trying to achieve. If you merely want to share information, you really don’t need to spend $50K on an e-course to communicate new policies. Ethical vendors will point this out – and save you money.

Evaluation Criteria

Let’s be honest here. There’s always one or two things that are MOST important to you. Sometimes it’s your timeline. You need something fast…and your top evaluation criteria will be how well a vendor can meet your timeline. Other times, you have a high-profile project and what you’ll value most is a vendor who can truly partner with you in thinking through needs and optimal solutions, and then produce a high-quality, creative solution.

Though some vendors will tell you it’s possible to do good, fast, and cheap all together…that’s relative. We can be two of those three things, but most vendors cannot be all of those things. Simply letting the vendor know which two are most important to you can help you get responses that are useful to you. We’ve had some terrific honest discussions with clients – and declined to respond – when we’ve discovered their top priority is not one we feel we can honor. (We just had a client who wanted us to bid a project two ways: 2) super-fast with lowered quality standards and 2) high-quality with lengthened timeline.)  After considering what “super-fast” would mean (just about absolutely killing everyone on the project in order to complete it in four weeks), we replied back that we felt we could only bid on Option 2. The client was fine with this…and the evaluators can go with what’s most important to them.

Summary

The best projects happen when there is a high level of trust and good communication exchange throughout the proposal process. We start consulting from the moment we receive a proposal so we make sure our response truly addresses the needs the client has – which often are nowhere on their RFP.

Clients who have a rock-solid RFP help themselves. They get responses that better match their vision. They also minimize the risk of the project scope expanding on them because it wasn’t fully thought through at the RFP stage.

I welcome any other tips folks have on what makes a great RFP. Any war stories can also be shared and enjoyed. I suspect most of us have at least one!