Slashdot Mirror
Ask Slashdot: Biggest IT Management Mistakes?
snydeq writes: Sure, nobody's perfect. But for those in charge of enterprise technology, the fallout from a strategic gaffe, bad hire, or weak spine can be disastrous, writes Dan Tynan, in an article on the biggest management mistakes in IT. "Some of the most common IT gaffes include becoming trapped in a relationship with a vendor you can't shake loose, hiring or promoting the wrong people, and hiding problems from top management until it's too late to recover." What are some other career- and company-destroyers you've witnessed in your years in IT?
Implementing SAP
Outsourcing
Outsourcing your SAP implementation
People in India can't possibly know your business, your other employees or your customers as well as qualified, competent, real live boots on the ground in the US of A.
The two biggest mistakes I see is that a dev team which is doing fine gets cut and the people outsourced or offshored. Sales and quality hit the shitter, but management doesn't care one whit about that, since to them, the only people that matter are the S&M guys (sales/marketing), so more gets offshored.
Practically every mistake in IT is recoverable, except for failing to manage customer expectations.
In particular the two ways in which I can specifically think of that lack of customer expectation management becomes a project killer are lack of solid requirements (e.g., constantly changing requirements), and mismatch between the developer's idea and customer's idea of what the deliverable should look like.
I think that the requirements one is the worse of the two because it is so easy to have this conversation:
cust: Can you just add in this one little change here? ....
dev: Sure thing
cust: While you're at it
Code Complete covers this pretty well with the analogy of building a house. "Moving" a wall is really easy when the house is just a drawing on paper. It is considerably more difficult once the foundation is poured, the walls are up and the roof is on. People building houses know that asking to move a wall in the later stages means lots of money and time on the project. However, because software is an intangible and you can't see it taking shape in the same way as a house it is much more difficult (for someone who is not a software developer) to appreciate that things that seem simple might actually be major architectural tasks for the project.
Not implementing and operating a data backup system properly.
I have been bit by this myself and I thought I was doing a good job at it. (I'm not an IT manager -- I'm a software engineer who often gets shoved the IT manager's job for one reason or another.)
Almost every other failure can be mitigated but not this one.
Show me an OS that can replace W10 with everyday apps. There isn't anything out there that can handle Acrobat, MS office, Outlook, Exchange and other items, other than Windows. Oh, AD capability is a must out of the box.
Don't tell me what to use. Tell me what you are trying to accomplish, and I will find a solution. That's my job as an engineer. Of course you can't run Exchange on Linux without virtualization. But if your goal is to get e-mail, calendaring, and contacts I can do that for you.
Need Acrobat? Sorry. Try coming to me and saying "I need to read PDFs" or "I need to save this document as a PDF". Sure. I can solve those problems for you.
"I want Office on Linux". No, you don't. You want some of the *features* Office provides...on Linux.
Time and again, it's the sunk cost fallacy. A system that an organization might have spent a few million dollars to build is just not shaping up into anything they can use, but they keep at it rather than ditching it and seeing what they can do to change things.
What ironic about this is that I think agile actually encourages the sunk cost fallacy because teams will go "oohhh we can 'pivot' a little each sprint." Uh, no. If it's deep-fried dog shit for an architecture, and design you're not going to "pivot" out of this. It gets even worse when you have a management culture that doesn't understand refactoring; most of the agile teams I've been on have had managers who flat out don't care about technical debt and think they can default on it which reinforces the problems with the sunk cost fallacy down the road.
Executives with no IT experience running IT departments.
NO. More likely the executive making promises to customers and PMs without checking with the IT department and then demanding a months worth of work be done in 72 hours to one week and fire them if they can't get it done etc.
If you do get it done then it will continue. You are screwed either way
http://saveie6.com/