NJORD Estonia: Risk Management in Industry Digitising

The base for digitising is the procurement of the required hard- and software. Regarding hardware, it is common to have the necessary specifications drawn up and based on these to agree on what must be developed. However, in the case of software, the situation is more complicated.

Several methods of how to develop and implement software are used in software development. The choice of the method is crucial in determining how to lead the project and how the different agreements are concluded during the project on the functional and non-functional requirements of the software. The development often tends to be a creative and lively process in the course of which the original requirements are reconsidered, new requirements are generated, or some requirements are waived. Therefore, it is of utmost importance to document what the customer and the developer are agreeing upon, starting from the source document. Otherwise, it may happen, for instance, that the customer requests a software that is compatible with the customer’s other systems and if the developer is not aware of that, they would not know to offer such a solution. As a result, it may happen that the necessary information does not reach the right destination and due to that, the production fails to meet, for example, the food safety requirements. This may cause material as well as reputational damage.

The need for documentation becomes evident in the process of checking whether the result corresponds to the initial reference, i.e. during testing. All errors cannot be detected by testing, but with a methodical approach, testing helps to detect errors early and thus, prevent potential damage. For instance, when the software is needed for controlling a device, which cuts metal components, a software error may create a situation, where the components are not actually of the required size and the customer cannot use them in the final products. Defective software may also include security risks leading to trade secret leaks.

The agreements on how and to what extent documenting is carried out, how it is delivered and who and how performs the testing, must be clearly stated in the contract. Neglecting all this, a situation may arise, where the customer has no understanding of how the system works, what the requirements are, and lacks the ability to test the system. Without the agreement, the developer does not possess the knowledge and the obligation, what must be done in the development process – whether it is necessary and to what extent it is necessary to document, whether there is a testing obligation and how the correction of errors must be carried out. According to law, the developer is required to supply a system that meets the terms of the contract, but in the absence of a clear contract, it is hard to prove, what the exact obligations of the developer were and what requirements the system was supposed to meet. In the absence of documentation and in case of failure to test the software, the shortcomings may not appear in time and the customer may not be able to file claims against the developer.

Various solutions may be agreed upon in the testing obligation: to clearly oblige the developer to test (and to agree on the amount, time schedule, and methodology) or to order testing from a third party. If the testing obligation lies with the developer, consideration should be given to how to regulate a situation, if the developer does not fulfil the obligation accordingly and that causes the additional expenditure of time and money for the customer. It might happen, that the developer delivers a system with errors, which would have surely been exposed during testing (e.g. mandatory fields cannot be filled in), but the developer has nevertheless delivered such work to the customer. A solution could be a contractual penalty agreement. When ordering the testing from a third party, applying penalties to the developer could be considered, in case the developer fails to solve the problems revealed by the testing after several attempts, and that leads to the need for further developing and testing.