The Request for Proposal (RFP) represents the bedrock for procurement activities to outsource business processes, operations and development. We’re all familiar with the concept:
- The services to be sourced are identified and neatly ringfenced
- All the information sources containing records of the services tasks, SLAs, KPIs and actors are compiled into a precise, concise description (without upsetting the current team delivering the service)
- The various bidders have all the insight they need to bid accurately on the service and add a flavour of their own talent
- The document carries through with well-defined, but not overblown, SLAs to the contract.
- The service provider delivers outstanding service, the customer is happy with the lift and shift.
Back in the real world of business, RFPs can struggle with anything except the simplest services. Where the customer finds the information difficult to assemble, RFPs are vague and obtain non-committal bids more representative of sales literature. When they have the information at hand, the RFP can turn into a monolithic prescription of every detail, together with a list of SLAs that gives the provider the feel they are a cow about to be milked for every penalty imaginable. The contract becomes a catch-all, defeating the ‘trusted partner’ aim before the tender is even released.
This is where the Request for Solution (RFS) comes into its own. Whereas the RFP too often attempts to cover every detail of the ‘how’, the RFS gives a looser description of the requirements of the service, without being prescriptive on the expectations of execution. There is plenty of room for must-have requirements, design and security mandates and the like, but the focus is on the capability, not HOW it is delivered. This leaves the providers room to demonstrate their talents and address the business problem presented. This is especially useful when the CIO and their team are dealing with fluid and transformative environments. It encourages a collaborative approach to the partnership where the common tie between the organisations is the aim to deliver a service, not a set of instructions.
This doesn’t mean the RFP is finished; not least as the RFP capability is one that most IT procurement teams understand well and feel confident delivering. But for sourcing proposals that are complex, innovative and transformative, it might be worth investigating the use of a Request for Solution process, rather than wrapping your providers in instructions and SLAs defined to cover your uncertainty.