If it ain’t broke, don’t fix it.

Have you ever had someone tell you that? Or some variation thereof? Frequently, as technology leaders, we are driving innovation at organizations, and with innovation comes change. For a person who knows their job really well, knows all their tasks, and exactly how to do them (even if they are painful or wasteful), asking them to change can be a challenge. We’ve all heard that classic urban legend of the employee who spent 7 hours each day tinkering with Excel, only to discover some macro or function that could do the task in 6 seconds. But if they know exactly how to do the tasks that take 7 hours, and it works and the customers are happy, then what is the incentive to do it differently?

So when looking at a large change (I’m not talking about just fixing a few bugs in the backlog, I’m talking about migrating an entire application or workflow to a new platform or system) how can you build the justification and convince the users, administrators, and maintainers, that this big change is worth it?

1. See the Big Picture….you might be making someone else’s job easier

One time, I was helping to install a new application for a customer organization that changed the way they did event management. It required all of the different stakeholders involved with an event to use a new system to coordinate on the event: venue, catering, vehicles, invitations, etc. I distinctly recall the stakeholder who managed the vehicle fleet was not happy. Why? Because to them, using email to just receive a request was easier for them than having to use a new webapp, and to them, this felt like “change for the sake of change”. But the general manager of the team gave a great response.

“You know what? Maybe you’re right, maybe this does take a few extra minutes for you each day, to have to check a web page instead of just watching your email. But for the event coordinators, for whom this currently takes hours and hours for them to write up all these emails to all these different people that they have to send requests to, this will save them many hours each week. So we are asking you to do a couple of extra minutes each day, to save these other people on our team hours each day.”

(OK, so in retrospect, we could have delighted everybody by just adding email support to the application, and in fact, we did in future versions. But this was the initial MVP/Beta release).

This was a great response and honed in on the fact that you are part of a team, and you have to work together for the common good of your organization.

2. There’s always room for quality improvement

Is it really true that it “ain’t broke”? There’s always something that can be done better. In fact, you usually don’t have to look very hard. Is your product backlog really empty? Were there really no outages, bugs found, user complaints, or anything recently?

Now I’m not just talking about picking one task and going and addressing it. I’m talking about taking a look at all these items above and having the conversation whether a complete migration or refactoring can address many of the issues identified in the items above all at once.

• Continuously hitting the edge of functionality for your app (i.e. mobile support, security issues, etc)? Look at switching to a new framework that provides the capabilities that you’re missing.
• Have tons of physical infrastructure issues, such as constantly having to upgrade networking equipment or buy new hard drives to swap out in your SAN? Look at moving your workload to a SaaS or IaaS provider.

Make a list of all the “pain points” and look for ways to aggregate them into high-level areas, and look at ways that transformation can address an entire area at once.

3. Your customers always want new things, and if they don’t get it from you they’ll get it somewhere else

One of the justifications for the resistance to this change is because there’s a “what’s in it for me” question. Using the Excel example above, the question becomes why bother changing if what I’m doing is meeting the need?

This is going to sound a little harsh, but this is reality. The answer might be because if you won’t change, someone else will. If you’re not willing to learn that new macro that takes 6 seconds, and then go help your organization or your boss get better, then at some point someone else will show your organization how this Excel task can be done in 6 seconds, and you’ll just be replaced entirely.

Companies and organizations have to evolve and move forward, and you have to choose whether to be part of that or not. Your customers are going to want your webapp to work on their mobile devices, and if you don’t provide a mobile experience then they’ll find another app provider that will. So you’d better learn the mobile userspace, and you’d better migrate your webapp to that new framework that provides a quality mobile experience.

A final word of warning: Don’t just do things for the sake of doing them. Deciding to rewrite your app in a different language just because that new language is “cooler” doesn’t make sense. Make sure you’ve spent some time thinking and doing the analysis of whether this particular change addresses enough pain points and customer needs, and can fix those issues all at once.