Slashdot Mirror
Ask Slashdot: What Are Some 'Best Practices' IT Should Avoid At All Costs? (cio.com)
snydeq writes: From telling everyone they're your customer to establishing a cloud strategy, Bob Lewis outlines 12 "industry best practices" that are sure to sink your company's chances of IT success: "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." What "best practices" would you add?
ISO 9000
ITIL
TQM
CMM
You need to have to crawl before you can walk Management frameworks are for Olympic Class organizations.
Suggestion - Build your own policies, procedures, and get those in place so you know what the pain points are before you try to implement someone else's idea of what's ideal in IT.
Fred in IT
I am not talking about common tools such as email servers, word processing, spreadsheet...
But software core to the operation of your business. Companies will sell you massive enterprise solutions, filled with best practices and buzzword features.
However the effort in implementing this is usually much more complex and costly than a small team of full time developers to make simple solutions to solve the problems unique to the business.
These companies selling these solutions hire a team of full time employees just to support the company. Then they charge you for the software and their time plus the profit margin. So you end up paying more for features you don't use and extras that are hacked in and barely work.
Your organization offers solutions, products or services that are unique. Why would you expect software and best processes to be the same.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
ALWAYS avoid adopting technology that you don't understand just because somebody on your staff or a salesman with some glossy sales flyer says it will be great! If your manager shows up with the idea, convinced that it's going to be the solution to all his problems and won't take your advice on the matter, update your resume....The devil is ALWAYS in the details...
There is no silver bullet... Trust me, I've looked for years... However, that doesn't mean you cannot shoot yourself in the foot with a plain old lead round.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
From bitter personal experience, trying to implement the entire ITIL manual down to the tiniest detail instead of treating it as a guideline for what might be applicable.
Case in point: my former employer had a dated-but-usable change management and helpdesk system they'd used for years. It was due for replacement. They brought in a non-IT project manager to design it. Mrs. Non-IT Project Manager proceeded to treat the ITIL guidelines as some sort of roadmap, demanding the most granular, process-laden, cumbersome, needlessly-complex system I've ever seen. It was universally reviled. Nobody understood it. Nobody was properly trained on it. Tasks that used to take hours now took days. People started working around it, not using it, in order to get even basic stuff done. The system required a complete overhaul -- this time using actual input from the people who would be using it and/or served by it -- and eventually became usable at a cost and schedule far beyond the original mandate.
Meanwhile Mrs. Non-IT Project Manager was given a raise and promoted to somewhere where she couldn't do that kind of damage again.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
Best practice is code word to stop complaining and do it my way.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Forced password changes every X days. This just leads to people picking really shitty passwords. At one company I worked at for a while, they mitigated this by simply doing "simple word" + month + year. TOTALLY hard to figure out!
A directory service is good in theory but most it departements isn't competent enough to hande it, i.e. it will cost more than not using it. .
So every computer and server in the company should have separate accounts and passwords? I ask because having a common source for accounts and passwords across an enterprise (or even a small business) is one of the primary things a directory service does for you. Thinking about using Google, Facebook, or Microsoft accounts for you employees to log into company resources? Those are (outsourced) directory services as well.
Secondarily, directory services provide the ability to group users together for various permission granting. You grant rights to accounting resources to your "accountants" group and then you place your accountants in that group. When you hire a new accountant, you just put them the the group; when an accountant leaves the company or moves to a different job function, you take them out of the group. How would you accomplish this reliably without some sort of directory service?
If you are talking Microsoft's directory service (AD), you also have the ability to maintain consistent workstation configuration, which can be quite difficult without a directory service.
I believe it would cost you more in terms of time, effort, and mistakes you will make if you *don't* have a directory service.
If there's a best practice to avoid then avoiding it becomes a best practice, and then you should avoid avoiding it. Or something.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
therefore, buy IBM
1. Anything with rapid in it's name. Rushing stuff means it breaks. It may not break today, but it will break under heavy load when you're trying to do payroll.
2. Do It All At Once. Trying to change multiple things at the same time inevitably means you didn't understand the implications of the massive retraining, the fact that the sales force can't complete transactions fully, and the fact that the world ain't perfect like the software and hardware think it is.
3. Not having either rollbacks or testing, or cutting either or both of those. No rollback means you wiped the old server when you migrated everything. Now you have nothing. No testing means not just a few minor things will break under actual full user crush load, but that everything will break most of the time.
Here endeth the lesson.
-- Tigger warning: This post may contain tiggers! --
Also, Insource the IT from India.
Seriously, it's like every Architect, Developer, and Tester is Indian. The BAs too lately. Same problem as outsourcing through... no speed, no creativity, no ownership, no quality. Just confusion and half-assed results. And immigration for the whole familty. Good luck taking the PM roles from the angry middle-aged white women though!
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Or have very bad standards in the first place. That way, you are going to enjoy all "Web Application Worst Practices" that people can think of. I am currently assisting a customer wading thorough such a mess.
Also nice: Fire people that created and understand the application after they have finished, but before anything is documented.
And to top it off: Declare the proof-of-concept to be the final application. It is much cheaper!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I disagree with Bob's #6, that it is a mistake to charter IT "projects."
He says:
>
The problem is that IT does not have control over something like "increase sales effectiveness." It's nice to push that as a goal and justification for a project, but all IT can be held to is "implement Salesforce.com." That is our expertise and what we can deliver. Of course you can partner with other departments, but you shouldn't commit to nebulous goals that depend on them having their shit together and excelling.
Seems to be my employer's philosophy, anyway.
"UNIX is very simple, it just needs a genius to understand its simplicity." -Dennis Ritchie
I spend a lot of money paying Internet trolls to trash-talk linux in public forums so that my competitors won't run it.
From a book on Photographic Technique:
"Best Box. The Photographer has their Camera Bags. The Assistant has the Best Box. "Best" in this context is lost in History, but was generally considered as containing the most important Lighting goodies. The term dates back to Shakespeare. In Cinema, the person responsible for the Best Box is known as the Best Boy, regardless of gender. (Before "Boy" had any specific youthful gender assignment, it referred merely to a Servant or somebody useful, and maintains this definition in Ireland, where such people are known as "Boyos".) About two decades ago, a new term emerged, stolen right from Cinema- "Best Practices"; originally concerning Lighting. Anybody using this term these days off-stage is a fraud, and "Best Practices" is a phrase best commonly employed in the game of "Bullshit Bingo"."
As of NIST 800-63-3 forced password changes based solely on time interval is no longer a 'Best Practice'. Now the Best Practice is to expire passwords only when there is suspicion of account or system compromise.
Sadly it will take some time before the many organizations who copied the old best practice into their own documentation can step up to current best practice.
It seems "web architectures" are just becoming unnecessarily complex, perhaps because architectural purists are over-doing pet concepts (not just OO), or because we are all waiting for a new web UI/standard to be invented so that "web apps" are not so damned Rube-Goldberg-ified.
"We have to do it that way because the web has no state and is not a real GUI." We'll, let's find a way to give it real state & real GUI then, instead of fake it with blindfolded twirling back-flips, turning CRUD into Braille rocket science.
When I question the complexity, I'm treated as an over-the-hill dude who hates change. I just smell complexity creep and am trying warn people they are marrying a stack and not just dating it. They see "try new things" in the sense of "dabble in making a baby". (We'll, I guess that's what teens do.)
A typical shop's Dot-Net MVC architecture requires knowing MVC, Entity Framework, LINQ, Razor, and bits of other doo-dads. If all your ducks are lined up, then most of the architecture takes care of lots of stuff for you; BUT what happens when something goes wrong 7 years from now and you have to dig deep to fix it, say you need a database tweak, or a security bug needs patching in Entity Framework that changes its behavior, and nobody around remembers MS-MVC guts because it may be replaced by something new? I seriously doubt MS-MVC is the pinnacle of web apps such that it will likely be left in the dust by some Next Big Thing like most IT things.
I don't gettit. Can somebody mathematically prove this Dagwood-sandwich stack complexity is objectively the best we can do? It smells really wrong to me.
Table-ized A.I.
Make sure you FUND things like back-up tapes and document-security-review-and-inspection-staff. Certain parties like to cut their funds to sub-bare-bones.
Table-ized A.I.
Ahh yes, the "we really suck, but we consistently suck, we've got the ISO 9000 cert to prove it" argument.
Yes. That's the whole point.
True story. I used to work for a company that did low-cost assembly for big vendors. Razor-thin margins, which means that the whole business depends on a highly efficient supply chain composed of other low-cost suppliers. When it came to a specific production line, a change of less than 1% in components rejection would either cause a financial loss on the whole batch, or create an expensive shipping buffer which also incurred unsustainable losses. So at one point the company ditched a "mostly high-quality" supplier for a consistently terrible one. Being able to tune the production line and let it run at a predictable rate was immensely more profitable than getting fewer average component rejections.
And I believe this approach also works in large organizations. You don't want to have two sets of baselines for a big project depending on "how long will it take to get working environments"; you want always the same kind of environments and use that as a reliable figure in your planning. Both ISO 9000 and ITIL include continuous improvement mechanisms, but they're not higher priority than having a predictable, consistent delivery.
lucm, indeed.
Who have 20+ years experience in favor of outsourced "engineers" for 1/3 the salary and 1/10 the experience.
/ not bitter
Companies usually define IT as a cost center because money goes into the pit and no money comes out. They prefer putting $100 into something and getting $200 out of it. Give the sales staff a huge expense account and huge sales commissions and the money just pours in. Give the IT staff entry-level pay and continuously cut their budget because all you ever see is money going down the drain quarter-after-quarter. At some point they determine they really don't need IT and they save even more money. #Fail
Oracle, SAP, IBM and other expensive licensing deals.
You can't handle the truth.
Goes with #4. Internal Chargebacks. If you do internal chargebacks, make sure they are lower than what it'd take a consultant to do the same job. I've seen the chargeback rate so high, it was easier for the developers drive to the store and pick up a Dell Server (or whatever), and install that instead of buying the IT Server Service. Then you have piles of "rogue servers" running around and a valid business reason to undermine your own IT department.
When you spend $1M on IT and IT collects $5M on chargeback, making the "Service" profitable, at the expense of logic and reason, and leading to outsourcing.
If chargebacks reflect the cost of providing the service, and are lower than can be obtained elsewhere, then it will only be a good thing. It demonstrates the value, and prevents budget squeezing.
Learn to love Alaska
Active Directory is good, until it's landed with too many insane Group Policy Objects. Seriously, it'll make some people's lives just a living hell, especially developers. It's astounding what will fail to install when you can't check for updates. But, then again, you can put them and their machine in a different group with a different set of policies, but I haven't been to a shop yet that realizes that's totally a thing.
And yea, let your developers have the latest OS and updates. Make them the canaries in the coal mine. They'll appreciate the freedom and understand when it goes bad.
If $100k is a cheap tape system then I've got a cheap bridge to sell you.
LTO5 drives come down in price a lot since the newer LTO types have come out, and you can hold a lot of stuff with staggered backups over a few of those 1.5Tb tapes at less than $30 each.
It doesn't take a massive amount of data before the combined drive and tape cost beats external USB drives.
The important thing is so long as you have something that is not actually connected when disaster strikes. A tape or USB drive that is not physically connected to the machine when things go wrong is the idea.
No technology will help if you have shit processes and petty politics. Don't blame the tech, blame the shitheads.
No joke. It's a surefire way to grind your IT department to a halt and the rest of the company along with it.
Number one on that list should be "Make people remember ridiculously long passwords, force them to change them every other day and make sure that they have to invent new passwords every time, with no semblance to any of the past 1000". Not only will you ensure that your help desk is drowning in "I forgot my password" calls, especially after days like Thanksgiving when there's a 4 day weekend, it will keep people busy coming up with new passwords.
Number two is of course "and don't write it down". So you can make sure that people not only get creative in how they note down those 12+ character word salad you dished out to them, you can also make sure that they don't dare to talk to you anymore lest you learn where they wrote it down.
I think you can easily take it from here. Make sure you don't forget to keep the storage team busy with ridiculous "Best Practice" backup requirements that are impossible to fulfill and you should be the best CISO ever. Well, at least on paper. And we all know you only make big leaps in your payment when you switch jobs, something you'll do often if you heed the IT Security Best Practice recommendations.
Because you'll leave sunken companies behind you.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Flash is a horrible flaming turd of an application/platform that is depreciated and can't die in the fiery pits of hell as fast enough. They could never figure out what it wanted to do so they they tried to have it do everything and to sell it, they gave PHBs everything they asked for that could technically be rammed into code (notice, I didn't say "work"); thus causing today's problems. Please try to help along its demise as expediently as possible by getting it out of your organization.
[I know, tell you how I really feel.]
"Be particularly skeptical when presented with evidence confirming what you already believe." -
That's an interesting made-up story.