Some challenges can be too great for a company to solve on its own, especially if you have limited resources and experience. Setting your company’s overall direction can be fraught with danger as you could lead it into a blind alley for years with the wrong choices. This is where the RFI (and ultimately the RFP come in but I’ll deal with that one later).
The RFI is the prelude to an official project, you should decide what your main aims are without too much specific steer. You’re not trying to limit a project at this stage, you’re trying to understand the art of the possible. You’re usually asking consultancy firms or those firms with tools that appear to fit what you’re after. For the sake of this post we’ll concentrate on a project with very loose scope rather than something highly specific and potentially well understood (such as a unit testing tool).
- Prepare a document with your requirements clearly stated
What are you trying to achieve, in clearly defined sections. You’ll probably be surprised how often this sort of document shows up the difference of opinion between internal stakeholders. Often everyone seems to be in agreement until it’s precisely written down. Ask the company to reply to your RFI stating how they’ve met these requirements.
- Identify the experts in an area
Who are the main players and who aren’t? It’s very important to understand that if you’re going off for a change in development process you don’t select a testing specialist. This is sometimes a real issue when someone has a favourite supplier and insists they’re included (and even worse chosen!). Narrow the field up front rather than inviting tens of companies in.
- Detail your current set up
There’s nothing more annoying for a vendor than turning up with a proposal to hear “that won’t work here”, just because you didn’t bother to write the detail in in the first place. Assign a specific resource to write sections which detail all the relevant information.
- Keep an open mind
Don’t turn up with a pre-conceived idea of what you “must” have. There could be new ideas out there that are better.
- Have some idea how much you want to spend
Most projects have a budget, make sure you don’t waste everyone’s time. If you need a “proof of value” from a project make sure the vendors know this up front.
- Get project buy in from senior stakeholders before you start
This is really important to keep your relationships with vendors in a good place. Don’t spend lots of time and effort on a dead project. If you are going to do exploritory work make sure you explain that clearly to them.
- Support the project with technical staff
Often the vendors will have further questions, make sure you’ve got people lined up to answer these quickly so the responses can be as good as possible.
- Consider how the project will affect your current teams
Do they need knowledge transfer, are they suitable to take over the work later on? Ask the company to explain how it usually works with other companies.
It’s always useful to have a grounding in a subject so you’re not blinded by buzzwords. It’s good if you can do some reading up front.
So that’s the RFI, as I’ve said previously there’s an RFP stage after this but hopefully this post will help get you started.