How the success of your project depends on a highly informed Request for Proposal?

Why a well thought out, highly specific Request For Proposal is the only way to ensure accurate quoting and give you the best possible chance of selecting the right provider for your project

In our time around we have done several RFP’s, both creating them and submitting to them. Something that is always amazing to see is the variance into the responses to these RFP from different development houses.

What we have found is that the less defined ones lead to a greater variance in the quoting. This then leads to a selection process based more on chance than on certainty of high-quality results. I’ll use a simple story to illustrate this.

You will want to build a 4 bedroom, two bathroom house, with a double carport and swimming pool. This is what is found is put into a lot of the RFP’s, and it seems like enough information, so you take it to three builders and ask them to quote on it. But in essence, what you are asking the builders to do is be the architect and the builder at the same time. So one builder who likes building in the Mediterranean style will quote for building the house that way. Another builder who has a lot of wood in his stockpile will quote to build the house out of wood. The third will actually inflate his prices to include an architect. This leaves you with three quotes: a middle of the
line quote from the first builder, a cheaper quote from the second builder and a high quote from the third builder… and that isn’t the biggest problem. The biggest problem is that none of these builders know what you really want or need.

The main reasons why you need to flesh out an RFP for web or digital application before sending it out to development houses are as follows:

Varying Quality Standards:

Most people believe that listing “best practice” in their RFP, covers them, but in reality, it doesn’t. The best practice covers the presence of a feature, not how that feature works or behaves. I always imagine the scenario of you telling a used car salesman that you want air-conditioning. They take you to a car without air-conditioning and tell you to roll down the window for the “manual aircon”. So what you find is that by listing “Best Practice” it’s mostly left up to the developer’s interpretation of best practice instead of yours. Furthermore, if your RFP doesn’t clearly outline what your quality standards are, the level of quality will default to what the company

views as acceptable quality standards. This will lead to a situation where one company may lower the level of quality in order to lower their price to win the job.

Choosing the correct technology platform:

In the world of development there are several different platforms that can be used to develop tools and websites. As with all things, these different platforms are not created equal and it can take a long time to learn how to bend one to your will. In some cases, a developer might not choose the best technology platform for specific needs but will choose instead something they know and are comfortable with just so they have an opportunity to quote on the job. This is why within the RFP clear requirements need to be laid out. These requirements should not be used to limit a developer to a single workable platform but rather to remove unsuitable platforms as options. For example

WordPress, while it can be bent and forced to act as a web app, is not a platform that can scale and be flexible enough to evolve to meet the needs of a growing company or the growing demands of an established company.

Understanding the scale of work:

I know of several companies that have internally done an RFP or RFQ which, to their understanding, was a “simple project” and were alarmed to see the wide variance in the quotes back from different development houses. They often ended up choosing one of the cheaper ones, only to find out that a few weeks into the project, that developer was adding costs and time onto the project. Because they were able to point out certain features or requirements that weren’t outlined correctly in the RFP, the developer was well within their rights to do this. One might argue that the developers that quoted higher amount had already seen these gaps in the RFP, because of experience (normally a bigger or older development company) or them taking the time to really think through the process and all the issues they may come across (normally the smaller or younger companies). Either way, by the developer not being given a full understanding of the scale of the work required this almost inevitably leads to additional costs and time which can cause the project cost’s to climb to a point where you are paying 2 if not 3 times the original quoted price.

These are just three reasons of many, why a qualified approach by to creating an RFP or RFQ for the build of a digital or Web application is essential. For a company not well versed in the highly specialized world of technology development, the safest approach to this is by using an experienced third party who fully understands these technicalities and has worked through many projects of their own. If you are considering to take this advice, I would very much like that team to be ours, the Co-Foundry team.

Join the conversation

How do you see the role custom-development plays in business? Give us your views below.