RFP for Software Development – Request for Proposal Template & Best Practices

If you want to build software with an external company and think a request for a proposal is a thing of the past (and a pain in the… neck) – you should read this post. And if you think RFP is something like BTW or TMI – you should definitely read this post.

See why you should create an RFP when you’re looking for a software development team – and how to do it so that it’s useful for everyone involved.

So, what is an RFP (Request for Proposal) – and why send one?

A request for proposal is a document you’ll usually write when you’re looking for a vendor or a service development company. When you have a software tool or platform to build and are looking for a software house, the RFP will help you select the one you’ll eventually work with. The document outlines the details of your project (and we’ll get to the actual details in a minute) – including the technical requirements and time and budget constraints.

Based on an RFP, you’ll get proposals and quotes from the companies you send your RFP to. You will also be informed whether Time & Material or Fixed Price billing will work better for you. 

Which is the main goal of your RFP – to be able to compare bids and action plans from various software development companies based on as many details as possible. Your software development RFP can also help you see elements of your project you might not have noticed or considered before.

If you write it right, it’ll definitely help you make the right decision and make sure your project is off to a good start.

Source: https://www.smartsheet.com/request-for-proposal

Who usually writes an RFP in software projects?

The answer is – it depends. On both the size of your project and the size of your team. It can be the project manager along with any of the experts (or teams) at your company that will later be involved in evaluating the proposals and eventually, in the project itself. So make sure you don’t forget to include anyone who’ll play a key role. It would be good for the person who prepares the query to know the methodology of AGILE work because this is how software houses work most of the time. 

RFP Template – 10 Elements of a Complete Software Development RFP

1. Introduction/Project overview

Outline the project and the contents of the documents – so that after reading this the vendor knows if this is something they want to engage in. Remember, this is not an academic essay, so instead of writing long sentences just to reach the character limit, get straight to the point and make it as informative as possible.

2. Company background

Write a little about what it is that you do – and how the project fits into the overall landscape. You can include things like:

•  the story behind the company,
•  a list of products or services you offer,
• where your offices are located
•  how your company stands out among your competitors (especially if the software you want to build has something to do with it.)

3. Project goals and target audience

Describe what the project is supposed to achieve and who the intended users/customers are. Consider it a great opportunity to really nail down the goals and the target audience for yourself (another reason why writing an RFP for software development is actually useful.)

4. Project scope and deliverables

This is the place for including the stages of the project. What will it involve? What exactly do you need help with? What should the software be comprised of? Decide on additional aspects you’re going to outsource like:

• project management,
• graphic design,
• testing and QA,
• software training,
• etc.

5. Technical requirements

Here go any technical details that are essential to the project. Make sure to describe things like:

• your existing IT infrastructure
• other apps/platforms the software will have to integrate with
• devices and systems the software should work on
• user accounts
• accessibility
• etc.

6. Target deliverable schedule

You probably have a deadline – here’s where you include it, plus deadlines for all stages of the project you outlined earlier. Be prepared to negotiate.

This is important because it will help the software development company decide if they can even fit the project into their schedule, or prepare additional resources so they can meet the deadline.

7. Possible roadblocks

Anything you know might cause issues on your end during development? Don’t keep it to yourself if you want your project to succeed (within your intended time and budget.)

Your software development company needs to know if you anticipate anything that might cause additional problems or delays. Maybe it’s the current infrastructure that might need updating on your end in the process? Or planned staff shortages or changes on your team? Including all this in your RFP will help you find the company that has the skills and resources to manage in these situations.

8. Budget constraints

Include the planned budget (and be prepared to negotiate – you might not have considered every possibility.) Also, be prepared to decide if you want to go for a fixed price – or go with agile development that might mean the requirements might change during the process (and so might the cost.)

9. What are you looking for in a software development company?

Got any specific selection criteria? Maybe you’re looking for specific expertise, or a specific project management approach, maybe location/time zone is important? Write them all down here. Make it crystal clear who you’re looking for – this will make the final selection much easier.

10. Point of contact

Let vendors know who to contact in case of questions and how to deliver the proposal. And don’t forget to include the deadline!

Remember, the more precise you can be, the better offer you can get from a software house.

What to keep in mind – best practices

Here’s a bunch of tips and best practices that might help you create an effective software development RFP (because we’re not bothering with writing ineffective ones – ain’t nobody got time for that!)

• Provide context and as many details as you can. This will both save your vendors’ time – and yours (because you won’t have to keep answering the same questions all over again.)
• Know your IT infrastructure and technical requirements. This is super important, so make sure you include your IT experts in the process of creating an RFP, if you have them on board – they’ll know what to ask.
• List all your functional requirements (the features your software should have) in a spreadsheet. The more detailed requirements at this point, the more accurate the quote you can get – and the fewer surprises later on.
• Separate your must-haves from nice-to-haves and wish lists. Decide what’s absolutely necessary for the MVP (minimal viable product.) What can come next? What’s great but won’t hurt if you can’t have it?
• Don’t send it to too many vendors at the same time. You might get overwhelmed otherwise. Spare yourself some time and make a preselection of those that meet your initial requirements. 
• Don’t just look for the lowest price. This might sound obvious – but unfortunately, it not always is. The RFP is your chance to find out a lot about your potential software development company – so take it and ask the right questions. If you’re just looking at the price, you might end up with lower quality/less functionality/slower development (and eventually, even higher costs overall.)
• Give them time. Detailed proposals will need at least a few weeks so make sure you don’t send your RFP at the last minute. If you want a thoroughly prepared and realistic proposal that is. Remember – what you agree on at this stage will later determine the development of your actual project.

Ready to RFP?

A good software development RFP is not that difficult to write – although many seem to think so. It’s probably only difficult if you don’t know the WHY behind it (and if you treat it as yet another useless document you have to create.) So sit down with everyone on your team that will have a say in this – and write down all the WHYs. And let the vendors respond with the HOWs in the proposals.