In a recent conversation at a client (thank Jen Wimberly!), I heard a phrase that I think  should be added to the IT lexicon – CUBAR or CUstomized Beyond All Recognition.

Often times, we implement a “package” or COTS (commercial off the shelf) software package only to tailor it to meet our needs. That’s good – we shouldn’t have to bend our business process or rules purely to meet the needs of a software package. But, at the same time, we shouldn’t just make whole-scale changes to a software package to a point where it essentially becomes a custom solution.

I’ve often advised clients that if they find a software package that isn’t at least an 85-90% fit with their needs, they should consider other solutions or building something from scratch. Why shouldn’t they buy something even if it meets 50% of theirs needs? Because ultimately it gets CUBARed:

• Making changes can be hard, often using proprietary frameworks or code that you have to work through; this limited amount of control can go from frustrating to just plain limiting – when you have to create extensive work-arounds for something fairly straight forward you should do more than just shake your head
• All of your customizations have to be maintained by your staff – and it’s often poorly documented, keeps you from being able to update the package and usually leads to poor data quality; on top of that, you usually have to invent your own processes and governance controls for the customizations
• Your customizations are often likely to result in unintended side-effects – such as creating security holes you didn’t know about, resulting in performance problems, etc.
• And, of course, customizations often require the skills and expertise of outsiders – that charge a lot of money and all the knowledge walks out the door after the implementation

This isn’t to say that all customizations are bad. But beware the CUBAR – it essentially creates an inflexible, impossible to upgrade, slow performing mess of a solution that could have been done differently.