December 03, 2010, 4:50 PM — Sometimes you meet a person who strikes you as an inspiring role model. Other times, you get a role model of a different sort, an example of how not to be. The CIO I had just spent an hour with was definitely the second type.
A corporal in a general's uniform, I thought to myself. I had found out earlier that he had never actually developed any applications software in his career, and he certainly didn't appear to know how to direct or delegate such a responsibility now. When it came to the IT framework of plan, build and run, he was quite capable of keeping things running, but he was clueless about planning and building. He probably never should have gotten his position in the first place, and it looked as if I was hired to help assure that he didn't stay in it much longer.
This was during my consulting career. I had been engaged by the managing director of a strategic business unit of a large enterprise who was having trouble dealing with the central IT service function. There were many problems, such as IT's failure to meet agreed-upon service levels and not seeming to care. But what had prompted his call to me was the near impossibility of getting software developed or modified. The IT function was unresponsive and bureaucratic, throwing up a stone wall by saying that it would work on applications software development only after the business unit documented the system requirements.
"I don't know what a system requirement is or how to document one," the managing director told me. "And the last time I got my people to try and do that, the IT function returned my write-up months later with a list of things that we'd omitted or that they thought wouldn't work."
His exasperation was rooted in business considerations. "We're losing business," he said. "We know how to address our problems with better technology, yet we're stuck, because this IT bureaucracy is keeping anything from getting done."
After he had filled me in on more details, I had a pretty clear picture of an IT function with a bunker mentality. It's not a rare thing, unfortunately, perhaps because there are so many things that can contribute to it. In some cases, IT simply had a very limited budget and no way to prioritize development expenses, so they raised hurdles to bar against new ones. Other times, IT had been badly burned after diving into a big development project with inadequate specifications. Or it had insufficient resources, or had lost the talent necessary to develop new applications, or was unable to communicate with business units or become involved in business unit issues. No matter the root cause of a bunker mentality, the result was invariably a relationship that verged on adversarial with IT's clients.