In my recent career, I have noticed a common misperception concerning legacy systems which strikes my interest. What I have heard said is that, “X system does not meet the users’ needs.” I remember a pearl of wisdom from my childhood, “There’s no tree but bears some fruit”. Translation: there is nothing so useless that it can’t be of some use.
A “legacy system” is a computer system, programming language, software application, process or other technology that is no longer capable of being supported or upgraded. Whether a system is actually “Legacy”, has little to do with the install date. I have seen a twenty-plus-year-old system during my former career, operating at the heart of a company, still a stable and viable core product even to this day. Likewise, the definition of a legacy system has nothing to do with the most recent upgrade or patch timeline. As a CIO I have noticed, when we analyze what to do with our legacy systems, we all need to be reminded of this.
Nebraska, like many States, is faced with a legacy system challenge: we own applications that serve critical business needs, but they are outdated and need modernization. Software replacement comes with several inherent risks. What seems obvious to do with these legacy systems is the “rip and replace” strategy, but in reality, there are other options to consider. Our ability to identify the best option depends upon our answering the preliminary research question: What problem are we trying to solve?
I would caution the belief that all the issues with a legacy system can be resolved with new software. The same issues will reappear if they are not resolved before replacement. Several times, government technology organizations have tried replacing a legacy system with a Commercial off-the-shelf (COTS) or Cloud solution and their endeavors produced inadequate results when what was already considered “inadequate” was replaced with a product that did not meet the customers’ needs. In some cases, the issues that already existed were not addressed before the replacement and the product had multiple defects upon release. In the worst-case scenario, the product did not function at all.
Project failures are not limited to the Public sector. The Private sector shares these challenges. The Standish Group Chaos Report found that in 2015 only 29% of IT project implementations were successful and 19% were failures. When examining the development methods that were utilized, the report shows that the Agile projects had a 9% failure rate vs. the Waterfall projects’ failure rate of 29%. As you know, I am a strong advocate for Agile Development and we have a large presence in the Nebraska OCIO of Agile leadership and development practices.
In my experience, I have learned that both Agile and Waterfall have their place in our agency’s development toolkit. I learned this by examining the three pillars necessary for every successful project - people, process, and technology. When I analyze a legacy system project, I similarly look at three factors: Risk, Cost, and Benefit. I evaluate and research the costs that are associated with the project to fully understand the ¬potential benefits to the consumer, then I compare the risks associated with the solution’s implementation. Finally, I rank the elements to determine if the impact of the proposed solution has more potential to be considered a success or failure project.
The Standish Group found that institutional knowledge and experience was the most common theme that contributed to project failure. The research shows teams who used the incremental or phased approach were able to minimize the most risk. The method also proved to encourage stakeholders to prioritize the most beneficial offerings initially, therefore those teams could focus on maximizing the value of the existing application’s functionality. I advise our teams to begin by examining the external and internal customer touchpoints - the front end portal.
Taking a Lean approach allows for quick wins and visible value. When updating business processes and delivering enhanced customer-facing portals, Lean can serve product functionality. Lean limits back-end changes to legacy systems except for those that are necessary to support the portal, and improve the process. After each phase, a Lean team continues evaluating and implementing further improvements, eventually building a fully functional interface with modern technological capabilities. After the interface is built, the team can deliver additional system capabilities that did not exist in the status quo legacy system.
Being Lean means that the team enables new channels to enhance customer experience while mitigating risk, they produce a consistent view of data, and they document business processes and functional architecture.
As I continue my career in IT, consistently I find that there is great value in taking the incremental approach when updating legacy systems. Primarily this approach helps mitigate risks associated with large IT modernization projects while lean teams develop system capabilities to enhance the user experience.
As always, thank you for what you do for the Citizens of Nebraska each day.