Originaly posted by AdrianK, 26-Jan-2010 at:
Vendors typically have to expend a huge amount of effort when responding to an RFP. This article looks at how they can help themselves (and thus the client), so that the effort isn’t wasted. The short answer is that whist RFP respondents typically focus on the solution they are offering, the real key is to take the human factors of the reviewers into consideration.
In my role as a Solution Architect (or perhaps just by being one of few resident development skilled geeks) I contribute to the RFP process – on the client side. I’ve also done a wee bit on the vendor side too.
Having done a string of RFP reviews in recent times I feel compelled to provide some feedback to those of you out there who submit RFP responses; and whilst most of you are doing well there are others who (with all due respect) desperately need some help.
[A bit of context – this feedback is based on experiences within the New Zealand public sector. I can’t vouch for other countries but I’m sure a lot of these points are transferable].
Before I lead us through the vast litany of unfortunately very common mistakes, let me give you some insights into the life of a RFP reviewer so that you can understand the context in things happen.
RFP’s are generally structured into sections with specific statements and questions within each; for the review, reviewers will be given a pre-defined score sheet from the contracts team (who usually oversee issuing of the RFP), and it’s no mistake that the score sheet utterly reflects the RFP.
Some score sheets expect the reviewer to individually score each answer and question pair; others expect a single score per section of questions.
When I’m reviewing responses that require score by section, I generally work through each section in turn for all responses, in other words I work by section not by response. For example, for a recent RFP review I was reviewing a stack of hardcopy responses:
- I usually start with a very brief flick-through of all the responses to get a feel for what’s coming. The score sheets are usually in Excel all setup with the respondents entered and formulas ready to aggregate results on a separate worksheet (which I avoid looking at until the end of the review). I stack the responses in the same order they are in score sheet.
- I’ll review the RFP itself again, as well as the question and answer sets that have been created – and I’ll have full print-outs of each at hand.
- I’ll then start the review proper, starting with the first appropriate section and the first response, then moving on to the next response.
- Once I’ve scored all responses for the current section I’ll move on to the next.
- If a section to be reviewed is large or covers multiple topics (they aren’t always as cleanly segregated as you might want) I’ll setup a more granular sub-score sheet of my own somewhere; in this case I might start reviewing responses per individual question, but not always.
Additional notes for each score are also entered; these are pretty essential for the final group review. As you might know the RFP’s will be reviewed by a group of people who will then come together to thrash out a result (or a short list). In a recent case my review took a full week (including normal day to day interruptions) thus the notes are essential.
Once the reviewers have completed their individual reviews (and scoring) they all get together for a formal review and scoring session where the final grading is done – this is the bit that counts.
The crucial point is that reviewing RFP’s is long and tiring work, particularly if there are a lot of responses, and it’s harder with responses that are of a poor quality. Thus one of the keys to a good result is to take the human factors of the reviewers into consideration – make your response a pleasure for them to score. So, how do you actually do that…
Structure
If you want best “bang for buck” this is the mistake you can’t afford to make: as mentioned above RFP’s and there score sheets stick to the same structure – deviating from that structure in your response is asking for a serious amount of pain and may well land you in the bottom %60 of scoring.
When you have to review and score a dozen odd responses you don’t have time to hold peoples hands – if the your response clearly follows the RFP structure the reviewers won’t have to think [1] in order to find the information to review, and they’ll thank you for it.
Use section names and paragraph / question numbers from the RFP to label the content in your response, and include this in the table of content if appropriate: make sure it’s really easy to scan, use decent indenting, bolding and other presentation techniques to make it so – but don’t go overboard.
With most RFP responses, at least some of the respondents will do just that; this consistency makes it easier for reviewers to work with those responses and the more that do this the more they will all benefit from the consistency; correspondingly, failing to do so will put your response comparatively on the back-foot. This is particularly true the more responses there are.
Next on the priority list is a decent Table of Contents (ToC), and please, please, please don’t forget page numbers.
What you want is a nice, clear, easy to read ToC which matches the RFP structure, with page numbers so I can jump straight there. “Hand-Over”? Oh look its on page 28. “Security Testing”? Page 13, bingo.
RFP’s that do none of this are so awful to review it’s not funny, and it takes little imagination to guess how that impacts on scoring, after all you can’t score a response you can’t find.
I’ve seen everything in between: responses with no ToC, ToC but no page numbers (bizarre) and page numbers but not ToC (near pointless). The sad truth is that whilst the reviewer should be scoring you on you content, you’ll get scored on your delivery instead – if it’s poor.
This brings up an interesting point, in that (for the reviewer) there’s often a fine line between scoring the response and scoring the way it’s delivered, and the division between the two can get quite murky at times.
Finally, RFP reviews always include a section for presentation and delivery; these should be easy points to win if you follow some of the advice above.
Content Quality
By this I don’t mean that you offer a database that is redder than everyone else (a red database is fastest, yes?); what I mean is that your response must answer the questions that have actually been asked. You might think this was obvious, however, I regret to inform you that the obvious is obviously not that obvious.
Failing to actually answer the question is at least as dangerous as ignoring the RFP’s structure. First tip: actually read the question. Read it again and make sure you understand it. Count to ten before you start writing. Discuss it with a peer.
It’s tempting to respond to the “training” section of questions with your standard training blurb – don’t rely on this. Make sure you understand the specifics of what is being asked and directly answer it – make it as easy as possible for those poor tired reviewers to give you full marks.
Responses that (reading between the lines) suggest the respondent is capable – but which don’t directly answer the exact stated question put the reviewers in a tricky position.
If in doubt answer the question directly (‘what they asked – not what they meant”, as strange as it might sometimes appear) and then additionally provide a ‘second’ answer that answers “what they meant not what they asked”.
In short: make sure you directly and specifically answer all the mandatory questions in the RFP. Reviewers generally mark a score as set-out in a predetermined score card (most likely defined by the internal contracts team); one of these options will cover responses that fail to answer questions specifically. Often questions can be lumped together into section and a score is given for the section as a whole – if you don’t answer all the mandatory questions you risk being thrown into the ‘failed to provide a response’ category even if you did answer some of the questions.
Consider very carefully when asked to describe your approach to completing a specific deliverable; is the RFP trying to elicit the steps you go through or your thinking behind those steps? It is – trust me. Knowing what your process is can be illuminating (but not always in the right way) where-as getting an understanding of why you do it that way is often more helpful – it shows that you can justify your approach or might suggest that (due to your understanding) you can compensate when variations occur.
“All software we produce under goes our comprehensive range of time-proven of software testing techniques” is not going to score you anything.
“All software component testing is automated using N-Unit with code coverage of at least %80 by the end of every sprint.” Is much better – I know the tools you use, it looks like you know what you’re talking about (code coverage) and your testing is integrated with your development methodology (don’t tell me you’re “agile” elsewhere in the response and then fail to mention relevant agile practices where appropriate).
Content Quantity
Reviewers will be looking to get the review done as fast as possible – be as succinct as possible – both in volume of text and presentation. The average reviewer may not be too interested in a whole page executive summary
(although this kind of thing may be useful to others?). Also, the bigger the document is the harder it will be for reviewers to find information if it’s not blatantly obvious from the table of contents.
The balance between too much info and too little can be a very delicate one, and it’s easy to get wrong. One approach that might work for you is to provide some level of detail (to try and expose your depth of knowledge) but not for the whole breadth of the issue
Pick you targets; make sure you understand the RFP and your relative strengths and weaknesses, what responses are you giving elsewhere? Some questions will lend themselves to a longer answer better than others, and for others a shorter answer.
If the RFP simply states that you need to confirm acceptance or acknowledge something then do so (assuming you accept, of course); something like “We confirm acceptance of this requirement” should do the trick. Evaluate the question – don’t feel you need to give additional info if it’s not necessary.
If you add additional information please make sure you still formally state acceptance as a clear acceptance is the fastest way to full marks.
Starting with the acceptance and then providing additional info is probably best. One advantage of sticking to the acceptance statement only is that it means you can add more content elsewhere; save yourself for where it’s worth going the extra distance, so that the overall response isn’t bloated.
Name drop – Mentioning the names of specific processes and technologies can be a very useful way of conveying a sense of depth without going into detail, for example: when questioned about security testing name-dropping specific threats demonstrates a knowledge of the domain – “… protection against SQL Injection, XSS, and Drive-by attacks…” makes it sound like you know what some of the potential and specific threats are, where-as simply saying you’ll defend against malware is very vague. Of course anyone can name-drop things they don’t actually know anything about, but the rest of their answer (and the way it is written) should give an indication as to the overall authenticity of their knowledge (as will the response overall).
Name-dropping is also useful in that anyone scanning a page of text might recognise words which catch their interest – and so lead them to actually read your response more closely. Conversely – a lack of ‘buzz-words’ might imply that you’re merely waffling.
Conversely, be careful not to rely on name-dropping alone; there are definitely circumstances where it’s worth putting a small degree of appropriate fluff around things; and also along these lines it’s a good idea to provide the full name rather than the acronym only. For example, when listing relative experience:
- Wrong: SOA
- Good: Service Orientated Architecture (SOA), 5 years experience.
Don’t wax lyrical about the subject if it’s not directly answering the question, for example: don’t discuss the advantages of standards compliance if the actual question is to simply state how you actually ensure the standards are met.
Presentation
Have you ever been guilty of judging a book by its cover? Presentation counts – and done right it’s easy an ‘easy’ way to earn points.
There are a number of points to this: the obvious visual and aesthetic aspects and (the less flashy but just as important) usability aspects like layout and wording.
An optional but useful technique is to prefix your individual responses with the actual question from the RFP, this leaves the reviewer in no doubt they have found the right content. A clearly headed and structure response should negate the need for this – so it does depend on how you want to present your response. It can also help whoever is writing the response to stay focused on target.
If you have supplementary information in other parts of the document mention it clearly at the end of the ‘formal’ part of the response to a specific question. Supplementary info is good but may not always be read in full by all reviewers:
- Reviewers will focus on the formal responses first and they may not review supplementary content particularly if they are under time pressures, tired or feel overwhelmed.
- If the reviewer thinks they have formed a sufficient opinion based on the ‘formal’ answer to a question they are unlikely go looking for additional info.
Including additional sections of information is fine – just make sure it doesn’t get in the way; reviewers hate having to wade through a big thick document just to find the information they need.
Never attach core information separately to the response (“sample widgets attached as jpegs”), if it’s worth including in the response please embed it in the actual response, and ensure it looks crisp when printed / photocopied in black and white (because not everyone will print in colour).
One approach is to include a “lesser” (but usable/readable) example in the RFP response document and a big flash high-res copy as an attachment – if the lesser example wets the reviewers appetite they’ll be more likely to go to the trouble to look at the separate attachments.
Think about who will be reviewing the responses: it will be a range of people with various skills and knowledge; what they will all have in common is (probably) a lack of time, tiredness and a lot of responses to go through – make it easy for them.
A lot of companies have pre-defined templates for making pitches, and some of these appear to be used for RFP responses; by all means use these as checklists or something to spark though on the response – but don’t use the template for the response: it probably won’t relate to the structure of the RFP, and will attract the pitfalls mentioned above. In addition, a response whose structure bears little resemblance to the RFP makes it look like you haven’t even read the RFP – a sure-fire way to get the lowest score (or risk getting thrown out altogether).
Website focused RFPs’ will typically have requirements around the aesthetic needs of the website; don’t provide text only answers – visuals are a must. Be pedantic over how these are displayed – they must be high quality (Nothing beats a quality full colour reproduction of a nice visual). Think about how the RFP is going to be actually delivered (usually a combination of both hard and soft copies).
When binding the response make sure it’s easy to turn the pages and that all the content on the page is clearly visible. Responses that sit fully open on any given page are a blessing – ones that refuse to sit still without folding over are painful. Ring binding is good, avoid staples and paper clips.
At the end of the day – if the RFP calls for a solution with any sort of aesthetics you don’t want a poorly presented response; if your response looks mediocre it won’t give the impression you can deliver a ‘killer’ design.
Thinking Ahead
RFP responses are usually reviewed by a group of people – usually selected to provide a range of stakeholders and expertise. You’ll have business focused reviewers (perhaps end users of the system) as well as reviewers who are there mainly for the technical aspects. These different audiences may or may not have the same degree of sway within specific areas of the review.
One thing to consider (for example) is the kind of language used to answer a certain question, for example: answers that require a technical response will probably require a different language style than answers that deal with more empirical subjects like visual design and user engagement. Think about the kinds of people who will be reviewing your response – and not just the response as a whole but also those that might focus on a specific area (technology, business, project management, and so on).
Get your geeks to write the technical content, chances are the reviewers will rely on the geek reviewer to help guide them during the final review session where the final scores are thrashed out. The same applies to other sections of the response – get the most relevant person (like the appropriate Subject Matter Expert (SME)) to write the content for a given area; get others to review and critque their work but becareful not to stamp all over their style and approach too much if it’s likely to appeal to the corresponding SME on the clients side.
Staff / Resourcing / People
One of the sections you’ll find in a typical RFP is one that requires you to provide information on the staff who’ll be working on the project, and you’ll usually be asked to explicitly state staff members by name against specific roles. This will be mandatory – so make sure you do it.
Make sure you answer the question – kind of obvious; don’t just rattle off the standard blurb (unless it’s fit for purpose) – it’s easy to slip into making the mistake of covering someone’s past history even if it’s not directly applicable. Make sure you directly and clearly answer the specifics of the question before adding details about what you do in your spare time.
Typically you’ll be asked to provide relevant details as to the experience of these people, perhaps in the form of a one page CV, there are many pitfalls here to be wary of – including all the baggage that usually goes with good CV writing, but there are several simple things you must do to avoid a bad review:
- At the very least: state the number of years experience in the relative field. Stating the number of years the person has worked for your company is pretty much irrelevant – say that if you want to, but only in addition to their total relevant experience.
- Stating relevant skills, projects, technologies and so on is good but not enough on its own (see the ‘name dropping’ section, above). Please don’t provide three pages of waffle and not state the total number of years of relevant experience.
- Provide all Staff CV’s / Bio’s in the same format.
- Pictures aren’t mandatory but are generally a good idea – people like seeing people. Make sure the photo quality and reproduction are excellent otherwise the value of having the photos will be diminished or may backfire completely.
RFP requests are typically after a well rounded solution (for example, if its a website there will probably be business, aesthetic, architectural, development and testing aspects that need addressing), bear this in mind when providing staff bio’s. I’ve reviewed RFP’s that needed a breadth of skill, and seen responses that listed a bunch of developers or designers and little else.
Don’t be afraid of out-sourcing. As a general rule I’ll give more points to a response that out-sources security testing to a specialist [2] firm rather than one that does it in-house, although this can depend on the size and skill of the vendor behind the response. That’s my personal position, and not everyone has the same views as me.
I guess there’s the potential for that to backfire if the owner of the RFP has some pre-conceived idea that they want a single vendor to deal with. If you’re a small firm then I’d say you’re better off taking the out-scouring route, and you can always have them working for you as a sub-contractor – so there’s still only one point of contact (and invoice) for the project owner to worry about. Just make sure you’re clear in your response.
In Conclusion
Writing a good RFP response is learnt skill and it’s evident when the response is coming in from someone who has done it before, but you have to start somewhere. It’ll be your team that does the actual work if you win – so you’ll stand the best chance of winning if the team contributes to the response. Allow yourself plenty of time, check the basics – and go get ‘em!
References
http://en.wikipedia.org/wiki/Don’t_Make_Me_Think1. http://www.morphological.geek.nz/blogs/viewpost/Peruse+Muse+Infuse/The+Laws+of+Specialisation.aspx2.
Some rights reserved. http://creativecommons.org/licenses/by-nc-sa/3.0
Peruse Muse Infuse 