Article by Thomas Bertels & Dennis Glacken
While transformation is often the stated goal of efforts to replace a legacy IT system, only a small percentage of these efforts will actually deliver transformational change. Many experience budget overruns, missed timelines, and requirement cutbacks. This article outlines some of the typical pitfalls and offers practical recommendations to minimize the pain and increase the return on investment of such projects.
Overview
Replacing a legacy system is more challenging than creating a brand-new system:
- The complexity of the current system is often not well understood. Many of these systems have grown in complexity over a long period of time, often with numerous additions and customizations. It is not unusual to find legacy systems that have been in place for thirty years or more.
- Experts are in short supply and may not even exist for some aspects of the system being replaced. Almost always, the original architects and programmers are no longer around. If documentation exists, it is rarely up to date.
- Users are unwilling or unable to challenge the current process. No matter how antiquated or limited the legacy system is, it works and is crucial to support an existing workflow. Changing an established process is a significant change management task. The need to provide convincing benefits to users to get them to adopt the new system and accept changes to the current process (and their role in it) is often underestimated.
- The transition from the old to the new system needs to be seamless. Besides making sure not to miss a beat when flipping the switch, the transition often requires duplicating staff – an extra cost just when the budget is nearly depleted and senior management is counting on the team to deliver the benefits.
This article provides a set of recommendations based on the authors collective experience and lessons learned from helping large, complex organizations replace legacy systems. None of these ideas are silver bullets.
Get management on the same page
It is often assumed that the senior management team is on the same page as to what the project is about and understands the problem the project is supposed to solve. But when interviewing the key stakeholders of a large-scale effort, the simple question, “What is the goal of the project?” often reveals that those guiding the project are not on the same page. Not taking the time to ensure the executive sponsors are sufficiently aligned is a dangerous shortcut and a common theme for projects that are in trouble. A simple alignment exercise focused on helping the senior team to agree on a finite list of SMART (specific, measurable, attainable, relevant, and time-bound) goals for the project, which are revisited periodically, can do wonders to help executive sponsors get and stay on the same page throughout the course of the project.
Challenge the current belief system
Oftentimes, the system that needs to be replaced has over time grown to support the increased complexity of business requirements. Rather than automating the current complexity, eliminating it where possible is a better strategy. This means challenging the status quo. A decision to combine departments or distribution channels, buy customers, vendors, or employees out of old contracts, simplify pricing or discounts, changing corporate policies, or trim the product portfolio can make a big difference. These types of decisions are made at middle to senior levels of management. Decisions that challenge the current belief system take time and are best made before big teams and budgets are put in place.
Fix the process first
One of the implicit assumptions of almost every project is that it does not make sense to invest scare resources into streamlining processes prior to implementing the new system. “The system will take care of that” is the dominant belief. When asking why the company is investing in a new system, you will often hear a list of problems with the current system: invoices contain mistakes, people are paid wrong, it takes too long to process a claim, or the system does not have the information needed for critical business decisions.
Although all of these types of problems can be solved with new systems, they can also be addressed through focused process improvements. Not only are these upfront process fixes less costly and quicker to implement, but they also create learnings that can be used in the IT system implementation effort, free up subject matter experts, and extend the life of the existing system.
Another benefit of fixing the processes first is that it puts the work and the people that perform the work in the center. The application is just a tool that people use to do their jobs. If the people and the work are at the center, then many different options can be discovered for meeting business needs. Once the project is started to replace the current system, the application becomes the center of every diagram and every conversation from that point forward. Once this shift happens then the team looks to put the solution to every problem into the application. This shift from work-centered to application-centered starts the project down the path of over-engineering.
Plan for imperfection
Nothing ever goes 100% according to plan. Agility is critical and needs to be designed into the project plan to create the capability for learning and course adjustments. At the very least, formal project reviews every six months with the project’s steering committee provide an opportunity to step back, reassess the original plan, and make intelligent course corrections. Often, there is a tendency to hide bad news and report the project status as green, while the schedule is slipping. It can make sense to have a neutral third party facilitate the conversation to ensure objectivity. To make good use of such a review, the steering committee members must be prepared for bad news and view its role not as critics but as active problem solvers that play a critical role in making the project successful.
Know and manage your constraints
Just as every factory or business process has a constraint or bottleneck that determines its throughput; project teams have bottleneck resources that limit the team’s throughput. Bottlenecks occur when one link in the chain of activities is not capable of keeping up with the volume of work they are receiving. In a factory, bottlenecks can be identified easily – one typically sees a stack of materials waiting for a single operation. Well-run factories know what machine or process step is the constraint and manage accordingly, focusing their attention to improve the capacity of the rate-limiting factor.
The same logic applies to projects: For example, insufficient programming resources can impact IT test teams, business test teams, business analysts, SMEs, project managers, other programmers, and a host of other projects. A delay in a constrained resource on a large IT project often has a cost multiplier effect of 10x or greater.
In addition to good planning, the trick with large projects is to know at any given time where the constraints are and to make adjustments quickly, minimizing the damage that one or two constrained resources can cause to a multi-million dollar project budget. Doing so requires empowering the project leader to make resource decisions.
Staff the project correctly
Staffing the project correctly is not just a function of having the right number of people, but having the right people:
Keep the team size as small as possible
Many projects are overstaffed in dollars but understaffed in skills. Fred Brooks groundbreaking book, “The Mythical Man-Month”, was published in 1975, but its insights are still valid: keeping the team size small is critical to ensure the project will meet timelines and deliverables.
Identify and dedicate the real Subject Matter Experts (SMEs)
One of the most critical decisions for any project is deciding who will provide the requirements. They will make countless decisions that impact timeline and cost. Missing requirements, or more likely over-engineering requirements, can de-rail even the most carefully planned project. Picking the right SMEs, managing them, and making sure that they are dedicated to the project is crucial, and often overlooked. Those who will ultimately use the software tend to be low on the totem pole. There is a danger of selecting managers who are not involved in the process, or the usual suspects, who are part of every project, instead of the smartest workers currently doing the work. “The key is to have SMEs that have a vision for the future process, have the skill to make timely decisions about how the new process will work, and have the wisdom to realize that rather than spend resources automating every special situation, those one-off exceptions can still be handled manually,” says Don Castle, a partner with Tatum (previously CIO at Nabisco International, SGS North America, and Global CIO of Johnson&Johnson’s Medical Device Companies.)
Make sure the Business Analysts (BA’s) have the right mental model
Bridging the gap between those using the current system and management’s desire to transform the business requires that SMEs be complimented with BA’s operating with the correct mental model. One key question you want to ask yourself early on: What level are the people at who are defining the requirements for your next system operating at? BA’s tend to operate in any one of four modes:
- Scribes write down what is told with little understanding
- Students take notes and ask questions, but only to ensure their understanding is correct
- Partners not only documents but is an equal in discussing how the new system should work
- Guides take SMEs through a process to arrive at better solutions, use data and facts to select between alternatives, and use their training, skills, and experience to help the organization get to where it wants to go.
Make sure your project is supported by a team of business analysts that are up to the task of guiding management and users towards making informed decisions.
Save some budget for the end
Too often, critical requirements and important capabilities are being sacrificed as time and budget are running out. Instead of cutting at the end, make careful cuts all along the project to ensure that funding is still available to do those things that deliver the most value for the company.
Summary
Imagine a project where the leadership team agrees on a realistic set of goals, the current business model is challenged and simplified, users are engaged in streamlining the process, a PMO anticipates imperfections and manages constraints proactively, the project team is staffed correctly and towards the end, funding is still available, making sure key functionalities do not need to be sacrificed. Avoiding the pitfalls outlined in this article is possible and can yield substantial returns.