Four Pillars: On enterprises and complexity bias

The kernel for this post was a comment made by Jeff Nolan (Hi Jeff!) on apparent complexity biases in enterprise software selection/development, and a follow-up by Jeff Weinberger, both relating to one of my recent posts. And before I commented further, I felt it was appropriate to link back to an earlier post of mine that new readers may not have seen.

It is within that context that I write. Sure we have complexity bias in enterprises, but it’s worse than that. We also have purveyors of complexity bias on the outside.
As the two Jeffs say, the enterprise immune system kicks in whenever something looks simple and easy to implement; it is a variant of “real projects have a zillion people working on them, cost the earth and are at least twice as long as Pinocchio’s nose”. That’s the easy bit.

The harder bit is the role played by unscrupulous consultants and vendors. I like markets. Markets have buyers and sellers and intermediaries. For seller read vendor, for intermediary read consultant. So the model’s OK in principle. What goes wrong?

Vendor lock-in is something most people understand. The subtlety, something I didn’t quite understand, was the passion with which in-house IT department staff back the vendor view, and create polarised debates about anything and everything. The classic Microsoft/Open Source debates exemplify this. Even terms like Microsoftie and Penguinista show the polarisation. It’s almost as if people define and sustain their identity within such polarisation. Once that happens the complexity issue is almost a guaranteed byproduct, as people plot ways to make implementing their bete noire as humanly difficult as possible. [And as you know, they don’t have to try very hard, such hybrid worlds are easy to mess up.]

Similarly, the classic “consultant is someone who borrows your watch to tell you the time, and keeps the watch as payment” is pretty well understood. There are consultants who prove this rule by being exceptions to the rule, but they are few and far between. I tend to think of them as belonging to one of three camps:

• Those who know the answer
• Those who know how to get to the answer
• Those who know how to put off the answer

The Know-the-Answer guys give you time-to-market and TCO savings. They know where you need to go, they know how to get you there, they’ve got the intellectual firepower as well as the experience. This type is rare, and in my book the only consultants always worth having.
The Get-to-the-Answer guys give you TCO stabilisation. You can rely on them to get you there, they are kings of process. MethodOne meets the 21st century. They have been militarised, do things by the book, always get you there, but it takes time and is like watching paint dry. You need them sometimes, as extensions to your labour force, when you have a skill or workload mismatch, or when you are prepared to fully hedge your project risk (and most of the reward). This type is less rare, and legitimises the existence of consultants.
The Put-off-the-Answer guys are the ones to watch for. Teflon types with the political nous to make sure nothing sticks, their projects never end, the “collateral damage” to in-house staff can be very high, nothing ever gets delivered, nothing ever gets stopped either. Unfortunately this type is too common. Sad but true.
And their route to doing this is classic smoke-and-mirrors. “This is complex, you won’t understand it” followed up by the careful introduction and seeding of as much low-level complexity as possible. Their goal is different. Perennial billing. Project names can change, deliverables change, timelines change. One thing stays constant: nothing of value gets delivered.

That’s why we (with the consultants’ help) spent so much time in the nineties mangling “off-the-shelf” products, customising them beyond redemption, ensuring that they reflected yesterday’s business model as faithfully as possible, then letting them come in on their white chargers (which you paid for anyway) to do the same thing with today’s business model…. that’s why implementation costs for standard enterprise software tended to be nine times the licence costs.

Once we realise the root causes of complexity bias, we can do something about it.