IT procurement and public tendering

Aapo Koski, Lic.Sc. (Tech.), recently defended his PhD thesis entitled ‘On the provision of mission critical information systems based on public tenders’. In this context, mission critical refers to the idea that should an IT system fail, this would significantly impede the company’s business.

Koski’s thesis is very practical and based on his experience of delivering the state emergency centre system. The thesis presents concrete suggestions for improvement in public IT procurement. In my opinion, these suggestions also apply to non-public procurement of IT systems. Below, I discuss a few points from Koski’s thesis (which is a summary of eight separate articles on the subject) specifically from the perspective of an IT lawyer.

Obtaining a large IT system is a long process, and by default, the business environment, tools, users and premises behind the procurement change over time. Therefore, the assumptions set at the beginning of the project may no longer apply as the project progresses. This should be taken into account during the project and in contracts concerning the project. Contracts are almost always written with only one delivery model in mind and do not take into account the fact that one phase of the project may be more feasible to complete using the waterfall model and another phase using the agile method and vice versa. Contracts should prepare for this reality at least by stating that the parties accept the possibility that the delivery method may change during the project, so that the project does not have to be forcefully completed based on an inappropriate contract.

Operational requirements of IT systems often focus on listing functions of the system, but unfortunately often completely fail to define qualitative criteria. However, a good IT system is not just a collection of functions if the user experience of the system is completely ignored. More attention should also be paid to testing. Testing will only provide useful information if it is completed with realistic materials and in the user environment. Although lawyers do not develop system requirements, they should be involved in checking that the requirements are not simply lists of functions, but also focus on non-functional issues such as quality criteria. Contractual incentives should also be provided for the implementation of a good IT system and for quality testing.

Koski emphasises that the transition from an IT supplier to a SaaS provider requires a profound change in thinking and in approach. The same applies at the contractual level. Trying to provide a genuine SaaS service with a contract intended for system delivery is pointless. The change in approach must also be reflected in contracts. An example of this is system error correction. The number of tickets handled by a supplier in a given time cannot be used as a sole measure of error correction, rather the quality of the service provided, and system performance, should be considered as measures of service quality.

The importance of good communication for successful delivery cannot be overlooked. By communication, Koski means genuine communication between the customer (including end users) and the supplier, which must be done in person, not in writing. From this, I have learned that contracts should not always need to require that requests, error notification or other observations are submitted in writing. If communication is always required to be in writing, this makes the process too rigid and does not serve the customer’s goal of getting the best system possible. This is only achievable through genuine, flexible and natural communication between the supplier and the customer.

Whoever acquires the mission critical system must be able to rely on the system and its supplier under all circumstances. However, building trust in public tenders is challenging, as the whole process from the outset is based more on fines and sanctions than on building trust. Contracts have also traditionally been written from the perspective of ‘trust is good, control is better’. A completely unknown supplier may be selected for a public procurement contract. Moreover, the customer’s expectations of the system and the supplier’s perception of the customer’s needs may not align. None of these factors help to build trust between the supplier and the customer. Nor does procurement law. For example, communication between the customer and the supplier is very restricted during the tender process to ensure the process remains fair. On the other hand, only unrestricted communication between the customer and supplier can help build trust. These aspects are beyond the control of the contract, at least as long as procurement law is what it is, however, these are good things to consider for the success of the project.

In public IT procurement, the current trend is to favour agile implementation methods. This should be reflected in the bidding process and the final contract. Agility in IT projects means that the goal may change along the way and this can also affect schedules. Invitations to tender with fixed schedules and very well-defined functionalities are all too common. Strict schedules and precise operational requirements do no facilitate agility. In this regard, lawyers should develop new ways of controlling contracts or accept that an agile project inherently contains more uncertainty than the traditional waterfall model. On the other hand, customers should understand that choosing an agile method requires more from customers than the traditional method. In agile delivery, the customer cannot wait 9 months for the supplier to bring them a complete system. Instead, they must attend meetings every two weeks to determine the direction and functionality of the project.

In general, acquiring a large IT system is difficult and risky. Procurement law does not particularly support good practices in IT system procurement, but careful preparations and investing in both the bidding process and the actual contract can facilitate successful procurement.

Arto Lindfors is a lawyer at Fondia, specialised in IT related matters, and has been involved in the drafting of the IT2018 terms and conditions.