Slashdot Mirror
Justifications For Creating an IT Department?
jjoelc writes "This may sound like an odd request, so first some background. I work at a broadcast television station, and I have found it to be very common for IT to be lumped in with the engineering department at many stations. I believe this is mainly because the engineers were the first people in the business to have and use computers in any real capacity, and as the industry moved to file-based workflows it has simply stayed that way. I believe there is a need for IT to be its own department with its own goals, budgets, etc. But I am having a bit of a rough time putting together the official proposal to justify this change, likely because it seems so obviously the way it should be and is done everywhere else. So I am asking for some pointers on the best ways to present this idea to a general manager. What are the business justifications for having a standalone IT department in a small business? How would you go about convincing upper management of those needs? There are approximately 100 employees at the station I am currently at, but we do own another 4 stations in two states (each of these other stations are in the 75-100 employee range). The long term goal would be to have a unified IT department across all 5 stations."
You believe there is a need for IT department, but even you have rough time determining what that need would be. If you cannot think of a reason yourself, why are you suggesting it to begin with?
This may be a bit naive, but maybe the fact that you're searching for justifications is a sign that you're not quite approaching this the right way. Maybe look at it this way - what is the need that this is addressing, the problem it would solve, the advantage it would give. You say that you believe that there's a need for IT to be its own department - why? Define that need clearly, then start working on the proposal from that.
Also, I'd give a strong thought to the relative advantages and disadvantages of the current system - it's easy to just disregard "the way things have always been done" as valueless, but processes evolve for reasons, and to at least a minimum level of functionality. Any change you propose needs to have clear, concrete, and valuable advantages over the existing process.
As background, I worked in an engineering department of a TV station for a while, and with the way things are going, engineering and IT are becoming far more intertwined and co-dependent on each other. Splitting them apart would, I think, be counterproductive - you'd end up with IT wanting to do their own thing and engineering being unable to make it work with their side of the house.
Having dedicated IT people and dedicated engineering people is a great idea, but they need a single leader to keep everyone pulling in the same direction (and some cross-training helps too).
There is already an IT Department, but it exists as employees, under the umbrella of Engineering. Creating an IT Department simply changes the titles and reporting structure, and adds a new business silo. The bigger question here is what needs are not being met that make you feel creating a new Department is the solution to? If it is a lack of funding given to IT requests/needs then whoever is leading the IT team needs to improve their skill at explaining/justifying IT requests. If IT requests made in the Engineering department fall on deaf ears (which is what I am assuming is occurring), and the company doesn't see this as potentially damaging, then creating an IT department, wouldn't solve the problem. It is a culture issue at that point. Believe it or not many people are bothered by IT expenditures, and are oblivious to the role it plays in operations except when it doesn't work properly. My advice to you would be to itemize what is failing to be met in IT currently and how creating an IT department resolves them. Feel free to post the reply/rant here. For the most part we've all been there, and or are currently there, and maybe we can help package the answers for you.
If it seems like the engineers of the station can handle it, what exactly are you looking to get out of a standalone IT department? They can be useful if the engineers are overworked, but really you should not try to shoehorn an IT department if it isn't needed.
Do you use Avid or another computer based editor there? Perhaps what the engineers are doing for their role along with IT isn't too much of a burden, or might be a way to clear their mind and work on something simpler.
My first reccomendation would be to check in with the engineers you want to "help". Second would be to check with whoever does budgets or accounting to see if there is any room for it...
Those who live by the sword, get shot by those who live by the gun...
Frankly engineering sounds like the right place for it. if you create an IT department then you will probably be pushed more under the business unit and that could be really bad.
You will go from "we need this to keep running" to "how will this expense increase profits".
Of course the real reason for this push maybe that the Author wants to move up and become a "department" head.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
In business areas where IT is a clearly defined discipline, different than what the primary business of the company is, where most, if not all employees have trouble performing their daily details without a clearly defined "IT function" within an organization, IT organizations seem to have sprung up as if they were needed, in all places where they were really needed. That they have not been (until now) clearly and obviously needed in your organization, suggests that the business need is not so clear cut. May I draw some parallels? I have worked in R&D environments around scientists and engineers, who know how to do most of the IT functions that non-technical people wish IT would do for them, and who actively resent some snot-nosed MCSE telling them how good Group Policy and locked-down IT environments are for The Business. May I suggest that what will (sadly) happen in your environment is that a major IT disaster will create the instant perceived need for Standardization and Lockdown. it is only a matter of time. Your most prudent course may be to do nothing extraordinary, but be there and ready with solutions when the actual animal offal hits the actual rotary air-movement apparatus. Warren
This is weird because being in the telecom biz for 20 years on and off, including working at a place that owned a lot more stations than the Poster owns, traditionally IT and engineering have always run separate networks and always been at each others throats. To the extreme of having two boxes on one desk, one on the eng network and one on the IT network and an air gap between the LANs.
Traditionally the way it seems to play out is the "IT" network is plain vanilla all microsoft centrally controlled and mainly focused on office drone productivity. Meaning the most specialized software IT supports is "Excel". The "IT" network swarms with viruses just often enough to terrify management at any suggestion of merging the IT and production networks (some "humorously" accuse the engineers of creating said crisis intentionally). The large IT network is famous for layer 2 routing loops (I can't believe they shut off spanning tree!) and whats best described as stupid OSPF tricks (like aggregating routes that are not "yours").
The engineering network seems to mostly be linux/unixy with not much central control (probably no lan wide file server, probably no wan wide DNS, believe it or not) although "whatever it takes to make a dollar" does fly so there is the occasional stand alone windows PC, which of course never gets updated because no one in engineering runs windows. Sometimes there is a firewall between the production network and the engineering network, or the eng network sometimes "dials into" the IT net via a VPN connection, but often there is an air gap. The secretary who clicks on every pop-up she sees in MSIE has no ability to access, say, the FM radio ad insertion box, although both are in the same building and have "something" plugged into their ethernet ports. Back in ye olden days I heard stories about salesguys hand carrying flashdrives with radio commercials audio files over to an engineer on the production network, I assume this still goes on.
This is also BAU common practice at ISPs and telcos and cablecos (kind of the same organization now, of course).
Some (some!) plants I've worked at are like this.. The CNC lathes and mills, or maybe the printing presses, and maybe the cad operators and/or preprint department live on one network, and the cubedrones in HR live on another network, and never the two shall meet nor are they maintained and controlled by the same people. Often, in the olden days, they used different technology, like if it was a "plant" the plant network was probably that 100-base-F fiber or whatever it was called and the cubedrones all lived on conventional cat-5 for obvious length limitations and also ground loop issues.
So that's your first job, decide how you'll interface the cubedrones with production/engineering, assuming they'll be interoperable at all, in any means what-so-ever. If you are not familiar with the telecom term/concept "demarc" well then you are in for a big education, thats all I can say.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
It's been my experience that in order to move people who decide on budget matters, stakeholders who are concerned about money...you have to focus on how your change will improve productivity for others, how it will improve cashflow, how it will make the company more effecient, how you'll make all the other departments able to make more money or report more news, etc.. If you can show that IT as it's own department makes money, or helps everyone else make more money, then it would mean that all the questions about cost go away. If IT doesn't cost them money, if it helps make money, then everything else is much easier to overcome.
Awk! Pieces of eight. Pieces of eight. Pieces of seven... ERROR: General Protection Fault. [Paroty Error.]
Depends on the size of the place.
Of course, engineering gets stuck with it at first because < cynical broadcast engineer mode > we are the only ones who can actually deal with physical reality </>... A separate IT department doesn't really start to make a lot of sense until you have radio AND TV who already have separate engineering groups with different takes on IT. CBS in SF has a separate IT group (run by a former radio CE) but that's with like 3 TVs and 4 FMs in the same building.
If your station is the hub for all 5, well, maybe but I think it might be a hard sell to the pointy-hairs / showbiz-money types. Maybe better off re-org'ing engineering with a separate IT subgroup and breaking out its expenses and tasks sepatately for the time being.
Eric
CE, KNGY San Francisco, back in t3h day
Looks like it's in your summary. Engineering departments are station-centric while IT scope is organization wide. Can you cite cases where local control trumped organizational needs? This is a bit of a tangent, but you might want to look into the history of the USAF splitting from the US Army. Both had many intertwined relationships, but the USAF side saw how being under the auspices of the Army detracted from their own goals and growth. I see a lot of similarities here.
Note, I'm assuming that your problems making your case are a communications reason, and not an issue of looking for personal reasons to sever yourself from your direct managers.
I swear to God...I swear to God! That is NOT how you treat your human!
This is weird because being in the telecom biz for 20 years on and off, including working at a place that owned a lot more stations than the Poster owns, traditionally IT and engineering have always run separate networks and always been at each others throats. To the extreme of having two boxes on one desk, one on the eng network and one on the IT network and an air gap between the LANs.
Likewise - I was in radio broadcasting as an assistant chief engineer for 8 years, and we and IT were always at each other's throats... They had the usual "we're the only ones allowed admin rights" attitude, which interfered with my ability to work on our digital audio workstations and automation systems. Eventually, it blew up, and we severed our networks. Anything that played audio became an "engineering" machine, and they were reduced to tending the email server and machines in the marketing department.
To the original questioner - it's important to bear in mind that, unlike many industries, engineering is a core aspect of the broadcasting business... The justification for having an IT department in a broadcasting company are not the same as with any small business, such as a small accounting firm, retail shop, dentist office, etc., where there's no one with the skills to maintain computers and manage a network. Instead, the justification is that it frees up the engineers to take care of transmitters and studios if they don't have to waste time re-imaging the receptionist's machine after he or she installed a dozen browser toolbars. But IT therefore is a subset of engineering... not a standalone department.
This already sounds bad to me before it starts. IT departments shouldn't have their own goals any more than the Finance dept. should have their own, or the HR department. All of these are "internal service departments" - they do nothing directly for the corporation, as such, they only do so indirectly by providing internal services to the staff.
You may notice the odd phenomenon already happening in this slashdot topic, of a bunch of IT geeks making fun of, and heaping criticism on, IT departments. That's because internal service departments are almost completely incapable of distinguishing when they are serving the larger corporate need, and just serving themselves.
I have yet to find the IT department that did an honest and humble cost-benefit analysis or risk assessment, one that came up with the conclusion, of, say, (to pick a currently raging topic as an example) "Yeah, allowing people to use Smart Phones at will is going to cause us a lot of pain, but that pain is small compared to the good it will do for everybody else, so I guess we have to suck this one up for the team".
Never.
The whole last 30 years since the PC came in (indeed, one could go back to DEC "minicomputers" and "departmental computing") has been one of steady spread and democratization of IT tools. "IT people" (that would be us, the /. crowd) have jumped on this cultural shift with enthusiasm and indeed evangelism. But IT *departments* have always stood in the way, holding it back, demanding to control it all. They assert the larger good, but never do that cost/benefit figure, never do a post-analysis of productivity "improvements" after they took over something that was not formerly under their control, and cost them quite a lot of money to manage.
So get a security guy if the corporation can afford one and needs one. Get a central IT purchasing and contract-management guy, if that is cost-justified. Get IT-type staff, each as needed. But split them up, don't let them become their own department. Absolutely not one with their own goals.
This can work out if, and only if, you steer clear of some cardinal sins I encountered during my years.
1. Keep the devs away from the other departments.
If you separate development and operations, do it all the way. Operations is what the departments talk to if they have problems. This of course requires good documentation so the ops can actually solve problems. If you don't do that, everything will eventually end up on the devs desks.
2. Keep the devs away from anything "live"
There must not be any kind of interaction between developers and the "live" systems. None. Zero. For exactly the same reason, they are after all the ones that created your software, so they are probably the ones that could solve a problem fastest. They are also the ones, though, who should be working at something completely different by now.
Separate ops and dev, but do it ALL the way. Else you end up with very overworked developers and very bored operators who won't have much of a clue of your system, usually ending in such a way that the ops get fired and the departments get merged. Of course, without hiring additional staff to do the workload.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The parent company wouldn't happen to have the initials NAM and have stations all along the east coast from Maine to Florida, would it? If so, I worked at one of the Florida locations.
Here is one shining (real world) example of why an IT department or one person in charge of IT as a whole is good: 6 TV stations. Some have Active Directory, some do not. Every station does email differently. With different providers. All have VPN to parent company. Parent company installs application on a Terminal Server for all TV stations to access. Said application REQUIRES a valid email account for each employee. Parent company sends a request for email account server details for all employees and requires employees to change their email passwords to first initial, last name, 123 (ie: jdoe123),. Guess what, you just gave Bobby, the new guy in Master Control the local manager's password - oh, and the CEO and President of the parent company's email password! Hell, he's got EVERYONE'S password! Before you ask, no, the user's are NOT allowed to change their password or else it breaks the software running at the head office.
The above scenario would have been EASILY resolved using Active Directory, Domain Trusts and a single copy of Microsoft Exchange. I even offered to do the setting up of this configuration. The users would only need to remember ONE password - the one they log into their computer with. The scenario above ACTUALLY happened and I'm pretty sure - if I wanted to - I could log into and read, anyone's email who works for those TV stations today.
Not all engineers are cut out for making IT shine. Sometimes you really want a dedicated IT person managing things, especially when you grow to multiple locations.
I haven't read all the previous posts yet, but my thought is "if it's not broke, no need to fix it".
If you've been working there for sometime, and you're turning to slashdot to answer questions like: "What are the business justifications for having a standalone IT department in a small business?" then you're contemplating something that even you can't think of the business justification for.
Really, if the station is profitable and is operating how normal stations operate, unless you can visualize how this would actually benefit the workflows, it sounds like you're trying to fix a problem that doesn't exist. On the other hand, if producers and editors were constantly throwing up their hands in frustration about this or that, then that would be the time to step in and suggest a fix. But from your description, it doesn't sound like that's the case.
What exactly would the benefit be to having a unified IT department across 5 stations? What would that allow those stations to do that they can't do now? Would they become more profitable? Or would they be spending money on a new department that they had done without for all these years?
Not many people know what exactly broadcast engineering is and are quick to jump on solutions that involve IT. I'm a broadcast engineer who has been teaching IT to the Broadcast Systems Technology program at SAIT Polytechnic for the past 17 years. The issues surrounding the broadcast industry (television, production houses, etc..) is that there has been an incredible amount of change occuring in the past 10 years.
The transition from analog TV to HDTV has been a steep learning curve as most stations now have two parallel systems running: analog and digital. It is not as if it is just one system either, there's analog and digital audio and video. HDTV does not consist of just one format, there are dozens of formats for HDTV, 480i, 480p, 720i, 702p, 1080i, 1080p, and several transport streams such as mpg2, mpg4, avi, IPTV, etc.. Plus be able to transcode between the formats on the fly. It goes on and on.
These changes affect every step in the process: from production, news gathering, mobiles, remotes, ingest, editing, branding, playout, transmission, etc.. The engineers have to learn all of these new formats on the job while maintaining a station and maintaining sychronicity between the audio and video as the streams are separate. Synchronizing audio and video and then trying to maintain consistent volume levels with a digital signal has turned into a big headache. Volume is not easily measured as one would suspect - it consists of more than the peak levels and includes the background sound which all has to fit in a restricted bandwidth.
Now add into this mix that most new equipment is based on server farms and ethernet, the engineer has to learn networking concepts also such as TCP/IP, routers, VLANs, subnetting and switches, etc.. Just to confuse the issue, there are already analog and digital devices in broadcasting called video and audio routers and switches. A broadcast router is used to select a video or audio source for viewing, editing, etc.. A broadcast switch is used for mixing, creating special effects and creating shows - you've seen pictures of a director sitting in front of monitor wall (which are now going digital) calling the camera shots: take camera two, fade to commercial, etc.. the operator (technical director) is in front of a console full of buttons and levers performing the commands.
The BBC receives about 500 MB of data in a day (old stats), the problem becomes how to manage that much data coming in, how to catalog it using metadata (MXF), determine what to keep, how long to keep it, what to throw out, etc..
Another issue is just to edit HDTV? Uncompressed HDTV 1080p requires 2 Gbps BW for transport. Most transport streams except for 10 Gbps Ethernet aren't there yet. Most editors can't handle data moving that fast so HDTV is transcoded down to a smaller format, edited, then the edit commands perform the edits after to the HDTV to create the final production. This means that each piece of audio and video has to have a time stamp on it called a timecode.
More and more ingest and transmission is being sent through the Internet and private VPNs between stations. Often one station will control all the affiliate stations in the province or state. The affiliate stations will have their servers in the "hq".
Back 5 years ago, you would see maybe 5 or 6 servers in a station, now you see rows of racks of servers of every type that you can imagine. There is a migration now from individual systems with each having its own server and a central storage such as SANs and NAS.
It is easier to teach a broadcast engineer about networking than an IT guy about broadcasting. But it is also imperative to have a trained and knowledgeable IT guys on staff.
Should it be a separate IT dept - absolutely not. The network is not separate, nor should the IT dept be. IT decisions which seem reasonable to an IT person can break the broadcast side or have dire consequences. The broadcast side is the money maker, the IT side supports broadcast.
(I am using standard staff prices for my area, Labor costs can very)
You have 10 engineers who are paid 90k a year. 1/2 of the time they are focusing on IT related issues which isn't their field. (450k spent on IT)
If you hire 4 people in IT that are paid 60k (240k spent on IT) who can focus on their jobs and get more work done as it is in their field.
So in this case the company is currently spending more per IT hour and the effectiveness per it Hour is less.
If you replace it with numbers in your area who knows... You may not be justified for an IT department or you may have a bigger need.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I think the OP is quite clear why he wants a separate IT department. He doesn't say, but I wouldn't be exactly staggered if it turns out that he is in charge of IT. Having a separate IT department would give him his own budget, and get the Head of Engineering off his back.
The OP therefore wishes a separate IT department for his own benefit. This may be as good a reason as any, but not one that's likely to cut it with the company. Particularly not the Head of Engineering. So he wants us to invent some plausible sounding reasons that he can sell to the company.
Here's hoping the company don't read slashdot.
The transition from analog TV to HDTV has been a steep learning curve as most stations now have two parallel systems running: analog and digital. It is not as if it is just one system either, there's analog and digital audio and video. HDTV does not consist of just one format, there are dozens of formats for HDTV, 480i, 480p, 720i, 702p, 1080i, 1080p, and several transport streams such as mpg2, mpg4, avi, IPTV, etc.. Plus be able to transcode between the formats on the fly. It goes on and on.
These changes affect every step in the process: from production, news gathering, mobiles, remotes, ingest, editing, branding, playout, transmission, etc.. The engineers have to learn all of these new formats on the job while maintaining a station and maintaining sychronicity between the audio and video as the streams are separate. Synchronizing audio and video and then trying to maintain consistent volume levels with a digital signal has turned into a big headache. Volume is not easily measured as one would suspect - it consists of more than the peak levels and includes the background sound which all has to fit in a restricted bandwidth.
Now add into this mix that most new equipment is based on server farms and ethernet, the engineer has to learn networking concepts also such as TCP/IP, routers, VLANs, subnetting and switches, etc.. Just to confuse the issue, there are already analog and digital devices in broadcasting called video and audio routers and switches. A broadcast router is used to select a video or audio source for viewing, editing, etc.. A broadcast switch is used for mixing, creating special effects and creating shows - you've seen pictures of a director sitting in front of monitor wall (which are now going digital) calling the camera shots: take camera two, fade to commercial, etc.. the operator (technical director) is in front of a console full of buttons and levers performing the commands.
The BBC receives about 500 MB of data in a day (old stats), the problem becomes how to manage that much data coming in, how to catalog it using metadata (MXF), determine what to keep, how long to keep it, what to throw out, etc..
Another issue is just to edit HDTV? Uncompressed HDTV 1080p requires 2 Gbps BW for transport. Most transport streams except for 10 Gbps Ethernet aren't there yet. Most editors can't handle data moving that fast so HDTV is transcoded down to a smaller format, edited, then the edit commands perform the edits after to the HDTV to create the final production. This means that each piece of audio and video has to have a time stamp on it called a timecode.
More and more ingest and transmission is being sent through the Internet and private VPNs between stations. Often one station will control all the affiliate stations in the province or state. The affiliate stations will have their servers in the "HQ".
Back 5 years ago, you would see maybe 5 or 6 servers in a station, now you see rows of racks of servers of every type that you can imagine. There is a migration now from individual systems with each having its own server and a central storage such as SANs and NAS.
It is easier to teach a broadcast engineer about networking than an IT guy about broadcasting. But it is also imperative to have a trained and knowledgeable IT guys on staff.
Should it be a separate IT dept - absolutely not. The network is not separate, nor should the IT dept be. IT decisions which seem reasonable to an IT person can break the broadcast side or have dire consequences. The broadcast side is the money maker, the IT side supports broadcast.
After reading some comments I have a few ideas. First you don't want an IT department, as the engineering section you want a sub group that focuses on IT. You are already technology management.
The biggest selling point for an IT group IMHO is technology management. In theory you can run without an IT group and the CEO could take on the CFO tasks but it works better when you have an IT group working on utilizing what you are purchasing in the best possible way much like a CFO handles finances. A group that is focused on planning, supporting and implementing an IT strategy rather than letting everyone spend top dollar on whatever they want. Are you publicly traded? If so to my memory there are requirements for IT by the SEC.
To extend the CEO/CFO analogy no one is allowed to justify their expenditures anyway they like, and no one group or individual should be able to use whatever technology they like at the station's expense. Even if someone buys it on their own dollar if it impacts the running of the station or the day to day they will want support. It's best to manage it.
What a good IT dept/group can give you is:
A) Fall back or options : If a server breaks or a hardware goes down they can have contingencies and replacements waiting to minimize downtime.
B) Planning: They can either reduce cost or make better use of what you are spending rather than having HP or Dell be your defacto IT Support.
C) Data management: Do you have backups? Do you have remote access? Do you allow work from home? Information is the new life blood of the contemporary business. Who is handling this precious resource?
D) Security - The Fear Card - do you really want internal memo's leaked because you never had a supportable security policy and someone to implement it?
If you really want to be a bastard recommend ITIL. That will tie up their resources for years but you'll have an IT group. ITIL is crack cocaine for management types.
You are already handling these functions it's just time to take it on and manage it.
You could always make the case for a promotion and be their interim CIO.
"Don't fear death... fear not living..." -me
Just thought I'd do something I don't ever see enough of here, and give a quick "THANK YOU!" for all the replies.Yes, even the bashing replies are valuable (in some way). If nothing else, they make me realize that I could run into some of the same attitudes along the way here.
To give a bit more detail (I wanted to try to be relatively brief when asking the question):
I actually feel very lucky. I work with a great group of very smart, and reasonably sensible people. I have over 10 years in the broadcasting industry. I also have about another 5 years as sysadmin in a small shop. I am currently the entire IT staff at this station, and the position was pretty much created just for me. The engineers here realized that the "general IT needs" were consuming too much of their time, and were suffering from lack of attention. When I came in, virus outbreaks were common (the AV server had been disabled in a previous virus outbreak, and never brought back online... Might have had something to do with it!), AD was in a shambles, growth had been handled by daisy chaining another switch (whatever was on sale at Best Buy) wherever they needed another port... The engineers who "ran" the domain didn't trust it enough to have their own workstations joined into it...I'm sure many of you know the situation. Again, most of this happened not out of complete ignorance or ineptitude.. or even out of much in the way of budgetary constraints... It was all because of neglect. The engineers had higher (and other) priorities, and usually took the shortest, cheapest, simplest route to "fixing" the immediate need without any long term vision of how the pieces should fit together
Since I was brought in about a year ago, I have basically rebuilt the network from the inside out, with negligible downtime. We're on Gigabit everywhere, all on good quality managed switches. All the tangles have been taken out of the topology, servers, GPOs, AD, etc have all been whipped back into shape, and the virus rate has dropped to less than one instance per month, all of which were automatically caught by the now up to date AV software on the workstations. We have redundant WAN connections, redundant DCs, regular backups...I have built standard images for each of the major departments, all the workstations are up to date, documentation for everything not only exists, but is organized and easily found...
I am lucky that this is a small enough organization that I know everyone by name. I make it a point to regularly, if they are having any trouble, if there is anything I can do to help. I have taken the time to learn the different software in use in each department, to learn how they work, and why, and have done many things to simplify and streamline those workflows. Again, I am very lucky that this is a small enough organization that I have the ability to do all of those things.
I'm (rightfully, I think) proud of what I ave accomplished here, and I know I could not have gotten it done without the support of the company and the managers who know enough to know that it needed to be done. I have proven my worth, in other words, and yes, have been rewarded for my efforts. Now, I feel it is time to start the process of getting the other 4 stations out of the same hole we were in last year. Within this specific station, I actually like and appreciate being under the Engineering department's umbrella. But when it comes to extending my successes here to the other stations, it gets more complex, and that is where the separate IT department becomes more needed.
So yes, to an extent, this is about positioning myself to be that IT director over all of the stations. It is also about doing what I honestly feel is in the best interests of the company, as they ave been good to me, and I see no reason not to return the favor. So again, thank you for all of the input, good and bad, it has helped!
1 point of call and 1 place to run things properly
Good argument against separating IT. What happens when they are busy (hint: IT is always busy). Who decides what "properly" means (hint: IT thinks they do).
IT is separate in most organizations because it requires specialized training which they don't want to give to everyone in the company. The reason Engineering groups are always at odds with IT is because they feel they don't need to go to someone else for things they know how to do. In a TV station, why should Engineering run and maintain every piece of equipment EXCEPT computers?
Intron: the portion of DNA which expresses nothing useful.
Background: I worked for 7 years in TV/Radio IT. Joined when our dept. was very small (3 people: me in support, a network manager and an IT director) and the company was one (national) TV channel. When I left IT was over 50 people, over a dozen TV channels, several high-traffic websites and dozens of radio stations. I was the technology director for New Media when I left (so you can tell how long ago that was... "New Media").
You will find as your company grows the need for IT will become more obvious:
There are dozens of things like this. The thing is, if you ask any broadcast engineer, they will tell you they can and should be handling this, largely because they have been doing it until now. In our case it was a protracted battle to wrench these things away from broadcast operations, but we had a very savvy and strong-willed IT director who would not back down from a fight. What we ended up with was IT (reporting into the finance VP at the time, now into the CTO) overseeing everything that is not directly related to broadcast operations, and Operations controlling their own network and machines, editing suites, AS/400 and specialty hardware that only they used.
What we realized was there were actually very few points where these two entities overlap, and since neither side wanted much to do with the other anyway it all worked out well in the end.
I would start by focusing on what the problems are. Outages from IT problems? Viruses? Downtime? Trouble with TV transmissions? Put a dollar value on the problems and you'll be 80% done with your sales pitch.
I would first start with a good description of what this IT department is supposed to DO, and only then can you see what isn't being done (the "problems").
From the simple description in this article, I don't see where an IT department would be helpful, at least not on the engineering side. Broadcast computing requirements are very very different than what a typical office or company needs. The production switcher, the content delivery systems, and all the other control systems are not just "peecees with windows and powerpoint", they are realtime control systems that need to interact with each other and stay functional.
An IT department that comes around to do a "windows update" on a regular basis may very well cripple the master control room if the updated system changes a critical driver or does something else that would only be annoying in an office.
No, in such an environment, creating an IT department to offload the "computers" from engineering is simply creating a problem where one doesn't exist. The IT deparrtment is going to be fighting with engineering over updates and virus scanners and anything else that IT wants to control but aren't necessary or are actually detrimental to the engineering use.
It is exactly this "kind of use" issue that we're facing here at the Uni. The "campus IT" is really good at running desktop systems with Word and IE for the liberal arts folks who use their computers to write fuzzy papers about the life of Wilford Brimley or whatever. They really don't understand what scientists do with their computers, especially computational dynamics or modelers. "First, try rebooting. What do you mean there are 'other users'? Just press 'ctl-alt-del'. What do you mean the computer doesn't have a keyboard or monitor?" We work VERY HARD to keep "campus IT" out of our college, because we need to get work done and "campus IT" would be part of the problem, not part of the solution.
I used to work at a TV station. My two cents and the short version.
The business end of the company has different needs and goals than the engineering area. An example a marketing person should not be able to access the transmitter site. Put a firewall between Engineering and the rest of the company. That is your point of demarc. There is going to be data sharing between the areas, but that is the purpose of the firewall. Setup procedures and standards for company computing. Train or work with a designated engineer on company IT procedures. Let the IT engneer setup engineering procedures The engineers only need access to a subset of the company IT. Engineers PCs should log on to the domain or their trusted domain.. Everybody is happy.
Very small companies can not really justify a separate IT department. All they can do is to have a support contract somewhere.
As a company grows, they may find, depending on how much they use IT (yes, some companies do not need much) that they can specifically use an employee to cut down on external support. They will still need external support for network and server support.
It is only once a company gets into 3 figures of desktops, they they would be stupid to outsource and have no self support. Many do this though. I have heard senior managers/execs say things like "Computers would be great if we didn't have to have IT." I suspect that this sort of comment comes from someone who was not allowed to put his iShinyNewShinyThing onto the corporate network or who did something really stupid and got in trouble for it. We all know the sorts of thing.
I'll see your Constitution and raise you a Queen.