We are experiencing a fundamental shift in the way technology is provisioned in the broadcast and media sector, yet the procurement processes have remained largely unchanged in 20-years. Moreover, there is increasing frustration in the vendor community that process isn’t as rigorous as it should be. Is it time to review the approach to RFP?
One of our programme management consultants, who has an adage or anecdote for almost every aspect of our business, is often heard saying “if an RFP lands on your desk, you know it’s not for you.” This is usually followed by a collective sigh in our office, but the point is as sharp as the messenger: many technology Request for Proposals (RfPs) are not necessarily the new business opportunity that they appear to be.
Within our software business we have developed a stringent set of criteria which we use to assess all RfIs (Requests for Information), RfPs (Requests for Proposal) and PoCs (Proof of Concepts) and decide whether to respond or decline the invitation to participate. The range of criteria is broad but ultimately equates to our likelihood of winning the project, balanced against the cost and risk (opportunity cost) of bidding.
I imagine that this is a standard approach among vendors but, on discussing the issue with colleagues and competitors during IBC, I noted a marked increase in cynicism. Vendors are increasingly treating PoCs and RfP with suspicion. Views range from “We are being invited to tender just so the customer can beat down the price of [alternative vendor x]” to “Customer y is seeking some free workflow design” or the prosaic “They need three bids for internal audit, but you never know.” The underlying sentiment across the board is that procurement processes increasingly lack the rigor and integrity they once had, and I consider this detrimental to both vendors and customers alike.
While the software division of our business responds to these tender requests, a proportion of the Blue Lucy business remains pure consultancy; where we provide advice and expertise on projects or programmes without supplying software. For consultancy projects, we typically manage or support the technology procurement process – including dealing with RfIs, RfPs and PoCs from other vendors. So, as both poachers and gamekeepers (bad analogy) we thought we could share broad lessons to tender success from our experience over the years:
Ensure that you set the vendor engagement approach in the context of the project’s relative maturity. Before rushing to formally commission a weighty RfP, examine the maturity of the project or programme. Where are you in the process? If the business case and a target operating model aren’t clearly defined, then you probably aren’t ready to formally engage in a tendering process with an RfP or PoC request.
Of course, it may not be possible to prepare the business case or define the operating model without vendor engagement – i.e. looking at what is ‘out there’ in terms of capability. If this is the case, your request should be limited to an RfI.
The outcome of the RfI will often inform the high level operating model and business case and will probably identify the likely vendors for the later RfP or PoC.
The formal RfP – the phase in the procurement when you require vendors to provide a costed solution to your business requirements and target operating model – should also be kept lightweight. The quality of the RfP should not be based on its printed weight and more may be gained from a spreadsheet of prioritised requirements and an operational workflow diagram than a verbose and overly prescriptive tome.
More on the PoC phase is set out in (5) below but we normally recommend limiting the PoC phase to the preferred vendor from the RfI stage. Be clear what the objectives of the PoC are – a key integration or proving a minimum viable end-to-end workflow. Both sides should be clear what success looks like.
The rigorous governance you apply to a programme or project should include the vendor engagement component, particularly in the RfP and PoC phases. Be fair and be seen to be fair.
There was a time when a conversation between a business customer and supplier was implicitly, mutually confidential, but increasingly business operators and vendors alike have sought to formalise this in NDAs. Non-disclosure agreements are designed to protect against the promulgation of non-public information about product capabilities or techniques as well as other confidential business matters. But they are routinely flouted.
In my opinion, the proliferation of the NDA has had the reverse effect on the disclosure of confidential information. Operators are naturally trying to ensure that they define and build the best systems possible, but doing this by sharing product information with a vendor of another product isn’t good form and is very likely to be in breach of the NDA. The technology innovation of tomorrow relies on respecting intellectual property today.
Change occurs in all projects and things change rapidly in this industry. The change management process set in the project governance should extend to the vendor engagement.
Project changes that may impact on the RfP process include a change in the objectives of the business or identifying a new potential vendor.
A change in business goals or objectives which alter the assessment criteria under which vendors are to be measured should be communicated to all tenderers. Modern software systems are inherently flexible, and it is likely that a response to an RfP has been crafted to focus the capabilities with the highest priority criteria. If the criteria change then allow the vendors to update their submissions.
If new vendors are identified during any part of the procurement process, ensure that they are taken through the same procedure and that all involved are kept informed if requirements evolve.
It is the PoC more than any other aspect of the procurement process that seems to cause the most heat in the vendor community. I suspect that this is because responding to an RfP may be viewed as a “sunk cost” in staff headcount, whereas a PoC will incur additional expense – such as infrastructure or writing software to a proprietary system which isn’t reusable.
Tom Gittins, CEO of Pebble Beach Systems wrote a very good piece for the IBC Daily back in September. Tom’s article is typically forthright, but balanced and constructive. In the spoken, rather than written, medium other suppliers are more vociferous. “We provided a 4-week PoC which cost us more than [large number] thousand pounds…..and [end user customer] decided to cancel the procurement process and build the system themselves, probably based on our architecture;” and “The workflow defined in the RfP was exactly what we had provided as part of the PoC and they award the contract to [another vendor], [expletive deleted.]”
As a software vendor, Blue Lucy has provided both paid and unpaid PoC systems in recent years and we too have felt that pain. But, as consultants we are clear: PoC or low-level design work should be paid for. If the fees involved merely cover a supplier’s costs the goodwill, focus and resulting quality of the outcome is immeasurably increased. To the customer there are some up-front costs, some of which will be apparently written-off, but this is more than outweighed by quality of the outcome and is ALWAYS less expensive than using an internal design team and clean whiteboard.
We have run two large projects as such in the last 18-months, both of which have achieved consensus and precision in the outcomes. None of the vendors, including those whose software does not form part of the ultimate solution, feel cheated or hard done by.
Always define and design the PoC in concert with suppliers and be clear about the aims.
There are generally no second prizes in a competitive tender process and outcomes are binary. In deference to the tenderers and the effort required to respond to even a simple RfP, it is important to provide constructive feedback. Ideally this should be a formal debriefing highlighting the strengths and weaknesses of the received proposal. This process can be painful for vendors and it shouldn’t be viewed as a further negotiating opportunity – it is invaluable in terms of lessons learned for the bid team and useful insight for the product management team.
Selecting a vendor or blend of vendors is only the start of the journey: you will have to work collaboratively through the delivery and transition to service phases, and for the lifetime of the systems you are building. This may be ten years or more. Establishing the partnership on the right footing is key to delivering projects successfully – and it starts at the very beginning.
The above guidelines have been forged through experience over the last 20 years and following them should help ensure the engagement is productive and fair. But shifting approaches to the implementation of technology may change the entire procurement process in the not-so-distant future.
How will the, welcome, trend toward cloud and SaaS operations impact the ‘traditional’ RfP and PoC process? We may be on the cusp of a functional shift. Comparatively, even the largest broadcast vendors are mere minnows in the rapidly expanding media services business if compared to Amazon, Google and Microsoft.
Once the scourge of the of the industry, these businesses are held up as role models, which the smallest supplier and the largest broadcasters aspire to emulate. But these businesses are not burning cycles and resources on RfP’s and PoC’s. If you want to use the cloud, you spin up the services you require and pay for the resources you consume, whether that be for a PoC or a fully featured deployment.
The world is changing, and the broadcast industry will need to adapt accordingly to retain the breadth of solution vendors and maintain innovation.