Many IT systems acquired through public procurement procedures can be out of date already at the time of introduction. According to the doctoral dissertation of Aapo Koski, Licentiate of Science (Technology), this is due to both the requirements of the Act on Public Procurement and Concession Contracts and the working methods traditional in the IT sector. Koski identifies three main problems inherent in public information system procurement: insufficient communications between the client and businesses, the long duration of procurements, and the working methods prevalent in software companies.
“We place too much trust in procurement notices being understandable and comprehensive. It’s likely that prospective providers get some things wrong, especially if the software company is unfamiliar with the client’s sector,” Koski says.
Completion takes as much as a decade
Koski has himself worked as a software developer and architect for years, contributing to the public procurement of a number of information systems associated with public safety and defence, among other sectors, where technology must function smoothly. In his dissertation, Koski, in fact, focuses on such systems, known as mission-critical systems.
A good example of a mission-critical system is ERICA, the IT system used by Finnish emergency response centres. Koski served as the system’s chief architect from 2010 to 2015. ERICA puts through emergency calls throughout Finland, displays the caller’s location on a map and proposes measures to be taken by the emergency response centre operator on the basis of the details they have entered into the system.
“The first early preparations for ERICA were made with the Emergency Response Centre Agency, the police, emergency care providers and rescue departments in 2008. The development of the system began in 2011, and it was deployed in 2018. It’s obvious that technology, the system environment and, partly, demand change over a period of ten years,” Koski says.
Koski believes that procurement legislation should not allow the tendering of IT systems of this scope as one entity when the end result may be achieved several years later.
“The legislation should force the procurement of systems in components, which would have a delivery time of, say, six months or a year. After completion, each component should be rigorously tested, and their development should only be continued after collecting user feedback. This would enable both the client and the software company to better react to changes in the environment as well,” Koski says.
“The custom of switching the old system off at one go and developing something new from scratch remains prevalent in the IT sector. We should come to accept that no system will ever be finished. They have to be built for continuous improvement.”
Transitioning from a project model to a service model
According to Koski, the third problem with public information system projects originates in the project-based thinking prevalent in the IT sector. Traditionally, software companies take a commissioned project to its completion, with both the client and company only monitoring the fulfilment of the original agreement. Koski believes that it would be better for software companies to manage projects as services in accordance with what is known as the SaaS (Software-as-a-Service) model. Under this model, the company would also be responsible for the maintenance and help desk of the system.
“This way, software developers could be brought closer to actual users who could provide them with feedback. This would also make reactions to change needs faster.”
The service model functions best when employed right from the start, but it can also be employed at a later stage. For example, the Emergency Response Centre Agency’s ERICA system is now operating according to this service model.
“Now, the party maintaining the system is able to quickly react to malfunctions and directly see how users are utilising the system. Ideally, faults can be fixed before users even become aware of them,” Koski notes.