Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Businesses Cloud Communications IT Technology

Ask Slashdot: Biggest IT Management Mistakes? 341

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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Biggest IT Management Mistakes?

Comments Filter:
  • by Anonymous Coward on Monday December 11, 2017 @09:10PM (#55720963)

    Focusing the department on nothing but fire stomping and not focusing on preventative design/administration.

    • by Z00L00K ( 682162 ) on Tuesday December 12, 2017 @05:29AM (#55722863) Homepage Journal

      As soon as you outsource you are in the hands of the company you outsourced to and that company don't understand your business model, only profit for themselves.

      Putting things in "the cloud" is probably the most dangerous thing you can do these days. It's like peeing in your pants, it feels warm for a little while.

    • Focusing the department on nothing but fire stomping and not focusing on preventative design/administration.

      LOL! Try doing anything else when the company you work for sees IT as nothing else than a cost-center!!!

  • frosty (Score:5, Insightful)

    by Anonymous Coward on Monday December 11, 2017 @09:10PM (#55720965)

    Implementing SAP
    Outsourcing
    Outsourcing your SAP implementation

    • Re:frosty (Score:5, Informative)

      by ShanghaiBill ( 739463 ) on Monday December 11, 2017 @10:14PM (#55721321)

      Implementing SAP
      Outsourcing
      Outsourcing your SAP implementation

      Whenever I talk to someone from a company that uses SAP, I always ask if they are satisfied with SAP and would choose to use them again.

      So far, this many have said yes: 0.

      For comparison, this is the number that have said they are happy with Oracle's ERP: 0.

      • by lucm ( 889690 ) on Monday December 11, 2017 @11:06PM (#55721571)

        Implementing SAP
        Outsourcing
        Outsourcing your SAP implementation

        Whenever I talk to someone from a company that uses SAP, I always ask if they are satisfied with SAP and would choose to use them again.

        So far, this many have said yes: 0.

        For comparison, this is the number that have said they are happy with Oracle's ERP: 0.

        I'll see your Oracle ERP and raise you one Peoplesoft, a true marvel of software engineering, where database tables have intuitive names such as PSPRSMDEFN or PSFLDFIELDDEFN (those are real names).

        Runner up: anything from ASG.

      • by Clived ( 106409 )

        Wow, the choices seem kinda limited then?

      • by jools33 ( 252092 )

        I work for a company that has implemented SAP - and yes we are happy (so there's a one for you).

        • by CBravo ( 35450 )
          You work at SAP?
          • He said implemented, he didn't say that it worked. Contractors make bank on SAP installs, I'd be very happy spending 5 years implementing the forever project with no downside save boredom.

            • by jools33 ( 252092 )

              It worked - for all but one of the companies I have worked for in the past 25 years. The one company where it did not work, the main reasons for it not working were catastrophically bad management; basically someone decided that a good salesman would also make a good manager (this turned out to be a bad decision). That lead on to multiple poor decisions, and in the end a failed project; whilst that SAP product that they were implementing, at the time was immature, but many other SAP customers have experienc

          • Re: (Score:3, Informative)

            by jools33 ( 252092 )

            No I work directly for an SAP customer (have done for 5 years now, cannot say which one unfortunately). SAP is not an inherently bad system, it really depends on how knowledgeable your implementation team are. SAP has some really dedicated developers and some very good support. There are definitely SAP horror stories out there - that people seem to love repeating forever and a day, but I can honestly say that I have worked with SAP for 25 years, and 20 of those were as a consultant, and in that time I saw o

            • Re:frosty (Score:4, Interesting)

              by Bert64 ( 520050 ) <bert@[ ]shdot.fi ... m ['sla' in gap]> on Tuesday December 12, 2017 @08:50AM (#55723471) Homepage

              Being widespread doesn't make something good, people copy each other even when doing something stupid... Also all the examples you give are large companies which is a very important thing to consider...

              SAP is a large, expensive system with many hidden costs in addition to the purchase price. You will likely have to buy lots of dependencies, lots of highend hardware, hire many expensive and highly trained staff to manage it and develop custom additions to handle your own business needs.
              If you have the budget to do this, then it can work well... But many smaller companies go in blindly because they want to copy what these larger companies are doing... They get unrealistic quotes from greedy third party consultancies, or only see the ticket price and don't consider the true cost. They buy the software, but don't buy enough hardware to run it adequately, or don't hire sufficiently competent staff to manage it.
              Many sales people will blatantly lie to you in order to sign you up for a large purchase, and then completely fail to deliver leaving you locked in with a huge bill and a big mess to clean up.
              The end result is colossal failure and a big mess, or a system that limps along and still ends up costing a fortune.

              A lot of people have a stupid mindset that "company X is huge and successful, if we copy them we will be successful too".
              Copying a company 100x your size is not a good business plan, if you're a small company you should act like one and play to your strengths. You don't have the economies of scale or huge budget enjoyed by large companies, but you have agility that large companies lack.

              • Re:frosty (Score:4, Interesting)

                by Doctor Memory ( 6336 ) on Tuesday December 12, 2017 @12:43PM (#55725285)

                A lot of people have a stupid mindset that "company X is huge and successful, if we copy them we will be successful too".
                Copying a company 100x your size is not a good business plan, if you're a small company you should act like one and play to your strengths. You don't have the economies of scale or huge budget enjoyed by large companies, but you have agility that large companies lack.

                Now try telling that to the legion of devs who blindly use products like Cassandra, Hadoop or Storm "because we need to be able to scale". Then they jump through hoops trying to get it to do what they need (and not always successfully).

    • I think you just gave the material for about 5-10 episodes of a hilarious sitcom.

  • Outsourcing (Score:5, Insightful)

    by Anonymous Coward on Monday December 11, 2017 @09:12PM (#55720987)

    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.

  • by Anonymous Coward on Monday December 11, 2017 @09:13PM (#55720989)

    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.

  • Biggest mistake (Score:2, Informative)

    by Anonymous Coward

    Executives with no IT experience running IT departments.

    • by Billly Gates ( 198444 ) on Tuesday December 12, 2017 @02:12AM (#55722273) Journal

      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

      • Re: Biggest mistake (Score:5, Interesting)

        by apoc.famine ( 621563 ) <apoc.famine@g m a i l . com> on Tuesday December 12, 2017 @11:12AM (#55724443) Journal

        A friend makes bank now after his CEO got pissed at sales and marketing doing this shit. His sole job is to go to sales meetings and keep sales honest. He knows the business well, and studies up on the customer to understand who they are and what they seem to need. Then he shoots down sales during the meeting when they start promising too much or trying to sell something that the customer doesn't really seem to want or need.

        The marketing folks hate him, but the CEO, developers, and the customers love him.

  • by SeaFox ( 739806 ) on Monday December 11, 2017 @09:17PM (#55721019)

    Biggest one I've seen is -- duh. [marketwatch.com]

  • by El Cubano ( 631386 ) on Monday December 11, 2017 @09:22PM (#55721037)

    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.

    • by lucm ( 889690 ) on Monday December 11, 2017 @11:50PM (#55721775)

      Practically every mistake in IT is recoverable, except for failing to manage customer expectations.

      Ok, let's see:
      1) Threatening to expose hackers AND using the same password everywhere including in your unpatched CMS (HBGary Federal)
      2) Botch manual deployment of a trading algorithm and lose $440 millions in 45 minutes (Knight capital)
      3) Do not handle race conditions properly and expose patients to doses of radiation 100x higher than expected (Therac-25)

      and the list goes on...

  • Sales Engineer (Score:5, Insightful)

    by Major Blud ( 789630 ) on Monday December 11, 2017 @09:22PM (#55721041) Homepage

    Always make sure your sales team includes a dedicated engineer. They will help keep them in line, and mitigate situations in which a customer was promised something like running Internet Explorer on AIX.

    • As a former SE (FAE in Intel-speak) for several companies, I'd also like to say that the underlying organization behind the SE is more important. Sure, a great SE can beat his head against the wall to no avail to the customer, but a great organization that really supports their SEs when they try to be "the voice of the customer" is really rare. Intel did it better than any other org I've worked with, but even they failed sometimes. Those danged customers kept having their OWN needs, dammit!!
    • promised something like running Internet Explorer on AIX.

      Well, that's maybe not possible to do, but, having a customer requesting this insanity is also not possible.

      • If I can get you to sign that you won't be paid before it's implemented, rest assured I will not only request it but also make it non-negotiable if I notice that you're too dumb to know.

    • Make sure the 'Sales Engineer' isn't a lying weasel like the rest of the sales team.

      Having one and having him do his job is all about how he's paid. If his commish structure is exactly like the other sales weasels, expect him to weasel with the worst of them. Only he's worse, he should know better.

  • by rgmoore ( 133276 ) <glandauer@charter.net> on Monday December 11, 2017 @09:25PM (#55721063) Homepage

    The big one I've seen with my current employer is that they've failed to expand their IT staff as the organization as a whole has expanded. The predictable result is that nothing but the most urgent requests gets handled promptly, and minor problems fester indefinitely.

  • by Anonymous Coward

    Is definitely a mistake. Lol

  • by Anonymous Coward

    Look at all the boobs in charge, and look at all the places no one is in charge. It's a fucking looney bin.

  • by Anonymous Coward on Monday December 11, 2017 @09:26PM (#55721073)

    I recently worked for a startup with a real big asshole brogrammer who never was in the office and always was misunderstanding what was going on. Eventually I caught on to these charades. He was also lying to investors about our startup actually containing AI when it couldn't have been farther from the truth. To cover my own ass I sent a text message to the CEO warning him that we were committing fraud. After that the mark was on my head. Our "brogrammer" calls me into a room and says that I'm toxic. I counter by asking him his working hours and if he understands what fraud is. Over the next few weeks regardless of what happened I was ripped into a room and told how toxic I was.

    Of course I was let go shortly after because the dumb CEO who always called me "his brother" was well aware of the sham and apparently didn't care. The crazy sociopath actually thought that I would still be friends with him after being fired. He also thinks it's some point I will come back to work for him, likely whenever that brogrammer finally leaves. I wonder if he knows that I'm planning on telling the FTC and his investors about this "AI" company. It's a bunch of regex matching natural language to appear as if you are speaking to a digital assistant. They're actually telling customers that this is a real AI system.

    I would call this a serious mistake because their entire future is essentially in my hands. Since this Psychopathic CEO thinks I'm his friend and going to keep the lid on this, he's just plodding along blowing his money on other endeavors. I'll just let him build a little bit more of a paper trail for me before I strike. That's what you get for listening to the brogrammer.

    • by redmid17 ( 1217076 ) on Monday December 11, 2017 @10:58PM (#55721525)
      Right now this post makes me think of Ned Stark and his paper shield, except that you don't really have a paper shield, merely a piece of paper with no writing on it.

      I hope to god you have some actual proof and can take it to the FTC. If you don't and you file a complaint, you might well be facing a lawsuit on any number of grounds. To be completely honest, I don't expect this to play out well for you
    • by lucm ( 889690 )

      I wonder if he knows that I'm planning on telling the FTC and his investors about this "AI" company.

      Nobody likes sour grapes. Learn from this and move on, otherwise you're just sentencing yourself to a lifetime of bitterness and angst.

      "Whoever is righteous let him be righteous still
      Whoever is filthy let him be filthy still
      Listen to the words long written down
      When the man comes around"
      https://www.youtube.com/watch?... [youtube.com]

  • Too many to list (Score:4, Interesting)

    by Anonymous Coward on Monday December 11, 2017 @09:26PM (#55721075)

    I've seen them all, but "buying products or services from Oracle" ranks pretty high up. Or more generally, putting faith in a vendor because of a glossy ad in "CIO Magazine" or somebody in management getting kickbacks. Nontechnical managers are incapable of making these decisions, but want to feel like they're in control, so they try anyway.

  • by greenwow ( 3635575 ) on Monday December 11, 2017 @09:33PM (#55721129)

    In about March, we started moving everything to Microsoft, and they audited us in August. About $250k worth of internal time later, they gave us the final bill. We didn't know, for example, you couldn't run Visual Studio Professional on Amazon on nondedicated hardware. Amazon charges $2.185 per hour for that which is $19,140.60 extra per year. We're paying $1,199 per year already for VS for every developer, so we assumed we'd be allowed to use it with no extra charges. We were wrong. I think the total bill after the audit was over $130k plus the extra almost $20k per year on Amazon. We don't even yet use Windows for production(customer facing stuff)!

  • by AlanObject ( 3603453 ) on Monday December 11, 2017 @09:35PM (#55721133)

    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.

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

      I think data backup is very important. What is even more important is making sure you can do recoveries from the backups. (And keeping older backups off site) Lessons learned the hard way at my former employer.

    • by Nethead ( 1563 )

      Almost every other failure can be mitigated but not this one.

      Oh, we mitigated around it. Thank $deity that Bitcoin was only about $700 back then.

  • When a company focuses on taking care of their Employees, then the employees can focus on getting work done, getting the client taken care of.

    Part of that is keeping employees skilled. You might think the worst that could happen is that they outgrow your company and move on because they've become highly skilled. That's not true at all. They could be underskilled and stay right where they are ...until the company goes under.

  • Like this? (Score:5, Insightful)

    by rickb928 ( 945187 ) on Monday December 11, 2017 @09:48PM (#55721187) Homepage Journal

    Arriving at the new hospital data center (a room 500 ft from the old data center) before anyone else (including IBM), doors open, snowing a blizzard out at 25 degrees, calling the CIO and asking him if he'd been in the room lately.

    Nope.

    Asking him if he had the electrical contractor's number Call it. There is not s single power outlet visible. Not one.

    Yeah, they closed up the walls and painted, the electrical sub never got called.

    Extension cords. Frantic 220 installs. Mangled sheetrock. The AS/400 came up about 5:30pm. I was secretly pleased our NetWare cluster was in failover...

    We got done about 10:30pm on a Sunday night. No one every asked if this was an IT blunder or or a contractor blunder, but I never discussed it with the CIO , ever. He paid the overtime. My boss was litersally, genuinely speechless, a first for him. This was the same client who had a Token_Ring network that would beacon furiously on a regular basis. IBM took three months to say they couldn't do anything with the CAUs/LAMs, and they should come out and be replaced with switches. Took me asn entire afternoon to find the loose DB-9 interconnect on an 8230 chassis, the ones that were welded on back then. Bolted it in place, problem solved, we did put in the T-C switches during the move. I credit Laura Chappell, her presentation on Token networks at Networks Expo when she was with Novell, and Lanalyzer, for making me a lot of money. Thanks you, Laura!

    Now there was the client who, after much analysis, believed his app vendor and replaced our 16MB Token-Ring network with 100Base-T, since they were adamant that Ethernet would outperform Token. This required recabling, drops from the ceiling, because we had reused the existing Cat 3 PDS in floor trays, but that wouldn't do for 100Base-T. No, it made no difference. The vendor them blamed NetWare and AdvantageDB, and in came the NT 4 server. The IT supervisor was the owner's son, but that's not why I questioned his competence.

    I don't know how that came out because they wouldn't use us for that, we were a 'NetWare shop', despite my finishing my MCSE. Fine. I know the new guys presented migrating NetWare to NT at our Novell user group two months later. That's how it was back then. Feh.

    • Re:Like this? (Score:5, Interesting)

      by Richard_at_work ( 517087 ) on Monday December 11, 2017 @11:18PM (#55721625)

      A month or so after I was "promoted" from lowly developer to "Systems Infrastructure Manager" during a whole-scale move from an old green screen AIX based system to a brand new in house custom rewrite in modern tech, we had some of the new replacement hardware onsite and being built up (although the replacement applications werent ready to go, but thats not important to this story).

      One friday, the UPS support contractor came in to do his servicing of the UPS - that went well, he finished up and switched it back from "bypass" to "protected". That triggered a surge on the electrical supply to both server rooms, which took the AIX box off line. Due to the nature of the green screen application, there was no way for it to be high availability - the data couldnt be replicated in real time, it didnt even talk to anything other than its own binary database files...

      A few hours later, the corrupted AIX box was restored and ready to go - by this time, the company (a busy call centre) had been on manual processes for the entire afternoon. On the advice of the UPS contractor, who said the surge was probably the result of too much load on the UPS at the time, we decided to do a full shut down of the entire system, switch the UPS back over into "protected" and bring everything back up - so we waited until 6pm and did just that...

      At 6pm, I threw the switch - and promptly looked over my shoulder at the comms racks behind me in the server room. The comms racks were billowing smoke. The comms equipment was burning. Before I could react, I heard loads of loud pops and bangs - both inside the server room and outside it.

      Another surge. This one did real damage - a dozen network switches dead, over 40 PSUs in the servers dead, one server dead outright, and loads of call centre desktops went (loudly) pop.

      Panic time. UPS contractor called back in - they gave the UPS a clean bill of health and promptly left, disavowing any responsibility.

      The board of directors shat themselves - at that point we didnt know the ultimate damage count, but suffice to say the company was dead in the water to any observer.

      Cue a desperate night of testing servers, pulling dead PSUs and swapping redundant PSUs between servers so that each server had at least one good PSU. Comms equipment was harder to solve, having to get some expensive switches from our local shop to tide us over. Desktops were bought from the local consumer PC store to give us enough desktops to run the company.

      Ultimately, we were back up and running for 8am Saturday - it wasn't pretty, but it was up and running. 3 of us in the IT tech team worked through the night scraping the bare minimum together.

      My predecessors DR plan was fleshed out to the point of "we have a DR site" (a commercial site a town over that we had a contract to use - no equipment there, no plans for how to fail over to it etc etc).

      So, on to the management failure....

      It just so happens that one of my things "to do" on the following Monday was to submit my DR plan for the "new world infrastructure" to the board, who were having their quarterly board meeting the following week (10 days after the company almost died). It was a modest one, but required some equipment outlay to make any DR event as smooth as possible - kept the same contract with the off site unit etc etc.

      They turned it down, said it wasn't needed.

      I quit the following week.

  • ...was caving and hiring the the admin by boss, the CEO, wanted me to hire, not the one I wanted to hire. Badddddd mistake, but she did end up letting me fire him after a series of highly visible fuckups.

  • Know your limits (Score:5, Insightful)

    by AHuxley ( 892839 ) on Monday December 11, 2017 @09:57PM (#55721233) Journal
    Know what results are needed.
    Does a medical database have to track phone calls, public and private databases to ensure every person who had a test got their results?
    If a person had contact with a professional over a result? That person never got a result and never saw the professional after a test was done.
    That a person actually got their results and did not move to another part of the country?

    Bring in an expert who has worked with the exact problem around the world and who can make a database work in your country.
    Real skills and the local experts get network and database they want.
    Have political and gov move in and demand they be allowed to build the network with gov staff and other contractors who have no skills.
    Thats how big gov can fail.
    Take a project from the gov that has the skills and give to the politically connected private sector.
    The contractors have no skills.
    Thats how contractors can fail.

    Stop using people with no skills. Stop allowing people to work on complex projects who did not pass their exams and got given a decade of social advancement.
    IT can work if the right experts in the private sector, gov, mil or as contractors are found.
    Stop advancing very average people with no skills into the IT sector every generation.
    Find professionals that can understand complex problems.
  • Sunk cost fallacy (Score:5, Insightful)

    by DeplorableCodeMonkey ( 4828467 ) on Monday December 11, 2017 @10:06PM (#55721279)

    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.

    • by Chrisq ( 894406 )

      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.

      I'll second that. I have worked on a project where literally everyone knew that we were not going to deliver. We had bought a package that did not do what we wanted - not even close. Within the first week of the project we were saying "get something else, this was a purchasing mistake, or let us develop something". After a meeting with the manager and supplier, it was agreed that the supplier would customise the package - which was a surprise as this was almost to the extent of customising a toaster into a

  • Cloud computing ... (Score:5, Interesting)

    by CaptainDork ( 3678879 ) on Monday December 11, 2017 @10:07PM (#55721281)

    ... it was actually just RDP to a remote server.

    At the first management/vendor meeting, I got to ask the first question: "How will response time compare to what we have now, with our servers in-house?"

    "Oh, it will be much faster!"

    It got worse from there.

    I asked the owner if he knew that light slowed down in a medium and he said he did.

    We already used RDP to the desktop and he KNEW about the latency.

    Management ignored the red flags I threw on the play and put everything on the cloud against my recommendation.

    We were a law firm and a time came when an elderly couple traveled from far away to sign some wills and the goddam cloud was down.

    The family law practitioner blew her fucking top and confronted me and told me to implement Plan B.

    I told her, "Ma'am, Plan B is Plan A."

    It cost a fortune, but they paid termination fees and put everything back the way I had it before they went nuts.

  • by aaarrrgggh ( 9205 ) on Monday December 11, 2017 @10:10PM (#55721303)

    We were on Linux for our file server for a decade and ended up needing to switch to Windows. We were tired of not having a good consultant and Windows consultants were easy to find.

    The mistake incidentally was not in switching to Windows per se; it can easily do the added tasks we need of it and Linux could not. The mistake was in thinking the issue was in finding good Linux consultants-- the issue was simply in finding good consultants period.

  • by bigdady92 ( 635263 ) on Monday December 11, 2017 @10:23PM (#55721359) Homepage
    There ya go, enough content for several years worth. May have to go through the wayback machine to find it but there is a litany of stories that still resonate to this day.
  • by hey! ( 33014 ) on Monday December 11, 2017 @10:38PM (#55721431) Homepage Journal

    Going into IT management.

  • I've seen many hardware projects run into trouble because the selected hardware platform is too small for the software. The temptation is huge to start the hardware project early. However, if you don't know how fast the software is, how do you know if the hardware will be fast enough?

    If the software is larger than the initial estimate (it usually is), and the hardware started too soon, then the hardware needs to be redesigned (often with software changes) and this is expensive.

  • Not firing, correcting, or demoting idiot managers is a big problem. Some managers are excellent kiss-ups, but treat their employees like dirt. Get feedback from their underlings, and if you see problems, do something about it. Sometimes with pressure from above they'll mostly correct bad habits, but if they don't, bootem!

  • A place I worked bought thousands of ink jet printers.
    Mistake #1. Not getting a supplies contract
    Mistake #2. They were a name brand printer will known for clogging cartridges and breaking. (I don't want to get sued so no, I'm not naming names.)
    Mistake #3. Bought a long term support contract and paid for it in advance.

    Result - they rented warehouse space to store the printers until the warranty ran out multiple years later.

  • by bcboy ( 4794 ) on Monday December 11, 2017 @11:23PM (#55721647) Homepage

    There's a widespread belief in IT that test code and UI are easier than other coding tasks.

    It's completely false. Both are harder than other coding tasks. Your senior devs tell you to assign these projects to junior devs because they don't want to do them. They don't want to do them because they're much harder than other coding tasks.

    It's win-win for the senior devs: they get easier work, and when the junior devs struggle, it makes the senior devs look even better. "oh, man, they can't even write a test suite. Well, I guess I should get the big bonus this year."

    Put your best devs on test and UI. Put your junior devs on the simple stuff: backend work.

  • by nine-times ( 778537 ) <nine.times@gmail.com> on Tuesday December 12, 2017 @12:16AM (#55721881) Homepage

    It's not the biggest problem, but it's one that I've seen a lot and isn't often recognized: Trying to fix organizational problems with IT systems.

    What I mean is, if people aren't doing their jobs because management won't enforce the rules, you can't fix that by putting in an automated system that notifies people that they aren't doing their jobs. If people don't know how to do the job because they're dumb and untrained, you can't just give them a sign-in to online training courses and expect them to catch up.

    Things like management and training take effort and attention, and until AI gets clever enough to make managers obsolete, an automated system isn't going to do it.

  • by brausch ( 51013 ) on Tuesday December 12, 2017 @01:43AM (#55722205)

    Make sure you actually can restore. Do it regularly. Restore to different hardware. If using tape, restore using different tape drives. Make testing restores a routine thing. When I was a boss, we did daily backups onto tape and same day read the tapes at the offsite recovery site (about 30 miles away).

    During my career, I've seen two restore failures where they'd been backing up for years but the backups were no good and they had no idea.

  • by Notabadguy ( 961343 ) on Tuesday December 12, 2017 @02:17AM (#55722285)

    Doing business with Oracle.

    And Microsoft.

  • Peter principle [wikipedia.org]
  • I don't want to say politicians are stupid. Most of them are very hard working and smart. However they are used to giving instructions to some one else to give some one else to implement. This means when the time comes to implement something and the poor guy doing the job discovers the rules are contradictory he can't push back. The contradictory rules are literally the law.

    In Canada the federal government negotiates a pay contract with various unions to come up with the rules for how employees are
  • A company that I worked for outsourced the desktop to a company with low support/maintenance fees but high charges for changes or deployment of new software. This was done by a new IT manager without consultation of all departments, seemingly based on "My desktop changes a couple of times a year". Many teams needed regular updates, for example a web testing team upgraded several browsers monthly, developers had to apply security patches to local web servers to match production, etc. At the end of a year an
  • by sandbagger ( 654585 ) on Tuesday December 12, 2017 @08:10AM (#55723325)

    'Nuff said

  • by Gonoff ( 88518 ) on Tuesday December 12, 2017 @09:14AM (#55723591)

    It didn't cause serious company problems but the funnietst management mistake I have seen was...

    Manager buys demo copy of some "amazing" speech recognition package with a view to selling to cusomers.

    Manager: Set it all up.
    Me : I can install it but you will need to set up your voice on it.
    Manager: No! You set it up and do that tecchie stuff.
    Observation, manager has a strong southern English accent. I have a slight Scottish one.

    When he started to use the system expecting me, it made out less than 75% of what he said. I ended up assisting with that successful sale. The manager then spent the time needed talking to the system and it worked for him as I predicted.

    Apparently, the customer thought it was quite funny too.

  • by roc97007 ( 608802 ) on Tuesday December 12, 2017 @03:06PM (#55726707) Journal

    The most expensive, wasteful, credibility damaging, productivity reducing, and sheer chaos producing IT management mistake in my experience was the decision by a certain freight company to outsource IT. The two-letter outsourcing company, who will remain nameless, in sales presentations (which I attended) painted a rosy picture of a "right shore" solution with capable vendor-trained personnel in several call centers across the world, so that no matter what the local time, the call center would be on local daytime, which would help them draw the best talent for the job, etc etc. They were offering best-in-class for a fraction of the cost of in-house IT.

    Upper management, who honestly thought that the entire job of IT was to push a button whenever a light came on, bought it hook line and cancellation penalty. As is often the case, they shook their collective fingers at us and told us "you'd better document your job thoroughly before you leave". Devops, my department, maintained a fairly extensive knowledge base, so it was only a matter of printing out all of our written procedures and handing them over (with two hands, because it was a lot of paper)to management of the outsourcing vendor. And, they lost them. So we printed them out again and handed them over. And they lost the second batch too. I'm convinced that they never intended to keep them. (More on that below.)

    Our last day was Friday, which was also the cutover day. I had transferred to a department that was being retained, so got to stick around and see the carnage. It was fascinating in exactly the same way a high speed head-on collision between two passenger trains is fascinating. You're retching, but you can't look away.

    This was back when Blackberry was still a thing, and all the execs carried one. BES went down Saturday and remained down for two weeks. This was the sign to upper management that things were perhaps not going as swimmingly as advertised.

    The helpdesk was a shambles. You couldn't understand them, they didn't know what to do or whom to contact, and major incidents would just disappear in the system and never get addressed. Employees would come to those of us who survived the layoff and BEG us not to make them call the helpdesk.

    The outsourcing vendor shook their fingers at us and said that those damned former employees had not documented their jobs well enough. I had a (third) copy of our procedures, and the names of the managers I'd handed them to both other times, and argued that we had in fact made a good faith effort, just ask these people. Only to find out that those managers no longer worked for the company. Curious.

    The vendor said they could recover from our former IT employees' incompetence, but it'd Cost More Money. And that was the other shoe dropping.

    Some former IT personnel were rebadged, so occasionally stuff still got done. They worked long hours in very stressful situations. Most of them moved on as soon as the economy started to improve.

    Promises of a "right shore" solution were absolute fabrications. The entirety of IT, except for those few overworked rebadged employees, was a single call center in lower central India, manned by people apparently plucked off the street, sitting at card tables with IP phones.

    The company tried to improve response by sending a number of people over to India to train the personnel there, but ran into an interesting phenomena -- as soon as employees of the outsource service got training, they WENT ON TO BETTER PAYING JOBS. This training effort served to flush out the people with any experience, causing an influx of new people who couldn't find an "enter" key with a gun to their head.

    A major plumb for people who got a little experience was getting off night shift, which was our day shift. So as soon as we'd built a relationship with an admin and taught him to do valuable things, he'd brag about how he's finally getting off night shift, and we'd never hear from him again.

    Speaking of which, I don't think th

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...