There is ample evidence that, in general, “software customizations are bad.” (So much so you might have nightmares where software customizations are vampires, haunting you, refusing to die in peace.)
But consider the other side of the coin: the risk of an organization going along with canned software functionality. This can downgrade an organization’s business practices to “average,” causing them to lose out on opportunities to improve performance.
Tweet: The Case for Customizing Software |
#ITprojects @MPapov http://ctt.ec/Uo30y+
It is true that the business always complains about functionality gaps in software and 80% of those complaints are noise. This means 20% of complaints are constructive. By understanding these complaints, you’ll see that performance-enhancing software improvements are definitely worth implementing.
Two Classic Excuses to Stop Customizations
There are typically two reasons senior management will give you as to why software should not be modified:
1. The first reason is this excuse: “If we make a change for you, we will have to accept change requests from everybody, and that would be wrong.” You see, these managers are still haunted by those customization vampires in their nightmares.
2. The second reason for keeping canned software functionality is that the software supposedly was designed based on “industry best practices,” which we presumably should adopt. Valid point. Most software you buy today was created based on input from dozens of organizations and so should fit yours. Well, it will match your business process as much as your business process matches that of your competitors. What about being better than the competitors?
Improve Upon “Best”
There is a simple answer to both of the excuses above—institute a transparent process for the evaluation of software changes and software replacements. Performance benefits will then drive decisions and keep politics out. Best practices will only become “bester.”
One might say that this is a lot like a SDLC process, which most large organizations already follow. Yes, I might be talking about that very SDLC process—as long as it is truly transparent, aligned with strategic business objectives, lives outside of IT, and actually checks the employee suggestion mailbox once in a while!
Tweet: The Case for Customizing Software |
#ITprojects @MPapov http://ctt.ec/Uo30y+
