There are several key principles that organizations can use to guide their efforts to replace legacy IT systems based upon a portfolio approach that allows the identification of priorities and effective allocation of scarce IT dollars.
Once an application has been identified for modernization, the focus shifts toward the successful delivery of its replacement. Unfortunately, the track record of many organizations (both private and public) is mixed, with too many examples of projects that have come in late at substantially higher costs (or, in some cases, not at all).
The challenge organizations face is how to approach projects in a way that improves their chances for success. While applying the formal disciplines of project management is fundamental, the single largest contributor to escalating project costs and failures is often the mis-alignment of project objectives and expectations across stakeholders.
Ensuring there is alignment between executive sponsors, political leadership, project managers and vendors, and a common view of “what defines success,” is a critical exercise that needs to occur early in any new project – ideally before it is even approved.
A good starting point is the creation of a set of standardized (and agreed upon) project type definitions that quickly convey the nature of a project, its scope, and the associated organizational change that may be required as part of implementation. Three definitions are used here based on past experience.
Direct replacement
At times, the best option is to replace a legacy application with a modern solution designed to provide a near identical set of functionality. This new solution should leverage new technologies and architectures to improve robustness and maintainability, but the services it provides should not change in any significant manner. These projects are best suited when a core legacy system is surrounded by a large number of applications that are expected to remain in place.
While the risk associated with these projects is generally low due to the known quantities of the legacy system, it is important that the assumption that surrounding applications will remain largely unchanged be maintained throughout the project. Direct replacement projects run into difficulties when the scope of the project begins to expand into surrounding applications or when changes to core functionality are made. In cases where the life of a legacy application has been extended by “bolting on” elements such as screen scrapers or terminal emulators to enable interactions with modern systems, a replace and extend approach may be more appropriate.
Replace and extend
As legacy applications often lack the ability to support modern interfaces (such as SOA) and critical capabilities (such as privacy, security and web accessibility), elements frequently have kludged together to emulate this functionality. If the organization does not plan to make significant changes to its business processes or the way it delivers client services, then a replace and extend approach should be used.
Similar to a direct replacement, the objective is not to significantly change core functionality but to incorporate modern capabilities directly into the new application as it is replaced. These projects will be larger than a direct replacement as they often result in changes to surrounding applications, which must be considered when developing estimates. While this does increase the level of implementation risk, operational risk will be reduced once the solution is in operation.
Like direct replacement, these projects can run into trouble when functionality changes are added to the scope of the project. This is commonly seen as the “while we’re at it” problem.
Business process transformation
If, however, the organization has decided that a more substantial change is needed to the way an application functions, it must consider changing the surrounding business processes in parallel with the application itself. Process redesign and organizational change management are often missed when technical estimates are created, yet they represent a substantial effort.
While these projects can result in significant operational savings, they are by far the riskiest as the scale of transformation can vary widely. So focusing on early stakeholder alignment is even more important.
By using a classifying framework, organizations can better recognize the risks where changes in underlying assumptions can alter the fundamental nature of a project, often leading to substantial increases in cost and time.
Kelly McDonald is a manager in Deloitte’s Systems Integration, Application Modernization and Technology, Media and Telecommunications consulting practices (kemcdonald@deloitte.ca).
