Three reasons why public authorities have to take ownership in software development

An agile footing can go a long way to succeeding

  • The problem: Public procurement often fails to deliver viable IT solutions for administrations.
  • Why it matters: In most cases, the development of digital administrative products does not allow them to address the specific requirements of individual authorities.
  • The solution: Public authorities need to adapt to agile processes and take ownership in software development.
“Digital administrative products are mostly custom-made with regard to the specific requirements of individual authorities – either by extensively adapting an existing market solution or by commissioning a new development.”

Simple, fast and secure – this is what most IT suppliers promise when offering their public sector IT solutions to administrations. However, the reality of IT projects in public administration is often quite different: too expensive, too lengthy, too complicated. Although administrations often invest billions annually in the purchase and development of IT infrastructure and software, the results often remain poor and have a bad reputation. But why is it so?

Let’s take a step back and look at the procurement process. Administrations generally consider software as a product that can be procured on the market. Accordingly, public authorities proceed in a similar way as they do when procuring conventional products: the desired service is described as comprehensively as possible in a public call for tenders, the most economical bidder is awarded the contract and delivers a result sometime later. The administration itself confines itself to awarding and contract management but stays out of product development as far as possible.

There may be situations where such an approach could make sense, e.g. when procuring commercially available office programs or using software-as-a-service (SaaS) offerings, but let’s face it: in most cases, there is no perfect solution for all use cases waiting on a shelf. In other words, digital administrative products are mostly custom-made with regard to the specific requirements of individual authorities – either by extensively adapting an existing market solution or by commissioning a new development.

Why agility is key

This leads us to the question as to why administrations must familiarise themselves with the principles of agile software development that have long been common elsewhere, take more responsibility for their digital products, and play a much more active role throughout the development process.

First, it is a principle of agile software development that digital products cannot be described comprehensively in advance and then only need to be developed. Instead, software is created in closely timed, iterative cycles in which an initially rudimentary prototype is tested, adapted and refined step by step and in close consultation with customers and users.

The principle of public product procurement leaves little room for such an exploratory approach to the best solution. It regularly happens that public authorities meticulously describe a desired product in advance (and invest a great deal of time and effort in doing so), but that the intended path in development then proves to be impracticable after only a short time. The fact that unforeseen circumstances arise during the extremely dynamic process of digital product development can hardly be avoided. The only question is how to deal with them.

Second, it is common practice in agile software development to include the customer perspective not only at the beginning and end, but throughout the entire process. In agile teams, this perspective is represented by the role of the “product owner” who describes functional requirements for the product from a user’s perspective, tests interim results, and prioritises the respective objectives for the next development sprint.

“In agile processes, the failure of a previously chosen approach can be anticipated much earlier, so there is still time to change course.”

Knowledge and expertise

Given that the product owner is an integral part of the project team and largely responsible for the success of the project, it is crucial that this position is filled by a person employed in the corresponding administration. While the knowledge and methods required for this role can be learned along the way, the product owner shall ideally be experienced with digital product development or at least have a certain passion for digital applications. The good news is that in-depth technical knowledge is not absolutely necessary for the role, since the point is to view the product through the eyes of the user. What is more important is the fundamental willingness and capacity to engage in agile project work, which is time-consuming but very profitable.

Third, if the administration assumes an active and formative role in the development of digital applications, the perspective also changes with the position: instead of viewing software as a product that must be procured on the market, it now appears as the result of a development process that administrations implement and are responsible for themselves, and in which they can, of course, still draw on external support (for example, programming, UX or design services).

By investing in development capacities instead of a finished product, the employees of the administration do not have to specify every conceivable detail of the desired application in advance but enter into a development process with a team of programmers to find the best possible solution to a problem within a given time frame and budget.

Risks and rewards

One might ask if it is risky to not clearly define all of the product’s functionalities in advance, but it is actually a way to reduce risk. In agile processes, the failure of a previously chosen approach can be anticipated much earlier, so there is still time to change course. Even a service provider, once chosen, can theoretically be replaced in the process if the administration as product owner takes care of transparent documentation of the process and insists on openness of the developed source codes (which should be done anyway).

In view of scarce resources, the idea of an administration that actively pursues digital product development may not seem very realistic for some authorities. However, when it comes to digitisation, it is no longer money that has been lacking in many places for a long time, but the skills and capacities to use this money effectively. But skills can be learned, and capacities can be created. It should be worth the effort as it would be an investment in the future of a digitally capable administration.

This blogpost was written by Benjamin Seibel, our director, and Yi Jun Huang, our executive assistant.