I'm sure that at least a couple of times you've seen that quote: " A journey starts with a single step." And we bet it has been one of a few rare constants in your Instagram feed. Even with this being such a cliche, it can't be closer to the truth. One of the basic steps for a successful IT project is creating a proper request for proposal, and it's one of the earliest steps in the life-cycle.
Here at JSGuru, we've seen how many problems bad RFP's can cause, leading to frustration and unnecessary complications. That's why in this blog we're going to give you a clear and structured explanation on how to write a proper and clear proposal. This is so important for startups and companies because it can provide a clear picture of what has to be done, in what order, how long it will take and how much it will cost.
I think you can agree that in the beginning there's rarely anything more important than having a good and specific plan for your future project. Imagine asking for an investment and not having a clue how you're going to build your product or in what stages. Shark Tank people would not be so proud and kind to you, would they? More importantly, if you are going to find a remote company that's going to build your idea/product, you want them to relate to it. You want them to feel what you feel and make it as their own creation.
Before we begin with the juicy stuff, let's just quickly define what an RFP is for those that are unfamiliar with the term. RFP or request for proposal is a document that gives a clue to a company that's potentially going to build your product on what exactly they need to build. It contains the problem you want to solve and how would you solve it with a specific list of features and your budget. It should be simple and straightforward.
So let's begin…
The summary should contain what you are trying to achieve with your project/which problem are you going to solve. Something like the first slide of your pitch deck... It's also good to address why you are trying to build the thing in the first place, the deeper reason behind all of it. It gives a clue to the remote team how to approach the whole thing and why they should care about your product.
Our solution is solving the problem for cheap accommodation in major cities during large expos. The app has to be intuitive and easy to use from the first sign up, with clean and minimal design. The design is very important to us. We want to make the process easier and more accessible for people that don't have much money but still don't want to miss out the experience of new learning, networking and growing their business.
You don't have to be this short, but the essence is here and there's no need to drag it out too much as well…
2. Your background
People buy from people, remember that. It's also a reason why your new potential partner wants to understand you better. If you are a fresh startup, give them a brief story about yourself and your team. If you are a well-established business, then explain what your company did in previous years and what you stand for. The key here is to be short and concise. Simple a few sentences will do the job.
We were a freshly founded startup and a team of people previously employed by large corporations that could afford to send us to large expos and shows that improved our career in many ways. Now, we would like to the same for people that want to visit them, but don't have sufficient funds to do so, or barely do.
3. Project range
Make sure that they understand the two previous steps clearly, that's how they can give you a really matched and fit advice for your project. After that, be clear what kind of services you would like to get from the remote team. Many of them have a full range of services that include more than development and design.
A complete list of those services could include (Some of these things on the list could be unnecessary for your specific project or it could not be enough. Unfortunately, the range and variety of IT projects make it really hard to have a unified list):
- Project Management
- UX/UI Planning
- Visual Identity
- Graphic Design
- Project architecture setup
- Frontend development
- Backend development
- Continuous integration and Continuous delivery
- Quality Assurance
- Content Migration
- Cloud provider setup
4. Parameters + sketches/mockups/wireframes/prototypes
This is where you get a little bit technical, that's if you know which programming languages and frameworks you want to go with. If not, this is an excellent moment to search for recommendations from the agency. Be upfront with what you would like to achieve and your goals. You can say to the agency that speed is the number one priority and this fact can certainly steer their recommendation to a specific programming language.
Now, let's talk about sketches, wireframes, mockups and prototypes.
It's essential that we understand the difference between these four. They almost represent the same thing but in different stages.
- So sketch is something very basic, just a basic layout of the wanted product.
- While wireframe is a layout with more structure and details. It exactly portraits where each element of the product is going to be.
- When it comes to mockups you can look at them as an added value to the wireframe, with your logo, colors, images, text.
Here at JSGuru we think every project should start with a mockup, it's okay if you don't have it, but the benefits are multiple. Let me name just two. Your remote team is going to understand the project better no matter if they made the mockup, or if you outsourced it to someone before that. The other is that you will have something concrete to show to your potential clients and ask for feedback, but also to investors if you're searching for funding.
The prototype is the last stage = functionalities added to the mockups. InVision is an excellent app that could help you with this. Be sure to check out their blog, every entrepreneur wanting to understand design a little bit better should read it.
We've been on a dozen meetings where potential clients presented their mockups and it was a complete revelation on how their idea should work. So please do yourself a favor and invest your time in making one.
Beautiful, you've made it this far. Making an RFP is like a puzzle game, and this is one of your last puzzle pieces to fit. If you've done everything correctly this should be easy. Analyze and come up with a deadline. Try to be realistic and if you don't have any clues how long something takes in the development process feel free to consult the agency. A tip here could be to set a deadline a week or two shorter, so if something happens you still have time to fix it.
Let's backtrack a little bit. Sometimes it can be overwhelming to think about everything and figure out all the necessary steps but that's business and you need to have most of the answers when others start to knock at your door. If you're questioning the timing of your project and second questioning it in the first place, we've also written previously "When is the right time to develop your product". This blog can maybe answer some of the questions you might have.
It's ideal for us that the project is released by the beginning of 2020. Because spring is the conference season and we would like to start having people that are considering visiting conferences on-board. But before that, we need to have cheap accommodation owners signing up too. To conclude, together with your advising we've come to an agreement that the sensible and doable deadline is December 15th. (You can even go into phases if you have them and dedicate an exact date to each one)
No special advice here. You know how much money you have and what's the budget for the project. There are some factors that can be negotiated though, things like are you paying for something in advance or the whole amount when the project is done. Maybe you would like to pay the MVP firsts and after you get new investments rest of the development phases.
What I'm trying to say is that these things are open for discussion. But it's important to be clear with your intentions and say exactly what you expect to be done for the money you're giving.
It's also okay to leave this part open and ask the outsourcing company how much it would it cost to make. We do recommend that you take the first option with the budget because this way you avoid losing time if both sides don't agree if the project is even doable for that amount of money.
We've secured $35 000 from our private funds. That's what we have for the design and MVP. (Be sure that you have clearly defined what is the MVP, which stage of the product and what features). In advance, we're giving $10 000 to kickstart everything and the rest after the products is realized and all checkboxes from the contract are checked.
There's talk lately that RFP's are not useful anymore because a lot of people don't know exactly what they want to design and build. To some extent, there's some truth here, but also if you go on a quest of RFP making you will answer some crucial questions at the beginning of the project. That can't be bad or unuseful, right?
What's not an RFP?
RFP is definitely not a few short paragraphs of product description written in an email. We've witnessed many emails of that kind and believe us they happen! We hope that they will avoid our path in the future. Someone searching for an outsourcing company should understand that we can't give you a good estimate with a lack of information. No matter how good their developers, engineers and analysts are, you need to provide them with crucial info (all of the above) to give a proper response.
We hope this made the whole thing clear for you and that your quest of searching for the right outsourcing company a little bit easier. You can always reach out to us and ask for more detailed explanations and advice. Good luck!
Before you go…
If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!