In a perfect world, RFPs would not exist.

The “holy grail” of getting a vendor to do work for you is to avoid the RFP process altogether because the minute you begin putting parameters around the work needed, you risk constraining the velocity of output. But the reality is that RFPs are often necessary, which is not necessarily a bad thing. After all, they force the you, the customer, to document your needs, while giving you a format in which to compare and contrast potential vendor partners.

The challenge is, in a world where legal and regulatory teams prefer the safety and formality of an RFP and purchasing teams/departments desire predictability and the ability to “templatize” the process, the use of the RFP continues to be a common practice.

No problem.

So, you need an RFP. What’s the best approach to get you on the right path to obtaining the product and results you need? Are there even different approaches? Yes, but I’ll get to that in a minute. Let’s start by explaining what’s NOT the best approach: the fixed bid RFP.

 

Why Do Fixed Bid RFPs Suck?

It's simple: They incentivize low quality and incentivize a bait and switch mentality of "bid low and make up the difference on change orders." And yet, they're the most common type of RFP. Why? Two reasons: cost and predictability. Purchasing departments love them. Legal teams prefer them. (Some) customers like them. Unfortunately, so do software design and/or development firms that

  • can’t compete on quality so they have to compete on price, alone
  • haven’t played in the space in which you compete
  • are willing to give up margin (possibly sacrificing quality) to have your logo in their portfolio
  • are using low cost or offshore labor for a vast majority of their work
  • are exhibiting any number of the red flags we previously wrote about here

Basically, the more you drive the price down, the greater the risk of low quality and you not getting ultimately what you and your users need. Building software is an inherently risky proposition. You don’t really know what you’re going to get until you dig in and start building it.

Believe it or not, while this is the most common form of RFP, it's a relatively new approach and a departure from the centuries old concept that values quality, partnership and craftsmanship over the lowest price. Let’s explore this “old” concept...

"Everything Old is New Again."

The vast majority of software projects today are developed using agile methodology, the most common method for software development. At Dialexa, we believe that projects which take agile development one step further and are based in the philosophies of the design-build concept from the beginning, have more successful outcomes.

What’s the design-build concept?

If you’ve ever built a new house, you know what I’m talking about. It’s the philosophy that you have a single source doing the design (i.e. architectural work) and development work (i.e. building), taking an iterative approach to ensure the product (i.e. house) is set up for success of performance (i.e. the house of your dreams), not just achieving it at the lowest cost possible. And, like in design-build construction, the technology partner bears the risk with you. This concept is not new; it's been around for over four centuries.

Ask yourself this: What do the Empire State Building, St. Patrick's Cathedral and Wrigley Field all have in common? These were all risky undertakings performed in risky environments that became great feats of architectural design and building practices and have stood the test of time, but they wouldn’t have been so had they been farmed out to the lowest bidder.

Simply put: When you design-build, you get a better product.

An Alternative: The Agile-Oriented RFP

Google it. Yeah, it doesn’t exist - not formally at least. But savvy customers have been using the premise of the agile-oriented RFP for years. 

It's based in the methods of agile development and more in-tune with the realities of software product development. This fact, alone, should make us all wonder “why are so many proposals fixed bid, which doesn’t support an agile development approach?” The best approach is to write your RFP to better accommodate for the agile development process, the most common (and in most cases, the best) software development process?

The agile-oriented RFP is based on managing the project end-to-end, including

  • discovery - understanding users, process and systems requirements
  • design - translating the requirements into a user interface and visual language
  • development - creating the software

Writing an agile-oriented RFP may seem impossible but if you frame it around the concept of velocity vs. cost, you will come up with creative ways to make it work for you. Velocity is not a foreign concept in the RFP process. It's not uncommon for support to be quoted and billed at a cost per time period (usually a month) or a set of resources per time period. Simplify it this way: Request a velocity-based quote on design and development - the two parts of the project after the discovery phase.

While it’s essential to have an idea of what you ultimately envision the product looking like and functioning, we suggest focusing more on your philosophy and objectives for the project. Try not to make architectural decisions upfront, if you can avoid it. This could limit your project from the best final solution. The more you dictate, the less agile the project is.

For example, if you were building a house that needs three bedrooms and two bathrooms in 3,200 square feet across two stories, you wouldn’t start by picking out the bathtub faucet in the master bedroom. Describe the major objectives - especially the business objectives - and let the iterative agile process hone the right details.

Make sense?

So by now you’re thinking “It sounds great, but without tight parameters, how do I know that the technology partner I choose is not going to just keep the project running and milk me forever?” That’s where finding and choosing the right partner comes into play. We outline a few tips in our post “Five Red Flags to Look for When Hiring a Software Engineering Firm”.

Do your research, ask around, read about prospective partners’ philosophies, talk to their past customers…or just call us (shameless plug).

To be clear, I’m not advocating against fixed bid RFPs because I want my employer to make more money, it’s just the right thing to do to get the best product. After all, the agile-oriented RFP is still well defined. Think of it as a “semi-fixed bid RFP.” There should still be an upfront estimate of a range of time and total cost necessary to complete the project but you don’t rely on this overall cost to make the decision; you rely on the relative velocity costs.

One other point: A fixed bid RFP is different than a fixed price proposal, project or project phase.  A fixed price project by a trusted partner (especially for the discovery or next phase of an agile project) can be a great way to understand the costs and timeline. It just needs to happen as part of a partnership and in an iterative way. You can't figure out the whole fixed price upfront.

Now that you know a little about these two approaches to RFPs, let’s break down the differences between them:

Fixed Bid RFP

Agile-Oriented RFP

Incentivizes technology partner to go by the “letter of the law” (specific to the contract). You sometimes hear - “bid low and make it up on changes.”

Incentivizes technology partner to build, work through the bugs, reveal the work, and iterate based on feedback and opportunities uncovered.

If customer, business or product needs change in the midst of the process, because the bid was so low (and fixed), you risk change orders, churn and dissatisfaction.

Changes in customer, business and product needs, within reason, are part of the deal. That’s the beauty of agile development...and an RFP that allows for the iterative nature of agile.

This format essentially pre-sets the architectural decisions, limiting the technology partner’s creativity.

The semi-fixed bid approach allows for a level of predictability for time and cost, while leaving room for iteration and improvement upon ideas and concepts that naturally come once you dig into software design and development.

Change orders and churn can lead to a potentially adversarial relationship between the customer and technology partner.

Iterative process led by constant communication inherent in the agile process = customer + technology partner keg party at the completion of work.


Technology partner is always trying to ensure the work fits within the bid.


Technology partner is focused on doing their best work to ensure the product is sound, successful and meets or exceeds the customer’s expectations (and aforementioned keg party is one for the record books).

 

You get the gist: Don’t put your project at-risk for failure by boxing yourself in through making the architectural decisions upfront and driving the price down. You’re risking quality and ultimately not getting what you and your users need. Give the agile-oriented RFP a try. It’s a completely doable, smarter approach that’s more in-tune with agile development and the realities of software product development - and it puts you more in control of your product’s success.

To learn more about how we approach problem-solving for our customers, including our software development process, click the image below.

Get Farther Faster with a free copy of our Guide to New Product Development Process for Software

 

Be in the know.

Sign up for updates.

Click to Comment