Balancing digital debt and digital options: Challenges of digital transformation at Green Cargo

Abstract

Green Cargo is a state-owned railway logistics company based in Sweden. The company has a wealth of experience in train logistics, and it is well-positioned to benefit from the push toward the zero-carbon future. To materialize this potential and to support growth, Green Cargo needs to create a strong digital foundation. This teaching case presents challenges faced by Mr Ingo Paas, CIO of Green Cargo, who is looking for ways to deal with an existing digital debt that has been hindering company’s digital transformation efforts.

Introduction

Mr Ingo Paas, CIO of Green Cargo, felt upbeat and excited. The last 12 months have been transformational for Green Cargo’s IT department in many ways. Although it was a bumpy ride at times, Mr Paas was looking forward to the future. As a professional, Mr Paas is pragmatic and reflective, yet he does not shy away from a calculated risk when he believes that a leap of faith is necessary. Perhaps it was his character that attracted Mr Paas to Green Cargo—a struggling state-owned railway logistics company badly in need of change. In many ways, the company was rigid and conservative in its approaches; however, mounting problems painted Green Cargo into a corner, opening the organization up to new ideas. The new management team appeared to be willing to push for such ideas. This struck a chord with the more adventurous side of Mr Pass, so he decided to jump at the opportunity. Mr Paas is not much of a micro manager. He sees the CIO’s job as being a problem-solver, storyteller, and motivator. He believes that a clear vision, good story, and a mandate to act can inspire a sweeping change even in the most rigid environments. Mr Paas is willing to take everyone to the brighter future, provided one wants to take the ride. The question is this: Would everyone want to take the ride?

Green Cargo’s IT department was in a tight spot as Mr Paas joined the company in September 2019. The IT department was burdened by old, expensive to maintain, and inflexible legacy IT systems that should have been retired decades ago. Over the years, other CIOs and expensive management consultants attempted ambitious transformation projects to rejuvenate Green Cargo’s IT, but they all failed. Two of such attempts took place between 2010 and 2019. Some of these attempts actually made things worse. Repeated failures and worsening situation triggered rounds of cost-cutting measures and gradual outsourcing of IT functions to external providers. Each time this happened, the IT department lost resources and capabilities, resulting in the ability to do not much more than keeping the lights on. One of the service owners at the department recalled that “we were an IT department in the name only.” The first thing that Mr Paas did was bring back purpose, trust, and confidence to the IT department. He initiated structural changes, creating more meaningful teams within the department, and started hiring new personnel to boost department’s capabilities. More importantly he gave members of the IT department a mandate to act, vowing support for individual initiatives.

So far, the progress is noticeable. Attitudes at the IT department have taken a positive turn. There is an unprecedented number of IT projects in the pipeline. For the first time in a long while, the IT department is seen as a supportive and forward-looking unit, not as the sick man of the organization. The morale has been climbing, and Mr Paas can feel the energy all around him. Yet, this journey is far from over. There are significant challenges ahead. Although some organizational adjustments have been done, the cloud of legacy systems still hung over the IT department, limiting what they could do. There was motivation, but now they needed action. How to carry out a successful digital transformation without straining the resources? At first glance, it is easy to dismiss yet another big transformation project, but what are the alternatives? Such transformations are a well-beaten, if dangerous, path. In contrast, anything else looks unfamiliar and risky. These challenges occupy Mr Paas’ thoughts. It is at this junction that Mr Paas turns to you, new IT strategy advisors at Green Cargo, for help.

Green Cargo

Green Cargo is a state-owned railway logistics company that was formed in 2001 out of the existing logistics division of the Swedish State Railways (SJ). Being Sweden’s largest actor in rail freight with approximately 60% of market share, Green Cargo supplies Scandinavia’s trade and industry with a sustainable solution to transport cargo. The company presents its services as greener alternatives to cargo trucks. Green Cargo’s freight trains transport mostly raw materials from forests and mines to process industries and consumer goods to the retail sector. Green Cargo runs a large and very complex operation as it is responsible for about 400 train departures daily. Green Cargo serves close to 300 locations in Sweden, Norway, and Denmark through their network, and with their partners they reach all of Europe (Green Cargo, n. d.). This involves booking and scheduling the train engines and wagons appropriate for the cargo being transported, coordinating with the national rail services and other logistics partners handling cargo before and after the delivery, staffing each train, ensuring train maintenance, and dealing with delays just to name a few. At the same time, Green Cargo needs to run these complex operations with high reliability. Delays in cargo transit can trigger a domino effect in a customer’s supply chain, which can result in significant losses for the customer. Table 1 summarizes the basic facts about the company.

Table 1.

Green cargo fact sheet.

Owner	The Ministry of Enterprise and Innovation, Swedish State
Chairman of the board as of 2022	Andreas Regnell
Chief Executive Officer as of 2022	Ted Söderholm
Headquarters	Solna, Sweden
Areas of operation	Sweden, Norway and Denmark. Connected to the European rail network through partners
Number of employees	1,800
Turnover	SEK 4.1 billion (approx. USD 420 million)
Train engines	360
Train wagons	5,000

Green Cargo is organized in 11 departments that represent business functions: (1) production; (2) planning; (3) vehicles; (4) sales; (5) marketing; (6) purchasing; (7) finance; (8) human resources; (9) communication; (10) IT; and 11) legal. At the top of the company, there is a management team that consists of nine members, which includes Mr Paas. The management team is overseen by the board of directors, which reports to the Swedish government.

Green Cargo business strategy is based on four pillars: safety, punctuality, customer focus, and profit. The four principles permeate decision-making across the organization. Green Cargo is a state-owned and state-supported enterprise. The Swedish government has a great interest in promoting train-based logistics for environmental reasons. Nevertheless, the company is conceptualized as an income-generating enterprise rather than a subsidized one. This is reflected in the strategy. Over the years, however, Green Cargo has struggled financially, despite a strong market position in the railway logistics market. This struggle has triggered an effort to restructure the board of directors and to make major changes in the management team. In the end of 2018, the board started with the hiring of a new CEO to help turn the historical negative trend of operational loss around.

When the new CEO, Ted Söderholm, was hired, he quickly made three conclusions about the current situation. First, most of the current management team was either comprised of consultants or interim appointments, which impacted their long-term commitment to their roles. To succeed, the company needed to drive a recruitment effort to get a strong, committed management team that shared his vision.

Second, Green Cargo, despite its troubles, had a strong culture and knowledgeable and experienced employees with a lot of insight into various aspects of company operations. Some of the best employees came from rail-worker families, who were proud of their work, and highly interested in Green Cargo’s success, but often met with a blind eye when they proposed initiatives. This created a climate of passivity, where employees avoided taking responsibility, as they believed that most initiatives would end up going nowhere, despite their best efforts.

Third, the current IT environment was a major hurdle for the continuation of developing the business further. Green Cargo’s IT systems and IT practices might have been on the cutting edge when they were initially implemented, but they had a hard time keeping up with the requirements of today’s digital world. Many digital transformation initiatives were attempted before but without success. Therefore, the IT department clearly needed to change how they approached this issue. This last realization convinced Mr Söderholm that he needed to put considerable effort into hiring a competent and forward-looking CIO with a vision. Fast-forward a couple of months, Mr Söderholm was interviewing Mr Paas in his office. The CEO and the CIO-to-be got along well during this meeting. Mr Söderholm believed that he has found the passionate visionary who could brave the treacherous path of digital transformation at the company. Similarly, Mr Paas thought that he had found the right environment to tackle tough challenges, space for making bold moves, and an opportunity to have a significant impact.

IT at Green Cargo

Green Cargo has an aging, outdated, fragmented, and costly IT system. This is due to numerous legacy systems, mainly comprised of the mainframe, which handles operational transactions, and an ERP system, which handles the company’s business processes. According to the CEO, it was a ‘world class back-end system’ when implemented decades ago. But now, with modern best practices, interconnected APIs, and prominence of Software-as-a-Service solutions, the legacy systems have become inflexible and have accumulated concerning amounts of digital debt. These legacy systems significantly hindered development of IT-enabled solutions for operations. Limited capabilities of these systems also kneecapped any initiatives toward data-driven value creation.

Yet, despite all the downsides, these systems played a critical role in Green Cargo’s operations. Green Cargo is a high-reliability organization that requires exceptional stability in their operations. The mainframe is a bedrock for such stability. Without the mainframe, all trains stop. In over three decades, the system was down only twice for mere hours. Therefore, the system cannot simply be unplugged and changed for another one.

Moreover, the legacy systems are deeply integrated with IT architecture overall. As shown in Figure 1, most legacy systems are embedded into most of the business processes and associated information systems. Due to a lack of historic documentation and lost skills, there is also no consensus on how all systems are interconnected. Therefore, Figure 1 likely reflects only a part of reality.

Figure 1.

Green Cargo Process-Based Systems chart.

Furthermore, as running a railway company requires many highly specialized systems, there are very few alternatives on the market. The legacy systems have been integrated with these specialized systems over the years through custom development and workarounds. Therefore, it is highly likely that replacements for the legacy systems will not be able to integrate with these systems out of the box. All these factors result in a challenging landscape for any digital transformation.

Mr Paas was recruited as a yet another CIO to give the digital transformation a try. When he started at the Green Cargo, he was told that his main objective was to migrate from legacy systems to a new platform. However, Mr Paas quickly realized that any such transformation would be challenging. His predecessors failed, again and again, for a reason. The IT department was underfunded and understaffed. Furthermore, excessive outsourcing stripped the IT department of many of its functions to the degree that the department barely had any control over IT. These constraints lead to low morale among staff, who no longer believed they were capable of positively impacting the organization. Other units at Green Cargo perceived the IT department as unhelpful naysayers who rejected most initiatives outright always citing the lack of time and resources. One IT architect described this lack of action: “Everybody in Green Cargo was used to the fact that nothing happened in IT, which was correct because, if we look at the staffing and the investments for a company with almost 2000 employees, it was below the point where any sort of a reasonable IT department could operate.” Things did not look much better on the project management side of things. There were no established procedures and no coherent roadmaps. When Mr Paas asked for examples of successful IT projects in last 10 years, the department could come up with only one example. None of these sounded to Mr Paas like an organization ready to tackle a giant multi-year digital transformation project. Mr Paas had extensive experience working in both corporate IT and management consulting. Over the course of his career, he had often witnessed large IT transformation initiatives fail. These organizations were desperate to replace their obsolete systems, but they bit off more than they could chew.

Green Cargo’s starting position did not inspire optimism. As a result, Mr Paas decided to start investigating alternatives. At the board meeting, where Mr Paas was supposed to outline his plan for IT transformation, he said that he did not have a plan, but he had a vision: stop thinking about replacing legacy systems and start focusing on building new digital capabilities. Any objections were addressed with a simple question: Do you want a functional IT or do you want more of the same? Given the Green Cargo’s history, it was relatively easy to convince everyone to look for some new approaches; however, the IT department is not ready for a change.

From the start, Mr Paas proposed sweeping changes: introduce agile development practices and agile structure, ¹ invest into the IT department, increase of IT department headcount, and give the IT greater autonomy. Mr Paas was especially adamant about renewing the IT department’s self-confidence and mandate to act. He told new colleagues at the IT department that ‘we can do it together, you have the power to act, and I can take the responsibility. I will support you removing the obstacles while being your sponsor, coach, and back you up’.

However, this was just the beginning. The real work started now. Green Cargo urgently needed to manage the digital debt that had accumulated over the years from legacy systems while developing digital capabilities of the company to give Green Cargo options for crafting their strategy. But how should this be done? Several conditions made this a difficult task: a systematically underfunded IT department, a shortage of high-skilled IT professionals in the market, and complexities of Green Cargo’s IT infrastructure. Mr Paas needed to come up with some potential alternatives for action and develop the strategy from there. Tomorrow, Mr Paas is meeting IT strategy team to brainstorm some ideas. Hopefully, they find the way.

Digital options, digital debt, and strategy

Digital options

Options thinking in business strategy was inspired by financial options. In finance, an option is a contract that gives its holder the right but not the obligation to buy or sell an asset specified in the contract at a specified price on or before an option expiration date (Tong and Reuer, 2007). For example, an investor can buy an option to sell shares of Company X at a price Y before date Z. If the price of Company X shares drops below Y before date Z, the investor can buy the shares, exercise the option to sell their shares at price Y, and pocket the difference. However, if prices stay at or above Y, the investor will leave the option unused and take the price of the option as a loss. Typically, investors trading options create options portfolios, which include various options, to mitigate such risks.

Translated into business strategy, options become investments in various strategic assets that provide the organization an option to take certain strategic actions in the future (Tong and Reuer, 2007). Options thinking offers an alternative to the approach of committing to a single strategy. Instead, an organization can cultivate strategy options portfolio that would allow the organization to exercise a promising option when the option is ripe (Luehrman, 1998). In this scenario, while the organization takes a risk by investing in various assets that may never bear fruit, a well thought out portfolio gives the organization flexibility to make the best strategic maneuvers to manage uncertain futures. A manager’s task is to formulate appropriate options, provide adequate investment for the options, and recognize when options are ready to be exercised.

Over time, options thinking has migrated from business strategy to IT strategy, taking the shape of digital options. Here, options are investments in digital capabilities that would allow the organization to take strategic actions in the future. This can take shape of investments in new technology or information infrastructure that would increase the value of IT for organization’s work processes (Rolland et al., 2018). As with business strategy options, managers mainly research and identify promising options, develop these options by providing adequate investment, and realize the right options at the right time (Sandberg et al., 2014).

Digital debt

The concept of technical debt comes from software development and describes an accumulation of software maintenance obligations that need to be addressed (paid off) in the future (Ramasubbu and Kemerer, 2016). There are two main sources of technical debt. First, debt is incurred when developers choose to implement quick and dirty solutions to address a problem or deliver a feature rather than using a better albeit more time consuming and expensive approach. Second, debt comes from older software that may have been a debt-free solution when it was deployed but became a source of technical debt as technological and business environments around it changed. Such software may also encourage developers to build sub-optimal solutions around the old software to make sure it meets new requirements.

More recently, the concept has expanded to include not only software maintenance obligations of an information system but also design, deployment, and social and information obligations (Ernst et al., 2021). This more expanded understanding of the concept is sometimes referred to as digital debt (Rolland et al., 2018). Digital debt can be broken down into eight sub-types of debt: (1) requirements debt, (2) design debt, (3) implementation debt, (4) testing debt, (5) deployment debt, (6) documentation debt, (7) social debt, and (8) information debt. Table 2 provides brief descriptions for each type of debt.

Table 2.

Types of digital debt (adapted from Rolland et al. (2018) and Ernst et al. (2021)).

Type of debt	Description
Requirements debt	Requirements debt is incurred when business requirements are not properly translated into software design. In such cases, software may work perfectly from a technical standpoint but fail to provide value to the business in the long run.
Design debt	Design debt is created when poor choices are made in design and architecture of IT solutions. In such cases, organizations forego establishing coding standards, design rules, and guidelines, focusing instead on creating a quick solution to immediate problems. This often happens due to lack of time and/or resources.
Implementation debt	Implementation debt is incurred from poor implementation of requirements and designs. For example, code written as an early prototype for a solution may end up integrated into the final product due to time pressure or negligence. While such code may work in the moment, it can generate problems from maintenance and development years down the road.
Testing debt	Testing debt emerges from a lack of proper testing of a solution before approving it for production. Testing may be deprioritized due to lack of resources or time pressure. Absence of adequate testing may pay off in the short term as bugs are fixed as they emerge. However, it becomes a significant hurdle in the long run as the solution grows and becomes more complex.
Deployment debt	Deployment debt is created because of mistakes and shortcuts in deploying an IT solution. Such mistakes may emerge from, for example, a lack of experience in deploying IT on a scale or from shortcuts made in preparing the solution for deployment. Deployment debt can lead to additional, unnecessary effort during deployment or even a critical failure of major organizational information systems.
Documentation debt	Documentation debt comes from poor software system documentation practices. In resource-constrained environments, documentation may be seen as the least important aspect of software development and therefore a prime venue for cutting corners. In the long run, however, poor or outdated documentation can be a source of significant challenges as no one remembers how and why the solution was created the way it was or even what it does.
Information debt	Information debt is incurred when information within the solution is structured inadequately. This may happen due to poor database structure, a lack of informational features, or deficiencies in user interface pertaining to presentation and navigation of information. In the long term, accumulation of information debt can lead to decreasing value of a solution as navigating, extracting, and manipulating information becomes increasingly difficult.
Social debt	Social debt emerges from failures in communication, management, and organization of development process. Therefore, social debt is not technological. Yet, social issues in the development process can have knock-on effects on every other type of debt described above. Examples of social debt are poor team management practices, flawed prioritization process, and communication breakdown between business units and the IT department.

The debt metaphor comes from a familiar concept of monetary debt. Like monetary debt, if digital debt is not repaid timely, it will accumulate interest—that is, it will become progressively harder and more costly to pay off. For example, software workarounds applied to an existing system to enable new features (not intended by the original developer) or integrations with other systems may eventually form a complex web of interdependent ad-hoc patches and hacks that make any changes to the core system extremely difficult, expensive, and disruptive. However, digital debt shares negative as well as positive aspects of monetary debt. For example, monetary debt allows factories to invest in expensive equipment that improves their production process and helps them stay competitive. If the factory were to pay for this investment in cash, it would take years of savings to be able to afford it. Such a delay would be undesirable in a competitive market. Similarly, digital debt is not a net negative that must be avoided at all costs.

Digital debt can provide an organization action options that would be unaffordable or impractical without the debt. For example, if a company wants to integrate their old inventory system with a new shipping system from a logistics provider unsupported by the inventory system, the company has two options. First, it can change its inventory system to something more modern that supports the integration. This would be a multi-year project that would cost millions and would likely disrupt their operations and subject the organization to the pains of change. Second, it can develop and deploy a small piece of software on top of existing infrastructure that would interface the two systems, bringing most benefits of integration. This solution would create digital debt, but it would be fast, cost-effective, and disruption-free. The debt could be repaid in the future when benefits of changing the whole inventory system clearly outweigh its downsides. At this point, the proper integration between the two systems could be implemented.

Therefore, digital debt can be beneficial or even desirable. The key is to differentiate between a good and a bad digital debt. The quality of debt can be evaluated on two dimensions: intentionality and risk (Ernst et al., 2021). Digital debt can be incurred either deliberately, where organization acknowledges the debt, or inadvertently, where debt is created unbeknownst to the organization. In terms of risk, digital debt can be positioned on the scale between reckless and prudent. A reckless debt occurs when IT prioritizes addressing immediate problems without consideration or risk evaluation associated with the debt. A prudent debt, on the other hand, comes with risk/benefit evaluation and a plan to pay off the debt in the foreseeable future. This good digital debt should be considered carefully. Incurring debt should be substantiated by tangible benefits, unlike options, which do not lead to debt. The risks of taking on the debt should be evaluated. Most importantly, there should be a realistic plan to repay or discard the debt in the future.

Strategy implications of digital options and digital debt

Digital options and digital debt are significant concerns for a company such as Green Cargo, which is trying to create a digital strategy amid a baggage of debt-ridden legacy systems. Positive aspects of digital debt make it an important ingredient in ensuring continuous IT operations and even digital innovation in an organization. Digital debt and digital options are interdependent (Farjoun, 2010; Rolland et al., 2018). That is, digital debt and digital options can both enable and hinder one another. Deliberate and prudent digital debt should open the door for an organization to identify and develop more digital options. Realizing well-conceived digital options, on the other hand, should help an organization repay digital debt. However, existing digital debt can also hinder an organization’s ability to identify, develop, and realize digital options. Green Cargo’s heavily indebted legacy systems have made replacing old systems or developing new digital services increasingly difficult. Incurring even more debt may not enable more options in such contexts. On the other hand, developing and realizing some digital options may create bad digital debt, which can become a problem in the future. Some of this debt may be a function of changing environments and requirements. Hence, a great option today may become a source of debt years down the road. This situation is partially responsible for Green Cargo’s current situation. Therefore, IT management has a difficult job balancing digital options and digital debt to achieve their strategic objectives without creating even bigger problems in the future.

At the intersection of digital options and digital debt lies design capital (Woodard et al., 2013). Design capital is the value of options and amount of technical debt that an organization possesses. From the perspective of design capital, digital options are assets and digital debt are liabilities. The state of design capital at any given company can be expressed on a design capital map (see Figure 2). The map consists of four quadrants.

Figure 2.

Design capital map (Woodard et al., 2013).

The first quadrant (option constrained) describes an organization that has not only low technical debt but also low option value. An absence of options constrains such an organization as it lacks digital capabilities. However, these capabilities are relatively easy to build as the organization is not burdened by existing debt embedded in legacy systems. Therefore, the organization can freely take on new digital debt and focus on developing options.

The second quadrant (low quality) describes an organization with low option value and high digital debt. This state is the least tenable as the organization is hit with both a lack of options for action and a heavy burden of digital debt, dragging the organization deeper to the bottom.

The third quadrant (debt constrained) describes an organization with high option value and high digital debt. This organization has a lot of potential for future development. However, the organization’s ability to exercise its digital options is constrained by the need to paying off old digital debts. Organizations in this quadrant need to prioritize debt reduction to reach their full potential.

The fourth quadrant (high quality) is the opposite of the second quadrant. Here an organization has many digital options and low digital debt. Organizations in this quadrant are well-positioned to seize emerging opportunities, counteract action of competitors, and weather external storms.

Although every organization strives to be in the fourth quadrant, it is not possible for every organization to achieve a state of low debt and high option value. As internal and external conditions change and organizational strategies evolve, organizations would need to move between quadrants, prioritizing either debt or options. Even organizations firmly positioned in the fourth quadrant cannot remain static. A gradual accumulation of digital debt and a need to explore new digital options would eventually push these organizations into another quadrant. Therefore, maintenance and growth of design capital is a constant balancing act that undergirds digital and organizational strategy.

At the crossroads

Back at the strategy meeting, Mr Paas and heads of teams were brainstorming the approach Green Cargo’s IT should take to resolve problems. Mr Paas argued that it was time for them to start shooting for the stars. The existing situation is clearly untenable, and traditional approaches have not gotten the company far. In his view, Green Cargo needed to become a digital, data-driven company. This required bold moves. However, the situation on the ground took some shine from this vision. The company’s resources were scarce, and digital debt would drag down any ambitious initiative. One needed to thread a very tiny needle to succeed here. Odds of this game were certainly not for the faint-hearted. After intense discussions, some initial proposals started to take shape (see Appendix III for summaries). These were accompanied with some guestimates of benefits and risks of each action. These guestimates would need to be investigated further once Green Cargo moved to formulating a concrete strategy. The ideas emerging from the discussion represented a broad spectrum of action. For the sake of the discussion, the various paths for action were clearly demarcated, but the ideas contained within them were not necessarily mutually exclusive.

While the contours of each alternative started to become visible, further investigation into each of the ideas would be necessary. Mr Paas was staring at the notes chaotically drawn on the whiteboard. There were a lot of good ideas and paths of action, but none were perfect. One needed to carefully balance potential outcomes, risks, resource requirements, digital capabilities of Green Cargo, as well as the impact of the final strategy on the organizational culture and morale. Mr Paas also felt that perhaps he is missing something. “Are there any possibilities we are not seeing?”, Mr Paas thought.

Assignment

The time has come for analyses, decisions, and actions. The day after the strategy meeting, Mr Paas is meeting with you to discuss the next steps. Your task is to offer compelling strategy recommendations. As a starting point, consider the following components for your analysis:

1. Reflect on the overall situation at Green Cargo’s IT department.

a. What is the as-is state of Green Cargo at the point of Mr Paas’ arrival?

b. Analyze digital options/debt condition using design capital map (see Appendix Figure A3).

c. What are the key challenges Green Cargo faces?

2. Establish the desired state of Green Cargo’s design capital and develop a vision for achieving it.

a. What will be the key obstacles in achieving this state? Evaluate their severity and prioritize them.

b. What key assets does Green Cargo already possess? Evaluate strategic importance of these assets.

3. Formulate a strategy and create an action plan for Green Cargo going forward based on the information provided in the case. Feel free to make assumptions when necessary. Make sure that your plan is well-substantiated. In addition, keep in mind that your plan needs to convince Mr Paas, so you should think about how you would sell it to him. You could start by considering the following aspects:

a. Describe the short- and long-term implications of your plan for digital debt and digital options of Green Cargo.

b. Evaluate risks associated with probability and effect.

c. Evaluate the benefits related to organization and customer value.

d. Describe step-by-step through a roadmap how your plan will achieve the desired state outlined on Task 2.