In-Depth

You've Been Left a Legacy—Now What? (Part 2 of 2)

IT modernization projects help you deal with old application ghosts before they spook the bottom line. We offer seven best practices for controlling and managing a project

• By Ed Olmstead
• 07/26/2005

You’ve decided to finally do something about modernizing your old legacy applications, you’ve audited your current IT assets, you’ve built a bullet-proof project plan, and gained management’s commitment—now the trick is to carry it off without a hitch. Sounds simple enough.

The good news: if the plan was done right, it can be a relatively hassle-free project. The bad news: if you let down your guard now, disaster is lurking in every line of code. This week I'll discuss how to manage your modernization project to virtually guarantee success.

After a thorough plan has been developed and approved, the project focus shifts to management and control. At this stage, several important considerations can assist in the management and control of the modernization effort.

Best Practice #1: Justify All Scope Changes

Change happens, no doubt about it. This can result in rework, delays, and cost overruns, so be prepared for a little triage. Project scope changes fall into three categories:

• Required changes, including maintenance fixes, regulatory changes, market changes that demand a competitive response. The project plan should contain time and budget to accommodate this type of contingency.
• Enhancements can quickly impact cost and schedule once your project is underway. Evaluate them closely. If a thorough plan has been created, these changes should not be critical to the success of the modernization. Once the modernization is complete, these changes can be re-evaluated and implemented as separate projects, possibly using new tools established during the modernization effort.
• Cosmetic changes do not change the functionality of the application. They include changes to the presentation of data or application navigation and can often be accomplished for little cost and with negligible impact on the project schedule. These changes can add significant value without a major impact on cost or schedule. Remember however, that cosmetic changes could impact testing and validation methods used for verification.

Justifying changes in the project scope requires a well-defined change management process. Each change request should be documented, categorized, costed, and its schedule impact evaluated. At periodic project status meetings, each requested change should be discussed and either accepted or rejected.

Best Practice #2: Break the Project Into Clusters

Armed with all the system assessment reports, project scope, and objectives, it should be relatively easy to determine how the system breaks into natural segments and subsystems. There will likely be a logical order, maybe some common routines will need to be modernized first, well before anything can be tested. When developing these clusters, remember:

• The impact application freeze time will have on the project and the business. By selectively grouping applications for modernization, freeze time can be reduced and in some cases eliminated.
• To effectively deploy implementation clusters, some bridges/interfaces may be needed between the “old” and the “new.” Bridges must be carefully designed to insure proper synchronization of systems that for some period of time may be running on different platforms or databases.

Best Practice #3: Think of the Effort as Multiple Projects

It is quite possible that you can use multiple modernization approaches on the same project. One portion can be non-invasive, another might be migration, while part of the project will be reengineered. As long as you understand how the parts relate to each other, you can focus your modernization efforts on those with the greatest impact on results.

Best Practice #4: Use Your New Tools Along the Way

As each stage of the project is completed, you are in a new position and should consider what new tools you may have at your disposal. For example, once you move to a new platform, you can reengineer applications at a more controlled pace using the new tools available on the target platform. The testing effort also provides an effecive introductory training platform for your staff.

Best Practice #5: Consider Doing a Pilot/Proof of Concept

Your pilot should use a representative sample of code and business processes that can be implemented in the new environment and have measurable results you can use to develop metrics for the remainder of the project. The IT Audit and Global Assessment should identify the best and most inclusive candidates for a pilot.

Best Practice #6: Identify New Architectural Changes

This is a critical consideration, especially since changes can increase project cost and complexity. Some modernizations are simple, some are much more challenging, and others are simply not worth attempting to automate in any way, regardless of what a vendor might claim.

A good example is the effort needed to translate a document from English to another language algorithmically. English to French can be done with reasonable results. English to Chinese is not so simple due to a much greater difference in the language architectures. One can be done to a reasonable degree using automated tools; the other can be done in theory, but the result may not be very usable.

Similarly, converting from a mainframe to Windows using COBOL lends itself to an automated approach. However, the architecture of the two environments is quite different. The mainframe is a multi-tasking, multi-user environment, while Windows is multi-tasking, single-user OS. This difference makes the replacement of OLTP monitors a difficult choice.

All computer environments are not the same; some have completely different architectures that present more complex challenges to modernization, making it extremely important to choose the correct modernization method.

Best Practice #7: Select the Right Resources

Selecting the right resources to support a modernization effort is essential to its success. Most companies do not have sufficient resources in-house with the unique skills that modernization projects require. The typical modernization project calls for supplementing the internal staff with consultants having the specialized experience gained through many successful implementations of this type of project.

Nonetheless, the selection of internal resources to support the project is important. The prospective project team members must possess a thorough working knowledge of the source platform and the applications selected for modernization. They must “buy in” to the project and accept the changes to current processes required in the new environment. Resistance to change on the part of a single team member can severely impede project progress and demoralize other team members.

Be sure to broaden your representation. Business-unit personnel should be included on the team along with IT staff. This is an enterprise project, not an internal IT initiative.

The consulting partner you select should also provide proven software tools to automate most of the modernization effort including: the inventory audit, platform migration, application migration, database and language migration, testing, and validation of results.

When selecting a partner, look for successful large-project management experience. Software modernization tools, staff experience, and prior successes are the important considerations when evaluating an IT consultant. Remember, however, that you are evaluating more than just a company—you're evaluating the individuals who will support your project.

Follow these best practices and your chances for success will greatly increase while your risks will be significantly reduced.