Why legacy modernization projects fail
Advice on how to how to steer your project toward Success
By Deanne Wertin
Information technology companies understand the potential value of technology projects, but their hunger to capture that value exceeds their ability to deliver successfully on the ideas and commitments that are being made.
As such, projects fail again and again. Consider:
- Overall project success rates vary from 24 percent to 39 percent, depending on the study and the type of technology project
- One in six projects (17 percent) result in a "black swan," completely consuming the business
- Fifty percent of projects of more than $15 million deliver only 44 percent of the value intended.
Why do legacy modernization projects so often fail?
Here's the bottom line: it's rarely about the new system, the vendor, the contract or even the methodology. It's about the large number of unknowns and about a lack of organizational capability; it's about the utter lack of infrastructure readiness, and the impact on a company's ability to execute successfully on even its best ideas. This isn't an information technology problem, but it becomes the CIO's problem pretty quickly.
Project failure statistics suggest that scope leakage--the work that isn't understood up front and for a variety of reasons doesn't get done--leads to projects that don't deliver the intended value. Worse, the underlying cause of scope leakage, a lack of understanding of the work to be performed, is insidious and affects the other pillars of a successful project--schedule and budget adherence.
How it Happens
All too often, the first thing required after getting project approval is to develop a master project schedule.
You have to define activities, dependencies, dates--all without having a complete understanding of the most important driver: scope. It's like agreeing to a cross-country drive without knowing where you will start the trip, the roads you should take or the equipment you will need.
If you've hired a vendor or business partner to execute the project, you are largely at their mercy--with their limited knowledge of your company and environment--to get this right.
It's no wonder that somewhere along the way you discover that you took a wrong turn and have to work your way back to the correct path, which affects schedule, cost and sometimes means you have to reduce the scope of your effort to address the other constraints.
Not failing is not success
Organizations often try to rationalize failure. But not failing is NOT success, even if you do enjoy the view along the way.
These are all just symptoms. The cause? A lack of focus on the "as is" environment--an overzealous commitment to a big bang solution that focuses on the "to be" environment without fully understanding the starting point and the work to be performed.
An organization replaces its old system for a variety of reasons--increased functionality, reduced maintenance costs, improved skills availability, and/or a desire for improved business efficiency. The old system worked well for a long time and there is still much that is good about it. But, that good is not well documented, the system isn't user-friendly and, occasionally, regulatory changes make it obsolete.
Organizations often can't do things the old way with a new system, but that doesn't mean the new system escapes from doing what the old system did. Unlike operational business processes, which can be streamlined or modified, core business rules, such as those associated with program eligibility, benefits and payments are still foundational to the system's functioning. It is important that these are accurately reflected in your new system.
The information within legacy systems generally informs the new solution design and subsequent development better than requirements and joint application development sessions. Often, organizations get so excited by the future vision--and so convinced by vendors that the best way to ensure success is to minimize the "as is" focus--that they forget about the incredible information asset they have.
Accurately capturing, configuring and programming the new system to implement these business rules--which number in the thousands for large programs--is no small feat. There is the issue of data and how the business rules process that data--rarely understood and often complicated.
Other issues include data stored in non-readable databases, so-called work-arounds to connect supporting systems, incomplete testing and even the need to find employees who have experience with the system.
Increasing Success Rates
There are lots of ways a company can address the knowledge gap and create a project foundation that can enable implementation of the new solution.
- Execute a "phase 0" to put that foundation in place.
- Modernize your client's database and convert the data so it will work well with your new application.
- Extract business rules and use them as a foundation for your requirements; they won't change, regardless of the business processes.
- Where needed, modernize code within systems that will interface with the new solution so that you reduce interface complexity.
These are simple and relatively inexpensive ways to avoid costly work-arounds, project delays and missed requirements later. Additionally, they increase your capability to manage vendors; you've reduced their unknowns as well and can hold them more accountable for the success of the solution. You shift risk to them by reducing the opportunity for exceptions and excuses.
Breaking projects into smaller pieces, with each informing the next, is another responsible and measured approach to new system development. Incorporating Proofs of Concept that use real data and real rules to determine solution fit is another. These are all affective at improving planning through gaining a better understanding of the project and avoiding scope leakage.
If you've created the proper project foundation and then use one phase to inform the next, you are less likely to incur schedule or budget overruns.
We all love the idea of a big-box solution with its promises of simplicity--but it just doesn't work that way. Avoid getting caught up in the "hype" of the new. Remember to focus on the foundation first, only then can you develop a solution that will truly commit to a scope, budget and schedule that will deliver the intended return and benefits.