Why IT modernization and monolithic methods cannot coexist

Much of the federal government still relies on inefficient, costly, fragile, decades-old systems to which more than 75 percent of its total IT budget is allocated. Some agencies have attempted to modernize these massive legacy systems. Many more still need to. While there has been some improvement in the success of these types of modernization efforts, the government still doesn’t have a great track record. If the government wants to be more successful now and in the long-term, it needs to change the way it approaches modernization.

Having more money certainly helps. To help agencies fund the modernization of their legacy systems, Congress approved and President Donald Trump signed into law the Modernizing Government Technology (MGT) Act as part of the  larger Defense authorization bill.

The MGT Act can help agencies secure funds and execute modernization projects based on their respective needs. However, without changes in the mindset and approach to these modernization projects, these funds may just leave us with the next generation of legacy systems that need to be modernized. We’ll be no better off than we are now.

The world is changing faster than government IT can respond. The bar is rising on citizen expectations of the experiences and interactions with the federal government. Technology is evolving at an ever-increasing pace. So are security threats and the sophistication of our adversaries. Big data is getting bigger, doubling every two years, by some predictions.

Advertisement

How can the federal government hope to keep up?

There is hope. There are proven ways to address these challenges.

Here are five suggestions for the federal government to successfully modernize its aging IT systems, avoid the pitfalls of outdated IT, and keep pace with an evolving world:

Create autonomy in teams and architectures

Building loosely coupled systems supports continuous delivery. It also leads to better performance through simplified operations, with more efficiency and less risk. When you’re able to make changes to different parts of the system independently, you improve speed of delivery, shorten cycle times and get more value sooner.

Teams should also have the freedom to experiment. This provides the opportunity to explore what to build and how to build it in order to deliver the best results. While this concept is counter cultural in many parts of the federal government, the 2017 State of DevOps Report states: “A team’s ability to try out new ideas and create and update specifications during the development process (without requiring approval from outside the team) is an important factor in predicting organizational performance, as measured in terms of profitability, productivity, and market share.”

Be agile — don’t just “do” agile

There is a big distinction between doing Agile and being agile in your approach to work. “Doing agile” is about following an agile methodology, like Scrum. You use the vocabulary, perform the ceremonies, and follow the process. It’s a good start, but it will only get you so far.

“Being agile” is about a mindset and a culture. That mindset and culture embraces change, empowers teams, leverages experimentation and views failure as an opportunity to learn. In contrast, government culture is built on controlling change, commanding teams, intensive planning and avoiding failure at (almost) all costs.

Think in terms of mission — not projects

When an organization operates with a project-based approach with definitive starts and ends, it must identify new funding, issue new contracts and form new teams for any new projects. Once a team has formed, the team still must go through the storming and norming phases before it actually starts performing. The result is a long lead-time before the organization sees any value from a new project and a lot of associated risk. When that project is a modernization effort, the organization may just decide to delay it, enduring the pain of operating with outdated technology until it finally outweighs the pain of addressing it.

In contrast, when an organization operates with a mission-oriented approach (or product management approach in the private sector), it experiences less friction in tackling new requirements. Value can be realized much quicker since most of what is needed to tackle something new is already in place. With less pain associated with modernization, it will happen more frequently. An organization can now improve its technology on a “forever” basis and pursue perpetual innovation.

Build a trust-based, collaborative relationship

The relationships between internal IT departments and their respective agencies aren’t always great. The relationships with external contractors aren’t any better. We could accomplish a lot more if there was a little more trust and collaboration among agencies, their IT departments and their contractors.

Former CIO of U.S. Citizen and Immigration Services (USCIS) Mark Schwartz wrote in his book A Seat at the Table: IT Leadership in the Age of Agility, that IT departments are too often treated like external contractors by the rest of the organization, rather than key partners in achieving the organization’s mission.

The same is often true of how the private sector is treated. There are ways to approach these relationships that lead to improved trust, collaboration and results.

Notice these suggestions don’t have anything to do with which technology you use or which products you pick. Technology isn’t the issue. The way the federal government views, funds, uses, manages and maintains technology is. Putting these suggestions into practice will be hard, but it will be worth it. Federal IT will be more responsive, more resilient, and better able to serve citizens. And we may just save a few billion dollars along the way.

Jeff Gallimore is founding partner at Excella Consulting — a technology consulting firm with expertise in software development, business intelligence and agile best practices.