Recent Posts

Six Ways to Handle Concurrency in the JVM

Is there value in learning Vanilla JavaScript?

How to be efficient in remote design work in multicultural teams

Companies often turn to the Request for Proposal (RFP) process when selecting a software development vendor. I see about three RFPs per month, and the companies that issue them tend to follow a misguided path that goes like this:

First, the company decides it needs to build custom software and wants to outsource the work to a third-party vendor. So they publish an RFP document comprising dozens of pages describing the software that needs to be built in writing.

Next, they contact a handful of vendors to share the RFP document and ask for proposals outlining the time, cost, technologies, and so on to complete the project. Vendors do their best to provide an accurate proposal, but since they struggle to fully comprehend the project's scope and have incentives to underestimate the project to make their proposal more compelling, they —intentionally or not—overlook the project’s complexity. Components of the project are omitted, leading to oversimplified proposals.

This results in companies receiving inaccurate proposals that only capture a portion of what actually needs to be built. A vendor is then selected based on the inaccurate proposal, the project begins, and the software vendor quickly starts issuing change orders or exceeding their estimate as the thousands of details that were missed in the proposal are discovered.

The company isn’t happy, the vendor isn’t happy (since their client isn’t happy), and the project starts to spiral out of control. ‍

There’s a Better Way

Trying to explain the development of a custom software application in writing is like trying to explain the construction of a custom home in writing. It’s possible to create a general summary, but impossible to fully explain the thousands of details that will need to be understood for the project to be a success.

When building a home you first hire an architect to design the home. Then you hire a structural engineer to create construction plans which explain to the general contractor how to build the home. Finally, you send the designs and construction plans to general contractors who provide proposals to build the home. Since they are all bidding on the same set of plans, you can rest assured that the proposals will be apples to apples.

Software should be built in a similar fashion. First, you should engage with a UI / UX designer to create high fidelity mockups (designs) for every view of the application. FullStack’s playbook outlines our step-by-step process for designing and developing software, including examples of each step in the process. ‍

Once the designs are complete, the designer should build a clickable prototype, which replicates the functionality of the finished application, and allows both teams to understand exactly what will be built. Below is an inside look at how our design team builds app prototypes.

‍

After the designs and prototype are complete, a software architect should be engaged to create a plan for developing the app. At FullStack, we call this “technical discovery.” The architect should determine the best technologies to use, plan data migrations, investigate third-party integrations, determine the number and types of developers required for the project, and so on. For any particularly complex features, the architect should code a simple version of the feature to ensure that it can be built to a satisfactory level of performance.

The final step is to create the Request For Proposal document. The RFP should ask vendors to provide an estimate based on the designs, prototype, and technical discovery document that you provide them.

More general information such as a company description, business goals of the project, background on existing technology, database requirements, vendor selection criteria, schedules, key contacts, etc. can also be included.

I also recommend including an estimate template for the vendors to complete. You can view and download a copy of FullStack’s estimate template here. The estimate should breakdown each feature, view, workflow, etc. of the app into as much detail as possible, and create a corresponding line item in the estimate.

Vendors should estimate each line item based on the best case and worst case scenario so that you have an idea of how much each line item will take to build. An average should be taken of the best and worst case scenarios for each item, and that should be the target time requirement for developers to hit.

Vendors should also include time for project management, quality assurance, design reviews, user testing, meetings, and communication.

By having all vendors estimate the project using the same approach based on the same information, you’ll receive apples-for-apples proposals that you can confidently compare to one another. And since you took the time to properly design and architect the project, you can breathe easy knowing that once development starts, the project will be completed on time and on budget.

A Side-by-Side Comparison

Here is an example of a typical software development RFP. It’s a 12-page description of everything the company hopes to achieve from their software development project. There’s nothing wrong with this RFP per se, and much of the information they include is useful. It’s just incomplete.

RFP Document ‍

And here’s an example of a clickable prototype, which demonstrates the look, feel, and functionality of the software, and allows the user to actually click through the prototype to understand exactly how the software will function once built.

View a Clickable Prototype for a Desktop App‍

The prototype will allow software vendors to fully understand what needs to be built and provide accurate proposals that can be properly compared to one another.

Written by

David Jackson

As the CEO of FullStack Labs, my primary responsibility is for the management of the company. I manage and directly contribute to many different departments within the company, including recruiting and hiring, marketing and sales, bookkeeping and accounting, tax and legal, and general operations. I take a hands on approach to management, meaning I prefer to roll up my sleeves and work directly on projects, instead of managing through meetings, policy, and bureaucracy. Prior to FullStack Labs, I was Vice President of Sales and Partner at CAE, where we built an industry-leading marketplace for buying and selling used capital equipment. I graduated Summa Cum Laude from the California State University Sacramento with a degree in Business Administration.