So you need an RFP?
You’ve been tasked to get your RFP document ready to send out to vendors. You’ve identified a major gap in your IT infrastructure, and you’ve got the budget set aside for what you want to accomplish.
In this article, we are going to focus on the needs of a software/database focused project, but similar concepts will be able to be done with any project.
The major problem with an RFP process, especially for small teams, is that your bulleted list of requirements is too vague for anyone outside of your company to interpret. When you say “ability to create customized reports”, that could be interpreted by proponents to mean “when you ask, we’ll customize them for a fee” to “if you know crystal reports, and have SQL knowledge you can customize any report”. These are two massively distinct responses to what seemed to be a straightforward question.
Why are you really creating an RFP?
Companies will typically be creating an RFP for one of three reasons:
1. You don’t have the internal expertise to complete the project.
2. You don’t have the internal capacity to complete the project in the timeframe you need it completed.
3. You already know who you are going to work with and just need the process to appear fair and transparent.
If you’re goal is to cover number three because you’ve already got a vendor in mind that you trust, then by all means just download a free RFP template and make the section of the requirements mirror the proposal you already have on your desk. Problem solved, you should be ready for your golf tee off tomorrow morning with your vendor!
Let assume if you are still reading this you either don’t have the capacity internally to complete the project our your team lacks the technical expertise to do it.
If you don’t have the resources internally to execute the project:
To get a better results in any IT project we think it’s critical to focus on outcomes of the project, rather than deliverables of the project.
- What business value will this project produce? More sa
If you have the resources internally, but not under the given timeline:
If you are truly just looking for execution in RFP then what you really are looking for is a commodity response to your RFP. You already know how you want to implement the project, you just can’t because your team is working on other project. If that’s the case, then I would suggest focusing your efforts more on agencies that provide staff augmentation.
You and your team already know that you need to implement this with C# a SQL Server backend and hosted on MS Azure. There’s no sense sending out an RFP to get back responses of people want to develop it in Node.JS or Laravel, or Rails or whatever their platform du jour is. In this scenario, especially since you already have the team internally that could be completing the project, you should create a small internal team to go through the RFP and create their ideal plan for what the new system will be like. If your team isn’t on board as to how it’s going to be completed, then you are risking your long term success on the project – especially if support and maintenance are handed back to your team after the project handover. Taking these steps and getting your team involved first will prevent you from ending up with a really bad case of “not invented here syndrome”.
What are my actionable steps from here?
- Decide on the business outcomes you want to meet with the success of this project.
- Identify the potential cost savings and revenue increases based on the business outcomes you have defined.
- Take our free email course that focuses on identifying waste in your business processes and IT systems.
How are you struggling creating your RFP documents? Reach out and let me know!
Want to create an RFP that gives you excellent proposals?
We offer a project roadmapping sessions specifically for companies who need to lock down requirements for their custom software projects.