"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.