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?
1. Give up.
1 point of call and 1 place to run things properly
... is the sweet, sweet rage it will engender when your future IT techs tell folks that they can't use their iPhones and the editor of their choice for undisclosed security reasons. Ah, I can feel the little bits of evil already spreading, ruining people's days, causing them to hate their neighbor, kick their dog and neglect their children, leading their neighbor to flip off an old lady, the dog to bite the postman, and the kids to grow up to drug addicts.
Bwahahaha! Screwtape, you ain't got not nothin' on IT!
Check your premises.
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.
Make a formal business proposal and justify its ROI. Also, creating the basic architecture would be a plus... I feel like I'm just stating common sense?
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).
Are there problems with your current setup? If so, how will an established IT department fix this?
-- or --
Will this new approach save money? (reducing licensing, people, etc.)
... I'm thinking that you should probably split it off from your development department.
Here's why (from a developer perspective).
It's better for devs to have someone else build a good wall around their sandbox (note: around, not through) then to have us devs make the entire organization's security match our own needs. We're probably competent enough to do things right, just as we are competent to test our own software. And we'll get it right most of the time. Thing is, we'd rather be developing new and cool stuff than doing security and installations for folks most of the time, and thus, get lazy, or miss things that might be obvious to those who aren't so closely involved with the problems that they only see the detail, and not the bigger picture.
And before I get jumped, a good IT department facilitates development, not stifles it, by doing day to day necessary tasks and keeping the decks clear for the developers. And yes, they do exist. True, there are some really bad and draconian ones out there - but it doesn't have to be that way.
Also, it's probably cheaper to hire IT folks than to pay qualified developers to run IT.
Check your premises.
If you are lucky enough that your IT costs are hidden in another department then go with it. Once you become a business cost you are done for!
You got the touch!
Engineers handle the heavy lifting and IT gets to sit at a desk all day laughing as the boss repeatedly trips the firewall trying to visit a porn site.
Seriously though, if you haven't seen the tiered IT model you should look into it: having established zones of responsibility saves you time and frustration, especially when it comes down to figuring out what to prioritize--so engineers aren't expected to drop the new broadcast antenna project to run off and fix a dude's desktop for instance.
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
Questions you have to answer yourself:
* Are the IT needs not being met because the budgeting goals of the department that current IT work falls under are not the budget goals of IT?
* What would be made easier by moving IT to its own department? What is currently obstructed by IT being under another department?
* What benefit will the non-IT folks at your company see from a liberated IT staff? How will you better be able to serve them?
Because people who are supposed to be doing other things (and are probably better at those other things) are having to do IT stuff instead.
Having said that, if I was running the place, I'd outsource it *if* I could find a good *local* outfit that dealt with that stuff.
http://rareformnewmedia.com/
Engineers **think** they know computers, but that is a big difference from running IT operations.
"Accidentally" let a virus go inside the network. Watch how the engineers handle it. Perhaps drop a USB key in the parking lot with all the nastiest viruses installed. That will go across your network quickly, assuming MS-Windows and printers are on it.
The video engineers won't know how to prevent this from happening the next time, how to lock down a network, how to lock down computers and servers any more than I do about broadcast video systems. I know storage - high performance storage, backups, disaster recovery, network architecture with different segments for different purposes. I know proxy servers, blocking default route and DNS from end-user computers.
OTOH, does anyone working there have IT operations experience? You could be showing your own lack of knowledge.
Staying up with IT knowledge is a full-time job. I suspect that staying up with broadcast engineering knowledge is a 5 yr thing, not constant.
If you want this to be really effective at making your point, wait until a week before sweeps week and have a few IT professionals ready to help.
I hate to say this, but I know lots of small businesses with 150 people that have an IT department of 1 person and a contractor they bring in as needed - usually 1 day a week for server stuff. At one client, that contractor outsources to my company when they need complex infrastructure or virtualization updates. He knows he is in over his head then. OTOH, he is extremely well versed at running MS-Exchange and some specialized architecture apps that we simply do not have the skills to handle. The IT employee is competent but spends most of his time cleaning up after the CEO screws something or after the "art department" installs some other virus-infected "trial application."
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.]
Ask your boss how many of the engineers understand and effectively implement systems security practices. Ask him if he's cool with Channel12 down the street having a preview of every broadcast before it airs, and not being able to audit accesses to determine where the leak or breach occurred.
"But we have to pass the bill so that you can find out what is in it,..." - Nancy Pelosi
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
You've got 500 employees sharing data. That's something that needs to be managed. Pitch it simply as focus and efficiency. Moving IT to its own unit allows you to have IT workers focused directly on IT. In the event of a major IT issue, you won't have jack of all trades employees trying to manage several different job roles. You probably don't need a huge department a small number of employees in a central location and one or two in each station.
But also focus on training. The small agile department will allow you to focus IT training and allow the business to take advantage of new technologies more easily. Engineers will learn many things, IT guys will focus on learning things relevant to making IT better in the work place.
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!
Being in charge of an IT department for a law firm, I can understand your needs. Management doesn't really understand the IT needs of a company, because they don't understand how information flows, or the need for having information available at all times, and keeping that information secure. I've seen small businesses pay some IT person to come in now and then to fix problems, but no one is monitoring their systems, making sure systems are setup properly, and upgrading current infrastructure to keep up with changes. The IT department is there to maintain, upgrade and research the current infrastructure. The benefits of having an IT department will only be realized when you see how much more capable the company is in the next few years.
-- By all means let's be open-minded, but not so open-minded that our brains drop out.
If you want to justify anything to management, the best way is often going to be to relate it back to money. Will creating an IT department save money? Will it help cut some kind of expense? Will it make it easy to bring in revenue? Will it help your revenue grow? Will it allow you to do something more efficiently, requiring fewer people to accomplish the same thing?
There are lots of routes that lead back to money somehow. Improved security might mean protection against lawsuits, meaning less money lost in settlements. Improved employee morale might mean that you can hire and retain better people without increasing salaries. Changing the division of labor might improve efficiency and productivity.
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 think your engineering dept is your IT dept. "Engineering" has many definitions and in the industry/context that you describe your engineering department seems to a support department focusing on technology. It does not seem to be "engineering" in the product/tool development sense. In this sense it makes sense for IT to be a group inside *your* engineering dept.
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.
If you departmentalize IT it will be easier to outsource it.
Having to work for a living is the root of all evil.
I also work in the broadcast field. Our issue with IT is that its business model is aligned with generic IT operations, and not an engineering operation.
What I'd suggest is, if you already haven't, is create clear role groups for the engineering department, one that does "IT stuff". Once you add a separate IT entity into the mix, you'll have much more red tape to get things done.
One case in point. You have an application that requires a PC workstation that interfaces into a video server. This application needs to run on the engineering network. However, because it is a workstation, it is IT's job to configure and maintain. BUT because it needs to run on the engineering network, IT may have issues plugging into that network. If you think that opening a port through a firewall will do, think again. Quite a few server API's assume full-open networks, as all operations should be run on the same network. Neither side really want to create a DMZ system or a bunch of them.
Now you have a network power struggle. The house network, run by IT, and the engineering network, run by the engineers. Trust me when I say this, but the engineers don't want another department controlling their network.
The you have IT questioning why these workstations are not running server OS's, and instead still require XP. These applications are not mainstream, ie: installed by typical consumers. They are specialized, that use rather old API's that don't play well with Vista or 7. There is no reason to change what still works.
That's just the tip of the iceberg. Guidelines need to be written clearly. You'll need to include a good set of engineers, not just the managers, but the front line guys, to work out the edge cases so that the business can still run efficiently. There's nothing like having to install a new system only to have to wait for IT to evaluate the software to come back with a really silly response like the application requires a hardware key that limits the flexibility of running the application.
You need to break down the status quo and why you feel it does not work well, and what you hope the future end state to be.
Do you currently have broadcast engineers who are pulling double duty doing both IT and broadcast work? Or do you have IT focused individuals mixed in amongst the broadcast engineers? Can you quantify how much time is being spent on IT work vs. other responsibilities? Is having people pull double duty causing them to be ineffective at one or the other tasks?
Typically management will want to have justification in terms of hours being spent and how greater efficiencies can be achieved by changing from the status quo. Or a list of business capabilities that you can provide by changing that you cannot provide effectively now.
In order to gather this information you may need to work with your coworkers to determine just how much time is being spent in different capacities. Note that you may encounter coworkers who are adverse to the change.
To sort out your own thinking AND create a presentation for the management, you may want to create a simple two-column list. Column 1 = Engineering Responsibilities, then Column 2 = I.T. Responsibilities After you create several drafts you should then ask management what the company priorities are. You should do this BEFORE presenting your list to management. After talking to management, rank your two lists in the order that management cares about. And present everything on one page. There should be no more than 3-5 priority items in each column and you should be able to explain WHY the responsibilities need to be excluded from Engineering.
The Flux Capacitor needs a Friction Re-lign and IT are the only ones who know where the friction spanner is...and stuff.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
If you have a business. IT is cheap. You don't want engineers, people's who's time is infinitely more important than "fixin' the computers", to be fixing the computers. Seriously, you have to be insane not to have an IT person designated at least. I've had small business operations where I was quite capable of doing it myself, but I assigned the business to a friend and associate to handle it.
Why? Time is money. Let's look at it from what one example I have done personally.
Retail: As owner, my best time is interfacing with customers. Customers LOVE having the owner handling their business. It's a personal touch that empowers them and allows me to bring the full blunt of my resources at meeting their wants and needs. If I have my head stuck in a computer, customers feel off put by it. That's the draw back of being charming and charismatic, if you don't put in face time, it can have an opposite reaction. You can become "stuck up" and they will turn negative towards you. They don't shell out volumes of cash at you then. I feel like such a man whore working retail. I digress....
My brilliant friend, who wears that ball cap everywhere, who has bad teeth, and a hen pecking fat wife who calls him every other nanosecond to whine about kids she's too fat to get up and beat properly, needs a job. And is so damn overqualified for fixing my computers and keeping it all running properly that if there is a computer problem, it will be because ninjas from another dimension have gated in, and chopped them up with energy swords, after they beat Chuck's (my friend) ass into the ground. Sans that or something equally fantastic, I know the computer situation will be in good hands.
Chuck works cheap. If he isn't working, he's miserable. My time is worth money, lots of if I am doing my damn job. I can pay Chuck well, and come out ahead because I can deduct what I am paying him from what I make and still be out ahead. This is just thinking about a very small business in means of employee numbers. As you increase the amount of people involved, it becomes exponentially needed in part of the equation of balancing out your employee's time.
If your business is built around computers as vital tools for anything beyond simplistic small business book keeping, you are daft in my opinion for not assigning at least ONE human element to focus on IT.
Take the Red Pill.
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.
EE's are not the best IT guy and IT guys should not need a min of a EE just to work there.
I used to work at a software company that interfaced with TV stations. The engineers at TV stations don't know and don't care about computers. They use them, and they know the software that runs on the computers, but they aren't computer guys, in the strictest sense. They don't have much intuition about why computers aren't running properly, and what they want is support contracts so that their computers get fixed. Which is fine, nothing wrong with that.
In case you don't know, TV stations are at the center of a massive shift from tape-based to file-based workflows. With the transition to file-based broadcast systems, a bunch of guys at TV stations have already gotten the axe. All those guys you used to see jamming tapes in and out? All gone. NBCNY at 30 Rock used to have rooms full of guys jamming tapes for upload to feeds, and they have all been fired and replaced by computers and file-based workflows.
The problem with removing IT from the engineering department is that more of your guys in the engineering department are going to get fired. They are going to get some IT guys, and suddenly there is going to be a lot less work for engineering.
This guy probably wants to be able to stop getting calls from the rest of the staff(producers, reporters, advertising, etc) asking why their email isn't working, or why their desktop won't boot. I wouldn't want to hear about those things either.
That's what most upper management will make decisions on
gaps - what can't you do now that needs to be done. both capabilities and time to execute may be important
risks - what risks do you face with the current organization? (viruses, lack of auditing for any regulations you need to meet, hardware/software at end-of-life etc)
savings - how much money the business saves with a proposed re-organization. this will require determining the costs of the new IT department. If the cost is $0, just do it today and present the savings - but I'd guess it will take at least your time and probably parts of other peoples' time all the way up to the CEO (reading a new department line-item on reports does take time)
It would be best to present ways to fill the gaps and minimized the risks without a reorg as well. Then let management decide if IT department solution is better than the other solutions.
New departments are not always better. There is overhead of creating budgets which can lead to debates over resources, attention from upper management, and allocating time from other departments (HR, legal, etc) You may just need to better define the mission of your department (e.g. include IT services) and annual/quarterly goals and change individual responsibilities and hiring if needed. I'm in a situation with too many departments. Some minor things require 4 people (team lead level) to approve. When I want to start a new project I have 3 department heads I can go to for funding - they'll all start by asking if one of the others will approve and I may end up needing something from each of them which means extra stakeholders to deal with in the project (which isn't always a bad thing)
Unless you can demonstrate that having a separate IT department can save the company money, there are very few sensible reasons (legal requirements may be a sensible reason) for changing a successful organisational set up.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
All people hired should be competent at maintaining their own computer equipment. *HOW SHOCKING*
I am amazed that a company of your size does not have a separate IT Operations department. The best explanation sometimes is the most simple one. We need to establish an IT department so that our engineers can focus on doing their job. If you are looking for a financial reason, IT employees as a rule make less than developers and engineers. You could pay someone or someones less money to handle everything from changing mouse batteries to monitoring and tuning your network and server health to budgeting. To further conserve on money, you could cycle through interns and provide them with experience while receiving cheap labor and possibly a future permanent employee.
Figure out:
how much downtime costs the company
how many of those incidents are due to engineers screwing up servers or databases
which engineers are avoiding engineering work doing IT work
compare labor costs of a IT pro and Engineer
If you can cost justify having six IT pros, couple of OS admins, couple of DBAs and a few tech support persons then it should be a no brainer...companies would rather pay engineers to do engineering work...not setting up PC's or installing and managing databases or patching windows servers....
I would love to be in an IT department which was under engineering -- or even operations -- whatever, as long as it is not under accounting, where it is usually found.
Oh, wait. Perhaps you're a sociopath who feels the need to build his own personal empire.
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.
When I read this, I thought "I am not alone" the same thing is happening at my company. We are a Radio Station and own other stations in the state. For a period of 4 years there was a quasi separate IT dept. in essence were outsourcing our IT dept., to a company in another city because we couldn't get IT talent to come to our small town, we hire a network admin in house to take care of the day to day. In terms of technology and implementation, this was a great thing for the company, We had a lot of equipment that put us on the cutting edge. saving us a lot on support among other things. They were using things that the engineering dept cannot begin to understand: they don't know software or 'who' TCP/IP is, all they know is restart and see if that fixes it.
Engineering went to the board of directors and convince them that an IT dept is wrong and using Linux, Cisco is bad.......or anything special is bad. so they stop using this company that was our IT department,
Engineering from what I see, tries to hard wire everything they can (I admit it stable and easier to fix) if they can't do that, then they contract and outsource, causing a big expense. but in their view, "I can just make a call and they will fix the problem and I come off as the hero."
But in reading the comments from the other people it makes sense not to split the departments, since at my company there is a natural competition between the two. I agree with one of the comments, maybe uniting the two is a great choice but I would say the leader of that dept should be someone with a Computer Science background, not a Engineer in Electricity certificate, The right person in the right department, At the end we all work for the same company and we should work together.
Rather than rush to a separate IT department, try to more narrowly define the problem. I'm guessing you're seeing a difference between keeping the broadcasting equipment up and running; keeping the news, sales, and accounting department's PCs running; and keeping the stations' web sites on line. They're all seen by non-techies as "engineering" functions, so trying to create a distinction between "engineering" and "IT" probably won't go over well with management.
Is there some inherent problem with keeping these people within the same pyramid? It doesn't sound like it, as many stations operate this way. Or are you really tackling a political issue, where the current head of engineering is some old guy who doesn't care about this newfangled web stuff, and you don't think the PC side gets the budget/time/attention you think it deserves?
It's always hard to push management into making top level changes. And if you're trying to fight a battle with Mr. Entrenched by making an end-run around him, you've already lost -- he has had the ears of the owner for years, not you. (And in just about every case, he already sees you coming. It's not good to be seen as the usurper.) Instead of trying to work around him, try working harder with him. Look at creating the subdivisions under the existing engineering organization.
John
... that it may sound like a good idea now but when the company goes through a difficult phase working in a separate IT department is like having a bulls-eye on your back. Not only do you have to justify the department now in order to get it you'll have to keep justifying it especially when it'll be seen as on overhead cost because it won't generate any revenue of itself.
I can see why you would want to separate broadcast engineering from IT support but one risk is you end up with a corporate IT dept who don't understand broadcast: "oh sure we'll fix that in 24 hours." "but I'm on air NOW." "yeah but you see the sla....". As the line between IT equipment and broadcast critical equipment (and networks) is ever more blurred having everyone understand the nature of the broadcast environment is really important Been there in the BBC. It ain't fun when you're on air, the playout system is down and IT stick to a eight hour response.
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?
It allows management to see the costs of IT.
The Kruger Dunning explains most post on
Here's something to consider: What happens if the company renames "engineering" to "it" and "engineering" becomes a sub-task of "IT". If this is palatable, then the opposite should be true as well. In other words it doesn't matter what the names are - as long as the functions are being taken care of.
There is no reason why "engineering" can't have the IT function. If you are able to identify functions that are falling through the cracks (desktop support, disaster recovery, programming/development needs, server maintenance, etc) - then the focus should be, within the "engineering" department to address those needs. If the director of the department is not responsive, then that should be brought up to higher level executives.
If you're finding that you need to consolidate because other departments are going on their own - then that needs to be addressed as well. But I wouldn't approach it as a need to break away from engineering. I would approach as growing a sub-department within engineering.
-CF
The average corporate laptop is plenty proof that an IT Department usually doesn't "work". Most people can't download even trivial applications, so their productivity takes a deep dive.
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.
IT is a support service. Its there to help the real work get done. Note: its not the real work of the company!
Engineering is a support service as well. It's there to help the real work get done.
Bottom line, its the same kind of service. It supports the real work.
So you say television station. When the live streaming goes down. Whose issue is it? Engineering or IT? Who set it up in the first place?
Bottom line, by dividing the 'groups' into separate departments you will hinder work actually getting done. No need to put of fences.
Here's another argument against.
With 75 people, it only takes one person to maintain the computer network. Note I said "maintain".
With a pool of engineers and technicians, you could pull in help (running cables for example) when it comes time to 'expand' or 'enhance' the IT infrastructure. Not going to happen when the walls go up.
You very much don't want an IT department with its own goals.... The goals are that of the company as a whole, IT supports those goals. Your engineering group might be served well to have people on staff that specialize in the IT support services, but I would put an management structure on top of the engineering group that can manage a single budget, propose appropriate projects and improvements, and can move/grow the staff it has to fulfill the need.
I see this come up often with IT people who have little to no understanding of how a business works. Your owner, if he is a good one, doesn't care about IT. He doesn't care about how "pretty" his organization scheme is. He doesn't mind that the "logistics" guy is also the janitor UNLESS it hurts his bottom line. You're talking about a business which provides work and puts food on the table for a lot of people.
The best proposals are 3-5 pages at most, backed up by more data if necessary, and clearly detail how you can make a business more efficient, fault tolerant, increase profit and/or reduce expenses, and do it without breaking anything. Established businesses tend to be risk averse, and it's a good thing, or you likely wouldn't have a job.
Show how dedicating the time, money, and effort in an IT division will make/save the business money. Businesses aren't for fun. They aren't technology playgrounds. The best organized and most pleasing doesn't necessarily succeed. An IT department because you think/feel it should be that way? GTFO of my office.
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.
Beautiful! [nt]
I am a video engineer for a large post production company and my day to day operational and functional duties cross the video/IT boundaries hourly. There really is no need to separate them into distinct departments. In fact that would only make my life harder if only some of the engineers handled "IT" and others "video/audio"
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
I always try to do the exact opposite- put the IT people WITH the business units they are serving. You get more "synergy", better communication, and much better overall service. It also engages the business units with IT, so it's not an us/them game, but more of a team of people working towards the same goal. My 2 cents.
. . . then you don't need it. America has been undergoing an awakening over the past decade, discovering that it doesn't need a lot of things, like a middle class or IT. It also doesn't need a fast food industry or Viagra, but that's another post. Corporate America, which has become the new first class, has discovered they don't need Americans -- from manual laborers to retail clerks to discovery lawyers. Soon they will discover that they don't need America. Downsizing, a popular term of the last century, is now the national motto. There are now only three areas of employment in America with a future -- (1) morticians, (2) tax preparers for the rich, and (3) military personnel (we need somebody to keep the nukes fresh). Everybody else should consider a career as an illegal alien in China.
I'm always amazed that an IT department needs to be justified in this day & age but I understand what you mean. IT is misunderstood routinely. I think one major 'big picture' issue that should be discussed with management of any company is what their goals are and what their future plans will be. Until they can answer that, creating an IT department may be putting the cart before the horse. That said, it sounds like your company is moving forward and growing and managing multiple sites will require at least one body per site. If your company doesn't see IT valuable and necessary I'm not sure how they can expect to grow. Just the physical layout of your company with remote sites will produce a need by default. I've worked in a company where one guy was trying to manage exactly the type of configuration you find yourself in--remote sites, growing staff, growing tech demands, etc.--and let me tell you if was a mess when I started there simply because it was unmanageable. IT is very time consuming and NOT always in a 9-5 schedule. You'll be surprised that even 100 users, while seemingly small, will place heavy demands on your time and resources as the business grows. I think you just need to set up a formal meeting and ask---then go from there. Justification of a dedicated IT department doesn't seem that unreasonable especially if your managers expect to grow quickly.
If the boss will not differentiate between technicians maintaining the office computers and technicians maintaining the digital broadcast environment , is he also unable to differentiate between doctors who are dentists and a doctors who are proctologists?
I work at a large TV station (~400 employees) and our IS department is a division of our Engineering Department. The engineering department encompasses IS, Truck Operators, Broadcast Transmission Engineers, Maintenance Technicians, Master Control Operators, and Tape Room Operators. We have our own budget as part of the overall Engineering budget. Our IS department is fairly independent in some aspects but integrated in others. IS is fully responsible for Intranet servers, storage servers, news production servers, fax servers, NMS servers, print servers, domain servers, user workstations (100-150) and the network infrastructure. There are several system that both IS and Engineering are responsible mainly on-air systems. Several of the engineers have some computer experience and can help provide basic troubleshooting or follow IS created documentation, but when they get in over their heads they call IS for assistance.
More broadcast systems are transitioning over to IS and the line to determine whether a system falls to IS or to Engineering is getting blurred. One example is our Grass Valley news editing system that was just installed last March. Our old system fell exclusively to Engineering as it was comprised mostly of broadcast gear. The new system we purchased which is more heavily integrated into our house network and house servers, required more interaction from IS. Due to the high level of expertise required for troubleshooting the news system server has fallen mainly on IS.
An IS department provides a higher level of expertise than most maintenance technicians can provide which will lead to reduced server downtime. In addition, a good IS department can proactively identify areas that can be improved and can build out new work-flows to reduce user interaction and increase productivity. You also need an IS department to ensure security through your network. If you have a major virus outbreak do your engineers know how to respond and solve the issue quickly?
Also, IS can bring new ideas that can save money. We recently transitioned from a satellite broadcast distribution system to an IP broadcast distribution system that is saving the company hundreds of thousands of dollars each year and increased revenue as various end points could no longer leach off our satellite signal.
As more and more broadcast systems are transitioning to server based systems the demand for IS technicians is only going to increase. We are planning on converting 2 of our engineering positions to IS positions in the next 6-8 months increasing our IS department to 6 technicians plus a manager. If you can't express why you need an IS department then either you don't (highly unlikely) or you aren't the person that should be making the recommendation.
Ah the benefits and efficiencies of departments with their own goals, budgets, personnel, etc. In the US we have the FBI, CIA , NSA, military intelligence, etc. See how well that worked.
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!
Wow, you have that many employees and you are relying on an engineering department to deal with IT issues. Amazing you are still in business, or you have a really good engineering department.
I've covered a lot of this in my "THANKS!" below, but wanted to reply to you specifically. If I hadn't replied below, I would absolutely mod you up. I started in TV back in 1992. I'm not so terribly old, but I ran plenty of shows from 2' machines, 3/4', beta (I can still make a betacart walk and talk, if you can find one still in use anywhere ;-) I was lucky enough to get in right as the first digital commercial insertion systems were coming out. I trained MCOs on FastTrack, at another station, we were beta-testers for Avid's first system. I left TV, and went into computer support, working my way up from call center hell to sysadmin for a small company. I got a couple of certifications as employers required, but I'm proud of the fact that I got the real world experience first, then the certs later (and pretty much just to make HR happy) When I came back to TV (~2005) everything was moving, or had moved to computer, so It worked out quite well! (and FastTrack had been bought out by Sundance, and Sundance was bought by Avid, oddly enough...) That combination of broadcast experience and IT experience is one of the main reasons I got the position I have now. It is also perhaps one of the reasons I can see the different needs (and where they overlap as well) between "general IT" and the broadcast chain. I know the fine line I'll have to walk, but feel certain in my ability to do it.... Just need some clarity on how to start the ball rolling with the rest of the management.
... it's not even a function. The same as security or quality, it permeates everthing you do or product - unless it doesn't, which is when you're fscked anyway. My recommendation is training key users in the technology that's actually being used, and have the necessary resources sit with the corresponding departments. Someone should oversee it (ideally a CIO), and make sure every department has taken care of things like contingency plans, desaster recovery (nobody cares about backups - you only ever care about restore!), etc ...
If you're big enough to warrant system images for your company, then you can start having an IT department. Before that, you only need an IT budget - and regular meetings of the IT people to talk about what's going on and what needs to happen ... if THEY say "hey, we should do more IT than our job", or even "we should hire someone to do IT full time", then it's time to act ... before that? Let engineers be engineers ...
Also, don't fall into the outsource trap. Most of the time it's better to join forces with offices around you and support each other by lending the expertise ...
Don't. A common complaint among IT people is they are marginalized inside of the company. In great measure that happens because IT tends not to be acquainted with the real business of your organization, so they end up as some sort of sophisticated janitorial service. Stay involved with all those messy company affaires, that's what the real world is made of.
I have had the pleasure to be part of the CBC IT team a couple of years ago (before cutbacks) and the IT Department is quite vast. Once it was the same people that did maintenance on the electronic hardware, but for long it has been seperate teams. From what I understand, having specialised teams helps, but it's important for all technical support teams to work together and not in competition (a situation that can result from union feuds, limited budgets, and a lot other factors).
With the developpements of the last 15 years (amongst others, The Internet), a dedicated IT support group was critical at CBC, and is now ubiquitous.
My two cents worth.
One of my managers in the past taught me how to justify stuff by looking for the business case to do it. If I couldn't justify it that way, then the request wouldn't be granted. (I could come back if I needed to and try again.)
So, what's the business case? How would it increase the profits for the company? How about the SWOT analysis - which model (current or your proposed) as the greater strengths and opportunities?
Think like the manager to justify it to management; but you may find that it doesn't make business sense to do it either.
And don't forget to include the costs of transition in your analysis either - both to the new structure and what it would cost to return to the previous structure if things failed to be as beneficial as what is being proposed (e.g. cost of and plan for exit strategy in case of failure).
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
It's something that's definitely a big consideration that you have an operation that's spread out amongst several locations, and IT professionals, who specifically keep up on the latest developments in security procedures, threats, and the like, are going to be more adept at planning for such things than engineers who happen to be able to set up a computer network. With an IT department, it's easier to justify the costs of continuing education to make sure they stay apprised to the latest developments. And this will help to insure that necessary network communications between locations stays secure. The big question to ask - what information, important to your business, would be the most devastating for someone to get a hold of, and what does your current batch of engineers do to protect it? If you aren't comfortable with your answer to that question, then an IT department is a necessity. (While I'm in an entirely different industry, I'd say it would hurt pretty badly if someone got a hold of every record associated with your advertisers (customers), including contacts, detailed information on payments, even potentially account information, etc, etc)
If you're trying to sell this to executives, it's not going to make sense, unless you can show that such a change will increase the efficiency of your engineering department, and save the company money because IT people are usually cheaper than engineers. Which, they usually are. Any kid out of junior college can man an IT department, for example. Sure, it's done that way everywhere else, but that alone is not a good enough reason. More efficient engineers that are happier, and not as overworked seems like the logical angle to me.
This signature has Super Cow Powers
In the early days of Unix/network admin, you were one to three people to handle a whole company, and made heavy use of contract employment to fill in the gaps.
If you think it's going to be a hard sell, don't try to sell a complete management infrastructure. Start with justifying the following: (1) a lead alpha admin with some management (and interpersonal) skills. He or she won't come cheap, but will be essential. (2) an admin trainee, perhaps a lateral from some other department (an engineering technician looking to move up, for instance). The trainee will be able to handle non-emergencies so the admin can go on vacation (or get a decent night's sleep). (3) a night operator to do backups, nighttime upgrades and handle junior-level emergencies. This is more essential than you'd think. If you spend all your admin's time doing upgrades and backups, (s)he will be less likely to be available when your staff is in office.
Later you can pick up a network admin and split duties between system and network, and if the job grows big enough, a specialist who handles desktop and peripherals like printers, scanners, plotters and so forth.
What I described above is a bit too specialized, but with a small group of people you do what you can with what you have. In a pinch the system guy can handle network, the network guy should know how to reboot a box, the PC specialist should know how to do backups, and so forth.
Grow as needed. Once you reach 6 to 8 people (if you ever get that far), you'll have to start thinking about an IT manager.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
You are asking the wrong people. Have you ever seen Slashdot give a majority of answers that don't seem to be generated by a hormone fueled teenager? Try a site that deals with executive decisions instead.
It sounds as you are not an IT expert. Start with that. Hire an EXPERIANCED network engineer and let him/her tell you if a dedicated IT department is the way to go. Let the accountants do the accounting, the doctors do the doctoring, and the engineers do the engineering.
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.
Just like any other proposal:
1. summarize all the current problems (that will be addressed by your solution)
2. Summarize your proposed solution
3. explain in detail your solution and how it will address all the problems
4. explain how much it will cost (in money and people and whatever else) and how it will be implemented (at what cost and how long)
5. summarize what the follow-up will be after the solution is implemented: what will be measured to gauge success, what loose ends will need to be tied up, what will constitute the basis for the clean-up or how new problems will be looked-for and fixed.
Plan to be able to discuss in detail the specifics of questions that will be raised as you explain things.
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.
It's all about the benjis. Make a case with bottom line $avings and you'll get your department.
As long as you are grouped in with Engineers, you will be seen as useful and productive. The moment you are in a standalone IT group you will be a useless cost center that every fresh MBA will try to cut costs in. Nobody likes it, but the truth is that from the MBA point of view (and they are the ones who will ALWAYS decide your fate) IT is something best outsourced like the WSJ tells them to. You will never in your career be as valued as an Engineer. Don't give up the association that you have with them or you will soon regret it.
The number one mistake that I see people in the IT industry make is not reading WSJ, even though it's garbage. The people who make every decision that matters about your job make their decisions based on it like it was the bible. Know your enemies!
Hi jjoelc,
if you are hiring for an IT job, then you will get IT trained people. Sounds good in theory, but having worked as a "Broadcast Systems Specialist" [i.e. electronics technician specialising in computerised broadcast systems] in a large national broadcaster with a separate IT department,let me assure you it will not end well.
The IT people who are hired will know networking, software, server admin possibly phone systems really well, but will rarely have any empathy for the simplest broadcasting principles and priorities. My advice is to foster IT, Tele-communications and networking specialists within the broadcast engineering areas who answer to the current management, but have more of a focus on IT needs.
P.S. The IT department where I worked insisted on business cases, managing priorities and planning redundancies for everything; but on several occasions took networks off air due to IT requirements, and in one instance refused to interrupt an important meeting when 2 national radio networks were off air because of a failed router. Whilst the "networking" department were fantastic to work with, the rest of IT were useless and the big IT boss was eventually escorted off the premises by security guards with his stuff in a cardboard box.
One works to make a company more efficient, not to increase one's job security.
IANAL but write like a drunk one.
They don't have time to do it, and it is not their game anyway.
IANAL but write like a drunk one.
Have a read up on Organisational structures - that Wiki link is very much introduction only, btw. Also the nomenclature isn't standard everywhere, for what you appear to desire, the wiki refers to "functional structure" which appears to be what I think of as "departmental structure".
An organization is just that - an entity that provides structure for organizing. Different structures have detailed and substantial strengths and weaknesses. Any change is a major undertaking and can be expected to have implications over time, many of which will not have been foreseen. The way people work, their goals, priorities, reporting lines... Everything changes - usually even the desk location.
Perhaps the most relevant issue with a departmental structure is the internal focus. An IT department is a service department, it exists to service the other departments. But it's budgets, reporting, goals etc are focused on... The IT department. Other departments become "service users" or "customers". These are the people that get in the way of IT department objectives. Marketing want new gear? Not in my budget and I don't want the hassle. Never-mind what the implications might be for the organisation as a whole, they need it signed off by IT but there's nothing in it for IT. This BOFH syndrome isn't (necessarily) due to some personal characteristic of the IT department manager, the departmental organisational structure actively pushes in this direction.
The IT "service centre" also means the IT "cost centre". Instead of being integral to the whole team and an important "value adding" factor in the money-making system, the focus becomes how much it costs. The number one objective becomes saving money.
People generally have difficulty adapting to a new structure, basically because it's a hugely different form of organising. People who have been at an organisation for a long time tend to think their way of doing it is "obvious" and have difficulty imagining anything else. People who come from another organisation can have difficulty adjusting and think that the way their previous employer did it is "obvious" even though they may struggle to explain why. This is part of the reason why a business restructuring or combination often involves significant changes in management.
This is a huge red flag, you've just told us you have no sound basis for the change nor do you really know what you are doing. That doesn't necessarily mean the underlying idea is wrong, but rather that you don't understand it. You need to think this through in a detailed, formal way. Articulating the proposal will then be straight forward.
I work at a large broadcast radio cluster in San Francisco, one popular with the local sports teams.
Lumping IT with traditional RF engineers is a MAJOR problem being seen at all kinds of broadcasters the US over.
I'd be happy to answer any questions about how to forward IT's needs in regular engineering depts., I've grown quite adept at it.
You wrote:
Wrong. The goal is to have a cost-effective solution to the various I.T. problems and concerns from around the organization.
You want to justify an entire new department to take the place of something that already exists in an informal state - you have an uphill battle.
There two good reasons for a company to spend money - to either sell more product or to produce the same product for lower cost. It would be very hard to explain how a Cisco-certified network pro on staff will help sell more advertising, so I'd suggest going after the "lower cost" strategy. Make a list of all the activities you imagine this new group will perform, then put the names/titles of the people that are currently doing each, then how much time they spend on those activities per day/week/month/year, and then put their relative cost down. That is what the company is currently spending on IT.
Now make the same chart, only put proposed hourly costs next to each IT task and run the same numbers, that is what your new department will cost the company.
So then you take the current expense, subtract the proposed cost, and that SHOULD deliver some savings BUT you;ll have to be sure the people that will no longer be doing "pick-up" IT work around the organization will have some "better" activity to do with their new-found time.
Make no mistake about it, your IT group will cost more than the comapny is currently spending, because salaried broadcast engineers who will no longer work on PC issues won't take a cut in pay - they'll cost just the same...
Your argument/proposition is that the comapny will spend a bit more money, will get more productive work out of the various professionals around the company, and hopefully that will allow the business to grow/succeed.
Ken
I can add a little to the conversation from a unique perspective. I was recruited from an IT help desk manager role into a broadcast engineering position earlier this year. The company I work for, a local news cable television station with 25-30 employees, has three full time engineers on staff but needed someone with an IT background to deploy an HD playout system, upgrade all aspects of the newsroom computer system, design and maintain a digital archive system, create a secure network, etc etc and so on. .I support everything that has electricity running through it (nothing new there). Sometimes I need to troubleshoot problems in the airpath, tackle issues with an audio board, switcher or mic - but more often than not I add value by solving computer related issues and discovering software solutions to problems that the existing engineering team would have simply missed.
I walked into a world patched together with string and tape by the existing broadcast engineering team in an attempt to keep the ship afloat. I think they made a smart gamble on someone with NO broadcasting experience.
I started in focusing on the IT related goals while picking up on the broadcast engineering side as I went along. It was painfully obvious from the beginning - broadcast engineering is simply evolving into a specialized realm of IT. Everything we do depends on our computers, servers and our network. The traditional broadcast engineers in our company were blindsided by this reality and have been scrambling to keep up.
In a nutshell - television broadcast engineering is not rocket science. I'd recommend advocating the hiring of someone with a strong IT background with a proven track record of mastering the unknown and a willingness to learn the technology and language of the industry.
In my situation I am the in-studio engineer in charge - my primary responsibility is the technical quality of our four news related cable channels - but the reality is that I am just a glorified IT guy.
He isn't saying to outsource IT, he is saying to break it off into its own business unit at the company.
Give IT a bit more control, and make it a separate entity that is accountable on its own (instead of taking the engineers down maybe?)
No, I read him as suggesting that it be a separate department, rather than simply be a part of Engineering. I'm assuming that in a TV station, Engineering is in charge of ensuring that all the video footage is clear and properly organized so that news crews don't do things like showing the wrong videos against a news story, or show really poor quality video. Granted, it's IT based, but the above function is different from ensuring that all the computers are working properly in the first place, all the networking equipment is up & running all the time, and so on.
To the OP, I'd suggest making the case this way. The functions are two separate & specialized functions. People who are good @ video editing and the like ain't necessarily good @ troubleshooting or staging laptops, getting all malware removed, ensuring that the network is never down, and so on. Similarly, people who are good @ managing your networks ain't necessarily whizzes @ video editing, or other such operations.
So when all this is bunched under a single umbrella - Engineering, there is an expectation from people outside the department, simply based on hierarchy, that if one of the computer technicians is on leave, then a guy who does the video editing can troubleshoot your computer, or get the network back up, and when that doesn't materialize, the finger pointing will start. Therefore, the demarcation of these two responsibilities is important, and which is why the CIO should not be the same person as the VP of Engineering.
So, where I work, we are part of Engineering. I think it is kind of logical. But, my boss and I are specialized in our roll. The engineers work on the broadcast side, we work on the computer side. By being specialized, we can work faster and better. We have roughly 100 people in our organization, and my boss is full time, and I am 1/2 time. (The other half of my job is on web development).
So, my boss and I are responsible for:
Desktop machines
Intranet and Internet infrastructure
All serves not used in broadcasting
Avid computers
Streaming/encoding computers for online "broadcast".
My boss has some cross-training with the engineering side which makes things easier. I got hired on because I was an IT guy that had radio experience from years back.