What makes IT organizations fail? Often, it\u2019s the adoption of what\u2019s described as \u201cindustry best practices\u201d by people who ought to know better but don\u2019t, probably because they\u2019ve never had to do the job.\n\nFrom establishing internal customers to instituting charge-backs to insisting on ROI, a lot of this advice looks plausible when viewed from 50,000 feet or more. Scratch the surface, however, and you begin to find these surefire recipes for IT success are often prescriptions for failure.\n\n1. Tell everyone they\u2019re your customer\n\nLooking to fail? Make sure everyone in IT tells everyone outside of IT, \u201cYou\u2019re my customer. My job is to exceed your expectations\u201d (or, worse, \u201cmake you happy\u201d).\n\nEmployees outside of IT are not IT\u2019s customers. They\u2019re IT\u2019s colleagues, with whom IT collaborates as equals if anything good is going to happen for the company as a whole.\n\nAs \u201cdigital\u201d has gone mainstream, information technology has become ubiquitous, embedded in nearly every corner of the company. Which is why savvy business leaders have lost patience with the whole internal customer metaphor. They\u2019ve figured out that the IT organization is as much an integral part of the business as the information technology itself is integral to the company\u2019s products and services.\n\n2. Establish SLAs and treat them like contracts\n\nWant to do some damage? Establish formal service level agreements, insist your \u201cinternal customers\u201d sign them, and treat these SLAs like contracts.\n\nAnd if you really want IT to fail, argue about whether you\u2019ve satisfied your SLAs every time an \u201cinternal customer\u201d (there\u2019s that word again) suggests IT isn\u2019t doing what they need it to do. It\u2019s a great way to keep relationships at arm\u2019s length.\n\nOh, and if IT hasn\u2019t lived up to its SLAs, what\u2019s its \u201cinternal customer\u201d supposed to do. Sue?\n\nIf you\u2019d prefer success, then you\u2019ll remember that relationships require trust, that trust doesn\u2019t happen unless you recognize colleagues as actual people, that if they like you they\u2019ll work with you to fix whatever goes wrong, and that the purpose of contracts isn\u2019t to define relationships \u2014 it\u2019s to spell out what happens when there\u2019s no trust and something goes seriously wrong.\n\nOh, and by the way, post-COVID, huge swaths of the workforce became virtual, which in turn means that huge swaths of the workforce depend on commercial, consumer-grade ISPs for their network infrastructure.\n\nWhich in turn means many of IT\u2019s SLAs are no longer anything IT can even influence, let alone control.\n\n3. Institute charge-backs\n\nHere\u2019s a terrific way to discourage the use of information technology: Institute charge-backs. You have two alternatives. The first carefully details every type of cost each cost center has incurred, from CPU cycles, to SAN and NAS storage (separate them, of course), to developer hours, to help desk calls billed out in 10-minute increments.\n\nNothing encourages collaboration like arguing over the accuracy of the bills that determine which corporate pocket should hold the money.\n\nThe second type of charge-back takes the company\u2019s total IT spend and spreads it across the company on a per-capita basis, so there\u2019s nothing left to argue about. There\u2019s also no point.\n\n4. Insist on ROI\n\nSure, it\u2019s lovely when a proposed project generates a positive financial return on investment all by itself. But as IT has become pervasive and ubiquitous, embedded in everything the business does, the moral of the ROI story is that the old way of thinking about IT decisions must be stood on its head: Information technology is no longer approved on a case-by-case basis.\n\nWhat needs case-by-case approval is doing things manually. Automation is what\u2019s assumed.\n\n5. Charter IT projects\n\nWant a formula for business\/IT dysfunction? Define projects in terms of software delivery, so IT\u2019s job is done when software satisfies requirements and meets specifications.\n\nThat way, when business management complains that the software doesn\u2019t do what they need it to do, you\u2019re in a perfect position to argue it does exactly what \u201cthe business\u201d said it should do, because it meets the specs, doesn\u2019t it?\n\nAgain: IT has become ubiquitous. That doesn\u2019t just mean everyone uses IT\u2019s products. It means everyone who uses IT\u2019s products thinks in terms using information technology to make their part of the enterprise run differently and better.\n\n6. Assign project sponsors\n\nIt\u2019s well known in project management circles that every project must have a business sponsor or it has little chance of succeeding. But want to ensure that a project fails? Assign one.\n\nSponsors \u2014 real sponsors, not SINOs (\u201csponsors in name only\u201d) \u2014 want their project to succeed deep in their guts, are willing to take risks if necessary to make sure their projects succeed, and put their names and reputations on the line regarding their projects\u2019 business benefits. Think someone who\u2019s been assigned to be a sponsor will do those things? Me neither.\n\n7. Double down on your cloud computing strategy\n\nCloud computing isn\u2019t a strategy. That\u2019s assuming the conclusion \u2014 that every application should be run in the cloud \u2014 instead of making it a decision about your technical architecture.\n\nA well-defined technical architecture should be defined in terms of services. The services are what you need. Sure, the cloud might be a good way to provision some of them. All of them? Maybe, maybe not.\n\nIt\u2019s an old rule: Form follows function. IT\u2019s services are the functions. The cloud is one form some of your needed services might take.\n\n8. Go Agile. Go offshore. Go both at the same time\n\nAgile methodologies have a lot going for them. One prerequisite for success is a high level of informal user involvement so that course-corrections are frequent and small, developers see progress every day, and user acceptance testing is a daily occurrence.\n\nOffshore has one thing going for it: a lower hourly cost of labor. What it doesn\u2019t have going for it is any possibility of the high level of informal user involvement Agile depends on. Combine a 12-time-zone difference, language barriers, a cultural chasm, and interactions limited to what can be handled with web conferencing, and Agile is pretty challenging.\n\nIt is possible to make it work, but it isn\u2019t for the faint of heart, and certainly isn\u2019t for IT organizations that are Agile novices.\n\nWant to go Agile? Want to go offshore? Pick one.\n\n9. Interrupt interruptions with interruptions\n\nThe next step to surefire IT failure is to insist everyone multitask. After all, it\u2019s a highly desirable ability, right?\n\nWrong. What multitasking really accomplishes is reducing productivity and quality while increasing stress in the attempt to get more done.\n\nWhenever you\u2019re tempted to ask someone to stop what they\u2019re doing to work on something else, remember: Humans don\u2019t multitask. The best they can do is to go back and forth from one task to another. Every time they do, they waste time switching mental gears. The more concentration a task requires, the more time they waste when they have to.\n\nWant IT to succeed instead? Let people finish what they\u2019re working on before they move on to something else.\n\n10. Juggle lots of projects\n\nIT never has enough staff to handle everything everyone wants, so it just makes sense to do everything you can to deliver it anyway by launching lots of projects and moving employees back and forth among them.\n\nIf, that is, you want all projects to take a lot longer, cost a lot more, and deliver sub-standard results.\n\nIf you want IT to develop a good reputation, establish this rule: Every project that launches will be fully staffed, with \u201cfully staffed\u201d meaning the project will never wait for a team member to become available to work on it.\n\nDo this, and every project will finish before any one project would have finished had you kept on juggling them all.\n\n11. Stamp out \u2018shadow IT\u2019\n\nThere\u2019s no question that when business departments roll their own IT, bad things can happen. That might seem to be a convincing argument for preventing it, but it tells only a third of the story. The second third: Business departments engage in DIY efforts because IT doesn\u2019t have enough staff to solve the (usually) small business problems that shadow IT takes on. Which puts IT in the awkward position of forcing business departments to do everything in Excel, even when superior alternatives are available.\n\nThat\u2019s the second third. The third third? Good luck trying to stamp out shadow IT. It\u2019s awfully hard to even spot business use of cloud-based applications. And if IT is successful in stamping out shadow IT? Most likely the functionality IT prevents will become scope creep for some other project.\n\n12. Say no or yes no matter the request\n\nThe last and best way to ensure IT failure is to say no or yes no matter the request. Say no, and you damage your relationships. Say yes, and you\u2019re making promises you can\u2019t keep because you and everyone else already have all your time fully committed, because you always say yes.\n\nThe right answer if you want to succeed instead is, \u201cWe can do that. Here\u2019s what it will take.\u201d\n\nThere\u2019s an inviolable rule of request management, whether the request is a project scope change, a software enhancement, or providing a tablet to someone who isn\u2019t scheduled to receive one: Nothing is ever free.\n\nDon\u2019t say no. Don\u2019t say yes. Explain what you\u2019ll have to do to satisfy requests. What follows will be a conversation rather than an argument.\n\nMuch better.