January 18, 2018
When you’re on the hunt for a new outsourced software development partner for your next project, will you be issuing a Request for Proposal (RFP)? RFPs give you the chance to solicit responses from multiple companies at the same time. Done properly, an RFP process can reward you with a partner that has a good understanding of your needs, has demonstrated their capabilities to the work you need, and will provide good economics for the services they’ll deliver
At Accelerance, we’re experts in helping companies find and establish new software development outsourcing relationships. Based on our experience, here are some guidelines you should consider.
The Software Development RFP Process
An RFP process should allow you to equally evaluate vendors who have used the same baseline of information as you and/or your company to prepare bid responses. Therefore, it’s crucial to construct a good structure for your RFP process, create a schedule for key milestones in the RFP process, and communicate often to participating vendors.
Typically, an RFP process has the following key activities:
-
Communication to prospective vendor-participants of your intention to solicit bids by an RFP process.
-
Distribution of the RFP to all interested vendors, along with a master calendar for the process.
-
A period of receiving and responding to clarifying questions submitted by the vendors. The normal protocol is to receive all questions – then respond to ALL questions in a document to ALL vendors. You may choose to have a couple of iterations of questions-and-answers, perhaps even including an open conference call for all participants.
-
Deeper, one-on-one response reviews with a short-list of finalists (usually 2-4 vendors).
-
A response back to each participant, along with some feedback on why a bid was not chosen (for losing candidates).
-
Execution of formal contracts: Master Service Agreements, Non-Disclosures, Statement of Work, etc.
-
A formal kickoff planning session with the winning vendor.
-
The official kickoff meeting for the project.
Fixed Price Bid for Software Development RFPs
A Bad Idea for Most Projects
In concept, requiring a fixed price proposal bid seems appealing. After all, if you know exactly how much it costs aren’t you minimizing your risk? Actually, we find it’s rare that a customer should ask for a fixed price bid, for these reasons:
-
Design specifications are rarely complete in your RFP document. Therefore, bidders must make many assumptions to create a bid.
-
Most fixed price bids will be padded for risk-contingency.
-
Most fixed price bids require upfront money.
-
In a fixed price RFP, you have one chance to document everything you want designed into your software. Anything left out will have to be managed by a change-order process, which can become frustrating and onerous.
Fixed Price Forfeits the Opportunity for Agile
A fixed price software probably means the outsourced development team will be employing a waterfall development methodology. Therefore, all the powerful benefits of speed and effective design companies get with Agile development will be forfeited. Instead of incremental design and Sprints of completed work, the development team deploys software in large “big bang” phases. In a recent interview with one of our offshore outsourcing partners, a project manager with the company told us, “We don’t like fixed bids with RFPs…If we are asked for recommendations, we suggest the Agile process – we preach Agile – because [our potential client] will get better value for their money. If something is wrong 12 months, 6 months, 2 weeks after implementation, they can change it. We let them accept, adapt, and we’ll be responsive.”
One Exception
In our experience, the only time you should consider requesting a fixed price bid is if the scope of work is small, and FULLY understood (and explained in the RFP document). An example of this would be a minor enhancement or remediation to an existing software application.
Comparing Software Development Proposals
The vendor’s response to an RFP should tell you more than just about the level of effort and fees structure.
-
How well did they respond to your directions? This likely indicates their ability to follow your software design instructions.
-
Can you find similarities to your company and your application need in the vendor’s other project work?
-
What do the references tell you about their work product? Did the company references have a good partner relationship with the vendor – or was it adversarial?
-
Past client work - how similar were these software projects to yours?
-
In getting to know the vendors who respond to the software development RFP, learn about their challenges as well as their successes? Do they demonstrate flexibility and creative problem-solving skills?
About Software Outsourcing Contracts
Contracts create the necessary legal constructs in which you and your software development partner will operate - many Accelerance partners have contracts that are governed by US law. Think of contracts as guard rails along a mountainous highway…they exist as a final measure of protection against disaster, and should only be pulled out as a last resort. In conjunction with your legal counsel, your legal documents will likely consist of:
-
A Master Service Agreement (or MSA), which creates a broad framework for the relationship between you and your outsourcing partner. This agreement is probably where your company will affirm that all source code and other work materials (the “intellectual property”) of the relationship will remain the property of you – the customer.
-
A Non-Disclosure Agreement (NDA), which helps ensure that no company-proprietary information will be shared with any third parties.
-
A Statement of Work (SOW), which restates the work commitments and fee structure which the vendor has committed to.
Contracts are important, but it’s impossible to contract for performance, innovation, and productivity. This is where your software management process is essential. The working relationship is governed by covenant, not contract.
Working Together
The real work begins after the selection is made and the contracts are signed. You’ll want to establish team member roles, finalize your software work plan and establish regular rhythms of project accountability and metrics. You must establish standards for the team for coding standards, development environments, libraries, and change management.
Hopefully, you’re using an Agile methodology that includes daily standups, and sprints. If so, then you can often negotiate a free or money-back-guarantee for “Sprint 0”, which allows you to examine your new development partner’s ability to integrate with your team, communicate effectively, and adhere to mutually approved-timelines.
Beware of silence! If your chosen software development company is chronically late to meetings, absent from meetings, communicating poorly, or just generally not interacting with good questions – these are potential warning signs that your project may be in trouble. Be on top of these warning signs early on, and reset expectations with your partner.