I've seen this happen more times than I can count.
An organization decides an old system needs to be replaced. The existing system is slow. It's difficult to maintain. People have created spreadsheets and workarounds to compensate for its limitations. Everyone agrees it's time for something new.
So the organization spends months selecting a new platform, implementing it, migrating the data, training employees, and finally going live.
And when everything is finished? They've recreated almost exactly the same process they had before.
They bought new technology. But they kept the old thinking.
“The Old System Did It This Way”
This is one of the most dangerous sentences during any modernization project: “The old system did it this way.”
That statement isn't necessarily wrong. Understanding how the existing system works is important. But it should be the beginning of the conversation, not the end of it.
The next question should be: Why did it do it that way?
Sometimes there is a very good reason. There may be a regulatory requirement, an accounting control, a customer commitment, or a legitimate business rule behind the process.
But sometimes the answer is simply: Because that's what the old system required.
And that's a very different thing.
Workarounds Have a Way of Becoming Requirements
Imagine a system implemented fifteen years ago that couldn't automatically send information between two departments.
Employees solved the problem by creating a spreadsheet. Every afternoon someone exported data from System A, cleaned it up, put it into the spreadsheet, and emailed it to another department. Someone in that department reviewed the spreadsheet and entered the information into System B.
Not ideal, but it worked.
After years of doing this, something interesting happens. The spreadsheet becomes part of the official process.
Documentation gets written around it. Employees are trained on it. Managers expect it. Maybe somebody even creates reports based on it.
Eventually the company replaces System A and System B with modern platforms that can communicate directly.
Now comes the critical question: What happens to the spreadsheet?
You would think the answer is obvious. Delete it.
But that's often not what happens.
Instead, someone adds a requirement to the new system: “We need it to generate the spreadsheet.”
Why? Because that's how we've always done it.
We have taken a workaround created because of a limitation in the old technology and turned it into a requirement for the new technology.
Requirements Need a “Why”
This is why I believe one of the most powerful questions in technology and Product Management is also one of the simplest: Why?
When someone says, “We need this report.” Why?
“We need this approval.” Why?
“We need this field.” Why?
“We need users to enter this information.” Why?
“We need the new system to work exactly like the old one.” Why?
This isn't about challenging people for the sake of challenging them. It's about understanding the business outcome behind the request.
If someone needs a report because they use three pieces of information from it to make a decision, maybe they don't actually need the report. They need those three pieces of information.
There may be a much better way to give it to them.
Don't Confuse Familiar With Good
There is also a very human element to this. People like what they know.
Even when an existing process is frustrating, employees understand it. They know its quirks. They know which buttons to push, which spreadsheets to open, and which shortcuts make it tolerable.
A new process introduces uncertainty.
So when organizations implement new technology, there can be tremendous pressure to make it behave like the system it's replacing.
That may make the transition easier, but it can also defeat much of the purpose of modernization.
Familiar doesn't necessarily mean efficient.
Sometimes the uncomfortable part of modernization isn't implementing the new technology. It's letting go of the old process.
Start With the Outcome
This connects directly to something I wrote about recently: Stop Automating Bad Processes.
Before automating something, understand what people are actually trying to accomplish. The same principle applies when replacing technology.
Don't start with: “How do we recreate what we have?”
Start with: “What are we trying to accomplish?”
Then work backward.
What information is actually required? What decisions need to be made? Who really needs to be involved? Which controls are necessary? Which steps exist only because of limitations in the old system? Which reports are actually being used? Which approvals add value? And which things are simply organizational habits?
Once you understand that, you can design the process first and choose how technology supports it second.
Modernization Isn't a Technology Project
This is where I think many modernization efforts get into trouble. They are treated primarily as technology projects.
Replace the database. Move to the cloud. Implement the SaaS platform. Rewrite the application. Build the APIs. Migrate the data.
All of those things may be necessary. But technology modernization without process modernization leaves a tremendous amount of value on the table.
If you move a bad process into the cloud, you still have a bad process.
If you rebuild an unnecessary workflow using modern APIs, it's still an unnecessary workflow.
If you use AI to automate a decision nobody needs to make anymore, you've simply created a very sophisticated way of wasting time.
New technology doesn't automatically create a better business. Better thinking does.
Before You Rebuild It, Challenge It
Whenever I look at an existing process, I like to mentally put every step into one of three buckets: Keep it. Simplify it. Eliminate it.
Some things absolutely need to remain. Some things still provide value but can be dramatically simplified. And some things exist only because they have always existed.
Those are the ones we need to be willing to eliminate.
That can be uncomfortable because eliminating a process often means questioning years of institutional knowledge. But that's exactly why modernization creates such a valuable opportunity.
You're already changing the technology. You're already disrupting the organization. You're already investing the time and money.
This is your chance to question everything surrounding it.
Otherwise, you may spend a great deal of money implementing tomorrow's technology only to recreate yesterday's business.
And that's not modernization.
That's just a newer way of doing the same old thing.
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/
