Are RFP’s Undercutting Your Digital Transformation?

Many companies opt to use a request for proposal to kick off communications with potential product or service vendors. Wrapped up in the decision to create an RFP may be a desire to create a level playing field for competitive bids, a need to limit interactions with sales reps, or (too often) an uncertainty of where else to start.

At least and depending on the project, it’s problematic. At worst, a vendor’s Response to RFP can be the first link in a chain of software development failure.

How to Use RFPs Wisely

There is a time and a place for RFPs. When a company is comparing commodity-like products, the RFP process can allow for the quick and successful evaluation of vendors. In software development, an RFP may be appropriate if you are looking to make modifications to an existing off-the-shelf system or in sourcing vendors for projects that involve a well-defined base product and well-defined modifications that can be quickly explained and understood.

But — problems arise when the RFP is used for transformative software projects. Why?

Why a Response to RFP Can Limit Your Product’s Potential

Virtually every RFP written for software development asks the same set of questions:

• What technologies do you know?
• What is your software development life cycle?
• What is your expertise in our industry?

It is important to know that the vendor is going to develop your software in a language that you support and that they have some rigor around their development approach.

But, problems arise when the answers to questions included in the RFP dictate the direction of the solution rather than collaborative and creative problem solving.

Most RFP’s focus on what the solution should look like, which limits the exchange of ideas. Focus on the why you are investing in the software: What is the core problem? Too often companies draw conclusions about an approach or the form the final solution should take, risking leading vendors to create a response to RFP that leads everyone down the wrong path.

RFP’s Aren’t Real-Time, Like Team Interactions Will Be

Vetting vendors based on templated responses can eliminate the opportunity to understand their ability to identify and act on business problems or dynamically provide expertise or guide expectations — traits on which the success of most projects rest.

Agile software projects rest on team members’ ability to understand, communicate and build together. Why postpone interactions with a software team in favor of a response to RFP with limited scope? Start interacting with vendors right away. See if their culture, values and process fit with yours — it could be the difference between success or stagnation down the road.

Why Critical Conversations Beat the RFP

Start instead by discussing your business vision with vendors and hear their ideas on how they would approach the problem. This provides a sense of the vendors’ capabilities, and may provide you with new insights on your concept. After your initial screening meetings with vendors, pick a couple to work with you to whiteboard your ideas and help develop a project approach (depending on the size of your project, they may do this for free). They are likely involved with dozens of projects each year with various technologies and can provide insights on current technologies, areas of risk and ideas from other projects on which they have worked (including from other industries). These sessions will also provide a better idea of what kind of working partners they will make.

Focusing on the business problem will help spur creative thought and approaches from vendors, ultimately driving more business value. This approach may actually reduce the time required, provide a better solution, and spare your team the time wasted on an ineffective RFP.

What to Do When an RFP Is Inevitable

Sometimes an RFP can’t be avoided, especially if leadership buy-in is needed in the early stages of a project. Keep it simple, and use it to screen out vendors that lack the technical expertise in the technologies that you support — rather than allowing it to dictate the solution to the development need.

Keeping it simple can help provide you with some insights on vendors and, most importantly, frees up time for both you and potential partners to have discussions around the business problem. A two-way conversation is far more effective than a one-way edict that’s met with a misguided response to RFP.

Reimagine Project Kickoff

To avoid compromising your project’s scope, be strategic in your use of RFPs. Think how the questions you ask will frame up — and potentially limit — the development partner’s response to RFP and approach.

Leveling the playing field for good ideas does not have to come at the cost of collaborative and creative problem solving. Reimagining project kickoff by embracing rapid ideation sessions to gauge vendor capability provides a more comprehensive pathway to developing a successful digital solution.

Most RFP’s focus on what the solution should look like, which limits the exchange of ideas. Focus on the why you are investing in the software: What is the core problem? Too often companies draw conclusions about an approach or the form the final solution should take, risking leading vendors blindly down the wrong path.