- How to write an RFP for a software house in a way that serves your project? - 9 December 2022
- Techn(olog)ical debt and how to avoid its dreadful consequences - 23 March 2018
- Software development – how do we do IT in Poland? - 6 September 2017
Have you ever wondered why IT projects fail?
Forbes Technology Council found 14 different reasons of negative outcome in software development. Some involve a very early stage of the project and could be avoided by writing a proper RFP.
This is why I come to you with a short instruction about how to write it. Keep on reading if you wish to end up with a working piece of software, successful in its purpose and functions.
What is an RFP really for?
RFP (Request For Proposal) is the initial document you write before selecting a software house. It should help you collect business proposals from various vendors.
Because it is intended for software development professionals, it is important for it to fully describe your requirements. The better you explain your needs, the better offer you will get. And I don’t only mean a cheaper one.
An effective request for a proposal reduces risks of future misunderstandings. And ultimately ensures effectiveness and favorable outcome of the project.
In return, you should get a detailed recommendation of the most suitable approach. Of course, if RFP’s recipient is interested and capable of meeting your expectations.
Who should be the one to write an RFP?
Who should you give the task of writing an RFP to? Are you considering a particular person from your team?
The choice is yours to make. This can be an assigned product owner, a member of the IT department, or maybe a hands-on Head of Sales.
The most important thing is that they are aware of the way you do business and are able to recognize what and how needs to be done in the system. Broad understanding of your day-to-day work routine helps too.
Remember that the goal is to get a software that serves real users. I strongly recommend organizing a meeting with everyone who could provide valuable feedback. The best option is to invite members of all the relevant teams and include their perspective beforehand. The RFP itself can be drafted by one person, but it definitely needs to be a group effort.
Why it matters if you write an RFP?
There are at least four different benefits of preparing an RFP (that I was able to quickly come up with). Keep them in mind if you ever consider skipping that part during your next software development project.
RFP vs. RFI vs. RFQ – what’s the difference?
It happens that people sometimes confuse the RFP for a request for information (RFI) or a request for quotation (RFQ). Before I skip to explaining how to write it, let’s make sure that you know the difference and can recognize it from afar.
Request for information (RFI) is used to clarify the information provided by the vendor in their public materials. It should be used at the very early stage of interest when only simple explanation is required.
Request for quotation (RFQ) focuses on the pricing for an evident product or service. It applies when your only concern is how much something costs. And there is no need to lay down a strategy for how to build it.
RFIs and RFQs come before or in simpler situations than bespoke software development. RFP, on the other hand, is much more detailed and very suited for software development. It should include a list of technologies to use and timelines to meet during a very complex project.
How to write an RFP that serves?
As I have tried to tell you, Request for Proposal needs to be comprehensive. The more detailed and thorough it is, the better for you and for the software house that gets it.
Here’s the instruction for it, I have promised. Follow those five steps and get it right at your first try.
Step 1. Write a project overview
The first part of an RFP should be the executive summary of your goals, requirements, and restraints. I recommend writing a brief introduction to your business and including feedback about the current state of your IT environment. If you wish to get a mobile app – make that clear as well.
In order to write an informative intro, ask yourself the following questions:
Step 2. Define scope of the project
Now it is time to focus on the technical aspect of your project. This part will probably be the longest component of your RFP. It will require a lot of time and consideration. But do not get discouraged. If you do it right, it will be easier for the software development team to come up with the right solution. They will also more effectively determine the amount of work and estimate the costs.
As you probably already know, most of the software houses charge by the hour. If you want to know how much you’ll pay, you need to first agree about what is there to do and how difficult it will be.
I suggest that for this part of your RFP, you provide the following information:
Step 3. Share preferable timelines
Setting timelines and setting priorities are inseparable. Therefore, while preparing an RFP, you need to ask yourself two important questions:
By having this information, the software house can decide whether they:
Step 4. Specify your budget
Even tough, I do not recommend fixing a price for the whole project, it is still beneficial to think your financial capabilities through. If you are able to estimate your budget, it will be easier to break down the costs of each stage of software development and decide about the priorities. The software house team should also help you decide what to leave for later if the features become too pricey. Unless, there are no limits?
Step 5. Lay out selection criteria
At the end, it is good to let the vendor know how you’ll judge if they’re right for the job. If you make the evaluation criteria transparent, it is more likely that you’ll receive adequate feedback.
For instance, ask a supplier to provide the following:
Additional tips for RFP stage
- How to write an RFP for a software house in a way that serves your project? - 9 December 2022
- Techn(olog)ical debt and how to avoid its dreadful consequences - 23 March 2018
- Software development – how do we do IT in Poland? - 6 September 2017