\u201cO what a tangled web we weave,\u201d explained Scottish novelist Walter Scott, \u201cwhen first we practice to deceive.\u201d\n\nBut no matter how tangled the web when someone else is the target, it has nothing on the mess that happens when we\u2019re fooling ourselves.\n\nAnd fool ourselves we do \u2014 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.\n\nHere are nine common situations where CIOs lie, not to their IT staff or to colleagues throughout the business, but to themselves.\n\nCIO self-deception #1: We\u2019re aligned with the business.\n\n\u201cAligning IT with the business\u201d sounds so much like a great thing to do that many CIOs institute elaborate IT governance processes to make sure it happens.\n\nIt\u2019s too bad so few businesses of any size are aligned with themselves. They\u2019re more like Dallas\u2019 Ewings than the Partridges. Aligning with the business usually comes down to either placating the political power players or instituting a chargeback system.\n\nChargebacks? Yes, chargebacks. It\u2019s IT as handyman: We\u2019ll give you whatever you ask for, as long as you fund the project.\n\nWith chargebacks, IT might not be aligned with the business, but it\u2019s aligned with the business budget. If that aligns with the business, it\u2019s all good, and if it doesn\u2019t, well, it\u2019s someone else\u2019s problem.\n\nCIO self-deception #2: The only reason to upgrade software is when a new version provides important business value.\n\nNot 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\u2019t be accused of spending on technology for technology\u2019s sake.\n\nEven better, the IT budget can shrink because it doesn\u2019t have to cover the cost of keeping things current.\n\nCIOs 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.\n\nSoftware upgrades are preventive maintenance. You either pay it now or pay it later. Later is a much bigger number.\n\nCIO self-deception #3: The big mission-critical project that\u2019s fallen behind schedule? We\u2019ll catch up in the next phase and deliver it on time.\n\nHere\u2019s the usual progression:\n\nBusiness case: It\u2019s thin. So whoever\u2019s 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.\n\nRequirements 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\u2019s okay. Everyone knows the more thorough your design, the less time you\u2019ll need for coding and testing. We\u2019ll make it up then.\n\nPlanning: 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\u2019s the project manager who, in desperation, fiddles and twiddles until the schedule looks plausible, so long as nobody looks at it too closely.\n\nWhich they won\u2019t because it tells them what they want to hear.\n\nYellow: That\u2019s 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\u2019s complexions in the green.\n\nSecond, they start a job search before the project tanks their reputation.\n\nLevel 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.\n\nLevel 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.\n\nOff 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.\n\nCIO self-deception #4: We\u2019re doing ITIL.\n\nThis might seem like semantic nitpicking, but there\u2019s no such thing as \u201cdoing\u201d ITIL. ITIL is a framework, as its proponents patiently explain to whomever is willing to listen (generally a small and apathetic audience that doesn\u2019t include our self-deceptive CIO).\n\nITIL lists the things IT has to be good at. It doesn\u2019t 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\u2019s list that works in all situations. (Don\u2019t believe me? Think about how you\u2019d run IT if you worked in a small ad agency. Now think about how you\u2019d run it in a large government contractor specializing in cybersecurity.)\n\nOn top of this, there are a lot of CIOs who equate \u201cdoing ITIL\u201d with having a decently run service desk (or at least renaming their help desk so it reads \u201cservice desk\u201d) 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.\n\nCIO self-deception #5. We\u2019re doing agile.\n\nThere 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.\n\nFor every one that actually adopted Agile there are probably a dozen or more that follow some form of \u201cagilefall\u201d instead, strictly adhering to every single one of Scrum\u2019s formalisms while completely ignoring the spirit of the agile transformation.\n\nAs is the case with so many other business and IT practices, there\u2019s a difference between checking off the boxes and properly executing the work the check boxes are there to keep track of.\n\nAnd I\u2019d guess half the IT shops that have avoided the agilefall trap have gone around the bend in the other direction: They aren\u2019t practicing Agila. They\u2019ve instituted Haphazard instead, often at the behest of a waterfaller who was certain before the entire effort started that agile was doomed to failure \u2014 and did their best to make sure their prophesy was self-fulfilling.\n\nCIO self-deception #6. We\u2019re doing devops.\n\nNo you aren\u2019t. You aren\u2019t even doing agile. Can\u2019t you read?\n\nOkay, okay. If you must know, in spite of all the buzz about devops, its proponents didn\u2019t invent collaboration. Agile \u2014 the real thing, not agilefall \u2014 advocated collaboration long before devops came along, although, to be fair, IT operations wasn\u2019t who developers generally collaborated with.\n\nHere\u2019s what devops adds to the agile mix:\n\nFirst, dev teams include IT ops, for purely selfish reasons: They don\u2019t want to wait for their environments to get built, and they don\u2019t 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.\n\nThird 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\u2019t entirely compatible. Kanban works better.\n\nSorry to be the bearer of sad tidings.\n\nCIO self-deception #7: We have a customer service culture.\n\nHear those snickers coming from the help \u2026 sorry, service desk? That\u2019s your service desk staff trading dumb user stories. Not the makings of a customer service culture. One of those would begin with respect.\n\nIt doesn\u2019t matter, because if they have a customer service culture, their CIO thinks the rest of the business is her customer.\n\nVery bad idea. It leads to ill-fitting concepts like chargebacks \u2014 a great opportunity to waste time, energy, and trust arguing about the IT bill.\n\nIf it isn\u2019t entirely clear why \u201ccustomer service culture\u201d is the wrong idea, see what happens when you delete the word \u201ccustomer.\u201d\n\nCIOs should foster a service culture in IT.\n\nHow can they know whether they have one or not? If they still hear dumb user stories, they don\u2019t have one.\n\nCIO self-deception #8: Our information security is tight.\n\nRemember the bit about agilefall and checklists? Far too often, when there\u2019s 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\u2019s a compliance certification attached.\n\nPCI, 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 \u2014 far from the only loss of data from businesses that had passed some form of information security assessment.\n\nIf a CIO thinks information security is tight, he\u2019s probably wrong. It\u2019s the CIOs who are concerned their information security might have a few holes who just might be in decent shape.\n\nCIO self-deception #9. Our IT governance processes make sure we only undertake high-business-value projects.\n\nLet\u2019s go back to the whole business alignment thing again.\n\nIT governance is supposed to make sure only the highest value projects are funded. And yet, no matter how well-crafted the process, it\u2019s still implemented by the same cast of characters who aren\u2019t \u201caligned\u201d with each other in the first place.\n\nSo in addition to estimating each project\u2019s value to the business there\u2019s horse-trading and sheer spitefulness involved in the final set of decisions.\n\nAdd 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.\n\nBut increasing revenue calls for customers doing what you want them to do. Often, they don\u2019t. You can\u2019t boss them around. You have to persuade them.\n\nNot a bad habit for your everyday executive to get into, by the way, but not one enough everyday executives have.\n\nWant a bottom-line takeaway from all this? It\u2019s this: If you\u2019re certain \u2014 about anything \u2014 you\u2019re almost certainly wrong. If you\u2019re a CIO and you\u2019re sure about any of these nine topics, or, for that matter, any others, ask yourself this simple question: Why?\n\nCIO self-deception #10: We don\u2019t need to involve the business in this.\n\nLet\u2019s imagine IT has established a cadre of first-rate relationship managers to handle outreach to the business. Let\u2019s further imagine the relationship managers are doing their jobs, coordinating business needs with IT capabilities and so on.\n\nIt\u2019s entirely possible that in this situation a project that calls for knowledge of, say, how the business makes use of information technology can rely on the relationship managers to provide that knowledge for projects that need it.\n\nBut (there\u2019s always a \u201cbut\u201d) when the time comes to pivot from planning to action and that action will, inevitably, affect how things get done in the business, it will take quite the sales pitch to persuade them that having a strong relationship with a relationship manager was a satisfactory substitute for actual business involvement.\n\nIt\u2019s an old, old rule: If you\u2019re going to do something that affects someone you ought to involve them in it so the result is something they were part of and not just something that happened to them.