9

I thought this would make for a good topic with some interesting suggestions.

What are the first things you would do when taking over IT at a new organization?

What are some red flags you would look for immediately?

What are your MUST haves for a department (depending on the size of the organization)?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Robert Swisher
  • 1,147
  • 7
  • 14
  • 2
    While I like your question, it is close to a duplicate. This is a topic that has been covered on varying levels. See: http://serverfault.com/questions/152707/new-sys-admin-job-where-do-i-begin – Warner Jul 14 '10 at 17:36
  • Even if it doesn't get closed as a duplicate this kind of question should be wiki. If nothing else, it's very subjective. – John Gardeniers Jul 14 '10 at 21:36

3 Answers3

18

Honestly ... nothing, not a damn thing. I sit back and learn the job as it is done NOW by the people that are there. After some time and when you are sure you have a good handle on how things work now (not just technically, but politically, and inter-personally as well) you can start formulating lists of what you think should be changed.

If you don't understand where you are right now, your ideas of where you should be could and most likely will be wildly off from reality.

As for red flags:

  • Many many manual processes
  • No Change Control
  • No Documentation or worse wrong documentation
  • VP/C-levels that are WAY too involved in the day to day operations (like resetting servers when you aren't in the middle of an emergency and nobody else can do it)
  • Cheap equipment everywhere but the company claims to make XXX (million/billion) a year
  • Unhappy employees
  • Constant firefighting
  • No or poor monitoring system
  • "You need to talk to 'joe'" is the answer to every question you ask
    • and joe isn't in IT

As for must haves ... I think that depends on on what you do and how you do things... like I must have a digi terminal server hooked to a modem with a dedicated line as a last resort if I can't get to my Voice Routers... but you may not need that. Once again, sit back and take some time to figure out how things are and what peoples complaints are first before swooping in and wanting to change everything.

Zypher
  • 37,405
  • 5
  • 53
  • 95
  • +1, Especially "No Documentation or worse wrong documentation" - That's the boat I found myself in a few years ago when I went to update documentation (the old stuff was dead wrong, missing info, extremely outdated). – Chris S Jul 14 '10 at 19:13
  • @Chris: It's a current pain point for me ... a lot of facepalming as i try to update documentation :) – Zypher Jul 14 '10 at 19:54
  • +1 If it's running, leave it be and concentrate on learning it. Few things in life are quite what they first appear to be, including inherited systems. – John Gardeniers Jul 14 '10 at 21:40
  • +1 for attempting to understand the political and inter-personal climate before changing things. To make big changes work, you need buy-in and that's hard to earn if no one likes you. – gMale Jul 15 '10 at 06:19
8

This is all high level stuff:

Security:

  1. Audit who the admins are. Verify they should be admins.
  2. Determine what the IT controls are in place and the last time they were verified.
  3. Verify patch levels / OS and application updates.
  4. Perform at least minimal vulnerability scanning using readily available tools.
  5. Check physical security on servers and core networking equipment.

Environment/Performance:

  1. Determine what pain points exist in your data center.
  2. Find out what your SLAs and OLAs are and verify they are remotely reasonable.
  3. Put at least cursory performance monitoring on systems to ensure none of them are overloaded.
  4. Understand how key assets are deployed and have physical verification that they are where everyone says they are and they are configured as they are supposed to be.

Personnel:

  1. Meet with IT personnel one-on-one or in small groups outside of the work setting (lunch, for instance) to get to know how each one is as a person.
  2. Talk with folks who interact most with your IT staff to determine who are the hard workers, who have good people skills, who are brilliant but socially challenged, etc., so you can ensure they're in the proper places to do the job.
  3. Determine where your pain points are from the security and performance and make a call if it's the current people who are employed, lack of people, lack of tools, or some combination.
K. Brian Kelley
  • 9,034
  • 32
  • 33
  • With regard to security I would add be looking for written policies regarding acceptable use and data access. Also policies relative to specific compliance areas such as SOX, HIPPA, PCI DSS. If this takeover is via an acquistion, I would likely look at IT projects and assessment whether or not any of those projects should be put on hold until it can be determined how they fit into the total IT portfolio. – jl. Jul 15 '10 at 18:26
0

Great answers.

1 -- Analyze the current processes and systems so that you understand them better than your predecessor. Even if it is a stupid reason in your eyes, something probably was not configured the way it is for no reason at all.

2 -- Concentrate on efficiency, not growth. You want to do more with less, then grow from there. Going forward, things should be extremely well documented, secure, but most importantly of all, scalable.

MisterITGuy
  • 46
  • 1
  • 1
    I've found that the "something probably was not configured the way it is for no reason at all" is only true ~75% of the time. – Chris S Jul 14 '10 at 19:15