Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I started working as an IT department manager in a non-IT company. One of my first assignments is to get some estimate of the current state of IT, so we could plan for service monitoring, improvements, etc. I also have one other person working in the dept. What would be a good way to approach this assignment? I would like to follow ITIL guidelines, as it's supposed to be a collection of best practices, but I don't want to get to entangled right away. So I plan to start using OTRS as a service desk with basic categorization, then start building on that. I am also thinking about making a Service Catalogue or something, but I am not sure how deep to get into it and how much detail to document. I am thinking about making a Software and Hardware Inventory, but don't know if that would be a smart thing to do right now. So I would like to hear some ideas from the ServerFault community that will certainly help me (and any future googlers stumbling in here).

share|improve this question

closed as not constructive by HopelessN00b, ewwhite, Mike Pennington, Iain Aug 6 '12 at 17:50

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
    
I think it is not a dupe as that huy is starting anew. –  Zlatko Aug 5 '12 at 20:15
4  
To be honest, if you'd asked this during the working week I'd expect it to be closed NC fairly quickly as there is no real right/wrong answer. –  Iain Aug 5 '12 at 20:18

6 Answers 6

up vote 8 down vote accepted

Forget everything told so far - you have TWO critial issue first.

  • Check the licensing situation. This should be fast - either there is maangement, or not. if someone has no clue where the licenses come from, it is a problem.
  • Check backup procedures including restores. MOST businesses go bankrupt when a critical data afailure occurs.

These 2 items also give yo ua general idea of the state of the whole affair, mostly by seeins how the people answer. You may directy hit into a rats nest, or get something decent.

Everything else is secondary - mostly because these two items should not take more than 2-3 days to find out and report on.

share|improve this answer
    
+1 - these points should be obvious but all too often people post here after a disaster because they still managed to miss them. –  RobM Aug 5 '12 at 17:32
    
Plus it gives you a good idea how the organization follows rules. Those are most ofte nthe negelcted parts - and after that you know how "legal" your job is, how sloppy the people are etc. –  TomTom Aug 5 '12 at 17:52
1  
Everything else is secondary? Change-control processes? Monitoring system? On-call rotation? Ticketing system? Intrusion detection? Virus scanning? Password policies? –  Mike Pennington Aug 5 '12 at 19:11
    
I have to start somewhere and since Wednesday it's my head on these criticalities :-) I will start here. And since I start here, I'll mark your answer as accepted –  Zlatko Aug 5 '12 at 20:06
    
@MikePennington - you might disagree but TomTom has a point. I'd say that when you take over a new IT department and you're worried about its process, you want to triage issues, and I can make an argument for TomTom's ones being in the top 5 at the very least. If you're non-compliant on licences and you have a volume licence then the vendor may withdraw the right to use that in the future, driving up costs of IT in a precipitous manner. And backups are a required fallback point for at least two of the issues you mention. –  RobM Aug 5 '12 at 21:02

Ben Rockwood has a couple of useful links, in his Lisa 201 Keynote. Recommended reading.

share|improve this answer

If you don't have a ticketing system already, this is priority #1. This way, you can say "Hey, we're getting crushed! My guys are averaging 50 assigned tickets a day" or you can say "Uh, maybe we don't need to hire anyone else for a while".

After that an inventory is a good thing to have. Plenty of software will do hardware and software inventory at once, so there's no need to treat them separately.

Also, I would meet with all of my employees and ask them what they think needs improvement and promise them that everything they say is confidential. If there's a real problem, you'll hear about it from them. The people answering the phones or managing the severs on a day-to-day basis will know every procedural problem that exists. You just need to get it out of them.

share|improve this answer
    
I am getting a ticketing system first. But I haven't thought of speaking with the personell (just one guy), so it is a great advice. –  Zlatko Aug 5 '12 at 20:04

When building or re-organizing an IT department, it is difficult to beat the advice in The Practice of System and Network Administration by Thomas A. Limoncelli, Christina J. Hogan, and Strata R. Chalup. They offer battle-tested priorities and requirements that I've found invaluable.

share|improve this answer
    
I would recommend the same. All in what you need independent of your enviroment. –  Mr.T Aug 5 '12 at 18:26
    
Thanks, books are always a good thing to have and consult. –  Zlatko Aug 5 '12 at 20:02

I'm pleased to see you mention ITIL - not just because it's the framework that I'm familiar with but because working to A framework, any framework, is useful in this situation. I'm sure you don't need me to tell you this but ITIL needs to be customised to the size and the requirements of the business; if it's a small business you're working in and you want to implement ITIL procedures then maybe you don't need formal change management and release management boards if those meetings would essentially be between all the voices in one person's head. It's a framework, not a strait jacket.

I'd start by making sure you have the basics - @MDMarra and @TomTom both have posts which contain the first few things I'd certainly be looking to do. I'd also add one-to-one meetings with the key users of IT in the business to see where they think the current setup meets their needs well and where it could use improving.

I'd use the meetings with the key users to start putting together the service catalogue - in my mind this is a living document you build based on user perspectives so they have an "email service that supports access by x and y methods" rather than "Exchange 2010 service pack 1 with 2 servers configured as..."

In addition to MDMarra's good suggestions for the meetings with the IT staff, I'd use the chance to get them onside with any service catalogue you're working on, and use it to discuss how calls are logged and explain how splitting helpdesk calls into service requests, incidents & problems can help them.

share|improve this answer
    
Thanks, I like the bit about meeting key users. I think I'll definitely do that. –  Zlatko Aug 5 '12 at 20:00

It would behoove you to find out how your IT department and the technology that's been implemented serves the needs of the business. What are the critical applications and services? What's the impact to the business if those applications and services aren't available or aren't reliable?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.