Why "Running IT As a Business" Is a Bad Idea 364
snydeq sends along a provocative piece from Infoworld, arguing that the conventional wisdom on how IT should be run is all wrong. "Bob Lewis dispels the familiar litany that 'IT should be run as a business,' instead offering insights into what he is calling a 'guerilla movement' to reject conventional 'IT wisdom' and industry punditry in favor of what experience tells you will work in real organizations. 'When IT is a business, selling to its "internal customers," its principal product is software that "meets requirements." This all but ensures a less-than-optimal solution, lack of business ownership, and poor acceptance of the results,' Lewis writes. 'The alternatives begin with a radically different model of the relationship between IT and the rest of the business — that IT must be integrated into the heart of the enterprise, and everyone in IT must collaborate as a peer with those in the business who need what they do.' To do otherwise is a sure sign of numbered days for IT, according to Lewis. After all, the standard 'run IT as a business' model had its origins in the IT outsourcing industry, 'which has a vested interest in encouraging internal IT to eliminate everything that makes it more attractive than outside service providers.'"
He is correct (Score:2, Insightful)
He actually hit the nail to head with this. This is the thing most people working with IT or geeky professions miss, and why they think everything free and such is so great movement. Business DOES NOT work on mere technical things. Nothing in the world does.
This all can be really put into one line: People don't care what you do. People care about results of what you can enable them to do. If you provide that, great! If you dont and jab about "better ways" to do things while costing time and money, then.. sorry, but bye bye.
As a more slashdot friendlier terms, do you really care how a pizza place makes your pizza? No. You only care about how good it tastes when you eat it.
Nicely put (Score:5, Insightful)
I work for a large insurance company in the UK. I'm a 'senior developer' if you like. One of my biggest gripes? The notion that work on the website - for a purist such as myself (and web designers and editors that also work on the site) - is subject to zero requirements, the 'customers' want everything for nothing, time-based 'estimates' that are taken as the law of the land. Every approach the customer wants you to implement is never in the right frame of mind for how the web works (noone understands the medium in which they're presenting to the customer outside). Your work is governed, oriented and OK'd by people who have no interest in how to do things properly. Fat-cat bosses who think their 10 years experience in Fortran 30 years ago makes for true understanding of how a website should work. Their way, no matter how stupid it seems to you the unenlightened one, is the right way. Trust me, I'm a fat-cat!
What ends up giving way? Quality. And it pisses me off. I can't do my job properly. Code reviews, unit/mock/functional testing, analysis, UML *all* have to give way because of all the above and just to get it out on time. Maintenance costs increase, but as long as it's out of the door it's OK. Would you build a house without blueprints? Would you remove an accountant's calculator from their desk because *you* don't work that way? Nope. [Excuse the crude analogies, they still get the point across]
The following sums it up well:
I've always hated this is approach to web development and steering change on websites. It's backwards. Archaic. Frustrating.
Re:He is correct (Score:5, Insightful)
You've got part of the idea. The main problem in IT is that since we don't actually make a profit off anything directly (unlike the pizza analogy), what accounting/management sees is a department that's better at making pizzas for less than last year. As such, they figure that it would be *even better* if you could, perhaps, make a substantially similar pizza with less people and less money.
Keep that going for a few years, and you end up with people wondering why it takes so long for their pizza to arrive, and why, when it does, that its missing some of the requested toppings and the cheese is partially dehydrated Velveeta.
The perennial problem of IT: It's benefits are several degrees removed from its efforts, from the POV of an accountant. No direct revenue generation means "less spent is better", with no solid way to quantify the benefits of having a well funded, well populated IT group (as opposed to not having one or both).
Sounds like a cop-out for bad customer service (Score:3, Insightful)
Right idea, weird reasoning (Score:5, Insightful)
While I do agree that running IT like a business is often not the best way to go about it, some of the things said in the article are simply bizarre. For example, what does this even [b]mean[/b]:
Instead of reacting to users, he should be their peer. Primarily, I asked him why he didn't transition from building Web apps to instead creating a solution using cloud technology and true mobile devices like BlackBerrys, iPods, and emerging tablets. He could offer a better solution, at about a quarter of the cost.
While buzzword compliant it doesn't really mean anything.
Re:IT Are Like Janitors (Score:5, Insightful)
If you run a factory, that's true. In almost every other business, it's not.
IT makes 90% of what goes on in a modern company possible at all. ERP, CRM, CMS and about three dozen other "tools" are as vital to a company today as hammers and workbenches were to a craftsman hundreds of years ago. Janitors aren't. They clean up and we don't want to miss them, but they don't run the company.
IT isn't the brain of most non-tech companies, but it certainly is the heart - it keeps the blood/information flowing through the veins/channels. Going even a few hours without it is noticeable in most companies, IT going down for a day is the corporate equivalent of a heart attack.
Re:Sounds like a cop-out for bad customer service (Score:5, Insightful)
Really? Where I'm at, as IT gets progressively more like the exact thing TFA advises against, I think "customer service" is actually getting poorer.
Back in the day, users would send an email to IT to get stuff fixed. If the problem warranted, a discussion would develop, an agreement would be made, and work would be done.
Today, we have a faceless ticketing system where users are forced to fill in drop downs that categorize their problem, to make sure reporting is nice and easy for the management. If IT has to query the user, they're supposed to put this query through the ticketing system. Direct communication is becoming less and less desirable, as is customization. If a user asks for something special or unique, the response is almost always "we don't support that".
NO (Score:2, Insightful)
Posting anonymously for my protection. As a long time sysadmin and somone who provided phone based tech support for a couple years as well, I hate the whole IT a business thing. Whenever I hear a manager say something like "we're here to serve the customer" and they mean other employees, it tells me that the manager fundamentally doesn't understand how good IT practices work. As a sysadmin, I'm supposed to have the power to tell a co-worker that the password they are using is too weak or that they need to use this program instead of that. Or that we can't do what you want on the server or network because its too insecure. They shouldn't have the right to override the technical decisions of people with more experience with them. Especially when it comes to security.
Employees are not customers, they are employees. They are paid to do their job and follow the rules. If they can't, they should be let go.
Poor communication skills (Score:4, Insightful)
The article highlights the flaws of poor communication skills, attributes these flaws to "IT as a business", and then suggests a new method...which is just as susceptible to communication flaws.
I dig what they are trying to say, I really do. But it's nothing new, and certainly nothing beyond what we already have.
My perspective after 20 years (Score:5, Insightful)
Bob Lewis dispels the familiar litany that 'IT should be run as a business
IT is a service, a service that makes your business run better. And the better that service is shaped to your business, the more adapted to how you work, the more efficiently your business operates. The biggest payback from IT is saving money. A dollar saved is better than a dollar earned. A dollar saved is pure profit. A dollar earned you have to subtract the cost of overhead and doing business.
Too many times IT people operate from a perspective that's more religion than service. The time to upgrade to Windows 7 is not when SP 1 comes out, it's when upgrading saves the company money. A service mentality does not try to force-fit technology where it doesn't belong. Maybe not everyone in the company needs Windows 7. Maybe the call center can use Ubuntu workstations, maybe the graphics departments work more efficiently with Macs. A service mentality focuses on what works best for the company and saves money, not what your technical people know and where they've invested their training. Yet I see that a lot. Not what works best, but what the techs know. Their expertise limits their technology choices instead of expanding them.
IT-as-a-business also positions it as antagonism (Score:5, Insightful)
Ideally, as someone who isn't in IT but uses technology, I like to think the IT guys are on my side. If something is broken, and I can't fix it myself, or something could be better and I can't improve it (due to lack of knowledge or resources or access), they're there to help me out. Setting up IT "as a business" fundamentally changes this way of thinking about things, though. My group then sees IT as a cost center: we want to use as little of their stuff as possible, or we might get billed for them doing stuff for us. IT sees us as customers to whom a bunch of crap can potentially be sold, generating revenue for their IT business.
Outsourcing in general sucks (Score:1, Insightful)
I'd say in general that outsourcing anything sucks. I suspect the only exception is if the business is very small - too small to occupy at least one full time person. After that, you're better off bringing it inside, whatever the role.
Depends on how you run your business... (Score:2, Insightful)
Re:IT Are Like Janitors (Score:5, Insightful)
Do you drop your trash on the ground wherever you please? Why not? You are far more important than the janitors, both by title and salary.
Why not let the janitors follow you around and clean up after you as you constantly change their job requirements? YOUR job produces the revenue for THEIR salary, right? They should accommodate your wishes at all times.
Oh, wait, if you did that, you'd just be an asshole. The amount of extra babysitting you'd require from the cleaning staff means other coworkers aren't getting the support they need.
Your petty "IT are just janitor schmucks" attitude is self-centered, narrow-minded, and utterly detrimental to the company as a whole. All you amount to is being the jackass that never flushes toilet 'cause he's too important.
Re:Sounds like a cop-out for bad customer service (Score:4, Insightful)
I think you really hit a nail on the head here. The trick is that "a business" has one product. If you go to ford you expect to get a car. They are "customer oriented" I'm sure, but if you ask for a pizza, you won't get it; or, if you do, they'll charge two thousand bucks and get a car designer to deliver it to you.
IT can't work like that. We also went to the "faceless ticketing system" and now our IT managers run around worrying about "submerged IT"; or basically business people doing it themselves. That's obviously going to happen if the IT people aren't involved in doing what is actually needed for the business.
Economics versus Job Satisfaction (Score:3, Insightful)
I personally try and produce code that meets and exceeds the business requirement, and does so within the time-frame set by the business. The problem, I think is that software engineers, in general, are a bunch of perfectionists, and we like to hold off announcing a 'final version' until the last possible moment. (Google Mail was in beta for how long?)
What I have come to realize, though, is that it is not just the IT departments that feel this way. In general, there are some people in every department, of every company that belive that their performance would improve if only they had a greater measure of self-determination. Perhaps the number of people who feel this way is highest in IT, but it is certainly not exclusive to IT.
So what it comes down to, I feel, is that we are slowly drifting towards a business culture where the individual has more control over their job, and where sucess is measured by job satisfaction instead of economics.
At least, that's the direction I hope we are heading in.
Re:He is correct (Score:3, Insightful)
As a more slashdot friendlier terms, do you really care how a pizza place makes your pizza? No. You only care about how good it tastes when you eat it.
But you seem to have missed the biggest reason why you try to run IT as a business in the first place, and that's to make the business side come up with something resembling specifications or business needs or some sort of picture on where they'll be going with this. I've been working for some time now with a public service who has split off their IT services and trying to professionalize their relationship, but I see plenty signs of how it has been.
To use a baker's analogy, the service side (equivalent of a business side) would start projects that weren't really evaluated or even estimated and planned, they were just started and ran because they were needed to deliver some service. And it was a bit like starting a baker off on making dough, but they haven't decided yet if they want a pizza, a bread or a pastry, or for how many exactly. But they're pretty sure it'll need dough. And ultimately it turns out half of it was just to throw out and will never be used for anything useful.
Don't get me wrong, if IT manages to be involved in the business as a strategic partner and not just service delivery that's great. But my impressions, and I have worked at quite a few allegedly competent private companies too, that it's difficult enough to make the business side agree on what they want internally. And that's also one of the big points about making it a customer/vendor-relationship, you can't have 50 ways of going to the IT department for something. There has to be a process, a pipeline where they as a customer agree with themselves before ordering with IT.
I won't name names, but I've met big companies where it turns out different departments were trying to do the same thing using different software for no other reason than that they didn't know about each other's projects. That ordering process is also a point of visibility, what are we really doing and does this really make sense to do this combination of things? Particularly if you're trying to set some enterprise-wide standards, you're bound to crash with some other project that might be smart in itself, but would make you dependent on something you're replacing.
Sure, you can do all this without that strict division, there's nothing that explicitly requires it. But those that try, struggle....
Re:NO (Score:4, Insightful)
Not posting anonymously...
And not trying to start a war, but that attitude is exactly what is wrong with IT today.
Yes, we have to make sure everything is secure, obviously. But what you describe, the "Follow IT's rules or go find another job" is fucking stupid, and only encourages the Shadow IT in an organization who, without training or knowledge that we have, are liable to open up security issues that we don't even know about now, because they're hiding it all from us.
In my opinion, I agree with TFA completely, in that IT is no longer the Preventer of Information Services and slave to the end user...BUT...it is our duty to provide the business with the tools and education they need to efficiently perform their job role.
In other words...we're the fuckers driving the business, but we serve the business, not the user. By serving the business, our users are no longer our customers, they're our peers, helping us drive their efficiency and ultimately driving the business.
I dont "sell" my programming/etc to the users here. I write code which enables the business to be more efficient, and have better tools available to the end user than what they had before. Anybody that doesn't get that in IT is on a path to future failure.
You don't understand the article. (Score:4, Insightful)
The whole thing sounds like a cheap excuse for providing even LESS customer service than IT departments deliver already (and most IT depts I've worked with have already been FAR from customer-friendly/b>).
The whole point is that you're thinking about it the wrong way. There should be *NO* "customer" anything.
When I'm working on an important project, and need a critical piece of software or hardware upgrade, I certainly don't expect IT to drop everything and come running immediately.
What you *should* expect is for IT to be a part of the project from the beginning, rather than just being asked to provide something after the fact. They don't need to "come running" because they're already there.
Business School Ideology (Score:5, Insightful)
Interesting article. From what I have observed over the past few decades, there has been a steady growth in ideology in business schools and economics departments. These ideologies are usually simplistic models or sets of ideas that are supposed to be broadly applicable. Many of these ideologies have come and gone like fads. Many of them, while useful, are not axiomatic. Business school graduates often treat the "management" skill-set that they learn in school as broadly applicable to any field. Thus, MBA graduates may move between extremely diverse positions. I know of one that went from managing a train manufacturing plant to managing a food manufacturing facility. Because he had no previous experience with working with food, he faced significant difficulties both in making the food plant operate smoothly, and in making a profit. He didn't have a clear idea of where he could cut within the operation without endangering food safety. He lacked both detailed knowledge of production methods, and had a poor understanding of scientific principles. Under the ideology of business school, this person's management skills should have been directly transferrable between many different fields. The reality on the ground was quite different
In the case of the topic at hand, it seems to me that one particular model, consisting of customers and service providers with all such relationships entail, is not optimally applicable to a specific situation (IT). The economy, and the world, is far more complicated and subtle than simplistic and faddish business school ideologies.
Re:He is correct (Score:5, Insightful)
Re:Poor communication skills (Score:3, Insightful)
Re:My perspective after 20 years (Score:3, Insightful)
I understand what you are saying, and even agree for the most part, but:
Technology changes constantly. One of the important jobs of the IT department, and one that tends to annoy the people that pay the bills, is to keep the IT infrastructure from becoming so obsolete that it becomes unmaintainable.
Trust me, the IT department doesn't like upgrading stuff any more than you do. But you HAVE to keep things modernized. Would the company rather save $40k now, or have to spend $150k in 10 years to have all of their discontinued/unsupported/proprietary software and data migrated to new products? Not everything needs to be upgraded all the time, but there is a lot to be said for staying no more than 2 versions behind on anything.
That's the biggest issue in IT, I think. Keeping yourself from getting trapped by old equipment/software. It's a treadmill, yeah, but you are either running or falling off.
Re:He is correct (Score:3, Insightful)
Er, I highly doubt you'll be making the same wages as an accountant at either place. Any place that can be described as "local" isn't often going to employ a dedicated accountant. You're going to need to pick up several accounts to work out to the same pay-scale, and then you're going to be expected to provide the same level of service _to each one_ that a single dedicated accountant would be able to provide. So, good luck doing more for the same pay, only now it's more difficult because you need to fix your own damn computer when it breaks.
Re:He is correct (Score:4, Insightful)
Ya if they really wanted to run IT as a business what they would have to do is, at the start of a project, negotiate how much the project was worth to the business and what IT's cut will be. They could book that as profit. Projects that simply don't have enough ROI for IT would be left to twist in the wind. The same thing could be done with incidents maybe at the category level. Have people decide what the potential loss/hour is on an incident and book that as cost savings IT generated for the company. If an incident isn't losing quantifiable money then don't expect anyone soon.
IT does book profit but the problem is that if we make accounting more efficient with our hard work all the accountants get nice bonuses and we get to go fuck ourselves.
Re:He is correct (Score:4, Insightful)
Well, what if everyone wanted to use their own custom solution? This might not be an issue in a company that has 4-10 employees, but one with 100-10000 surely is going to be.
That's a false dichotomy. Most people will get along just fine with the standard stuff, but not everyone. Real life is a constant barrage of exceptions - so too will be any large company. A good 'system' is flexible enough to accommodate those exceptions with ease. Trying to standardize/squash out the exceptions just leads to one of two results - the creative employees leave and all you've got left are drones who will eventually trap the company in mediocrity or "midnight requisitions" where you get exactly those kind of "idiots who think they're the best and then break their computers." Any system designed to go against human nature rather than complement it will eventually result in total failure.
bad management (Score:4, Insightful)
Don't confuse problems stemming from bad management with problems stemming from a bad model.
The idea of internal customers comes from Total Quality Management. TFA bears absolutely no resemblance to TQM. TFA describes what happens when you have the old style business structure (divisions/departments) and a pointy-haired boss learns accounting are calling IT a "cost centre" and then mistakes an accounting technique for a management technique.
People like to blame accountants for this, but that's because... accounting is a different department. Sure, this "hairball" IT system I'm supposed to be in charge of is all someone else's fault, but that "chargeback" system, well accounting is in charge of that aren't they!
FWIW TFA is quite disappointing for Infoweek. It displays numerous hallmarks of a self-help book. It massages the ego by implying that yes, you are being looked down upon, you should be more important and given more freedom and control ("IT should relinquish its increasing stance as an order taker, and earn and advance its intended role as the qualified engineer of what makes a business hum"); it's all someone else's fault ("hard to get the business leaders to step up"); and genial bashing of accountants in order to be all like-minded and chummy ("full employment for accountants"). Ironic then that all does is suggest adopting a business structure that has been core material in accounting studies since Japan started making cars, all wrapped up in executive-speak babble and buzzwords (unsurprising given the reference material).
By the way, most of the time people seem to assume doing the whole integrated thing will automatically be more productive and satisfying. It can be, but don't for a minute assume it's also easier. One thing the traditional model does supply is a command structure and set procedures - take that out and everybody finds they have to do stuff that previously they associated with management.
Re:IT-as-a-business also positions it as antagonis (Score:3, Insightful)
The problem is that fundamentally, every other 'business support' eventually finds that it cannot be ruled by business... and as such makes itself a profession.
Lawyers - check
Accountants - check
Constructions and other engineering fields - check
Trades people - check
Right now, I'm looking at the elevator and it has be inspected by a licensed inspector. Yet, I'm working on software that runs the very internet... and I know they can bring in someone who has no experience and no knowledge and no licensing to build and test the router?
Anyone see anything wrong with this picture?
Even something as simple as network management (CCNA style). No other field would let CCNAs operate routers. They'd all require a skilled person a degree and probably industry certifications (CCNP) to operate a basic router.
You can look at other fields like healthcare. They all turn themselves into a profession so they have something to stand on when faced with 'business'.
There are a lot of things a profession does
1. Ensures people are trained properly. Lawyers go through grad school, become associates, learn under a senior lawyer... Law is complex. You can't throw a new grad lawyer in the middle of corporate law. Yet, in engineering, I've been thrown into an issue where the core internet router of a major city was down... and I (the new grad software engineer) was thrown it to deal with the ISP and diagnose the problem.
2. Ensures Quality. You have a voice if you feel standards are being violated. Short cuts taken that threaten some higher values (security, stability...).
3. A sense of independence
You are in charge of this. No business person tells a lawyer how to do their job. Yet I'm amazed when business people decide how to run software or IT. Oh, just throw people at projects... that'll work. Don't value knowledge in the current code base. Sure!!!
I'm fully aware of the downsides of professions... there is no way technology would have been able to progress as fast if it were a true profession. People would use the profession as job protection.
I am fully aware of business' need to make a profit. I don't rant against that. But as all professionals we say... if you let me do my damn job... we'd save you money! Give me 5 professional software developers and 5 professional tests, and we'll do the job of 200. But I suppose being a business person with power trumps making money.
That said, I don't blame business people. I can only blame IT and engineers. We refuse to use professions. When we do get on top/management... we treat our underlings the way we were treated. Too many of us are timid and don't stand up for ourselves. How can we expect not to be trampled over?
Re:NO (Score:3, Insightful)
Screw it, I was going to mod a whole bunch of posts in this thread, but your comment is so stupid I just have to respond.
While you're right that "IT as a Business" is wrong, what your advocating is "IT as Lord high protector of all Technology" and its just as wrong.
IT must work to achieve the business goals, and IT's software must work to achieve the business goals. The buisness' primary goal is to make money, not to have secure IT. Sure, a secondary goal of the business is secure IT, but its SECONDARY to the functioning of the business.
When the business needs a system to perform some function it must either be:
1) involved in creating the product of the business
2) involved in managing the process of creating the product of the business (the accounting, sales, marketing, etc.) big area here
3) directly selling or distributing the product (web sales, digital data, etc.)
That's it. Your tight security is not one of the business needs. Now, for option 3 above, your site better be secure and safe and reliable, or you risk not moving product. But your security decisions in this case are to protect the business model, not to pretend you're an NSA agent. You need to reasonably expound on the business case for the security protection you want to install, because its an overhead cost to the business in producing the product. Do your risk analysis, show the costs, do the BUSINESS focused due diligence to achieve the security you need to have while still providing the services to customers that need to be provided. In too many cases I've seen security edicts that would rather shut down or routinely break a business function (many times for the lamest of reason) than be flexible or even cooperative with security policies and settings.
When IT touts security guidelines that live outside the business they're setting themselves up to get cut out of the process until all the people who keep the hard and fast "thou shalt not" security rules get pushed aside.
Its better to work with the business folks and present real business cases, that to point to some complicated software exploit and say "we need to stop this". The money you get paid should be used to support being able to bridge the knowledge difference and be able to convey a complicated software exploit to the business.
IT exists to provide the business with technology to do what the business needs to do. Too often IT embraces its separation from the "regular" parts of the company. And it always does this at its own peril.
Re:He is correct (Score:5, Insightful)
Re:Poor communication skills (Score:5, Insightful)
The article highlights the flaws of poor communication skills, attributes these flaws to "IT as a business", and then suggests a new method...which is just as susceptible to communication flaws.
I don't think you understood what you read else you couldn't have come to the conclusion you have. Right now, "IT as a business", creates a multitude of barriers which by their very nature inhibit communication. In many places this is actually by design and intent.
By stopping the impenetrable castle defense of IT from hiding behind ticket systems, voice mails, and layers of management, IT needs to be in bed with business. A shared pain is a fixed problem so long as money can be found. And if it can't, everyone understands rather than it being, "that damn IT group preventing my success."
Since IT is always treated as a cost center, the rest of the company is always looking to save money but axing IT. In turn, for IT to justify IT's continued existence, IT is always looking to build a billable project out of a mole hill. This does nothing but create an internal adversarial relationship between IT and the rest of the company. This in turn creates the human factors which create barriers in communication.
In most every large shop I've been in, IT actively works to provide value to the company and desperately wants to contribute to the company's overall success. The problem is, the entire rest of the company sees IT as a cost center and they are therefore actively working to eliminate IT, directly or indirectly. This requires IT justify EVERYTHING.
Until corporate culture changes, the "rest of the company" is the sole reason why IT not only costs more than it should but why mole hill tasks becomes a mountain of a project. Simply put, IT has no other choice as survival rides on it. Which finally brings us full circle. Companies have two choices; one, isolate IT and demand they justify their existence every day at every turn, whereby human factors take over, including breakdown of communication. Two, integrate them and empower them to help them help you; whereby IT's business becomes the company's success. Integration requires communication. The later of the two means those same human factors which cause so many problems in the first case, actually benefit the entire company in the second case. The second case is only possible with effective communication, and tearing down barriers is in everyone's self interest.
In short, communication is important to all businesses. The question is, are you creating barriers or enlisting everyone to assist in your success? Right now the common business mantra is the former rather than the later. If businesses want better IT bang for the buck, they need only look at their own corporate culture and ask, "how can I help you help me?" Synergy, when not used as a worthless buzzword, really can be a wonderful thing.
Re:He is correct (Score:3, Insightful)
Any system designed to go against human nature rather than complement it will eventually result in total failure.
I just wanted to underscore this. We have no opportunity to modify human nature. Think of it as constant pressure always bearing down. Failure will happen, so plan for it, just as you would any other force of nature.
Re:He is correct (Score:3, Insightful)
If pig anus taste that good, and is healthy, there shouldnt be any issue with you eating it.
Unless you have a religious objection.
Religious preferences in IT should not become an issue.
Replace "pig anus" by "Microsoft" or your favorite bad guy and then you sentence become:
"I dont care how well it works, if its made by Microsoft I dont want it"
Thats is just a stupid reaction. The problem is people are not objective. You hear "its pig anus" and their mind make it taste bad. If instead somebody tell you a generic dish name like "cajun style pork" it will taste just fine.
Now, obviously the fact that it taste good doesnt always means its healthy but you get my point...
Re:He is correct (Score:4, Insightful)
Yeah, the real difficulty is in presenting, "This is what your business would be like without the current IT setup."
It's kinda like "tax cuts solve everything" folks. It's a lot easier to say you want to spend less money, until you realize what services suddenly become much less available.
Service with normal staff levels: "I need an extra jack activated in my cube." "Sure, all the jack are pre-wired so I just have to turn on the port at the switch and you'll be good to go."
Service after staff levels are reduced to save money: "I need an extra jack activated in my cube." "Okay, I'll need to come by and figure out what your jack number is, then go to the closet and wire it, and then activate the switch. I think I can get to it tomorrow morning when I do a few of those in the same area, but I can't promise anything because I'm busy putting out fires."
Seems like a small thing, but small things add up quickly, and suddenly it takes a week to get a new jack lit up.
And then people want to know why, as if their shoulder shrugging at the cut in staff and resources wasn't the cause in the first place.
Rinse, repeat.
Typical (Score:2, Insightful)
This article isn't going to enlighten you or give you the secret to running a top notch IT organization. And neither are most of the comments that have risen to the top. There is no magic wand. Anyone that tells you otherwise is probably selling something. There's just hard work and a commitment to excellence with the acceptance that there are certain things which are inevitable:
1) You're in business to produce a profit. You're not in business to procure, deploy, or worship technology. Technology is a tool. No different than a screwdriver or a machine press or a clock. It helps the workers be more productive and capable of producing a profit. Nothing more. Nothing less. Used well, technology is power. Used unwisely, it's an anvil around your neck.
2) Organizations are groups of people. People in groups don't communicate well. People one on one usually communicate very well. Whenever you get a large enough group, there will be miscommunication and that thwarts most "techniques" or "methodologies" engineered to negate this effect. The sooner you realize that you can't engineer away humanity, the sooner you'll be successful in using one on one relationships to get most of your wins. ALL organizations will NEVER be in sync at any given time.
3) No matter where you work, there will be a bell curve of capability and skill. You'll have a few rock stars, most people will be in the middle, and there will be a few truly aweful people. It doesn't matter if it's Google or the Army or AJ's Nails and Hair. No organization can attract the best and brightest all the time for all needs. So even if you have good processes and good relationships, they won't always work and you won't always get good results. The best you can do is work hard to provide the best you can and accept the fact that not everyone you are working with is capable or motivated to do the same. Stop complaining and do what is reasonable to solve the problem. That will bring you the most success. And happiness. Read this again, and then lower where you think YOU are in the bell curve.
4) People are relying on you to guide them and help them to make informed and intelligent decisions. To them, what you do is scary and expensive and magical all at the same time. Keep the previous 3 points in mind on how they will present their problem to you and respond to the solution that you present to them.
I've been a CIO for everything from startups to publicly traded companies to companies I've founded. The principals don't change. Just the budgets and egos.
Re:He is correct (Score:5, Insightful)
From my perspective as an IT person - who has to spend a scary amount of time writing scripts and reverse-engineering various black-box 'off the shelf' software packages just to figure out how to install them, let alone get logs off them and get them to communicate with the rest of our IT infrastructure - I think most 'software developers' could really benefit by spending a few years in the IT trenches.
Software development really suffers from living in its own little bubble - a bubble where the developer thinks nothing of wiping and installing a whole new machine just to put their new package on, nobody ever needs to install patches, and there's no infrastructure. Software developers often seem to believe that their program is the world, a unique beautiful snowflake. Which is fine, it's their baby, they have some pride in their work. But a program is not a standalone thing, and a developer's job really isn't even started until they've worked out how their program integrates with everything else in a corporate infrastructure: how it gets deployed, how it gets configuration settings, how it gets updates (no, having an 'update now' window pop up to the user is THE WRONG ANSWER in the corporate world), where it emits logs to and in what format, how it talks to the Web server, how it talks to file and print, how it works on multiple OSes, etc.
And yes, this also applies to the new world of 'web applications'. Just because you've made a flashy new web service doesn't mean you've achieved anything - how do the users export their data, how do you send real-time updates to all the other web services on the planet, how do you track evolving standards, etc.
There's only one discipline in computing which is *all about* integrating the diverse systems that we all use every day - and that's IT! Hi there. You write the stuff - but we have to *make it work for us*. Sometimes that's amazingly difficult, and we just have to wonder what you development guys are smoking, and if you've ever tried to use your tools - or at least, use them in conjunction with anyone else's.
'IT' shouldn't be a separate thing. It should be called something like 'integration science' perhaps and analyzed like computer science.
For instance: making a very complex network configuration change is just like programming, but it gets no respect or tool support. 'Code' gets all sorts of IDEs, version-control systems - but can you version-control all the changes you make to your VMware images, Cisco switch configs, Active Directory schemas, databases, DNS entries, backups scripts? Can you manage all of these with a unified tool, as if they were all vital parts of the unified computing machine which in fact they are? No of course you can't. Why? What's stopping you?
The sheer diversity of incompatible tools, the lack of integration or standards, but mainly, the deep-seated attitude that 'IT is just janitor work' and that 'the real interesting challenges are in software development, not installation/support/deployment'. Sorry, but not from where I'm standing.
The network IS the computer now - so how about we get the tools we need to program that computer with a unified language? and save and load programs from it?
Re:He is correct (Score:3, Insightful)
You are Close. The problem with IT is that a lot of our job is maintenance that the users don't ever see or care about. With accounting and HR if you don't have enough people you get a backlog that shows up rather quickly on your balance sheets. If you think of IT as "those people who keep the PCs working" you will not notice when maintenance falls behind. Things will go on running until the lack of maintenance shows up as more downtime and then management will hire just enough IT staff to keep on fixing things but not enough to fix the underlying problem.
It's not just IT either. A few years ago the city of Montreal Canada realized it's roads were in bad shape and this was made painfully clear when a bridge collapsed killing a few people. It was discovered that every government for the last half century had simply been sending crews out to fix roads that were bad by scraping the pavement off the top and putting a new layer down. There was no substantive maintenance at all even though foundations needed redoing, leaky pipes were wearing roads out from underneath and so needed replacing and bridges had needed substantive repair. None of this was a new problem but because people could drive on the roads no one noticed until a few people died. Thankfully IT has less fatal consequences.
Re:He is correct (Score:3, Insightful)