How to write an RFP for a software house in a way that serves your project?

rfp for software house agile development
Michał Nowacki

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.

  • Working with the best. Thanks to an RFP, it is easier to compare potential vendors and to understand whether they are able to meet your requirements. You are better equipped to make the right choice and pick the most dedicated and experienced development team for the job.
  • Getting various points of view. In response to your RFP, you will receive multiple ideas about how to approach your project. You are free to merge them and further improve the strategy presented by the overall better vendor.
  • Saving time. Thanks to an RFP, you will spend less time explaining your business to software development teams. You will also filter out companies that are not suitable for the job and waste no time meeting with someone who cannot help you.
  • Better managing your budget. An RFP leads to receiving information about what each software house is going to provide and at what price. If you get through a process of sending out RFPs and then collecting feedback from multiple software houses, you will get a better understanding of what type of services come at what cost.

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.

  • when searching for simple feedback
  • casual in tone
  • goal: defining next steps
  • when exploring pricings
  • direct in tone
  • goal: effective budget management
  • when looking for very specific information about vendor, product and approach to software development
  • structured and formal in tone
  • goal: vendor comparison

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:

  • Why is it important to get a new software?
  • What is the main purpose of the software?
  • What are the goals during the project?
  • How will you judge that the project was successful?
  • What kind of obstacles are you trying to overcome?
  • Why is your current solution not working? (If you have one in place.)

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:

  • Project management requirements
  • Infrastructure requirements
  • Functional requirements
  • Quality factors and testing requirements
  • Platform’s requirements

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:

  • Is there a date for when you need the software up and running?
  • When should the development team start working?

By having this information, the software house can decide whether they:

  • have the necessary number of specialists for your project,
  • can meet the specified deadlines,
  • figure out how to divide tasks and give out responsibilities.

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:

  • a brief description of their company
  • introduction to the development team (i.e., experience, and resumes).
  • information regarding working culture and processes
  • project plan  (i.e., stages and timeframes).
  • technical proposal (i.e., technologies and architecture).
  • budget estimation (i.e., required project expenses, rates of specialists, and possible additional expenses)
  • suggestions for improvements not mentioned in the RFP
  • other customers’ testimonials

Additional tips for RFP stage

  • Don’t focus on the prices. If you only consider the price, you may end up with lower quality software.
  • Don’t focus on one solution. Let vendors offer solutions that they think may be effective. Their expertise should be of value.
  • Highlight “must have” features. The more specific are your needs in RFP, the fewer surprises happen during the project.
  • Don’t send your RFP to too many potential vendors. Remember that it takes time to evaluate the proposals. Send your RFP to 3-5 companies. You’ll have enough info and won’t cause work overload for your team.
Michał Nowacki
Scroll to Top