Why "Running IT As a Business" Is a Bad Idea
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.'"
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.
ilovegeorgebush
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).
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.
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.
Assorted stuff I do sometimes: Lemuria.org
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".
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
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.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
This concept will only work in an 'enlightened' company, ie one that IS IT. In a company that sells things or services, it's all based on how many beans you can count. If you have this completely integrated IT organization, how does the company keep the IT budget under control? Unless you segregate the work into it's own silo, and then yell it like those Burger King "Angry Whopper Onions", how will costs go down.
No one sees IT as a partner. We're not even a business unit in a company. We're a collection of desklamps and staplers. I've seen management boggled by the fact that a Windows SA doesn't know anything about tuning an Oracle database. "But you're IT!" I've seen very skilled people moved over into jobs they are not trained or qualified for, and then eventually let go because they didn't have the skills for the job.
I haven't seen many companies that don't down right object to the fact they have to pay for IT. They don't blink at ordering 1000 new business cards for all the sales people, but ask for a $50 piece of software and you might as well be Oliver asking for more pourage.
Outsourcing has just made it easier for them to do this. How are you going to have a strategic partner doing IT, when the IT person you are dealing with is loyal only to the contract you've signed with them and really could care less if the company is growing or not, as long as they get paid.
Yes, I'm bitter. I'd love to see the fantasy land where IT is cherished. Especially outside of an IT company. I haven't seen it.
And in some places I have worked you would now get the following...
Were you authorised to show these people CutePDF? Who gave you permission to to install CutePDF on their machines? Did you fully evaluate CutePDF to certify that it is the Best of Breed? Are their security implications to using CutePDF? Who is now responible for maintaining CutePDF? Who is going to train users on its use? Has it been fully documented? Are change control and the standard image build team aware of this?
In such environments it is much easier and healthier to just not care any more.... the above situation is not uncommon.
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
His IT 'business' targets delivering the lowest possible acceptable product and uses monopoly power to set the price.
You have an IT department that does not do this? Are you hiring?
XML is a known as a key material required to create SMD: Software of Mass Destruction
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.
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.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
I don't care how good the pizza tastes if it's made with pig anus and old fore skin. So how something is made does matter under certain circumstances.
This occurred in the call center where a friend of mine works. Their clients only required a handful of calls to be recorded each month, so rather than invest in an expensive system to record everything, they do it by hand (they use Cisco Softphone, so it isn't as difficult as it sounds). They were going to purchase him a Creative sound card along with some crap Creative recording software. He asked if he could just use Audacity instead, since it is rock solid, he knows how to use it, and since it is under the GNU there aren't any legal issues. Their answer? Nope. Because it is open source, their IT department "determined" its use could lead to a security risk.
Sometimes, the asshole is puckered way too tight.
Living With a Nerd
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.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
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.
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.
This and no other is the root from which a tyrant springs; when first he appears as a protector - Plato (423 to 327 BC)
On the other hand, how many users have I had where I go to their machine and they say they are having a "problem" connecting to the web, and they open up an IE window with 5 or more toolbars popping up?
How many users have I had that installed Weatherbug, or some other little widget, and then complained a couple weeks later when their machine was overrun by various spyware/scareware apps?
CutePDF, for instance, comes bundled with ASS ("Ask") TOOLBAR. Pain in the ass to remove. Nuisance in terms of security. If you don't know what you're doing when you install it, that crap gets dumped in along with it, then starts opening you up and phoning home as well.
"If it sounds too good to be true..."
Yeah. It's like that. Get yourself into a large enterprise and there are reasons to be cautious. Hell, there are reasons to be cautious at home on a 1-machine network.
Oh I agree with you. This is why I now avoid working in large enterprises. The work is generally more satisfying in a small/medium size business. Far less tedious, time wasting meetings about nothing. And nothing beats actually helping people get there stuff done better because of you.
In olden days when I was a young IT pup, IT was generally considered to be a subsidiary of Finance, which made sense at the time since most computing was done to crunch numbers, so we worked for the number crunchers. Later, as IT evolved, it tended to stay under Finance because people who do inscrutable things are just seen as similar in the eyes of management. This led to serious conflicts as, say, order entry or inventory management wanted changes but all fell subservient to IT's overlords in Finance. Finance, understandably, didn't want to spend their budget supporting other department's goals.
Eventually, IT started either being broken out into subgroups and living with their business areas as scattered fiefdoms, or centralized and moved up the management chain so the CFO and CIO were on the same level. As this happens, managing the IT teams becomes a unique challenge, because IT is in so many ways integrated into all aspects of a company in ways that other organizations simply aren't. So you either have (potentially well-managed and aligned) fiefdoms that use different platforms that can't talk to each other, or you have a group that tries to meet everyone's needs with as few discrete solutions as possible and, at best, succeed partly at satisfying everyone.
Money spent on IT is almost always considered "lost revenue", and a holdback from the old Finance days of IT is that every department needs to justify its existence. Thus the chargeback model was born. So concepts like charging rent for floor space (forcing managers to vacate space that will never be occupied to save their "rent" costs, and cramming their people into spaces too small for them to work effectively) or finding a profit model for IT (forcing managers to forgo any systems changes that didn't actually save measurable amounts of money, even if the ideas really would help in the longer term) were born to try and force the idea of efficiency into each department.
Once you do that, you will always find that you can get a specific task done in the short term by hiring someone who can just solve the problem at hand without being bothered by all the consequences like incompatibility with existing processes and systems, long-term support costs, etc.
You'll also almost always find it's cheaper to do a crappy job on your project now while your expense code is on the line, and leave the cleanup to future projects who have to deal with it and spend more money to use what you've built (but it's on THEIR expense code).
Plus, of course, IT itself is given very finite resources at most companies (which is appropriate) and has to fulfill specific goals of the company to "earn" those resources (which is also appropriate).
But there's generally a lack of appreciation for the benefits that creative IT can bring to a company, so few companies give their IT staff much in the way of leeway to explore new technologies (outside those mentioned in CIO magazine and implemented "right away" with little input as to whether it's the right solution for any actual problem the company is facing, or even what the solution is meant to do, and most of those are explored by a consultant anyway).
"This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
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.
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.
When information is power, privacy is freedom.
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.
Actually, this is something I have always disagreed with. Software development is nothing to do with IT, except that it uses IT. The idea that software development should be under IT seems to me to be the same as saying that electronics design should be under the building maintenance dept. because they deal with the electrical systems. Corporate IT (infrastructure / networking / servers / desktops / support) is a totally different thing to software development. I think one of the big mistakes in corporate IT is to make one big 'geek dept'.
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.
Roger that! After working at few very large organizations, I finally called quit, waited for a good opportunity to come by (sat home, did one or two certification while waiting), and could not have been happier with a smaller company I work with now. Not only can I wear jeans and t-shirts, have flexible timing, I can also use Ubuntu or any other Linux distro as my desktop at work without worrying about standards, policies and all such fuck-ups.
And I get paid a little more.
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?
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Good for you. I recently left a large enterprise after 20+ years that had gone from being a fantastic creative place to a loathsome hole governed by policy nazis. Where I work now is still large but truly empowered and I no longer hate going into work each day. I grieve for my former co-workers who are managed by MBA's who think that aligning with the business will move them upstairs. It hasn't happened to anyone yet but they still hold on to their deluded dream.
Average Intelligence is a Scary Thing