All projects encounter rocky roads at some point. But when a massive and expensive legacy project threatens to screech to a halt, the question inevitably arises: Kill it or keep it? The consensus among many experts is most legacy projects can be salvaged.

Pulling the plug
The reasons for killing a legacy project vary according to the project but typically include the following five:

  • Failure to meet project goals
  • Excessive costs
  • Changing market conditions
  • Wasted human resources
  • Pressure from customers dissatisfied with progress

Yet pulling the plug on a legacy product can ultimately cause more problems than it solves, warns Howard Kanter, an expert on legacy systems and associate professor of MIS and accounting at DePaul University in Chicago. For one thing, it’s easy to view the economics of the decision in the wrong light. “It could be a monumental mistake if a legacy project is halted to save $80 million when $20 million has already been spent, for example,” Kanter says. “It could also hold up other projects in the wings.”

Frequently, the decision to terminate a project is handled poorly. For example, many project managers fail to communicate the reasons for the decision—which is a major mistake. Everyone involved with the project has a right to know why decisions are made. Failing to inform them can create morale problems that can ultimately lead to a drop in productivity.

William Ulrich, author of Legacy Systems: Transformation Strategies (Prentice-Hall; $44.99) and president of Tactical Strategy Group, Inc., a management consulting company in Soquel, CA, says there is rarely justification for pulling the plug on a legacy project. “If a legacy billing system accounts for 90 percent of revenues, there is no reason to kill the project. Shut it down and you won’t be able to collect your billing. It takes time and money to launch an alternative system. You can’t imagine what that could cost a company.”

Focus on the business value
According to Ulrich, the most common mistake in dealing with legacy projects is failing to focus on important issues. Rather than concentrating on IT’s failure to manage or maintain a system, focus on the more important business value of the application—what it delivers to the business—as well as whether it justifies migrating, updating, and documenting those systems.

”If you shut down a system or try to rebuild it, you’re almost guaranteeing failure,” Ulrich warns. “If maintenance costs alone are considered and decisions are based solely from an IT perspective, you’re not going to make informed decisions. If you’re not careful, IT can be the culprit responsible for shutting down a legacy project.”

Kanter and Ulrich advise carefully managing and controlling a legacy project so you never get to the point where killing it, for whatever reason, is considered. Kanter advocates a “developmental life cycle methodology.”

“You need system implementation so you can stop along the way and assess the project,” he says. Ask yourself the following questions:

  • Have we accomplished our goals?
  • Should we be further along?
  • What are we doing wrong?
  • Are we under or over budget?
  • How can we improve the project?
  • Is there a typical issue or problem that crops up?
  • What is the best way to solve it?

One single person should never handle the assessment process. A steering committee should monitor the project so objective decisions can be made every step of the way. It’s all about making smart decisions. “As the legacy project progresses, you should be getting smarter,” says Kanter. “If you’re not, you’re doing something wrong.”

Understanding the system
Ulrich advises exploring the software tools on the market for monitoring legacy projects. They’re designed to improve legacy systems so they are manageable and maintainable.

“There are few legacy systems that can’t be understood, maintained or upgraded,” Ulrich says. “Many people go off half-cocked and fail to understand the disciplines that can be applied to deciphering these systems.”

In fact, for many complex systems, rewriting them only leads to confusion. “Often, you don’t know where to begin because you don’t know what the system does,” Ulrich says. “To begin to understand it, you ought to start at a high level and break the system down into subsystems and programs.” The more control you have over a legacy project, the greater the understanding. Otherwise, you won’t catch problems, and you won’t know where to make changes along the way.

Logic management 101
Metrics and controls are great, but most legacy projects go the way of all flesh because of poor project management, according to Skip Sanzeri, CEO of XML Alliances, a legacy application and integration company in Redwood, CA. “It’s a simple case of Logic Management 101,” he says. “Project management has to do with understanding the level of details. If you don’t pay attention to them, and what they mean, problems only accelerate.”

The problem with most legacy projects is IT managers don’t pay enough attention to setting them up properly so all parties work well together to meet goals.“ The heart of project management is mastering the details,” Sanzeri says.

Most legacy projects—all projects, for that matter—fail because of people issues, according to Sanzeri. “They’re seldom technology problems,” he says. “Given enough time and resources, anyone can solve problems with the right technology.”

What’s needed to ensure the success of any legacy project is input from every person connected to the project, including project managers, senior managers, end users, and often consultants, who provide objective readings along the way. In short, unless your company folds or radically improved technology makes killing a legacy project essential, your goal is to keep the legacy fires stoked.

Killing the legacy

How do you handle lingering legacy projects? Do you agree it’s vital to keep them alive, or should they sometimes be scrapped and replaced? Drop us an e-mail or post a comment below.