Dear Bill,
I was looking over your articles on “IT Service Management” at the RW Web site. In the stories, obviously you’re referring to a larger computer environment than my needs require. I’m not exactly sure what I’m looking for in an answer, perhaps just some advice, but I’m looking to start an online “Web radio station.” When I finally, hopefully, put this thing together, I want it to be relevant, as far as technology goes, for the longest time possible. Any advice you can pass my way would be greatly appreciated.
Thanks,
Marty Eby
Hi Marty,
Well, when you’re at the bottom, nowhere to go but up … 😉
First, I’d suggest reordering goals a little bit. I presume you’re looking at a business case and a goal of keeping your presentation relevant to your audience. “Radio” on the Internet is not precisely “radio,” and so you get to enhance it in certain ways to your advantage and lose a bit in expectations.
(It’s not quite like listening to the Cards on KMOX in your garage, but can provide something of the same delight, and you get to add related material links on your Web site that you wouldn’t have with traditional radio.)
Go through the ITSM parts quickly.
Service Level Agreement – What are you promising yourself and your audience as key IT performance metrics? Uptime? Quick recovery? Large archives? Delightful programming? Niche/specialist information?
Big radio stations have to promise 99.999 percent reliability for their audience and advertisers – 5 minutes total downtime a year – but that reliability is expensive. Figure out what your appropriate guarantees are for the type of service you’re entering, even if they’re guarantees to yourself – presentation, content, quality, technical.
You can also scale up to them over time – just make it overt in your plans: “Would like to have RAID backup of archives by end of 2007, depending on evaluation of profit or my wife’s paycheck.”
SLAs need to address what kind of production capabilities you require as well – you walk into a studio, whether it’s a laptop with a mic or not, and you need a certain kind of format, whether it’s editing/production software, sound effects library, archive of material and ads, etc.
What are you promising yourself and your audience, including ease of use, fluidness of transition, etc.? If you’re going to be in front of a machine for hours, figure out where your coffee machine will be – seriously – though make sure it doesn’t interfere with other equipment. Make sure the room will be warm enough in your pajamas at 3 a.m., and consider other pertinent life support systems. A happy host is a good host.
Workflow should let people focus on the important part of what they do, with minimal distraction. It’s hard to be funny while fumbling for a fader at the same time; do you have an appropriate outboard console attached to your computer, rather than relying on mouse clicks? Is the physical layout right, are the technical tools right? What are the basics for your performance?
Financial Management – Figure out where the technology lies in your planning, what you can afford and when (budgeting), how it impacts your regular broadcasting and emergency situations (“Oops, lost my main server – do I have funds to replace?”).
Fix specific dates, perhaps the first of each quarter, to summarize and reevaluate financial issues if you don’t have any pressing reason to check them more often.
Capacity, Availability and Continuity Planning – What are you offering, and how much disk space, network capacity, emergency preparedness do you require? Will more people be using the facility (meaning greater availability and capacity for certain production resources)? What spares do you need to keep going? Does your service need complete restoration, or can it limp along with a live mic or archives?
Service Support – Change, Config & Release – How are you tracking and maintaining your systems? Do you need info down to the chip level, or just to know “oh, my modem’s out”?
Keep your records relevant: When did I buy this, who will replace it, what does it cost, when did I last modify it? For a small setup, this can be as low-tech as manila folders labeled “console,” “PC,” “codec” etc. Now that you’re relying on your ISP’s DSL connection to you, what do you do if they change something and your show can’t go out? You want to add one itsy-bitsy program to your editing station, but it won’t boot. Do you have a backout or backup plan?
(Speaking of which, hold a Disaster Day each year where you check your disaster plans. You may need an offsite copy of different records, software and tools – where “offsite” might mean “up in the bedroom away from your kids,” a bank lockbox or at a friend’s).
Problems and Incidents – Do you have a record of what happened last time it wouldn’t boot? What the fix was? Any software required?
On my laptop at home, my DSL connection stops working every few months and I have to create a new one with exactly the same info. Now I have a crib sheet on my desktop with all that info available – cheesy, but it works well enough.
If someone else will fix your box for you, no problem; just have an understanding ahead of time how long it will take, and what you’ll do in the meantime, how much it will cost, etc.
Incident Management means getting back to an acceptable operating level, not “fixing the problem.” What tools will be required to diagnose problems? (Perhaps survey the person doing it for you). External network problems when doing Internet streaming can be difficult to track. Has your audience increased to the point of causing server dropouts? Is your ISP having difficulties?
I’ve had providers continually lower my bandwidth until I noticed enough to scream – unethical, but common. Make it a point to periodically measure your access, and use your listeners to help you stay aware of problems.
For “trouble ticket,” I’d recommend having some way of archiving comments and problems your users might have. Is sound quality acceptable? Do you need multiple bit rates? Do you need to support more formats? Could your Web site be better designed for its function? Can people easily get to your old programs and related material? Do you have transcripts or even sketchy outlines of shows as reference?
It’s also sometimes hard for audio people to evaluate appearance and visual workflow properly – at least I have those faults – so audience and expert feedback can help.
Observing someone else as they click through your site can be illuminating as well; what we think is intuitive might not be to others. A feedback “system” could be as little as a special e-mail address if you’re getting one e-mail a month, or a blog, or a trouble-ticket package like Bugzilla or DotProject.
Again, everything should follow your business model. If you expect advertisers, your model should be serious enough for their expectations. If you’re playing music 24×7 but a 3 a.m. outage for an hour is no big deal, fine; you’ve acknowledged the level up front (though with some head scratching you might figure out a workaround that gives you better reliability with little additional expense or effort).
It’s a good idea to keep a Quality Log that you update on say the 1st and 15th of each month. What’s working well, what could be improved, etc. Try to include one small improvement in each cycle to make this is an active process. As a result, you’ll have a noticeably better setup at the end of the year.
When you fix something, you should make an entry in your incident log, which could be the same as your quality log. Enter as much info as needed to understand the problem later. If you don’t have time to do it thoroughly, at least write down the basics even if on a Post-it that you attach that to your log for later. When you do your bi-weekly review, update missing info. If you find you forget, come up with a better way to write down details that fits your memory. Obviously computer entries are easier to search later, but you have to realistically allow for your own personality and habits.
So to answer one of your questions, no, these methods are not just for big operations – they just need to be scaled appropriately.
Cheers,
Bill
