Here’s What You Should Do Instead of Relying on an RFP
Here’s my advice and, look, I’m not advocating for us here, but you.
Custom software isn’t a house. It’s a business asset that has never existed before and it is customized to the very nuanced needs of your company or your product. The code for each of these applications is like a one-off novel with actions and behaviors and results defined by you and those actions and results and behaviors aren’t static. Software is ever-evolving – an organic response to the (hopefully) growing and changing needs of your organization. Creating applications is a creative and arduous endeavor and, having watched hundreds of applications birthed into existence over the past 10+ years, I can say that, despite a client’s best efforts to make this a bloodless effort, it is always a labor of vision, effort and, many times, passion. Successes in software aren’t met with a simple dusting off of hands, but rather awe, relief and pride. Our clients enthuse. They have toasts. They celebrate. Building custom software is emotional and it’s exactly for this reason that I love what I do.
So rather than approaching the effort of finding your custom software development partner in the same way you might approach your search for a copy machine maintenance contract provider, think of it as choosing a collaborator with whom you want to get into the foxhole of creativity, long nights, hard questions and deep trust. You can’t discern this with an exhaustive questionnaire or a glossy PowerPoint presentation by sales representatives.
Forego the RFP and get on the phone with the development partner.
Talk to their development, design and QA staff. Share your concerns and your vision. Roll up your sleeves and get a little dirty with the process.
Get to know the team members who might work on your project.
- Are the team members you meet intelligent and didactic? Can they break down concepts for you in a way that makes you feel comfortable? Are they patient? Are the people on the team passionate about what they do? Do they ask good questions? Do they seem to “get” what you need? Do you get the sense that they would develop software even if they weren’t paid to do it? How are their verbal and written communication skills? These are people you will be working closely with over the next few months and you want to be sure that communicating with them feels comfortable, easy and transparent.
- Are they honest and do they have integrity? Are they willing to tell you what’s going to be hard? Where your expectations are too high? Can they help you manage your own grand vision into something you can accomplish in a reasonable amount of time? Can they propose contingency plans?
Learn what you can about how they approach working on different projects.
- What are their development processes like? Have them describe how projects generally are implemented. Does that feel safe to you? Can you make sense of that? Are they willing to compromise on that process to help you feel safe or at least explain reasonably why changing that process is a bad idea for you?
- Have them talk about their past work. A portfolio or list of other applications here is pretty useless and not what I’m suggesting. What you are looking for is how they talk about their clients and the projects. Do they take obvious delight in the application development story? Are they proud of their relationships with their clients? How did they resolve conflicts in the development process or with the client? (Trust me, there is always something…) If they can demonstrate ownership of their part in the effort to implement a successful application for another client, that will bode well for their ability to demonstrate ownership of their part of the effort to implement your application.
Talk openly about your requirements in order to get a better sense of how they might address your needs.
- Spend some time working through the details of the requirements both because it will help the development partner better understand the robustness of the features you want to implement but will also allow you to see what it would be like working with their team. Does their requirements-gathering and clarification process give you comfort that they will be thorough when tasked with ferreting out the nuances of your application requirements?
- Ask to review the development partner’s Style Guide. This is a document that outlines, for the development partner’s developers, how code will be written, commented and documented. It’s sort of the development partner’s code manifesto and the fact that they have one and will share it with you says a lot about the standards to which they hold their developers and their work product.
- Ask the development partner to tell you about their QA processes. There’s a lot you can read up on here, but the big thing is that they have a formalized process and that the code is tested in an ongoing basis and as part of the development cycle. They should be able to share your custom test plan with you as development evolves.
Let your team talk with their team.
- Get your internal development team together with the development partner’s team for a chat if you have an internal development team. Everyone will need to work well together and positive relationships will smooth the way and may also allay any latent fears that your internal team will be marginalized, replaced or forced to support a hacked application.
- Get your stakeholders on some of the initial calls. It will be easier to defend your choice of vendors if they feel viscerally about the vendor the way you do.
Ask questions about their work with other clients.
-
Check references after you’ve had a successful initial set of calls about the application.
Ask the development partner about their number of repeating clients. - Ask them to tell you about them.
Work together to determine the best approach for your project.
- Collaboratively decide what the proposal should be. Perhaps after initial discussions, a proof of concept (POC) or Discovery proposal is the most effective and cost-efficient route to take. Perhaps it makes sense to break the project down into several, 3-month mini-projects with a solid estimate and requirements delivered in the proposal for the first as well as a broader ballpark on completion of the entire effort. Perhaps it makes sense to break off a module of work or to split the work between internal and external teams.
Don’t just focus on the projected cost of the development.
- Don’t choose on price alone. If you’ve done the above, you’ll know that the vendor understands your needs, is capable of implementing your project using proven processes and methodologies that demonstrate progress, and that they “have your back” when it comes to helping you make critical business decisions that might impact your business objectives. If the price of the proposed work scares you, the solution isn’t to go find someone else who can do the work at a cheaper hourly rate. If you don’t like the projected cost of a software development effort, go back to the development partner and ask them how to make your project less ambitious. The vendor you have the best relationship with will undoubtedly be able to extract your complete requirements, process them into tasks, prioritize them, manage the implementation effort efficiently, test the application thoroughly and release more successfully than the cheaper company you have a wonky feeling about. The poor relationship costs you money and may cost you the project – it is that simple.
If I’ve conveyed anything in this post, I hope that it is that your custom software development effort deserves and requires more than a 9-page RFP and an arms-length development-partner vetting process. If you must use an RFP format, including some of the above suggestions to make the assessment process more flexible, high-touch and collaborative will only yield higher quality proposals, better vetted development partners, a more successful application implementation and at least 8% fewer sleepless nights.
Click here to download the entire RFP article as a single PDF.
