Recoupling the organization

The decoupling of legacy systems into modular applications enabled a recoupling of the organization. This recoupling progressed in two stages. In the first stage, NAV introduced independent development teams that assumed responsibility for developing and operating their own applications. In the second step, these teams and their applications were recombined into product domains.

The introduction of independent development teams occurred gradually. The first independent teams were established in the context of small projects with few dependencies on other projects and systems. One example was the DigiSyFO project.

This project, which developed functionality for digitally following-up on sick leave, had one multidisciplinary team. Although most of the developers were hired consultants, the project was planned and managed by NAV employees.

“The project was initially set up with a single team with less than ten members consisting of two UX designers, two subject matter experts, one software architect, one developer, operations support, and agile coaches. This grew to approximately 22 project members nine months into the project” (Agile coach in the IT department).

Whereas other projects employed a staged delivery model with handovers between stages, the members of the DigiSyFO project took responsibility for all parts of its development cycle. In addition, the project was developed iteratively, and activities such as design, development, and operations were interleaved. Software was developed and released continuously, and feedback was constantly collected from end-users and other

stakeholders and reintegrated. The project owner, Kristian Munthe, described this process in an interview with MEMU (Haugen 2018), NAV’s internal magazine.

- It has been absolutely crucial that the project has used "agile methods", which means that they have continuously made improvements instead of waiting until the system was complete. We have received over 80,000 written suggestions. Some of these are on things that could have been easier and better explained. For example, it may be about small formulations that should be changed.

And then you change it straight away?

- Yes, if we agree with the input. We have made a lot of changes since the beginning.”

The project was deemed a success, and in 2017, it won the government’s digitalization reward based on outstanding achievements. The chairman of the jury summarized the project as follows:

“This year's winners are a good example of how things can be done in new ways to deliver services that streamline public management and make life easier for users. Both the government and Difi [short for the Agency for Public Management and eGovernment] have high expectations for the digitalization of the public sector” (Director at the Norwegian Digitalization Agency)

As agile development practices proved successful for smaller projects, NAV decided to apply these methods to larger projects. In 2019, the Parental Benefit project transitioned from staged to continuous deliveries midway through its timeline.

The Parental Benefit project, which was the largest ongoing software development project in the Norwegian public sector at the time, was intended to develop a new system for processing applications for parental benefits. A parental benefit is a welfare benefit intended to compensate parents for losses of income in relation to the birth or adoption of a child. The project, which had an estimated cost of 1.3 billion NOK, was initiated before the elected strategic change and thus followed the “old” delivery model with staged deliveries and handovers between departments.

A leading principle behind the formation of independent teams was that each team would have the competence and authority to develop services independently of other teams and be responsible for an entire service delivery cycle - from the inception of an idea until the service was eventually discontinued. By duplicating competencies across teams and introducing a distributed decision process, the organization ensured that development teams no longer had to await approvals or assistance.

To facilitate the formation of independent teams, the IT department was reorganized, and the hierarchical structure was replaced with a matrix organization. While in the old

structure, employees were organized according to their roles in the deployment cycle (planning, development, or operations), in the new structure, employees were grouped according to their competence fields.

This decoupling of applications allowed teams to work more independently. However, not all dependencies between applications could be broken. Many applications were part of larger value paths and had to be developed in relation to other systems and teams. As one of developers of the Parental Benefit project stated:

“In my experience, when people don’t see the value chain they’re contributing to, they begin to sub-optimize. It is artificial to say that you have a truly autonomous team in the area of Parental Benefit. All components and all applications support the same decision process.”

To address these dependencies, applications were grouped into functional domains, and a domain would encompass several applications and teams. The idea of “domain-driven design” (Evans 2004) permeated both the formation of teams and the decoupling of legacy systems.

“The idea behind domain-driven design is that it is more important to organize for flow. Optimal flow in the organization and in the code. And this is done by minimizing coordination and chattiness. You must bundle the things that belong together and keep the things that don’t belong together apart. You bundle people and code in domains. People within a domain will be more closely linked” (Manager in the IT department).

By focusing on domains, NAV was able to establish value paths that transcended the organization. However, the domains had to be established gradually and one at a time.

In this way, the organization could learn from the experiences gained during the establishment of one domain before establishing the next.

“The goal is to remove boundaries between departments. But you can’t do that by changing everything at once. All 19,000 employees. Because that won’t work. Instead, you can do what we are doing. Establish one domain at a time. Gain experience and prove to the organization that it works. Then you establish the next domain” (Senior executive of the Parental Benefit project).

As a principle, no legacy systems were brought into the domains. The domain teams only managed new applications. In practice, however, exceptions were made. In some cases, it was more practical to give domain teams responsibility for certain legacy systems while they were being replaced.

By creating cross-cutting domains, NAV was able to improve the flow and collaboration within the organization without physically reorganizing employees. By establishing one domain at a time, NAV could learn and adapt, gradually restructuring the organization

and redesigning its service delivery. At the time of this writing (September 2019), the organization had established three domains: Health, familily, and work.

4 Research methods

The goal of this research was to analyse the role of digital platforms in improving value co-creation in public sector organizations. This research required in-depth knowledge of how digital platforms influence the value co-creation process, the views and opinions of stakeholders concerning digital platforms, and the changing contexts in which these platforms are used. Studies that collect this type of data can be classified as “interpretive case studies” (Walsham 1995). Interpretive studies are based on the assumption that people subjectively interpret the world. A researcher must thus reconstruct this phenomenon by accessing these interpretations.

The research approach adopted in this study was inspired by Pan and Tan (2011)’s structured-pragmatic-situational approach to conducting a case study. This approach suggests that case study research can be conducted through an eight-step process that begins with the researcher gaining access to the case. Once such access has been gained, the “framing cycle” of the method is initiated. The framing cycle begins with the researcher gathering information on the phenomenon of interest and reviewing relevant literature. Based on the resulting mental concept of the examined phenomenon, the researcher collects and organizes an initial set of data and begins engaging in preliminary theorizing. This preliminary stage of theorizing results in the construction of an initial theoretical lens that is used as a “sensitizing device” (Klein and Myers 1999, p. 75) in subsequent data collection and analysis steps. Additional data are then used to further develop this initial lens by adding and refining categories and constructs. The framing cycle continues until the researcher feels sufficiently confident that the theoretical lens captures the phenomenon of interest and makes an adequate contribution to theory and practice.

This framing cycle is followed by an “augmenting cycle”. In the augmenting cycle, the researcher gathers additional data with the aim of developing the theoretical lens into a full-fledged theory. Data are systematically organized and coded using a series of sensemaking strategies for qualitative data analysis (Langley 1999). Once the emergent model has been validated against the empirical data and existing literature (Klein and Myers 1999), the model is presented to and verified by informants. This iterative process involving the emergent model, existing literature, and data continues until "theoretical saturation" (Glaser and Strauss 1967) is reached. Theoretical saturation can be described as the point where additional data neither reveal new properties nor provide further insight into an emergent theory.

In the remainder of this section, I provide a more detailed description of the research process.