9 lies CIOs tell themselves

“O what a tangled web we weave,” explained Scottish novelist Walter Scott, “when first we practice to deceive.”

But no matter how tangled the web when someone else is the target, it has nothing on the mess that happens when we’re fooling ourselves.

And fool ourselves we do — not because we deliberately want to set the wrong priorities, make the wrong decisions, and pursue the wrong goals, but because wishful thinking is a whole lot easier than looking at the world through glass-colored glasses.

Here are nine common situations where CIOs lie, not to their IT staff or to colleagues throughout the business, but to themselves.

CIO self-deception #1: We’re aligned with the business.

“Aligning IT with the business” sounds so much like a great thing to do that many CIOs institute elaborate IT governance processes to make sure it happens.

It’s too bad so few businesses of any size are aligned with themselves. They’re more like Dallas’ Ewings than the Partridges. Aligning with the business usually comes down to either placating the political power players or instituting a chargeback system.

Chargebacks? Yes, chargebacks. It’s IT as handyman: We’ll give you whatever you ask for, as long as you fund the project.

With chargebacks, IT might not be aligned with the business, but it’s aligned with the business budget. If that aligns with the business, it’s all good, and if it doesn’t, well, it’s someone else’s problem.

CIO self-deception #2: The only reason to upgrade software is when a new version provides important business value.

Not only does this sound convincing, it sounds executive. A CIO who makes this point is clearly focused on the business (and aligning to it) and can’t be accused of spending on technology for technology’s sake.

Even better, the IT budget can shrink because it doesn’t have to cover the cost of keeping things current.

CIOs who make this point, though, either have never lived through a crash-and-burn skip-several-technology-generations upgrade, or they have but successfully blame-shifted the mess.

Software upgrades are preventive maintenance. You either pay it now or pay it later. Later is a much bigger number.

CIO self-deception #3: The big mission-critical project that’s fallen behind schedule? We’ll catch up in the next phase and deliver it on time.

Here’s the usual progression:

Business case: It’s thin. So whoever’s brainchild this budding disaster is does what managers have done since before spreadsheets were invented: They fiddle and twiddle until the ROI exceeds the hurdle rate, convincing themselves their revised assumptions are still, if not entirely reasonable, at least doable with some luck and a strong tailwind.

Requirements and specifications: Estimating the requirements and specifications phase is a bugger. The bigger the project, the more unknowns lie lurking; each and every one of them complicates things further. The requirements and specifications phase always goes long, but that’s okay. Everyone knows the more thorough your design, the less time you’ll need for coding and testing. We’ll make it up then.

Planning: IT being aligned with the business and all, planning goes right-to-left, starting with the delivery date and working backward to whatever schedule will achieve it. This time it’s the project manager who, in desperation, fiddles and twiddles until the schedule looks plausible, so long as nobody looks at it too closely.

Which they won’t because it tells them what they want to hear.

Yellow: That’s the project status, also known as behind schedule with no path to salvation, but enough time before the deadline that denial still supersedes reality. Adroit project managers take two actions when a project reaches this stage. First they squeeze testing. This puts both the project and the team’s complexions in the green.

Second, they start a job search before the project tanks their reputation.

Level one testing: This consists of redefining the exalted state of good-enough down. With lax enough standards and enough political clout, even the worst code can get rammed into production.

Level two testing: Also known as PROD. You always test, and test thoroughly. The only question is whether thorough testing happened before or after the software went into production.

Off the rails: The new CIO stops the train wreck. His predecessor blames the project manager. The project manager attends PMI meetings the way those with drinking problems go to AA.

CIO self-deception #4: We’re doing ITIL.

This might seem like semantic nitpicking, but there’s no such thing as “doing” ITIL. ITIL is a framework, as its proponents patiently explain to whomever is willing to listen (generally a small and apathetic audience that doesn’t include our self-deceptive CIO).

ITIL lists the things IT has to be good at. It doesn’t prescribe how to go about being good at them, which is just as well, as there is no one way to do anything on ITIL’s list that works in all situations. (Don’t believe me? Think about how you’d run IT if you worked in a small ad agency. Now think about how you’d run it in a large government contractor specializing in cybersecurity.)

On top of this, there are a lot of CIOs who equate “doing ITIL” with having a decently run service desk (or at least renaming their help desk so it reads “service desk”) and maybe instituting a change advisory board (CAB) to sit between app dev and IT operations so they both glare at the CAB instead of each other.

CIO self-deception #5. We’re doing agile.

There are IT shops that have moved from waterfall application development techniques to one or more agile variants, or are in the process of doing so.

For every one that actually adopted Agile there are probably a dozen or more that follow some form of “agilefall” instead, strictly adhering to every single one of Scrum’s formalisms while completely ignoring the spirit of the agile transformation.

As is the case with so many other business and IT practices, there’s a difference between checking off the boxes and properly executing the work the check boxes are there to keep track of.

And I’d guess half the IT shops that have avoided the agilefall trap have gone around the bend in the other direction: They aren’t practicing Agila. They’ve instituted Haphazard instead, often at the behest of a waterfaller who was certain before the entire effort started that agile was doomed to failure — and did their best to make sure their prophesy was self-fulfilling.

CIO self-deception #6. We’re doing devops.

No you aren’t. You aren’t even doing agile. Can’t you read?

Okay, okay. If you must know, in spite of all the buzz about devops, its proponents didn’t invent collaboration. Agile — the real thing, not agilefall — advocated collaboration long before devops came along, although, to be fair, IT operations wasn’t who developers generally collaborated with.

Here’s what devops adds to the agile mix:

First, dev teams include IT ops, for purely selfish reasons: They don’t want to wait for their environments to get built, and they don’t want to wait on the CAB to deploy software changes. Second is automation everywhere, a truly good idea. Having to manually shepherd software changes through their paces is simply silly.

Third is that, with devops but not with most agile variants, and certainly not with waterfall, software is always in a deployable state. No, no, no, no, no. Not deplorable. Deployable. Among the many uncomfortable realizations for most agile shops, this means devops and Scrum aren’t entirely compatible. Kanban works better.

Sorry to be the bearer of sad tidings.

CIO self-deception #7: We have a customer service culture.

Hear those snickers coming from the help … sorry, service desk? That’s your service desk staff trading dumb user stories. Not the makings of a customer service culture. One of those would begin with respect.

It doesn’t matter, because if they have a customer service culture, their CIO thinks the rest of the business is her customer.

Very bad idea. It leads to ill-fitting concepts like chargebacks — a great opportunity to waste time, energy, and trust arguing about the IT bill.

If it isn’t entirely clear why “customer service culture” is the wrong idea, see what happens when you delete the word “customer.”

CIOs should foster a service culture in IT.

How can they know whether they have one or not? If they still hear dumb user stories, they don’t have one.

CIO self-deception #8: Our information security is tight.

Remember the bit about agilefall and checklists? Far too often, when there’s a checklist, checking the boxes becomes the point of it all instead of the checklist being used as a way of keeping track. Information security is subject to the same challenge, especially when there’s a compliance certification attached.

PCI, the payment card industry security standard, comes to mind. You might recall that Target lost 40 million or so customer records back in 2013 in spite of its PCI compliance — far from the only loss of data from businesses that had passed some form of information security assessment.

If a CIO thinks information security is tight, he’s probably wrong. It’s the CIOs who are concerned their information security might have a few holes who just might be in decent shape.

CIO self-deception #9. Our IT governance processes make sure we only undertake high-business-value projects.

Let’s go back to the whole business alignment thing again.

IT governance is supposed to make sure only the highest value projects are funded. And yet, no matter how well-crafted the process, it’s still implemented by the same cast of characters who aren’t “aligned” with each other in the first place.

So in addition to estimating each project’s value to the business there’s horse-trading and sheer spitefulness involved in the final set of decisions.

Add to that another annoying detail: Projects whose benefit is cost reduction will take precedence over projects whose benefit is increased revenue. Why? Reducing cost is within the control of the business. If everything goes according to plan, costs will go down.

But increasing revenue calls for customers doing what you want them to do. Often, they don’t. You can’t boss them around. You have to persuade them.

Not a bad habit for your everyday executive to get into, by the way, but not one enough everyday executives have.

Want a bottom-line takeaway from all this? It’s this: If you’re certain — about anything — you’re almost certainly wrong. If you’re a CIO and you’re sure about any of these nine topics, or, for that matter, any others, ask yourself this simple question: Why?

Related articles

More about AdroitAgile