We want every potential customer to see us cooking in their kitchen before ordering the pudding. We understand that by sharing some of our pudding, our customers would know what we have to offer and can compare it with alternatives on the market.
Outdated, expensive, time-consuming
We are excited to see the evolution of the waterfall-style RFP as a general market practice because we have felt our customers’ pain when we have heard words like “outdated”, “expensive” and “time-consuming” to describe it. And those were exactly the words CSP executives from more than 35 of the biggest telecoms organizations around the world used to describe the RFP process, still a standard in most (if not all) companies, according to a recent study conducted by the telecom industry association TM Forum.
The current RFP process has been in place since the 1980s, back in the day when companies could afford to spend as much time as needed in order to get what they wanted. Lengthy, written documents comprised of thousands of questions were sent through mail (physical snail-mail,that is) to prospective vendors that answered those questionnaires and mailed them back, just to be manually reviewed by someone back in the interested company trying to figure out what the best possible option for their needs was. Needless to say, the process wasn’t perfect, as they had to adjust the end results constantly until they got what they wanted in the first place, spending much more than what they had expected originally. The email era didn’t change the mechanics that much either. At least it got rid of all that paper…
Enter agile methodologies
According to TM Forum’s paper, Time to Kill the RFP? Reinventing IT Procurement for the 2020s, the fundamental flaw of the RFP process is that the advent of the cloud and software development has accelerated the pace of technology, making it difficult for CSPs to describe their needs properly with a traditional waterfall approach before they are obsolete, especially in an era of NFVs and SDNs. At the same time, cloud computing has evolved from a capex model, where licenses are being acquired, to an opex software-as-a-service model, where licenses –as well as platforms, infrastructure or applications– are paid on a monthly subscription basis. Oh, and now we also have agile methodologies.
Agile methodologies, as described in the TM Forum publication, have been adopted by many businesses mainly for software development. Their greatest benefit, among many others, is that requirements are able to be modified constantly throughout the process as the project evolves; there’s a constant delivery of working software, cooperation, direct conversation between service providers and customers, and, the most important thing: satisfaction. In fact, big companies like Telenor Sweden, and DNA, our customer in Finland, have completely moved or are headed to agile methodologies. Nevertheless, many big companies still believe that agile methodologies cannot be applied on a big scale.
A request for partner
TM Forum proposes a new kind of RFP in response to this. Instead of a request for proposal, they suggest a ‘request for partner’. This process would be comprised of five different steps, starting with technology scouting, where CSPs must research promising technologies and companies they are not aware of (“particularly medium-sized companies”, they say), in order to have a broader idea of the different approaches they can achieve their objectives through.
Then it’s time to issue an ‘ambition statement’. Unlike the request for proposal deliverable file, this document is short (fewer than five pages), it should be written by the technology team, and it should state the outcome and use-case perspective they are looking for. It would be followed by an invitation for previously scouted potential suppliers –between three and five– to engage in a proof of concept (POC).
The POC should deliver results that allow the CSP to determine the supplier they want to work with, so the fourth step would be to solicit competitive bids. They know who they want to work with, and they know what outcome to expect from them, so this bid should satisfy corporate guidelines for an easy stage 5, and that is the awarding of the contract.
At ECT we are aware that, as technologies have changed the way we live, methodologies also need to adapt to the faster, more creative ways of our current industry. As we have already said, we embraced this concept some time ago when we started to move our company towards agile methodologies. Since then, we have been working to quickly adapt to the needs and inputs of our customers, both internal and external. We are making investments and paying for POCs before any contractual obligation falls on our clients. This is convenient for us, because it enables shorter sales cycles, and, at the same time, it is convenient for our customers because it means more successful projects for them. We can now execute as fast as required by the changing needs of an industry looking to the future. And we are certainly working hard to make sure that future is a bright one.
So, in the meantime, who wants more pudding?