KISS

This post is neither romantic in nature or talking about the iconic 70's band by the name Kiss. Rather, this is about the good advice of KISS: Keep It Simple, Stupid.

Complexity is one of those paradoxical things that in business tends to be verbally opposed - but actions speak louder than words, and all of us in business have a tendency toward adding complexity just one bit at a time - draining the productive blood from the organization through a series of paper cuts. This month, Ken Keverian, Vikas Tenaja and Bob Victor of the Boston Consulting Group have an interesting article, "As Simple as Possible" [PDF Link] that has some intereresting food for thought on complexity.

While complexity can lurk anywhere in an organization, Keverian et al, seem to see most of it driven by a form of customer-responsiveness. This makes sense, it would be rare (and rather irrational) to introduce complexity for no reason. They provide three quick warning signs to look at your company to see whether you may have too much complexity. Do any of the following sound like your company?

Warning Sign Number One: We have 1,000 ways of discounting $100 to $98.
Warning Sign Number Two: Our customers hire outsiders to check for errors in our bills.
Warning Sign Number Three: 80% of our product codes generate just 5% of revenues but 20% of costs.

There are actually a couple of IT-related aspects when considering complexity, there's the need for IT to support business-rule complexity and then the issue of the more complex systems that are created (and must be maintained) as a result of supporting the business complexity.

The group actually points out the IT has tended to be an enabler for complexity. In many respects, technology is great for dealing with exceptional cases. However, the total cost impact of supporting so many exceptions is often poorly-understood. I remember a client I had in the early and mid-90's for whom we had created some extremely sophisticated systems to support a mass-customized information service offering for their customers. I can remember frequently hearing the line, "It shouldn't be a big deal, we only need to support this for 5% of the (customers/data/etc)," to which I always needed to remind the president that the cost of supporting the customization via automation was basically fixed, whether 1% or 99% of the transactions were affected by the custom code. Seems obvious, but you might be surprised how often we all fall into the trap of discounting the cost of supporting minor variations in process.

And even in cases when the complexity moves slightly away from IT and into the business, the systems-driven complexity is still there. For example, most enterprise systems support price list variations down to the ship-to address level - multiple price points for a single paying customer. Now, from a system standpoint, once the logic is in place to do the correct price lookups, it's not really IT's problem (until the next system upgrade, anyway) - but all of a sudden your pricing staff needs to handle just how many different price lists? One client of mine ended up building some customized tools to bolt on to their Tier 1 ERP product just to help automate the incredibly complex and customer-specific pricing management - and this company doesn't sell a particularly high-margin product.

And because the system can support this, your account sales force is all of a sudden able to negotiate pricing on a line-item basis. Now, for a particular account, this may make great sense, but because the incremental cost of adding each pricing customization is so small, it is too easy to allow for such pricing variations when it is not really necessary. After 10 years of doing this, the company may figure out the costs of supporting the variability are too high and they will embark on a rationalization project. As anyone who has gone through such an endeavor knows: it is much easier to inject complexity into an operation than to try to simplify things.

The article provides some thoughts about how to triage the complexity and attempt to either simplify it away or support it more efficiently. My main advice is to think about the introduction of complexity at the time it is being contemplated rather than trying to address it after the fact. To adapt a phrase from the authors, it is easier to say "A and B" rather than "A or B" - it is easier to introduce complexity - but one of the hallmarks of good management is strong and effective decision-making. Make sure the complexity you add is really going to be worth it.

Postscript: Don't confuse custom software with introducing complexity. More commonly, it is the package software vendors that are most likely to provide too many options. After all, they need to support multiple different capabilities across their customer base - unfortunately having the options available across customers means that an individual customer can too easily choose to make the "and" decision rather than the "or" decision. Even if the software supports it, it is important to think about the long-term consequences of the choice,