Many people would want a complete RFP document sample, which would let them almost copy paste the document, adapt it a little, change the fonts and header and reissue the document. Before providing such examples, it is key to understand what are is the best way to break down an RFP in order to make it easy for you and the vendor to analyze, and understand your expectations.
The structure of your document I suggest is the following :
1. Overview
- 1.1 Company Presentation : this gives an overview of your company, with global figures (employees, business units, sales or revenue figures, key growth drivers...)
- 1.2 RFP Context : this is often omitted but more important than you think. It provides the general context of the RFP and lets the suppliers understand if you are just replacing a deprecated platform or planning something scalable to take on a huge business growth or increase flexiblity on your services
2. Project Expectations
In this section, add one chapter per expectation. Based on whether you expect the RFP to be service / SLA driver or a very technical design based on a BOM (bill of materials), you can put several sections. These sections can be related to availability, resilience, flexibility, capability to scale up or scale out the solution... but also be technical requirements such as imposing your standards regarding management network (do you impose a non routed OOB management network), security access (should everything be authenticated against your corporate active directory), do you have specific connectivity & protocols (e.g on a Nexus core stack, you would have LACP network connections, meaning specific teaming settings on network cards). specific plugins with other platforms, reporting and capacity mangement feaures (capacity and performance trending...)
3. Instructions to bidders
- 3.1 : Key contacts (name, function / role, email, phone): indicate the SPOC (single point of contact for the project). Usually, on big projects, you have a project manager, the project sponsor or team leader and a guy from the procurement
- 3.2 General information for the bidders : in all RFPs, you should given the global guidelines to the bidders to avoid any surprises when attempting to close the deal at the end of the RFP cycle. Such general information would be :
- Proposal acceptance requirement : indicate language in which you expect the bidder's answer, the currency in which prices must be given, if you impose a fixed exchange rate against standard currencies such as dollar (because your budget is stable since it is based on a hedged currency)
- Proposal validity period
- Non disclosure information
- Non compensation conditions : indicate that no kind of compensation will be provided for manpower and costs associated when participating to this RFP
- 3.3 : Timelines : it is compulsory to provide timelines with your RFP, so that bidders know precisely what is expected and when. This is usually summed up in a small table with the key dates (date, milestone, action owner, communication medium)- 3.4 : Questions for clarifications : be clear about your rules on questions :
- Best practise would be that you have a milestone in section 3.2 Timelines indicating the hard stop for questions & answers
- In this section, you should indicate to all bidders if you allow yourself to disclose their questions anonymously to other bidders, should the questions be interesting to share
- 3.5 Evaluation criteria : be very clear on how you will assess their reponse :
- Is your project TCO (total cost of ownership) driven?
- Are you going to check compliance of the bidder's answer with you RFP requirements?
- Are you looking for a solution with proven stablity & flexibility
- Will you expect reference calls and reference presentations to prove the bidders professionalism?
- Will you be expecting a very clear vision of the project, resources to engage, efforts expected on your side, planning...
- 3.6 Proposal Structure : this is where you impose a certain level of structure to the bidders' response. It is key to get this part neat. Indeed, if all proposed are aligned in a "template" format, parsing the answers and comparing the bidders will be very simple. The usual information I expect in a response to an RFP is the following :
- Executive summary
- Bidder's presentation (I usually supply an excel sheet to impose the information I am requesting : turnover, operating income, best in class resellers and integrators, similar project references...)
- Technical solution : this is where you have to turn verbose mode on, indicating all RFP technical deliverables (high level design, low level design, power consumption, maximum capacity and performance of the solution
- Project Organization : explain all mandatory phases you expect the bidder / integrator to perform during the integration project (design workshops, activities, onboarding of your internal resources, reporting details and frequency)
- Financial Breakdown of the proposal : here again, provide an excel sheet the bidder should fill in and put all the fields you expect him to fill in (unit public price, unit proposed price, quantity, total price, taxes, non recoverable taxes , project costs, training and handover costs...)
- Terms and conditions : this is usually an internal document provided by your legal or procurement team
No comments:
Post a Comment