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.
Sign up for CIO Asia eNewsletters.