12 ‘best practices’ IT should avoid at all costs

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.

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.