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 formulas 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.
Legitimizing the idea of internal customers puts IT in a subservient position, where everyone in IT has to make their colleagues happy, whether doing so makes sense for the business or not, let alone whether it encourages the company’s actual customers to buy more 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.
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 define what happens when there’s no trust and something goes seriously wrong.
3. Tell dumb-user stories
You know them. The classics have punchlines like “Whiteout on the screen,” “Let me get this straight — you’re having a power outage and you can’t understand why your PC won’t boot,” and “I told him to try reversing the plug on his printer … and it was a three-prong plug (snicker)!”
Laugh when other IT staff members tell them, especially when they have names attached. Or if you want to ensure IT failure, tell them yourself. That way word will get out that neither you nor anyone else in IT has any respect for anyone else.
That’ll help the cause.
4. Institute charge-backs
Here’s a terrific way to discourage the use of information technology: Institute charge-backs. And not just any charge-backs — carefully computed ones that generate invoices detailing every category of expense 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.
5. Insist on ROI
Want to make sure critical projects don’t get funded? Insist that the IT governance process requires a clear, tangible, financial return on investment. Doing that pretty much ensures a slide into obsolescence, while technology that helps business departments deliver better results faster goes unfunded and projects that help drive customer satisfaction — increasing sales while reducing the cost of sales but not in ways IT can prove — are snickered at in the corner office, along with whoever proposed them.
6. 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 it’s supposed to do, because it meets the specs, doesn’t it? And if that fails, and the project doesn’t satisfy requirements, then you can argue the requirements were wrong. And whose fault is that? The business managers who signed off on them, of course.
Or, you could do what works: Starting with how you name your projects, define every one in terms of business outcome (“increase sales effectiveness”), not software (“implement Salesforce.com”).
7. 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.
8. Establish a cloud computing strategy
Here’s a wonderful way to ensure IT failure — establish a cloud computing strategy. That way you can assume the conclusion. You know you have to be in the cloud, so the purpose of the strategy is to make it happen.
Whatever you do, don’t think more broadly than that. Don’t consider a managed technical architecture, defined in terms of services. After all, doing so might lead you to believe that the services are what you need, and that the cloud might be a way to provision some of them.
It’s an old rule: Form follows function. Services are the functions. The cloud is one form some of your needed services might take. Avoid thinking that way, unless you want IT to succeed. Then it’s mandatory.
9. Go Agile. Go offshore. Do 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 a non-starter.
Want to go Agile? Want to go offshore? Pick one.
10. 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? What it really means 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, and 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.
Microsoft MCTS Certification, MCITP Certification and over 3000+
Exams with Life Time Access Membership at https://www.actualkey.com
11. 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 of the 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.
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 of your time fully accounted for.
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 laptop 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.
