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.
Requirements should be shared with the supplier as early as possible. The supplier should carry out pre-contract analysis and due diligence to ensure that it understands the customer’s requirements. It should also challenge any lack of clarity, over-ambition and/or unnecessary complexity in those requirements, to avoid disputes down the line.
The requirements (amended as necessary) should then be included in the contract to ensure that the supplier is contractually obliged to deliver technology which meets those requirements.
The same good practices detailed above in the context of the requirements document apply equally to the technical specification. Again, ideally, the specification should be developed and agreed upfront and incorporated in the contract. Unfortunately, all too often this doesn’t happen and the specification is developed post-contract during an initial stage of the project. If this approach cannot be avoided, the contract should identify clearly how and when the specification will be developed and agreed between the parties and how it will interact with the rest of the contract.
As changes to the requirements and specification after contract signature are common, the contract should include appropriate change processes. But including those processes doesn’t remove the need for proper preparation upfront. It is in both parties’ interest to limit changes in scope as much as possible; scope changes almost inevitably lead to delays, costs and arguments.
Testing and Implementation
The contract should detail the parties’ obligations in terms of acceptance testing, reporting and implementation. Even if detailed plans are to be developed following contract signature, the contract should, at least, specify the agreed methodology, approach and key milestones.
As delays tend to be the rule, rather than the exception, in IT projects, the parties need to agree realistic timescales. Customers should resist imposing timescales driven by arbitrary factors. Too often a project is assigned an unachievable deadline because, e.g., the CIO told the board that the project would be completed by a certain date, or the project budget documents assumed a certain completion date. Likewise, suppliers would save themselves a lot of pain down the road if they didn’t sign up to a timetable that they don’t believe is achievable simply in order to win the deal. If the supplier’s data and analysis suggests that the dates are not feasible better to have that discussion upfront. When a realistic deadline is identified, the parties should also recognise that, based on experience, delays are likely and build in some room for slippages.
In addition, where the technology the supplier is developing is particularly novel and/or critical, the customer may want to consider requiring a third party specialist to audit / validate the code before putting it into production.
Of course, there are a whole host of other reasons why IT projects do not succeed, many of which relate to failures in communication, project management and governance. When it comes to these topics, rather than carrying out a ‘cut and paste’ job from another contract, the parties should carefully consider what’s appropriate for the specific project. There’s little value including processes and procedures in the contract if they are not going to be workable in practice.