Legacy Software Replacement and the Importance of Requirements
Legacy systems drive the need for software requirements, mostly for system retirement, legacy replacement, and legacy migration. And I have seen expensive and high profile legacy system replacement projects flounder and come uncomfortably close to disappearing forever into the “bright lights that beckon to a deep and everlasting peace” on the basis of one factor alone: performance.
To put things in perspective, I am not talking about ridiculously slow response times that drive you to drink and elicit incredulous looks from your coworkers when you tell them “No, team, this is not the beta, it is the final version and it launches this weekend.”
I am talking about 5% to 15% increases in the amount of time it takes to execute certain functions or tasks; not ideal, but certainly not something that at first glance looks like it could cripple a project. But those performance issues can kill your project dead.
4 Reasons Performance is an Issue for Legacy System Replacement Success
1. Slick and Modern Does Not Always Translate to Easy-to-Use
Once mastered, keyboard-driven system interaction and data entry is incredibly fast. Mouse-driven interaction is inherently slower and in my experience will never be faster than the lowly keyboard in most legacy data entry scenarios. I’ve seen many legacy users who can create sales quotes, receive payments, create new accounts, and do a thousand other things without ever looking at the screen. I mean that very, very literally. (Try placing your next online order without looking at the screen and tell me how that turns out for you. You get the idea.)
Paradoxically, in replacing the legacy users’ “ugly green screen” with your “modern Web 3.0 UI” you have actually made the system harder to use! Easy-to-use in this context means, “how quickly can I do something no matter how convoluted and crazy the steps you are asking me to perform are?” This is a game that the slick interface is going to lose every time.
You have to think of easy-to-use very differently in this context. Time to perform a task (the proxy for performance) is the driving factor in legacy users’ experience of ease of use.
2. 10 Seconds Here, 10 Seconds There, and Soon We Have a Real Problem
Small increases in time add up in the course of a day, week or month. Depending on the specific areas of your application that are slower, the real impact or perceived impact of performance could be more acutely felt.
Organizations are very carefully staffed and in many cases, small changes in the time it takes to perform common tasks can very easily upset overall staffing dynamics. A 10% increase in transaction time that is a non-issue during the “slow times” of a business can become a killer at the end of the fiscal quarter or fiscal year as the volume spikes and as people struggle to perform their assigned tasks before the clock literally runs out on them.
Right or wrong, if the new system is slightly slower in some areas, you are going to be the “dog that ate the homework.” If things go wrong, someone will get blamed; it’s just human nature.
3. "I thought you said this stuff was better than the old junk!"
“Better” means that the users expect everything about the new application will be, well, better. Including how well it performs. This too is human nature.
Add to this the fact that almost every new application is way oversold and overhyped; I am not certain, but I guess this is also human nature. You put these factors together and expectations are sky-high across the board. So, when performance lags even a little bit in some areas, it is immediately noticed, cataloged and commented upon. Endlessly. This is, alas, also human nature. Our slick application is not going to escape human nature.
4. "I hurt like heck today."
Performance issues impact user perceptions right here and now. From the second your user fires up the application and starts using it, they see the issue, feel it and experience it. If they perceive there are performance issues, they are hurting today.
The benefits of the new application may or may not be available today. The first release of most legacy replacement applications typically only delivers feature parity. This is reasonable and a sensible approach to introducing new solutions. This is especially true when you are replacing something that is mission-critical, which most legacy applications tend to be.
The upshot of this is that the benefits of the new platform – the cool new features and capabilities – will only be available down the road. The good stuff is coming tomorrow. The users’ perceived pain is today. So, your user complains more today. They throw a fit today. They make your life miserable today. This is also human nature.
Legacy Software Replacement Requires Proper Planning
The combination of pain and perception of poor performance begins to eat away at the project. A task force is created to look at the issue. Suggestions are made, rejected, approved, debated and bandied about. Pretty soon the focus is gone from how great the solution is, to “fixing it.” The bloom is off the rose and now we are just left with yet another application that seems to be having performance issues. Fix it or else…
In the next installment of this series, I will talk about the typical reactions of project teams when confronted with this issue and where it usually leads them.
