How to kill digital innovation and roi in one easy rfp document
- Posted on March 24, 2017
The following blog post was written by Avanade alum Bjorn Molster.
This blog post originally published on LinkedIn.
Within the digital domain I have witnessed with increasing frequency how large organizations end up as victims of their own RFP processes (and best intentions) - choosing either the wrong partner, the wrong technology, the wrong approach, or sometimes all of these combined.
Let's spend 2 minutes to review some of the key problems when sourcing digital services using an RFP approach:
Problem 1: Assuming you already know precisely what you need:
Most digital development efforts will require some level of learning between start and finish. What turns out to be a good solution in the end, is rarely exactly what you conceived at the beginning (not least after the process of user testing). Many RFPs presume not only to know what will yield the best results - but also what metrics are best suited to assess the quality of the vendor who delivers it.
The issue here is that such RFPs effectively prevent vendors from exposing solutions you had not already considered. It is a bit like asking who has the best car to solve your transport needs - insisting that only answers relating to cars will be considered - all the while not realizing that helicopters exist at comparable price points, or that even bikes could actually meet most of your requirements at a far lower cost. In essence, you are assuming that nobody knows anything you don't - while chances are, of course, somebody does.
Problem 2: Pretending everyone's a robot:
Most RFPs will list a considerable volume of criteria to be measured - and often weighted - typically ending up with an Excel sheet ranking the most suitable alternatives. What this process often discounts is the crucial importance of psychological "fit" between two organizations (yours and that of your prospective vendor) in terms of their people, processes, leadership, culture and overall mindset. Effectively, the process pretends everyone's a robot and that these variables have little or no significance, when in reality they are often crucial - if not paramount. You cannot assign a point value to team chemistry: ultimately, you are buying talent.
Problem 3: You need product development, but you keep buying projects:
As described in problem (1), RFPs lend themselves to scenarios where companies define whatever it is they need and then ask vendors to quote them a price for delivering it. What typically follows is that once the projects are delivered - little or no budget remains to maintain and develop them further. The customers generally take huge risks by spending millions of euros on projects whose value is not proven until the investment budget is spent. In a nutshell - digital success requires continuous innovation - which in turn creates a learning paradox for procurement.
What most companies really need is not digital projects, but digital product development. Instead of just buying a platform and taking big risks - the customer buys a delivery team at a fixed burn rate, creates an MVP quickly and proceeds to continuously iterate and improve the solution. This is, in essence, the best practice approach from almost all leading solutions we see in the market today, from Uber to AirBnB, from MailChimp to Instagram. It gets results faster, at lower prices and with less overall risk. It also has the added benefit of moving focus away from technical specifications to proven business value.
So, having reviewed these key issues - what are some constructive ways to resolve them?
- Before issuing or even creating an RFP, invite leading vendors to a non-scripted conversation around the topics of interest to you. Take the opportunity to learn as much as possible about available solutions, approaches and common pitfalls. Moreover - get a sense of what vendor teams and cultures you feel might be the best match for your company.
- Make sure your RFP is not constructed in a way that prevents vendors from taking whatever approach they feel would be best - even if it might be different from the one you initially have in mind. Allow them to challenge you :)
- Ask yourself if you are just looking for someone to deliver a project or solution, or a partner to help deliver business results. Craft your RFP accordingly. Consider how much risk you are willing to take, and how much of it you want the vendor to share with you.
Last but not least: always keep in mind that unless you are buying a commodity that requires little or no adaptation / integration, a traditional fixed price model is almost always a greater risk to you as a customer than a well-tuned MVP approach.