Transformation of the IT development process

To address the challenging situation in the IT department, the CIO, under pressure from the municipality’s deputy mayor, decided to initiate a process transformation in that department. Consequently, the transformation was driven both by a desire to ease the internal situation in the IT department and a need to respond to external demand. As the CIO pointed out, the IT department would benefit from an improved manner of operation; however, on the other hand, if the IT department continued to underperform, it could also become obsolete and be outsourced: “The IT budget is about 30 million; if we do not create value through that, we can be bought as [an external] service” (CIO).

To aid the transformation, the CIO called in a group of consultants to design and then implement the transformation of the IT development process. As even the consultants had not done similar transformations before, the design and implementation were conducted iteratively in the IT department based on arising needs.

The redesign process began with the intention to better integrate EA as part of the IT development process. As EA was intended to play a critical part in each step of the transformation process, the focus on its better utilization in the process also revealed many other issues with the IT development process, and the redesign efforts were extended from EA to encompass the entire IT development process. A simplified IT development process model is presented in Figure 18. This model depicts the key parts of the process at the end of the case study and is the result of multiple iterations. The core idea behind the process and its interlinked activities was that it would never be finished but should be continuously developed: “This is only the version 0.3 …; now we have something to work with” (Consultant A).

Figure 18. The new agile IT development process (Ylinen 2021; Ylinen and Pekkola 2019).

The new IT development process can be divided into three general phases: need identification, solution development, and solution implementation. As many challenges with EA and the IT development, in general, originated from the business units’ tendency to advance new IT development projects independently, special attention was focused on the front end of the process (i.e., need identification and solution development). The solution implementation phase was improved mainly by means of better front-end management of the IT development process and experienced only minor changes. “Well, the end part of the development has not been considered even a bit. It was supposed to be considered, but it was left undone. The consultants that run the solution office only focus on the solution office …. Now they focus only on the development

…, not the whole process” (Head of continuous services).

The new IT development process was initiated when a new IT-related need arises in one of the business units. To ensure that the business unit contacts the IT department instead of developing an idea independently, each business unit had a dedicated contact person (account manager), who was responsible for facilitating communication between the business unit and the IT department. Under the guidance of this account manager, a new IT need of the business unit was then developed in the IT department in collaboration with the business unit. This development work was conducted in the newly established team known as the

“solution office.” “The solution office is this work supervision forum that sits on top of a Kanban board and collaboratively prioritizes their backlog, divides their labor, and meets to solve problems, etc.” (Consultant B).

The solution office was a virtual team in which both the IT department’s employees and external consultants participated based on the current needs of the solution office. At the time of the data collection, one of the consultants responsible for the redesign efforts was appointed head of the team, while other resources were viewed as a competence pool from which suitable people, both internal employees and consultants, were selected based on the different solution-development projects.

The solution office team was virtual because the public sector human resource management regulations did not allow the CIO to modify the existing structures of the IT department easily. To cope with the complex organizational structures, the solution office was built on top of the existing structures. The objective of the solution office was both to enable the IT department to utilize the existing resources and competencies more flexibly and to encourage the business units to collaborate with the IT department. Now the business units had a dedicated place where they could bring up their IT development proposals: “When [one of the business units] has a need, an interprofessional working group meets to consider whether the need has a viable solution”

(CIO).

The first step in solution development was brainstorming, during which the virtual team, in collaboration with the business unit representative, conducted an in-depth analysis of the particular need and the context where the need had surfaced.

This included both informal discussions about the situation and an official “solution day,” during which the selected virtual team and the business unit representatives met and discussed needs and expectations related to the solution. Also, factors such as the business unit’s yearly clock were discussed lest it prevent implementation during certain times of the year. Subsequent to the brainstorming, the solution development advanced to evaluate whether the problem could be solved with existing resources either inside the involved business unit or within other business units. This was then followed by an idea dialogue, during which different alternatives for the solution were discussed. Typically, three alternative solutions would eventually be presented to the business unit to choose from.

During the idea analysis and solution development phases, the solution office used a two-week sprint approach in which the solution was divided into steps that could be completed within two weeks. In these sprints, the enterprise architects were also closely involved to ensure that the developed solution would fit within the organizational EA. This approach was incorporated as part of the solution

development to ensure an agile but systematic approach, which enabled the IT department to take the lead in IT development projects from their earliest stages.

After the solution office had a prioritized list of presentable solutions for the business units, it was presented to the business unit representatives and then to the steering group of the business unit. Depending on the solutions developed, the options presented might be: for example, a list of potential systems to acquire or a suggestion to extend the use of an existing system already in use in other parts of the municipality. “When we have created a viable solution suggestion, we actually discuss what is going to happen next before moving the solution to production .… Previously, the situation, in the worst-case scenario, was that the client that was the loudest got what they wanted, and no one was thinking about the big picture (Consultant A).

In rare cases, the solution office could also suggest rejecting the case. This especially the case when upcoming changes to the municipal IT infrastructure could either solve the issue or permit its development. Of course, the IT department could only suggest a rejection as the municipal business units were independent operators and IT development projects were guided by political interest: “Well, political governance is different from corporate governance” (Consultant A).

After the solution was presented to the business unit representatives, they could suggest adding it to the IT department’s investment list. In cases where the business unit wanted to implement the solution using their own financial resources, they could also do so immediately, as long as the IT department had the needed resources available to support the project.

After the solution had been accepted by the steering group and funds allocated to it, the actual implementation followed a similar process as before. The IT department established a development project, acquired a suitable team and budget for the project, and then followed the advancement of the project as before. The most significant difference was that now EA was more closely integrated into the operations even though the EA checkpoints and observation groups had been dissolved. When the project was finalized, the responsibility was transferred to the operations center, which was in charge of the upkeep of the existing IT infrastructure of the municipality.