Why traditional RFx processes result in a bad deal - rethinking the RFx in a transforming industry

22.04.18 06:01 PM By Matt Koopmans

Request for Information, Request for Quotation, Request for Proposal - all part of a process leading to one thing - getting a commitment on capability and price of a vendor, and an expression of your obligations as dependencies to meet these in the actual delivery. In other words - a commercially binding contract between two parties containing Scope, Price, Time, Dependencies, and Exclusions. A contract that is referred upon especially when the delivery is trailing towards countering the commitments documented - when things go wrong. But does the Proposal - even if it is a binding proposal - have a place in such negotiations? Typically, the proposal is superseded by a Statement of Work (SOW). In a typical contract structure of a software delivery service contains a Header (or Master) Agreement containing all general terms and conditions, a Work Order (or Contract) containing price and time boundaries as well as project specific terms and conditions, and a Statement of Work containing the scope and method of delivery. The original binding proposal is in this construct not a reference document. The onus is on the customer, as the purchasing party, to correlate the various contractual documents to the original proposal. Even if they would have been a part of the contractual construct, what value would such proposal really provide, given it is a response to a set of requirements drawn up prior to the customer fully understanding a) the full potential of the to be implemented software, and b) the value of the existing processes versus new (yet uncovered) business processes in a transforming market. 

 

Intent and Purpose

The RFx process has its intents and purposes on both sides of the contracting partners. Unfortunately, they are not the same in a fundamental way. The table below shows the different perspectives that typically arise in this process. If you are somewhat familiar with the software and delivery procurement process, this is nothing new, and an argument can be made that because both customer and vendor are aware of the discrepancies in intent, the system is in equilibrium. Unfortunately, in most cases, that is false - in the vast majority of cases, the vendor simply has more experience playing this game. This is their bread and butter, where customers only go for a major systems implementation project once or twice in a decade. A second flaw of this notion of "equilibrium" is that it is a naturally good thing. Unfortunately, it is based on a level of distrust (although neither party generally wants to blatantly breach the contract, both parties would expect the other to exploit any unclear elements to their advantage. For an engagement that is potentially transforming the business, trust is absolute paramount for success.

 

Requirements Definition - the Devil is the Detail

The best way to force vendors into submitting a comparable response, is to detail the requirements to as low a level as possible. I have personally picked up RFP's with over 20.000-line item requirements for a financial system. These requirements are categorised by department or process, and non-functional requirements. Whilst it may provide the biggest chance on a comparable response, there are a number of disadvantages to consider:

·  It is time consuming and expensive to compile, rationalise and publish a large set of requirements

·  The detail in the requirements can only be based on what the organisation knows to that level of detail - the current process

·  It is complex and expensive for the vendor to compile a detailed response. Added to that a typical six-week response timeframe, and in the intricacies of the requested detail, mutually exclusive responses may be offered within the same document

·  The vendor has to balance risk and commercial sensibility, and is therefore forced to manage scope, dependencies and exclusions.

Basically, everyone is spending a lot of time compiling and responding to requirements, that does not necessarily lead to comparable proposals, but does reflect a response with capabilities mostly based on the current system. 


The case against the current RFx process

From the above it is apparent that the case for the traditional RFx process is weak. It is expensive, based on the current system or new detailed requirements that are compiled from the "unknown", and to top it off, the process is stacked against the customer due to the experience imbalance in favour of the vendor. When business systems implementations were still a bit of a "dark art", where technical experts would lock themselves into the server room for days just to install and configure the base of the system, so the functional configuration could even begin - when the authoring of any report would take several days (or weeks) of development time, that was the time the RFx process brought some contractual sense back into the systems implementations. Now, the business applications are more and more commoditised - they operate in the cloud, where the provisioning is a few mouse clicks and several minutes away. Reports are created by the user using a drag and drop and natural language interface. 


The Alternative?

We require a new way of thinking about contracting for business applications implementation. Where the RFx process focused on features and cost, we now must shift the focus to capabilities and value in a transforming industry. Instead of focusing on detailed requirements, we should start at the high level:

·  How adaptable is the system to new processes, business paradigms and customer experiences (from a customer’s customer perspective)?

·  What is the cost of that adaption?

·  How often is the User Interface redeveloped? (note: not enough, and the UI dates itself quickly, too much and you keep spending on training)

·  What is the expected time to value, the potential return on investment, and the payback period of each iteration of delivery?

Where the RFx process usually (due to its significant cost) focuses on large capital projects, the new process could focus on small deliveries:

·  Transformation plan for where the business is moving - six monthly update to rolling plan, yearly review

·  Proof of concept for the more complex or untested models and integrations

·  Small workload-based projects delivered in Minimum Viable Product (MVP) and Minimum Valuable Enhancement (MVE) iterations

Proposal comparisons between the vendors can be made on capability and value (including time to value). There will always be a contractual nature between a customer and vendor, but as it is no longer based on the balance of cost, scope, exclusions and dependencies, it has the potential to be one of increased partnership.

 

Originally posted: 20 November 2017

Matt Koopmans