12 ‘best practices’ IT should avoid at all costs

What makes IT organizations fail? Often, it’s the adoption of what’s described as “industry best practices” by people who ought to know better but don’t, probably because they’ve never had to do the job.

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

1. Tell everyone they’re your customer

Looking to fail? Make sure everyone in IT tells everyone outside of IT, “You’re my customer. My job is to exceed your expectations” (or, worse, “make you happy”).

Employees outside of IT are not IT’s customers. They’re IT’s colleagues, with whom IT collaborates as equals if anything good is going to happen for the company as a whole.

As “digital” 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’ve 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’s products and services.

2. Establish SLAs and treat them like contracts

Want to do some damage? Establish formal service level agreements, insist your “internal customers” sign them, and treat these SLAs like contracts.

And if you really want IT to fail, argue about whether you’ve satisfied your SLAs every time an “internal customer” (there’s that word again) suggests IT isn’t doing what they need it to do. It’s a great way to keep relationships at arm’s length.

Oh, and if IT hasn’t lived up to its SLAs, what’s its “internal customer” supposed to do. Sue?

If you’d prefer success, then you’ll remember that relationships require trust, that trust doesn’t happen unless you recognize colleagues as actual people, that if they like you they’ll work with you to fix whatever goes wrong, and that the purpose of contracts isn’t to define relationships — it’s to spell out what happens when there’s no trust and something goes seriously wrong.

Oh, 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.

Which in turn means many of IT’s SLAs are no longer anything IT can even influence, let alone control.

3. Institute charge-backs

Here’s 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.

Nothing encourages collaboration like arguing over the accuracy of the bills that determine which corporate pocket should hold the money.

The second type of charge-back takes the company’s total IT spend and spreads it across the company on a per-capita basis, so there’s nothing left to argue about. There’s also no point.

4. Insist on ROI

Sure, it’s 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.

What needs case-by-case approval is doing things manually. Automation is what’s assumed.

5. Charter IT projects

Want a formula for business/IT dysfunction? Define projects in terms of software delivery, so IT’s job is done when software satisfies requirements and meets specifications.

That way, when business management complains that the software doesn’t do what they need it to do, you’re in a perfect position to argue it does exactly what “the business” said it should do, because it meets the specs, doesn’t it?

Again: IT has become ubiquitous. That doesn’t just mean everyone uses IT’s products. It means everyone who uses IT’s products thinks in terms using information technology to make their part of the enterprise run differently and better.

6. Assign project sponsors

It’s 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.

Sponsors — real sponsors, not SINOs (“sponsors in name only”) — 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’ business benefits. Think someone who’s been assigned to be a sponsor will do those things? Me neither.

7. Double down on your cloud computing strategy

Cloud computing isn’t a strategy. That’s assuming the conclusion — that every application should be run in the cloud — instead of making it a decision about your technical architecture.

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

It’s an old rule: Form follows function. IT’s services are the functions. The cloud is one form some of your needed services might take.

8. Go Agile. Go offshore. Go both at the same time

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

Offshore has one thing going for it: a lower hourly cost of labor. What it doesn’t 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.

It is possible to make it work, but it isn’t for the faint of heart, and certainly isn’t for IT organizations that are Agile novices.

Want to go Agile? Want to go offshore? Pick one.

9. Interrupt interruptions with interruptions

The next step to surefire IT failure is to insist everyone multitask. After all, it’s a highly desirable ability, right?

Wrong. What multitasking really accomplishes is reducing productivity and quality while increasing stress in the attempt to get more done.

Whenever you’re tempted to ask someone to stop what they’re doing to work on something else, remember: Humans don’t 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.

Want IT to succeed instead? Let people finish what they’re working on before they move on to something else.

10. Juggle lots of projects

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

If, that is, you want all projects to take a lot longer, cost a lot more, and deliver sub-standard results.

If you want IT to develop a good reputation, establish this rule: Every project that launches will be fully staffed, with “fully staffed” meaning the project will never wait for a team member to become available to work on it.

Do this, and every project will finish before any one project would have finished had you kept on juggling them all.

11. Stamp out ‘shadow IT’

There’s 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’t 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.

That’s the second third. The third third? Good luck trying to stamp out shadow IT. It’s 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.

12. Say no or yes no matter the request

The 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’re making promises you can’t keep because you and everyone else already have all your time fully committed, because you always say yes.

The right answer if you want to succeed instead is, “We can do that. Here’s what it will take.”

There’s 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’t scheduled to receive one: Nothing is ever free.

Don’t say no. Don’t say yes. Explain what you’ll have to do to satisfy requests. What follows will be a conversation rather than an argument.

Much better.