Home » Readers Write » Currently Reading:

Readers Write: Replace Your RFP with an RFS

June 20, 2014 Readers Write 2 Comments

Replace Your RFP with an RFS
By Patty Miller

image

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.

View/Print Text Only View/Print Text Only


HIStalk Featured Sponsors

     

2 Responses to “Readers Write: Replace Your RFP with an RFS”

  1. 1
    flpoggio Says:

    Interesting ideas, particularly your example of Analytic tools and problem definition.
    “the solution architects are engaged as a group or one-on-one to hear what the problem and current state is.” But that assumes the client has already defined the problem, when many uses of analytic software is to identify problems before they become critical.

    Secondly, the buyer always has at least some skin in the game (your fee) , the vendor usually does not. A vendor should go ‘at risk’, no ROI= no payment. That’s what I call ‘blood’ in the game.

  2. 2
    Borrilld Says:

    Hi Patty,
    Well done and very creative! I’d like to suggest that during discussions about deliverables, timeframes, penalties (if any) and resource requirements that project management be represented at the table. Many times what is envisioned during the pre-implementation process does not reflect reality; project management involvement should minimize this risk, which, in my opinion, is a risk for both parties.
    Also, in the post implementation phase you suggest ‘regular monitoring’ to ensure the expected metrics are being met and maintained. This is a great idea and I would suggest that the vendor be involved in scheduled, on-site workflow reviews to ensure the new “current state ” processes are actually being followed. If I am the vendor and I have ‘skin in the game’ as you suggest I’d want to evaluate any reported deviations first hand. Any costs associated with these visits could be included in the overall cost of implementation.

Leave a Reply

Founding Sponsors


 

Subscribe to Updates

   

Search


Loading

Tweets

Report News and Rumors

No title

Anonymous online form
E-mail
Rumor line: 801.HIT.NEWS

Archives

Sponsor Quick Links

7ads6x98y

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Follow

Reader Comments

  • Perspective: Um, not to be a Negative Nancy, but if I were an Epic consultant, the first thing I'd do would be to fill out that surve...
  • Just a Nurse Analyst: Multiple times THR has stated they modified the clinical system as corrective action for this disastrous event. If they...
  • Amalgam: Re: Epic consultant salary survey - looking forward to the results and thanks for taking the initiative to look under th...
  • PM_from_Haities: I really don't agree. THR handled this as well as anyone could have. First, this man came in with something that w...
  • Jenny Dimento. MBA: DeSalvo feels the heat in the kitchen. She is smiling like a butcher's dog now that she can do some good for society, as...

Text Ads