When scanning over the words “please respond to RFP” in an email, I cringe a little because I know what I have to do next – explain why software development RFPs aren’t an effective method for evaluating potential partners.
The traditional RFP process itself isn’t the issue; it’s typically what’s asked within them.
In this blog, we’ll discuss what RFPs are and what they traditionally lack, and then prepare you for how to write an effective RFP for your custom software development project.
What is an RFP?
A Request for Proposal (RFP) is a formalized document that businesses send to vendors to bid on the business’ upcoming project.
Many times, this process is required by companies, and your hands are tied – you have to send out an RFP. We get it. You’re doing your job, and that’s okay. However, the traditional RFP may not yield the quality vendors you need for your project.
I’ve read many RFPs over the years. Typically, they are disorganized and lack context about the people involved as well as the underlying business problems that need to be addressed.
What happens time and time again during the traditional RFP process is the response with the best presentation or the lowest cost is selected.
For custom software projects, where the normal failure rate is 60-70%, do you really want to gamble your project on a broken process? I don’t recommend it.
What’s Wrong with Traditional RFPs
1. Lack of relationship building
The traditional RFP process doesn’t naturally facilitate partnerships. In fact, it puts parties at odds with each other and attempts to commoditize a process that requires trust.
Trust is only earned after a relationship is developed between the development team and the client. And both parties must commit time to building rapport and getting to know each other.
Developing a software system inherently has risks, and you need to know the team building that solution for you is one that you can rely on. By only having a vendor respond to your document with another document, as most companies expect when they send out RFPs, you can’t determine that at all and, in turn, increase the amount of risk associated with your project.
2. They don’t allow development firms to understand the big picture
When traditional RFPs are sent out, they typically aren’t responded to with a request for a deeper conversation to allow the development firm to fully understand the problem.
Without allowing the time up front to talk and help a development firm understand your business, you’ll end up spending more time later trying to fill in the holes that were missed or headed down the wrong path, ultimately leading to project failure.
When system requirements are based on guesswork and unclear, traditional RFPs can put your project at risk from the very beginning.
From our point of view, asking software development firms to pull together estimates for fuzzy requirements doesn’t make business sense. This is why we prefer to take prospective clients through our free Pre-Project Consulting process rather than respond directly to RFPs.
This process will help save you time and reduce the risk of your software project.
3. Unequal comparison
RFPs don’t give an apples-to-apples comparison. You’re not buying widgets. Firms have unique capabilities and differentiators.
For instance, Frogslayer has a reputation for delivering working, reliable custom software faster than any other team. We’re not the cheapest, we don’t build-to-spec, we don’t do staff augmentation, etc. Other firms take different project approaches or have different capabilities.
You have to tease this sort of information out of the companies you’re looking at. This is difficult to do in an RFP. Your best bet is to pick up the phone, have a conversation, ask questions, and let the firm ask questions back.
An Effective RFP Outline
So, what should you do if you are required to write an RFP?
This might sound crazy, but effective RFPs ignore project details, cost, and schedule.
To select the best partner, you should focus your RFP on understanding the vendor’s company and team. Below is a downloadable sample outline:
Company
Understanding a company’s background will give you a better look at the individuals you’ll be working with. Knowing why and how a company was created can tell you a lot about its values, beliefs, and motivation.
Additionally, employee stats will help you determine how long people have worked together; teams that have experience together tend to be higher-performing teams.
Financial and client stats, on the other hand, will give you a good idea of the health of the business. Profitability is a good indicator of stability, usually indicating a lower rate of mistakes or project failures and a strong ability to capture new work. Growth is also a good sign of stability and health. Not many vendors will be willing to give this info to you, but you’ll quickly see who takes transparency seriously.
- Brief History
- Years in Business
- Ownership Structure
- Are owners also employees?
- Are they active in running/managing the firm?
- Employees
- Headcount
- Years of Experience
- Retention Rate
- Financial Stats
- Revenue per employee for past three (3) years
- Profitability compared to peers
- Working capital
- How cash-rich or cash-poor are they?
- How much debt do they have?
- Growth rate for past 3-5 years
- Clients
- Total Clients serves in past three (3) years
- % of Revenue from largest customer for the past 12 months
People
Find a company that stands for something bigger than itself. Companies that invest in their people and get recognition mean that they care about their people. When you have happier people in creative-based work, they are more productive and innovative. Unhappy people are an indicator of “death march mentality” and bigger issues related to ongoing project failures.
- Culture
- Values
- Purpose
- Best Practices
- Activities
- Awards
- Pictures
- Hiring/Recruiting Approach
- Professional Development
- Learning Program?
- Speaking
- Publications
- Blogs/Articles
Relevant Projects
Past performance is the best predictor of future success. Including this section is a direct way of asking about their past performance rather than asking them to speculate about the details of your project. You want to make sure the vendor really understood and addressed the business goals of their client, not just able to spout a bunch of technical jargon.
- Relevant Projects
- Size of Project
- Duration
- Results
- Client References
- What was their most successful project? Why was it successful?
- What was a project that failed and why?
- What was the final outcome?
- What actions did they take to correct the failure?
- Was further work done for this client?
Proposed Project Questions
Finally, make sure the vendor understands your problem. This section will reveal their thought process, as well as how they approach projects.
- What is the risk?
- Any assumptions?
- Who is the proposed team?
- What is their approach?
- Management
- Communication
- Reporting
- What are their technical practices?
- Design
- Development
- Quality
- Do they offer support?
- Future Features
- Bug Failures
- Response Times
- Hosting & Monitoring
Questions for References
I cannot stress this enough. Always check references before moving forward with a team.
References can provide firsthand insight into team dynamics, communication patterns, and a team’s commitment to timely deliverables. Keep in mind, these insights can significantly impact the success of your partnership. Consider asking the reference the following questions:
- Who did you communicate with on the team?
Look for regular, effective, direct communication with the people who did the work. An account manager intermediary can be problematic. - How often did you receive a new release that you could evaluate?
Once things are rolling, a weekly release is totally possible but often rare. Monthly is the longest you should tolerate. - How was your feedback handled? Was it documented and then acted on?
- Were you able to steer development and influence features?
The team should be able to accommodate new ideas and refinement of features as you go. - Were you given regular status reports that included the amount of work accomplished and the work remaining?
- Were you surprised at any point during the engagement?
- How often did you hear things like, “We can’t do that because you didn’t tell us earlier?”
- Did your project run over budget, or was their initial cost estimate accurate?
Budgets aren’t always fixed, so this may be a complicated answer. - How did the team make estimates? Were those estimates accurate overall?
Any single task estimate may be off, but in aggregate, over a larger body of work or a longer period of time, estimates should be pretty accurate. - Were you actively encouraged to limit the scope of your application?
Clients usually err on the side of wanting to build too much. Building less and getting a product into customers’ hands earlier is often a better strategy.
Resources for Clients
Read post
Hiring the Right Software Development Partner
As I said above, the only way to know if a vendor is the right fit comes down to trust and comfort. And that won’t come until you talk to their team. Ask yourselves these 3 questions when evaluating a software development partner:
- Do you communicate well with their people?
- Do you feel that they understand your business and your challenges?
- Do they ask good, smart questions?
If you answer yes to all three of these questions, it’s safe to say they are likely a good fit for you and your company.
-
Ross Morel
