For many CIOs and sourcing executives, the tried and true “Request for Proposal” (RFP) is no longer serving its purpose as executives wrestle with ways to more nimbly and more accurately communicate complex outsourcing requirements to vendors.
The RPF Strangle
“We often hear complaints that RFPs strangle innovation because they are very prescriptive,” said Young. “They are not dead by any means, they are just not the growth in go-to-market solutions. CIOs know that long and detailed RFPs are not the best way to go when looking for a provider to solve a complex service requirement.”
In its place comes the “Request for Solution (RFS)” approach, more suited for programs that have ambiguity or strive to be transformative. Historically, RFPs fluctuate in terms of their detail and rigidity. Also common is working with top bidders to develop collaborative solutions that characterize the formal service level agreement (SLA).
Although a looser RFP and collaborative working sessions with top bidders may yield more flexibility for the market to propose solutions to ambiguous problems and for transformative change, the RFP’s dogmatic nature still constricts creativity.
But what does the RFS really do?
“An RFS is much less specific, it still has requirements, but they are more general,” added Young.
Essentially, you are asking for more out of providers when you are not prescribing the exact formula for the solution. People behave differently when they are asked instead of told.
“If you are unsure about what you want from the marketplace, often when innovation is involved, do and RFS and let the marketplace offer solutions instead of issuing prescriptive RFPs that close off thought.”
“You have a lot of solutions that come back that don’t all look the same,” said Young. “That is followed with switching the traditional RFP contracting process with “collaborative contracting” where ISG acts as sort of an arbitrator between the service provider and the buyer.”
In terms of bidding the job, the normal formula dictates issuing the RFP to a few approved providers and those few providers spend a lot of time and money to amply respond. The field has to be narrowed because no smart provider would spend a lot of money and resources vying for a contract they had little chance of winning. RFPs change that prototypical condition because providers can respond spending a lot less resources.
“With an RFS you can solicit more providers and even a different diverse set [more longshots that might have alternate-interesting solutions] because for a provider it is much easier to respond to a RFS,” Young explained. “Once you get serious, you have to do the RFP type vetting. The service providers generally like the RFS better, except when it is just an RFS guise that converts into an RFP – they don’t like that. That mostly happens when an RFP would have been adequate in the first place because it is basic optimization.”
That is the only situation in which Young sees the RFP being better suited: “I wouldn’t recommend a strict RFP anymore unless you are optimizing an environment that you are not trying to change.”
That is a pretty intriguing proposition when he also says that many companies have “their whole business model based on crafting and managing complex RFPs.”
“If you are unsure about what you want from the marketplace, often when innovation is involved, do an RFS and let the marketplace offer solutions instead of issuing prescriptive RFPs that close off thought,” advocated Young.
Standardization vs. Customization
In 2012, ISG polled 220 of their Fortune 2,000 clients, a majority of whom said they prefer a standard solution over custom given a cost savings of 40%. Even so, it is hard for a company to change business process, which might be necessary to work with a provider’s standard solution. That keeps RFPs for custom solutions flowing to the marketplace, even though another ISG study of service providers found that their prices are at least 10% higher when responding to complex RFPs.
That again makes the RFS attractive because “the RFP can end up being very customized and expensive while an RFS will expose you to more standardized solutions stitched together to fill the need,” according to Young. “Of course you would get everything custom if it were to cost the same price, but it is much more expensive.”
Also touched on was the human inclination – which can also complicate software development – that exhaustive requirement writing can somehow substitute for real time management.
“There is a tendency when a complex 2,000-page RFP is written with a meticulous SLA that it will run the relationship when it in fact never replaces governance,” concluded Young.