How can I communicate the risks of altering vendor software?

Question

We have a major problem where I work, and it's name is "customization". We have an old (10+ years) vendor software system that our IT and accounting departments previously loved to customize. Somewhere along the line this software started getting very buggy. Then, I was hired after the bulk of the customization.

Nearly every problem I've found with the system is a direct result of customization; everything we change risks breaking business critical financial software. Yet the accounting department keeps suggesting changes (because we always said yes!) and there seems to be little respect for how impactful changes might be.

Some changes cause no problems; forms can be (and are meant to be) customized in the vendor software, we can move around form fields, remove them, ect. But for every harmless customization like that they also suggest changes like stored procedures and triggers to manipulate data in the database for the vendor application.

I recently (barely) got them to stop trying to import customers from one vendor program into another as the information was completely incompatible. My problem with how that was resolved is because I found the system didn't work on the user side; the task was more complicated than they thought so they gave up. Regardless of how easy the user-side task is, the operation they wanted shouldn't have been performed.

How can I communicate that changing how this system works has risks, particularly when data validity is at stake? I'm a new (6 months) hire and it's become the status quo, but it's risking the validity of our financial data and our support contracts--once the vendor's support hears "X has been customized" that gives them that much reason not to support us or tell us it's our fault.

Answer 1

The risk/reward of customizing systems is to provide a competitive advantage which allows your company to offer something differently than the other businesses in your space.

The larger organizations that I have worked with derive a competitive advantage from customization and in that mind set, they make them do things more efficiently, provide more features or make more money.

The fact that I communicate in these situations is that it is a trade off. In making these changes to a system, the organization is developing its own internal knowledge base/expertise of their systems that they won't be able to easily do with out. This internal knowledge base needs to be better maintained and organized so that these changes can be tracked and managed. It also means that it could invalidate vendor support contracts and other aspects that the IT assets that the company uses for this process.

The biggest risk I talk about is version upgrades to vendor software when a company adopts this data management philosophy.. This is one of the most likely risks where something is going to break. The company needs to understand the trade offs that are being made and everyone needs to be on board with the process that it takes to support them.

For your culture, you can introduce an analogy or philosophy but you need someone who is responsible for the business to realize that they are creating an environment that has even further dependencies on internal business specialist who make changes to these systems.

For the car analogy, its not the mechanic who needs to know what changes are being made to a car, its the owner who needs to understand that it may take special mechanics, more money or loss of that service for period of time. Educate the owner is the key to this conversation.

Answer 2

Communicating to office dwellers? I'd go with analogies.

Tell them that all these changes are turning your typical 4-door domestic sedan into an exotic foreign car. Every time you bring it into the mechanic shop, from the tune-up, to the crushed light, to the transmission overhaul, it's going to be more expensive. "We don't have the parts, only the dealer with special knowledge can touch that, we tried but the manual is in German".

You are the mechanic in charge of keeping it running. The database is the engine. The whole system is the car. The accountants drive the car around. The cute little bunny the accountants swerved to miss is an umlaut character in the last name of a new customer. The light pole they wrapped their car around is the critical bug that was introduced when they wanted to add a disco ball inside the car.

Answer 3

Others have provided some good examples of using analogies and other language to answer your primary question, which was "How can I communicate that changing how this system works has risks, particularly when data validity is at stake?"

But based on your clarifying comment about how the task assignment gets to you, I'm not sure that any analogy is going to help you in the situation -- it doesn't really seem that people misunderstand what they're asking for, but rather that they don't care. I've been there -- we've probably all been there -- and in these situations I tend put forth a greater effort to be perfectly clear as to the issues, rather than couch them in terms meant to teach rather than warn.

Focus on what you can do, which is not single-handedly changing the minds of everyone asking for customizations that put data integrity and vendor support contracts at risk, but instead is speaking directly to your CTO (and in turn, the CFO) and being very clear as to the issues at hand.

Specifically:

• Ask your CTO or CFO (or whomever holds it) to see the service contract with the vendor, because (and I'd say these words) you're being asked to perform tasks that are potentially in violation of the agreement and you want to be able to point that out in your task feasibility report. They might not give it to you, but saying those words has often made folks in those positions better understand that you're serious, and the situation is potentially serious.

• If you do get a copy of the agreement, then when you write your task feasibility report, quote directly from it when there is a clear violation.

• If you do not get a copy of the agreement, then make your reservations very clear as to how the change could put the company in a bad position as regards the relationship with the vendor.

• If your concern isn't problematic because of the vendor agreement but is"simply" problematic because of the cascading effects of the change, outline what that means: if it's as messy as you say it is, then you probably only have one or two bullet points before you can use the "and it will topple like a house of cards" line.

In short, do what you can to very clearly and concisely point out the issue and its effects even a step or two down the line. That you have the opportunity already to put a feasibility report in front of the decision-makers is a good thing; you don't have the structure or management support (or ethos) to say "I need you to sign this saying you understand that this is a bad thing and I do not recommend it and am not going to be responsible for the effects of this bad decision" (like you might if you were a vendor and they were a client), but you can still put a lot of things on paper that show you are considering what is in the best interest of the company and its assets.

Answer 4

If they are telling you to implement stored procedures and triggers - you have a major business process issue.

Your biggest challenge is to get users here to change how they think. They need to be providing you with the problem or requirement. For example, we need data moving from here to here.

It should be you who is implementing the solution with the least risk/most gain, and it is you who can do this in a manner which will help prevent future development issues.

Some control in the form of user sign-off or requirements, and then sign-off of the delivered development will also help. If the user has to take some responsibility/accountability for what they are asking for, they may think over it a bit more.

Answer 5

You seem to be implying your choice is between a risky implementation of a business requirement or none at all. It's rarely that black and white. I have a hard time believing accountants are directly asking for stored procedures, but if they are, you need to give them what they mean instead of what they're asking for. Find out what the business requirement is, then figure out the least risky way to implement it.

If your vendor isn't providing the hooks you need to safely implement the requirements your users want, then that problem is with the vendor, not your users.

Answer 6

You are basically developing software and as such you need a development methodolgy. How are changes documented? Tested? Deployed to QA? Deployed to production? etc. I think if you start coming up with a methodolgy and the costs associated with it they will start to understand. Perhaps the costs are well justified and you just need to implement a procedure so the car never wraps itself around a light pole.