Here's a common conversation in the tech industry:
Customer: We'd really like a fix for this issue.
Vendor: We've fixed the problem in version 11.0.8.7. If you upgrade, your issue will disappear.
Customer: Um, maybe you're not aware of how big a deal an upgrade can be. We have customizations, and it takes time to upgrade them, not to mention the infrastructure components that need to be upgraded and tested...
Vendor: Not to worry! In a few weeks, we'll be releasing version 11.0.8.8 SDK, which will include productized versions of some of the functionality that your customizations provide. You won't need to maintain these extra bits of code!
Customer: Really? I can quote you on that?
Vendor: Sure. As long as you read the small print absolving us of any responsibility for functionality we don't deliver.
Customer: What did you say?
A recent CIO Magazine article on the difficulties of ERP implementations got me thinking about this issue. One of the chief villains in this story, according to the CIO Magazine writer, is customizations. Upgrade the system, and you also need to upgrade the customizations. In a system as complex as an ERP system, upgrading the customizations never goes smoothly.
So who's really to blame here? Do we point the finger at the vendors, who make products that require customizations in the first place, and who don't prioritize the feature Make upgrades easier highly enough? Or are the customers paying for their laissez faire attitudes towards customizations, some of which may not have been strictly necessary?
To do a decent job of answering these questions, real research is necessary. Meanwhile, we can do some informed speculation. Even if the overall calculation can't be accurate, even a back-of-the-envelope estimation might reveal which aspects of the upgrade process matter the most. And by matter, I mean, will cost the customer time and effort during the upgrade. Identify the critical factors, and you also can tell who bears the greatest responsibility for whatever problems exist.As with any such exercise, there are plenty of variables that you might consider, but only a few you can consider. We're only making a rough guess at something, so complexity, beyond a certain point, doesn't add anything. We want to arrive in the neighborhood of the truth, not build something so complicated that it never gets out of the garage.
Here's the list of variables I used for my own seat-of-the-pants calculation. Again, we're only considering the customizations, not all the other aspects of the upgrade:
- Number of existing customizations. This variable represents the customizations that the customer had the opportunity to discuss with the vendor.
- Number of new customizations. To be fair to the vendor, we have to acknowledge that customers are always thinking up new customizations. To be fair to the customer, the world changes (new business processes, new technology components that must be integrated, etc.), which compel them to write new customizations. Even if, during their last meeting, the vendor acquired perfect knowledge of the customer's set of customizations, that set is likely to have grown since their last conversation.
- Average time, per customization, to upgrade. I haven't decided to count customizations by feature points, function points, story points, or something else. I just know that points are involved.
- New functionality in the next release that replaces some fraction of the customer's existing customizations.
- Risk that the vendor will not deliver this new functionality (customization relief?) in the next release.
- Additional functionality in the next release that does not make customizations obsolete, but which do add overhead to the customization. The "You didn't ask us for it, but here it is" problem is commonplace in the tech industry.
- Average ease of upgrade, per customization.
- Average time, per customization, to handle additional overhead (change management stuff, such as training). This variable applies to all new visible functionality, whether the customer asked for it, or not.
Plugging some sample numbers, representing a fictional ERP implementation, into the calculation gave me a baseline. From there, I started cutting each value (number of customizations, difficulty of upgrading, etc.) in half, just to see what would be the effect of simplifying each element.
At this point, if I haven't said it enough, I'm just thinking aloud, so for God's sake, don't quote me. However, it seems as though the variables that matter most include:
- Average time per customization to upgrade. While customers might get better at doing customizations, vendors can invest in ways to simplify them. (If you've ever had the agonizing experience of seeing customers struggle to preserve customizations to a badly-designed web UI, you've seen at least one possible area of improvement.)
- Risk that the vendor won't deliver promised functionality that will replace customizations. Yes, customer complaints about the vendor's roadmap are justified. Vendors think in terms of releases, which are either fantastic, or slightly less fantastic than promised. Customers think in terms of projects, which will take either X weeks, if you believe everything the vendor tells you, or X plus some unknown number, if you want to look at vendor claims with a justifiably skeptical attitude.
- The number of customizations. On the other hand, it's definitely fair for vendors to push back on the number of customizations. How many of them represent something that the customer felt was important earlier, but nobody uses now? How many of them filled a genuine gap, but did so in a clunky way that's hard to maintain?