Government agencies around the world are under internal and external pressure to become more efficient by incorporating digital technologies and processes into their day-to-day operations.
For a lot of public-sector organizations, however, the digital transformation has been bumpy. In many cases, agencies are trying to streamline and automate workflow and processes using antiquated systems-development approaches. Such methods make direct connections between citizens and governments over the Internet more difficult. They also prevent IT organizations from quickly adapting to ever-changing systems requirements or easily combining information from disparate systems. Despite the emergence, over the past decade, of a number of productivity-enhancing technologies, many government institutions continue to cling to old, familiar ways of developing new processes and systems.
Nonetheless, a few have been able to change mind-sets internally, shed outdated approaches to improving processes and developing systems, and build new ones. Critically, they have embraced newer techniques, such as agile development, and succeeded in accelerating the digital transformation in core areas of their operations.
The Danish Business Authority is one of those organizations. This agency is charged with registering corporations that do business in Denmark. With the world economy teetering in 2009, it decided it could no longer maintain a largely manual registration process. It believed that replacing paper forms sent by mail with a simple online process was crucial to keeping the country economically vibrant. Specifically, a new digital-registration process would show both domestic and foreign companies that it was easy to do business in Denmark, help track money laundering, and better identify companies that didn’t report their income or pay taxes on it.
The Danish Business Authority set a goal of completing the specifications of a digital-registration system by 2011 so software developers could begin their programming efforts and formally roll out the streamlined process by 2014. In the first two years of the initiative, the agency used the traditional “waterfall” approach to design and development. But the effort stalled for a number of reasons, including ever-changing systems requirements and slow decision making.
In 2011, the IT organization revised its launch date and decided to trade the waterfall approach for an agile approach to systems development; a change in leadership was the catalyst. The agile approach has several hallmarks. New systems requirements can be accommodated late in the development process. It’s possible to deliver the software for parts of a system early, even before all the requirements are completely understood, to break design logjams. And decisions can be made more quickly if companies have only one team of businesspeople and software developers, rather than throwing requirements “over the wall” between functions and thereby facilitating divisiveness.
By 2014, the system was nearly completed. By 2015, the number of registrations requiring agency support for completion had dropped from 70 percent to 30 percent. More broadly, the registration system has helped Denmark to rank high on the World Bank’s annual index of digital government services and on another index that rates the efforts of European countries in helping new companies launch their businesses.
In this article, we consider the digital transformation of the agency: the challenges it faced in moving away from the waterfall methodology; the change-management principles it followed as it incorporated agile technologies, processes, and mind-sets into its traditional ways of working; and the results it has been able to achieve thus far. The agency’s story provides important lessons for government agencies everywhere that need to build critical digital systems.
Initiating the digital transformation
In 2009, the Danish Business Authority (see sidebar, “Helping to make Denmark’s economy click”) decided that its paper-based process for registering new companies had to be replaced by a digital one. New businesses often required weeks or even months to complete registration: they had to request the right forms, fill them out, and submit them through land mail. When forms arrived at the authority, workers had to enter data from each one into as many as 14 different computer systems. The agency recognized that this manual process was slow and error prone.
When the agency received the go-ahead to build a new corporate-registration system, it started with the waterfall method, a systems-development approach it had used for years. Under this approach, software developers go through discrete phases, starting with gathering the business requirements. Then they proceed to process analysis, including establishing the business rules that will inform the design of the system—for example, “treat this type of company and that type of company in different ways.” The next step is software design and programming. A core principle of the waterfall development approach is that a team using it can’t move to any phase without ironing out the details of the preceding one. There is good reason for that: fuzzy up-front requirements can introduce big software-design and -coding problems later.
In the case of the Danish Business Authority, this limitation meant that coding on the new registration system couldn’t begin until the process analysis was finished—and the development team couldn’t agree on the minutia of a standard process for registering a new company. Additionally, team members were involved only part-time on the project; each had other systems priorities. That contributed to long decision-making cycles, even for minor issues. Big decisions could take weeks to make, largely because the team gathering the requirements couldn’t get the attention of senior managers quickly. Plus, numerous system-design decisions had to be made collaboratively, and assembling the relevant business managers to make them was trying.
The result was analysis paralysis.
Exploring agile tools and methodologies
Around the time the system project stalled, the Danish Business Authority had brought in a new director general. One of her first priorities was getting the development of the digital-registration system back on track. After a comprehensive review of the program, the director general and the leadership team concluded that what it needed most was a design and development method that emphasized building and testing new systems in weeks rather than months and incorporating input from “customers,” external and internal alike.
An agile approach seemed more appropriate than the waterfall model, the team decided. For one thing, the agile methodology would allow developers to incorporate new system requirements into their design and planning late in the process. It would prompt them to deliver software code early, even before all of the requirements were understood. And it would bring businesspeople and software developers together on a single team, rather than having one try to decipher the other’s input after it had been tossed over the wall. Discrete project components could be designed and coded in weeks (or in “sprints,” as they were called) rather than months or years.
Rebooting the systems-development process
At the time of its reboot, the Danish Business Authority had found few government institutions, in or outside Denmark, that had used agile methods to develop core digital systems. As a result, the team created its own flavor of agile, based on seven critical elements:
- a focus on the customer;
- strong governance and swift decision making;
- an IT architecture that enables gradual changes in the system;
- a clear systems-development road map comprising a number of small, manageable projects;
- an organization that embraces agile and the processes supporting it;
- outsourcing to multiple partners rather than just one or two;
- and a culture of trust.
Here’s how each element played out in the Danish Business Authority’s digital transformation.
A customer-centric focus. Emphasizing customer needs gave the project’s team members clearer priorities and a common vocabulary. Initially, the program had focused largely on the agency’s own registration requirements and less on those of the businesses that would be using the system. That all changed under the agency’s agile development approach. For example, rather than forcing businesses to enter registration information into 14 different systems, the agency designed just one. That move alone saves businesses considerable time in registering companies—and it saves the Danish Business Authority a significant number of person-hours, as well.
Strong governance and swift decision making. The digital-registration initiative was mission critical but wasn’t treated that way until 2011. The CIO, for example, had been responsible not only for this project but also for a number of other IT priorities. In 2011, some of them were moved to a different department, so that the CIO could give more time and attention to the digital initiative. The CEO also became part of the daily project-governance team. This change caught the attention of other senior executives, who then recognized that they, too, had to make the system part of their agenda. Meetings to discuss the project’s progress became weekly events, which enabled the multitude of subprojects to stay on track because issues were monitored continually. What’s more, these weekly sessions—chaired by the CEO—let the project team bring outstanding issues to the table and have them resolved much more quickly.
The stronger governance extended beyond the CEO’s weekly meetings. After the big project was divided up into more than 30 smaller subprojects, the teams in charge of each of them received the authority to make decisions affecting their own areas. That meant they didn’t have to wait for answers, which had caused big delays in the first round of development. Further, each team included IT and “product owners”—people from the Danish Business Authority’s business operations—as well as representatives from the agency’s vendors. Project teams had the authority to make decisions on their system components quickly because someone from the business operations was there to finalize the choices.
A flexible IT architecture. The architecture of an information system stipulates where data will reside (how many databases), which software components will be shared across applications and which will not (such as user interfaces), and other technical details. A good architecture saves programmers time writing new code (by reusing common components), reduces errors, and defines system components so that they can be updated or replaced without any need to scrap the whole system. A poor architecture does the opposite: it piles on rework, introduces errors, and makes systems difficult to change.
The IT architecture for the Danish Business Authority’s new registration system divided it into more than 30 components. New features could therefore be implemented and launched piecemeal rather than all at once, which reduced the risk and complexity of implementing system changes. The architecture also called for only a single database, which eliminated the requirement that the agency’s people manually reenter information from one database to the next. This would be the sole “source of truth,” with all the information on a company stored in one place. What’s more, in the new architecture, all users—both internal and external (Danish businesses)—would see the same interface. Additionally, the architecture required the development teams to share software components, so that they didn’t have to reinvent the wheel. For example, the software for looking up a registrant’s business address was a shared component.
A clear systems-development road map. Traditional approaches to systems development emphasize getting all the requirements up front before any coding begins. By contrast, the agile approach emphasizes breaking up big systems into smaller components, which can be built and implemented one piece at a time and brought to market quickly. The key is building components in ways that minimize interdependencies among them. As mentioned, the Danish Business Authority broke its registration system into many smaller system projects. To track them, the management team created a clear road map showing when each would go live and its relationships with the others. That helped teams to know what their colleagues were doing, and when. Elements of the registration process were improved and launched sooner than they would have under the waterfall process. Additionally, the project teams that hadn’t delivered their modules could learn from the early releases and modify their plans accordingly.
Would you like to learn more about our Business Technology Practice?
An agile organization and processes. The Danish Business Authority followed standard practices in structuring each project team, which included business and IT professionals, as well as vendor staff. The teams were located in the same place, which dramatically reduced the chances for miscommunication, since it allowed each side to speak up early and often. The teams followed agile practices by asking the software-development vendors not to create specific requirements for their pieces of the system, the traditional approach. Instead, the vendors were asked to create user stories—denoting, for instance, what the system should allow the user to do at a general level. The programmers had more room to interpret the design and determine how to turn it into code.
Outsourcing development to multiple partners. Unlike many organizations, which outsource their software development to one IT-services company, the Danish Business Authority used four. The idea was to provide appropriate incentives and to promote more competition among vendors, which understood that future components would go to companies that had completed earlier ones on time, on budget, and on target. The setup even encouraged some vendors to overinvest so they could secure the next module. It also gave them an incentive to make their components easy to maintain and expand—if they did good work, there was a good chance they’d be the ones maintaining and expanding what they had built.
A culture of trust. Such incentives and ways of working—not asking vendors to collect detailed specifications before coding, creating teams of both business and IT people, and so on—created an atmosphere of trust and collaboration. The trust increased rapidly because the authority asked vendors to deliver their pieces of the system in 14 days. Mistrust didn’t have time to grow; each vendor could prove its competence quickly. By breaking the project into smaller pieces that could be turned around quickly, the authority enforced better performance from its vendors. It replaced underperforming teams or team members rapidly, in this way setting a tone that, just as high performance would be rewarded with more work, underperformance would be punished with less.
This culture of trust extended beyond the development of the digital-registration program; it was a critical element in the rollout of agile ways of working in other areas of the authority, as well. The digital-registration project team helped to provide support for the widespread adoption of agile techniques—for instance, serving as agile-implementation coaches and offering process demos and training on agile principles. That promoted trust in the methodology and, therefore, change across the organization.
Launching a new corporate-registration system
The agile approach to systems development put the digital business-registration project back on track. Many pieces of the system are live; the remaining modules are slated for release. The Danish Business Authority is already seeing some significant benefits:
- Less customer hand-holding. The average time needed to resolve a customer’s problems over the phone has dropped from 16 minutes to 5 minutes. The number of customer-support calls after registration has dropped from 70 percent of applications needing phone support in 2009 to only 30 percent today.
- Less need for rework by customers. The number of registrations completed accurately the first time around by businesses has risen to 92 percent, from 80 percent.
- Less time needed to get new employees ramped up. Because of the improved usability of the new digital system and because it automates much of the work employees had to do, the authority has reduced the time it takes to train new employees by 80 percent, from five months to one month.
This system has helped Denmark attract new companies. The World Bank compiles an index on the ease of doing business in 189 economies. In the 2016 list, Denmark ranked third overall, trailing only Singapore and New Zealand.1 A frequent user of the registration system, who works at one of Denmark’s largest law firms, estimates that she spends 50 percent less time on registration tasks and on updating corporate information, such as the names of new board members.
More broadly, the Danish Business Authority has significantly improved its ability to provide digital solutions in other areas. It has increased its IT productivity by about 60 percent, for instance, and significantly improved its time to market for new digital services (exhibit).
Denmark’s digital business-registration system is burnishing the country’s reputation as a place to launch new businesses. For example, it is helping the Danish government with the Start-up Denmark initiative—a campaign to attract new high-tech firms that can keep the country economically vibrant and serve as a magnet for jobs and talent.
By using an agile approach to building a digital-registration system, the agency has been able not only to streamline a critical service relatively quickly but also to provide proof of Denmark’s commitment to digital technologies and approaches. Indeed, government executives believe that doing business digitally has become critical to attracting the next wave of digital and nondigital businesses.
