When it comes to technology projects, lawyers have a dual role. Firstly, to help the parties convert the commercial deal into a robust contract. Secondly, to help identify what could go wrong and make sure that the contract has appropriate mechanisms to deal with failures and disputes. This second role is particularly essential because the evidence shows that many technology projects do fail. Projects are delayed, exceed budget, and/or don't deliver technology that meets the customer's needs.
And some tech projects fail in spectacular fashion, as we saw recently with the DAO [Decentralized Autonomous Organization] "hack".
The DAO, a form of leaderless investment vehicle running on the Ethereum blockchain, became one of the biggest crowdfunding projects ever when it managed to raise $168million in May 2016.
However, shortly after its launch the DAO was attacked and $60million was drained. A number of experts have suggested that referring to this incident as a 'hack' is misleading. What the attacker did, they say, was exploit a flaw in the design of the code. They argue that this was a failure in design, rather than a failure in security. Now, it's not unusual these days to push software out in beta form and fix defects along the way. Often that agile, risk-based approach to development is acceptable. But, in the case of the DAO, with the huge sums of money involved, it appears that this was a high-risk strategy.
In any case, the DAO incident acts as a reminder for all organisations; just because a technology is new does not mean that you can relax your standards when it comes to design, testing and implementation.
Where organisations use third parties for technology development, organisations need to consider carefully upfront what could go wrong with design, development and implementation and ensure that the contract adequately anticipates, and protects against, those risks. In addition to ensuring that the contract includes appropriate remedies to deal with failures and disputes, the parties should aim to create a contract which helps avoid those failures and disputes occurring in the first place. Key areas to focus on include requirements, specification and testing and implementation.
Evidence shows that many projects fail because there is a mismatch between the parties' expectations, or because the customer's requirements are too complex or over-ambitious. Customers should take sufficient time to identify their requirements upfront, involving all necessary stakeholders and users. Too often, customers begin the procurement process before locking down their requirements. Or they issue a 'shopping list' type approach which includes both essential and 'nice to have' functionality, rather than concentrating on clear achievable goals.
Once identified, it's crucial that requirements are clearly described. Technical jargon should be avoided as it can make requirements impenetrable, obscuring the customer's actual needs, and confusing both the customer's business stakeholders and advisers, and the supplier.
Sign up for CIO Asia eNewsletters.