Readers Write: Replace Your RFP with an RFS

Replace Your RFP with an RFS
By Patty Miller

I have been on both sides of an RFP, as a member of the organization issuing the RFP and the organization receiving the RFP. In one case, when on the issuing side, we did not select a vendor, as no traditional vendor solved our problem. We went back to the drawing board, so to speak.

From the receiving side, I have seen organizations spend hundreds of thousands of dollars to millions of dollars on software or services, only to realize none or a small portion of their anticipated ROI because they implemented only part of the services or software or never completed the implementation.

What happened? Everything was spelled out in the RFP. All the vendors followed the steps and they had their evaluation process down.

The RFP is a wonderful tool to reduce price and squeeze an existing vendor for savings or to use when the solution is known. But what happens when there is a real problem to solve or when venturing into new territory?

That is where the RFS, or Request for Solution, comes into play. Entrepreneurs, innovators, and vendors are some of the most effective problem solvers we have in society today. How do we harness them? Bring these solution architects into our fold and share the insights we have into the problem we are trying to solve or the direction we would like to take. Then, we can create a solution that is used, solves challenges, and realizes the desired ROI.

Let’s use an example scenario. Our organization is looking to purchase analytics software. What is the desired outcome? Is this in line with our strategic goals? For this example, we would like to better understand how we are paid and ultimately be paid 10 percent faster.

Problem Definition Phase

In this phase, the solution architects are engaged as a group or one-on-one to hear what the problem and current state is. An NDA may be a good idea during the problem definition phase. To convey the problem and current state, a presentation, observation, or a demonstration can be used. That’s it. Share the problem, nothing else.

In our case of looking to purchase analytics software, we find our DSO to be 89 days on average. Delays in cash collection inhibit our ability to reinvest in the company, thus delaying sales.

Ideal Future State Definition Phase

Describe and share with the solutions architects what some of the desired outcome looks like when the problem is solved, such as, we will reduce defects or have zero defects. We can deliver 10 percent more of our product to the customer for the same price. We have reduced overtime by 10 percent.

Make part of the selection criteria about these outcomes and other outcomes they can deliver and convey this information to the solution architects so that they will provide all the value they can. The ideal future state should align with organizational strategic goals as well.

In our scenario of looking for analytics software, we would like to bring DSO down from 89 days to 80 days and increase sales by 5 percent. Due to the high importance of cash in running a business, it is in our best interest to collect outstanding receivables as quickly as possible. By quickly turning sales into cash, we can put the cash to use again — ideally, to reinvest and make more sales.

Solution Definition Phase

During this phase, work collaboratively with each solution architect to refine the initial solution they provide. If this is a large project, this phase can take months. The payoff is implementing a solution or service that is used, solves challenges, and realizes the desired ROI.

In this phase, the solution architects are designing and proving — through POCs, demonstration, references, or site visits — how their analytics software will help us reach our desired outcomes along with other benefits they can provide. We decided the goals of this implementation. They will be to reduce DSO and more accurately forecast sales because the solution architects demonstrated in their solution that we would be able to forecast sales more accurately.  They also demonstrated how that would lead to turning sales into cash.

Contracting Phase

Contracting should include deliverables and a timetable based on the collaboratively designed solution.

For our analytics software scenario, in contracting we ask for a guaranteed outcome, perhaps not as aggressive as our original goals. In some instances, it might be more aggressive, depending on what the solution architects have demonstrated they can deliver and if our goals have changed in any way. Contracting can be difficult because everyone is trying to minimize risk during contracting, but ultimately everyone should have a little skin in the game, both solution architect and buyer. Include a change policy during contracting.

In our scenario of analytics software, we agreed that DSO would decrease by nine days in one year.

Implementation Phase

During this phase, the solution should be referenced frequently. If there are changes, they should be documented per the change policy agreed to in the contracting phase, especially if the anticipated outcomes change. Needs change during an implementation and, if additional value can be achieved, it may make sense to proceed in a slightly altered direction.

In our analytics software scenario, during implementation, some lean processes were put in place and DSO decreased by two days. We are now looking for the software to give us another eight days instead of the initial nine, although we think the benefits will be greater.

Solution Monitoring Phase

For a period of 3-12 months or more after the solution has been implemented, there should be frequent monitoring to ensure that the solution or service is utilized, has solved the challenge, and realized the desired ROI. If not, the solution architects or issuing organization should be accountable as per the contract.

If someone is truly interested in solving a problem, that person will have skin in the game. RFS issuing or receiving can be a scary process for an organization that is accustomed to the traditional RFP. The organizations interested in change will embrace the RFS; others may be resistant.

No organization can afford to spend its resources, time, people, and capital on a project that does not produce the desired outcome. I expect many vendors, entrepreneurs, and purchasers will welcome this collaborative solution design, but some will be resistant due to the insecurities associated with change.

Harnessing the power of the Request for Solution allows for bringing solution architects into your fold and implementing a solution that is used, solves challenges, and realizes a desired ROI.

Patty Miller is sales manager, health and sciences division,  for TechDemocracy of Edison, NJ.