January 16, 2018 11:58

Shortlist, perform, win!

The Open Development Challenge approach could revolutionise how technology services are bought

I was recently talking to a senior software engineer at a Houston-based start-up. His company had just bid on a contract to develop a blockchain-based system for a major European consortium of energy companies to settle legal disputes.

Blockchain systems are the hottest solutions in technology today. The most popular example is Bitcoin, the cryptocurrency, which, because of its disruptive nature, has dramatically altered hundred years of rules governing international foreign exchange.

Blockchain advantages

There are several advantages to blockchain systems. They are open source, which means that no single company owns the operating system or product (like a Windows 10, Oracle or SAP ERP implementation), so expensive software licenses as a cost are no longer relevant.

They are secure because each transaction is recorded instantly on numerous computers around a distributed network, all on the internet. Unless every computer in the network can confirm that a transaction has occurred, it cannot be validated.

Suppose a bank is working with a consortium of banks to offer a loan to a company and there are over 60 pages of documents. If any one party were to try and change the terms of the loan on a discreet page to its advantage, that change would appear only on that party’s system, but not be replicated on all other the computers within the network.

Such a change would, therefore, be rejected by the distributed ledger and never succeed in a court of law, in case there is a dispute. View this clip by Wired magazine which describes how digital data is secure in blockchain systems, without risk of rogue or innocent data corruption.

Security and trust

Blockchain systems are peer-to-peer, meaning a single computer does not have veto power over any other computer on the network. This is why government agencies such as the RBI and the Federal Reserve Bank hate Bitcoin — they are not in control of a financial transaction.

Blockchain solutions also require a lot of advanced computing techniques, including a thorough understanding of encryption. In a world constantly threatened by cyber attacks, blockchain systems could well provide the blanket of security which companies so covet.

A new disruption: ODC

The Houston start-up had just learned that it had won the bid and my friend was excited. But there’s a twist. The start-up had not yet won the entire bid in the traditional sense. It had simply won the initial bid to enter into an Open Development Challenge (ODC) — a new term which refers to how companies buy technology services these days.

How it works

Like blockchain, the ODC sourcing approach is extremely disruptive. The buying consortium floats a ‘Request for Proposal’ (RFP), the common industry term used for seeking interested vendors to bid on a project.

But rather than give out the entire award to the vendor that submits the most attractive RFP response, the consortium invites those initially screened as promising vendors to a development contest or a ‘hackathon’. All of the expenses of the vendor teams to travel to the consortium site are paid, and the labour hours for the hackathon are reimbursed as well.

At the consortium location, a business leader from the client organisation describes a use case — or a case study, a pilot or prototype — of the proposed project to all assembled vendors. The general requirements and constraints — such as the technology to be used, the hardware, the network, the security needs — are clearly identified. And the hackathon is kicked off, much like the International Olympics Committee Chairman declaring, “ Let the Games begin !”

Coding, coding and coding

The various vendors then retire to their hotel or conference rooms and begin developing the code for the use case. The teams fret and fume and burn the midnight oil over boxes of pizza and soft drinks.

This is no different from how MBA students prepare for a case competition. The goal is to turn in actual code and associated documentation to the consortium before the deadline, which is generally two weeks out.

Once the prototype is ready, the consortium usually requests a private readout of the product and may pepper the developer teams with various questions about the benefits of the design, the construction of the code, the testing, the validation, and the vulnerabilities.

Making an informed pick

Thus, under the ODC approach, the buying consortium is able to accurately estimate each vendor’s technical abilities under controlled conditions. The consortium is then better able to relate to the key players on each vendor team and assess soft skills, such as the ability to communicate and present, that are so crucial to a project’s success.

Much like Olympic judges assessing a gymnastic competition, the buying consortium then rates each vendor’s work across various predetermined factors. The judging is, obviously, not in public and the ODC performance alone is never the only criterion applied.

Other typical factors in evaluating a vendor — such as the buyer’s prior experiences, the vendor’s reputation and financial strength — are also taken into account. But the ODC performance is the most important factor because it is the best predictor of success when the actual project starts.

The disruptive approach

Today, complex technology projects are often abandoned midstream because the players involved did not fully understand the risk of a vendor’s proposed solution, on paper. Some large scale government projects are delayed much beyond the initial planned release date. If projects are forced into deadlines, they will often be buggy — such as the recent GST launch in India, or the Obamacare roll-out a few years ago in the US.

The ODC approach is extremely disruptive in the traditional technology buying world because it requires the vendor to demonstrate a working prototype under the watchful eye of the client. It stretches the vendors’ abilities to their outer limits and shows which technical areas they are weak in.

If a vendor fails to deliver the product in time or does so with lots of errors, the vendor knows it is probably not yet ready to assume the risk of such a major development initiative. The client too heaves a sigh of relief because it did not award a contract to someone based purely on sweet words in an RFP response.

Expect the ODC approach to become increasingly popular in the coming years — a welcome move to separate the wheat from the chaff.