The 3 IT processes CIOs need most

Principle No. 7 of the Keep the Joint Running Manifesto says that before you can be strategic you have to be competent.

IT’s processes and practices are how IT’s work gets done. They’re where competence, or its absence, happens.

The prior installment in this series talked about the hard truths of what it means to “improve” IT’s processes and practices. The question now is which of them you, as CIO, need to focus your personal attention on.

The answer starts with this basic principle: Managers should never personally sponsor more than three change initiatives. Exceed that magic number and you’ll lose your ability to focus, and, therefore, to lead.

But which three should CIOs choose?

What not to focus on: IT operations

The most obvious candidate for organizing your process improvement program is the well-known ITIL framework. But that would be a mistake.

It isn’t that adopting the ITIL framework would be a mistake. It’s a perfectly fine framework with decades of maturation behind it. It’s that ITIL’s focus is on IT operations. And IT operations only gets noticed when something goes wrong. As CIO you want to be noticed when something goes right.

So if your IT organization needs to be better at availability management, capacity management, performance management, infrastructure lifecycle management, systems administration, and especially change management, make sure you have the right person in charge of IT ops and make it clear you’re going to gauge their success by the only IT ops metric that matters — the Invisibility Index — which is to say you must be the only one to notice when IT ops isn’t noticed.

As CIO you should recognize that while IT ops is intensely important it isn’t at all strategic, except that, as noted, if it isn’t done well you can’t be strategic.

Delegate it, and make sure the manager you delegate it to has all the tools and support they need.

Process priority No. 1: The help desk

Fixing the help desk should be your top priority if IT’s reputation — that’s all of IT’s reputation — is less than stellar.

The help desk is IT’s red-headed stepchild, which is unfortunate, because a key factor in IT’s successful integration with the rest of the business is the quality of the business/IT relationship.

IT’s relationship with the rest of the business lives and dies at the help desk. So if you hear it referred to as the “helpless desk,” or if your business counterparts ask you why IT doesn’t know a system is down until they call the help desk to let them know, or if you hear help desk staff swapping dumb user stories, or if, when someone calls the help desk for something quick and simple and the help desk gives them a ticket number instead of the 10-second answer they need right now — pick your symptom, and if the help desk exhibits it, give fixing the help desk your personal attention.

The business support you’ll need to make the rest of your IT organization shine depends on it.

Process priority No. 2: Application support

Rule 1: If your application support teams are still immersed in waterfall methodologies, what are you waiting for? Start moving them to agile right away, and oversee the agile adoption strategy and its execution personally.

Rule 2: Agile is more than Scrum. Choose the right agile variants for the work IT actually does, not Scrum because “that’s what everyone is using.”

Rule 3: Most agile variants are designed to manage application development. Most IT shops “buy when they can and only build when they have to.” If that’s you, ignore Scrum completely. Instead, have your application teams adopt CRP (conference room pilot) or its close cousin, ATDD (acceptance test-driven development).

Rule 4: Most agile variants focus on delivering software as a product. Most businesses need IT to collaborate in achieving intentional business change. Modify whichever agile variants you adopt so that this is what they do.

Process priority No. 3: IT architecture management

We’ll cover how to evaluate the quality and excellence of the IT architecture itself in the next installment of this series. If it’s poor, that’s a symptom of a misfiring IT architecture management practice, of course.

What are some other signs your IT architecture management practice needs help?

“We can’t tell how good our architecture is,” is a surprisingly and depressingly common symptom. For that matter, “We don’t know what we have” isn’t all that unusual.

What else? It hasn’t:

• Published and publicized a short — and short means no more than a dozen — list of architecture principles that guide everything else. And beyond being short the principles must be written in simple, jargon-free language.
• Published and publicized a list of standards that are: rooted in the principles; kept current based on a well-documented practice; and refreshed on a regular schedule — quarterly makes sense.
• Established lifecycle management as standard practice, integrating it into IT planning and budgeting.
• Developed a cloud strategy built around the architecture principles and standards, and around an understanding that cloud is an architecture, not a storage and processing locus.

That doesn’t mean that if the IT architecture is free of these flaws that the practice is in safe hands.

An IT architecture practice — along with its business-integrated cousin, the enterprise architecture practice — is at constant risk of devolving from adding and maintaining value to becoming a bureaucratic quagmire.

This hazard isn’t, by the way, unique to architecture. Any organization that’s chartered to review and critique the creative work of other teams shares the same risk.

Top-notch architecture requires an anti-bureaucratic mindset. It also needs funding, because projects that deliver applications with satisfactory features and functionality cost less than applications with satisfactory features and functionality that adhere to architectural standards.

As it’s unlikely that your average executive sponsor will be willing to pony up the difference, projects that deliver or modify application functionality will need an architecture subsidy to cover the spread.

An IT architecture management function must find ways to achieve healthy architecture while minimizing the use of enforcement as its primary tactic. It must also persuade executive leadership that good architecture is a wise business investment. Because of these two vital concerns, it’s hard to escape the conclusion that even under the best of circumstances, as CIO you should personally oversee the IT architecture team.

But what about information security?

In this day and age, where IT-related threats to the business are increasingly sponsored by organized crime and malicious state actors, and where the potential damage from intrusions long ago grew from “aggravation” to “enormous,” information security has to be one of IT’s top priorities. But, similar to IT operations, information security effectiveness is measured by its own Invisibility Index.

Only it’s worse, because to be effective, information security has to be intrusive, so some level of unlikable visibility goes with the territory.

One more point: Information security that isn’t tightly coupled to high-quality IT architecture is information security with holes in it.

So fold information security into your IT architecture practice, where you, as CIO, can keep an eye on it, too, without it further fragmenting your attention.

Addressing IT innovation (aka ‘digital’)

Look at where business opportunities for innovation are happening, and you’ll find that information technology is, if not the top contender, certainly among the top three.

As CIO, your choices here are to either take charge of IT innovation or to embrace the idea of adding a chief digital officer to the executive leadership team.

But that would constitute a proclamation of inadequacy on your part. Also, it would divide IT leadership in two, with the CDO becoming Captain We Oughta while you become Dr. No. And so “CIO” would become a statement of your retirement plan (“Career Is Over”).

Let’s not do that.

Instead, fold IT innovation into the IT architecture practice as well. Doing so not only gives innovation an organizational home so that it doesn’t fragment your attention, it also places responsibility for innovation in the same place as the long-term need to integrate IT innovations into the rest of the IT architecture. You don’t, after all, want IT innovations to become future islands of automation.

How to handle ‘DIY IT’

Do it yourself IT, also known as “shadow IT,” “rogue IT,” and “STOP IT!!! You’re giving me a migraine!!!! IT,” is something all too many CIOs do their best to stomp out.

In this, they resemble King Canute ordering the tide to not come in.

And anyway, DIY IT is more opportunity than problem, as it dramatically increases the company’s IT bandwidth without increasing its IT spend — or at least its visible IT spend.

DIY IT’s drawbacks are, for the most part, avoidable. Mostly, it takes IT providing a modicum of support in terms of technical consultation to ensure it complies with IT’s architectural standards, in exchange for which the IT architecture function gets the documentation it needs to prevent DIY IT from becoming covert IT.

Which makes support for DIY IT one more IT practice that can comfortably fit into the IT architecture function.

In conclusion

For IT to be competent, it must accomplish its work using well-designed, defined, and documented processes and practices. CIOs are accountable for all of them, but as a practical matter can’t personally guide a transformation of more than three.

In most IT organizations, the three process domains that most need the CIOs personal leadership are the help desk, application support, and IT architecture management. Polish these to a shine and IT will succeed — and succeed visibly.

That’s only if IT operations shines too, which is why, paradoxically, CIOs should make sure to delegate that responsibility. Fail to do this and you won’t have enough bandwidth left to burnish the big three.