Mastering an IT Department

I've been managing IT projects and departments for a couple of years, and there is a number of patterns that pop up quite clearly. When the new engagement starts, it likely falls into one of two categories: greenfield or legacy.

Greenfield is simple on its own - you will get a business idea, or vision, more or less refined. Maybe you will also inherit a team that is over the forming crisis and is ready to perform. The rest is simple - you follow the book, pick a process, plan and roll the ball.

Legacy is a different story. You get some documents. You get some processes. You get some deliverables. And it all was managed if you're lucky. I never was.

In a perfect world I can imagine a picture, when there was a manager, and they were managing a project successfully, but personal reasons kicked in and the y had to hand over. Possible? Of course. Probable? Nah. Most likely somebody decided to put a manager into a department because it became a mess.

If you get a half-baked project in your hands - it still can be a simple case. No breakdown? Lets break it. Milestones missing? Easy. Estimates? Good we just handled the breakdown. Just imagine you're starting a new project, and then be happy when you discover something is already completed from your list.

Things get tricky when you get the whole IT Department, with all the legacy systems you have to run along with the brave new projects.

Experience shows that operations are a bottomless bucket eating all team's time, especially if the heritage you got is rich and vibrant. So the best first step you could do is...

Split your projects from your operations

Be optimistic and guess how many resources you need to run the business. Your guess will be wrong anyway, but 20% more then your optimistic estimate is still better than 20% more then your whole team.

You can do a permanent split between operations and development teams, or you can set up a rotating schedule, when everyone is doing operations now and then. Both approaches has pros and cons, and both are valid. But once you distinguished those two - try to keep the effort spent on operations within the boundary, only pulling people from projects when absolutely necessary.

Having separate backlogs for projects and ops also helps. Additional bonus you get from having a clear boundary - now those areas can be managed using different methods which will suit those the best, for example more agile Kanban is good for less predictable operations, while Scrum is a favorite balance of agility and predictability for many who run IT projects.

Once your bravest sailors draw a water from holds and keep the ship afloat, you got some free hands to fix the leaks. The next step is to...

Fix the root cause

It is not only tempting, but also seems perfectly reasonable during a crisis to fix an issue and jump onto the other one. And this is how you keep a crisis running. Instead, your goal should be to make operations 100% autonomous. Some routines may be too expensive to automate, some are to be decommissioned soon and dont deserve the burden, but keep the goal in mind and only allow exceptions for a very good reason.

Instead of keeping crisis mode on, try following a simple algorithm when facing an issue:

1. Carefully log the issue, so you have all the data to build reports and investigate the cause.
2. Fix the issue fast, so the system gets back to normal. If you dont feel that the proper solution is coming soon, make sure to describe actions taken if somebody needs to do it again.
3. Now take your time to investigate why the issue happened, and fix the cause once and forever.

Of course, step 3 may take a lot of time and is rather for the project stream than for operations. What I would usually do is I'll fix the issue and then immediately create a linked one within projects backlog to find and address the root cause.

Let this habit occupy your routines for some time, and you will realize that you're spending less times fighting fires and getting more capacity for what is important in life, specifically to...

Document your assets

Gut feeling tells me that a majority of issues born while changing a system that one poorly understands. It does not even have to be a system somebody else build. We all are merely gold fishes floating around IT aquariums, creating sophisticated new solutions and forgetting what we did in either 5 seconds or 5 months. Invest in a documentation.

Documenting is a topic well deserving a separate post or book, but strive to log everything supporting your system: architecture, infrastructure, applications, components, processes, peers. Just make sure to keep the details level reasonable, so it does not get outdated in 5 seconds. And make it easier to navigate through, so your team likes it and finds useful.

And one day those efforts will yield you enough time to implement all those improvements and the new features you were dreaming about. Good luck!