10 RFP response signals to watch out for

When you're reviewing RFP (Request for proposal) responses you make sure that the provider has met all your specified requirements. A provider missing a requirement on the proposal is a bad signal. Then you weigh the response details against each other and finally the price gets calculated and you choose.

But here are 10 specific signals outside of the standard stuff above that I look for.

1. Handover

Do they mention how the handover will work and how long it might take? There will be a time when the relationship ends and you have to take ownership of the vendors output. You have to make sure the vendor has a plan for this already and the indicate how much time it will take. And that the estimate is realistic.

2. Quality Focus

Do they have a quality focus to avoid bugs? Do they specifically allocate time for cleaning up bugs (there will be bugs). Is there evidence that they have a culture of quality work in their organisation outside of just mentioning QA and unit tests. Do they reward high quality work? Do they highlight it as their best (even though it might not have been the most lucrative or the largest client)

3. Identifying specialist knowledge gaps and mitigating

Do they have all the skills you know will be required to make the project a success? If you know you need specialists based on your RFP, have they mentioned that in their proposal? Have they got those skills internally or do they know they can source it. Have they offered to learn it? Does that sound achievable for your timeframe and requirements?

4. Simple upfront costs

Are they clear about all additional costs? Is it clear who covers licencing for development tools for their team? Who covers travel or onsite allowances? Do they have different costs for different levels of engineer?

5. Risk identification

Do they give an indication of what they work on first? For example is it the highest business value piece or the riskiest engineering piece? Do they have a solid design and investigation process. Is it specified how long this will take in the proposal. Is it realistic? If they are just going to start building stuff right away it's unlikely to be the right thing unless you have a fairly simple problem.

Have they described better ways or tools than the things you might have suggested in the RFP? You might get a huge boost in productivity or maturity by working with an organisation that will pull up your skills.

7. Competitors

Are they working for a competitor? You have to make sure they wont have any conflict of interest, or if they do that they are open about how that can be mitigated (dedicated teams, different segments). As long as they are open about competitors you should consider the valuable experience they already have in your industry.

8. Local or Remote team

Are they local to you or remote? Even though an organisation might have offices in your country it's very popular to ship the actual work off to a cheaper location and get location arbitrage. This will likely be reflected in the price which might suit you but do watch out for premium prices that will send your work off to an offshore team.

9. Are you a tiny customer for them?

Are you going to be a large customer of theirs or a small customer? If you are a tiny customer you may not get the same level of service if they have to apply more people to a larger customers project. It is likely that the organisation would support the larger customer ahead of you. Sometimes its better to work with a smaller vendor.

10. Rework and surprises

Do they talk about keeping iteration time back for unforeseen issues? They are a new team working on your system. They will build the wrong thing sometimes, they will write bugs and there will be surprises! Favour the vendor that explicitly builds this in to their iteration plan.

That's it! Good luck choosing an awesome vendor!!