I am in the middle of my umpteenth system replacement project. There are some universal assumptions that are endemic to the user community in every system replacement project. They are born of hope and frustration. They are almost universal.
1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.
If you have ever done one of these projects, you know. They are assumptions that you must actively work against. They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true.
The new system will do *EVERYTHING* that the old one does, only better.
No two systems are aligned to have the exact same set of capabilities, and “better” is in the eye of the beholder. Unless the new system was designed specifically to replace the old one and the customer was willing to pay for “everything” & “better”, it is not likely to happen. Only once did I run a project like this, and it was a tremendous success. But it was a custom build replacing an existing custom build, which is rare.
The new system will support *ALL* of my existing processes and procedures without significant change.
In reality, this is not what you want. Your user community has been “working around” deficiencies in the existing system for a long time. That is why they are funding a system replacement project. Most likely, they have starved the funding of enhancements on the legacy platform, which just makes it worse. There are probably policies in place that are in part based on limitations of the current systems. Many times my “requirements” for a replacement system are actually, “Make my existing work around easier, better, or faster.” Significant change is required to yield significant improvement.
The new system will be *FASTER* than the old system.
It really depends on how you define faster. If faster means I get my work done faster, then yes. If faster is measured in response time or run time, then maybe. A Porsche travels three times as fast as a school bus, but holds 5% of the people. Which one will get the kids to school faster? Raw speed is not bad, it simply isn’t all you need. Operating leverage is what I call the “operational advantage” that allows a system to help reduce operating cost. Sometimes it is the system’s workflow – how many steps to complete some task. Other times it is how the data required to make decisions is displayed (the system is fast, but you spend your time calculating and figuring things out, because the system doesn’t). Sometimes the problem is scale, you can only support some number of concurrent activities, before the system capacity is exhausted. Sometimes it is scale of data, performance degrades in ratio to the amount of data that you are storing.
The new system will have *BETTER* data quality than the old system.
The old system’s data quality issues are the result of the policies and procedures you developed to ensure data quality. We used to say, Garbage In, Garbage Out. If you don’t invest in policies and enforce data input quality rules and calculate data quality metrics, then your data quality will not improve. You may not invest in those things in your current state, but I guarantee that your new system will not be materially better if you don’t invest going forward. Most of the time, data quality is less a function of the application system, and more a function of the discipline of the organization around it. Maybe the data quality perception is because your current system does not express or present the information you want to inform your decisions. Maybe the perception of data quality is influenced by the sources of your data. It assumes that you can qualify and quantify what BETTER means to your business.
The new system will address *ALL* the shortcomings of the old system.
The old system’s shortcomings are the difference between what you need it to do and what it was designed to do. Those shortcomings represent the change that has happened in your business, and your unwillingness to fund system changes to keep up with the business. When you decided to buy or build a new system, you probably devised a list of capabilities that you need and want. If the system you buy doesn’t have some of the capabilities you need, then there will be shortcomings. If you don’t fund the project sufficiently to build all of the capabilities that you need, there will be shortcomings. Every new system implementation is a compromise, no system that you buy or build will ever do everything that you need as well as you want. As a rule of thumb, a system you purchase should have greater than 80% of your needs (not wants) met in working code before you buy. You should recognize that the difference you will back fill with procedure and work around after you implement. A system you build (rather than buy) can launch meeting less of your needs, as long as you have a plan to fund the remainder, and a more graduated plan to migrate your business from the old to the new.