This is the third post in our ongoing series: The First 90 Days. When you're coming into a company as the first-ever IT manager, you have to hit the ground running. The work you do in the first 90 days is what sets you up for success for the rest of your career, but it's also a huge challenge. To help, we put together this advice on the process and mindset culled from our team's extensive experience running IT for top Silicon Valley companies.
In the last post in our series on succeeding as a new IT manager, we talked about the situation audit, AKA the thing you need to do first before you do anything else. This might actually be all you get to in your first 90 days on the job.
But for the purposes of today’s article, let’s assume you complete your audit in record time. And let’s say your workload is manageable enough you can be proactive rather than reactive.
While we’re at it, let’s also imagine you have perfect abs without having to exercise, your breath stays minty fresh at all times, and your Spotify playlist always chooses perfect tunes and never subjects you to Fred Durst. But still let’s assume you’re always going to get hit with a lot of unforeseen work—we want to keep this fantasy at least somewhat plausible.
How do you know what to tackle first? And how do you set reasonable goals so you can make measurable progress and finish more or less on target, even when the universe conspires to screw it up?
That’s what we’ll be discussing in today’s post. We’ll take a (very short) look at planning for IT departments—prioritizing projects, goal setting, and juggling short-term and long-term work—and give you some advice on getting it right. A later post will go more in-depth on the day-to-day scheduling of tasks. Today, we’ll look at the big picture.
The Zubat problem, or: why do I need an IT work plan?
Some of you are probably already tuning out. You might be thinking: “Well, that’s all well and good for the perfect abs scenario where there’s time for long-term projects. But I have so many open tickets right now that any schedule I make is going to be closer to wishful thinking than planning. Why should I waste time making plans I know I can’t follow?”
You know what? You’re right! It is not possible in IT to create a 100% accurate work plan. Many IT managers can’t predict what they’ll be doing in the next day with much certainty, let alone in the next 90 days.
Yet this actually makes planning even more important.
To understand why, I’d like to briefly talk to you about Pokémon.
In the first generation Pokémon games, Pokémon Red & Blue, there is an area relatively early on called Mt. Moon. It’s a cave that separates Pewter City and Cerulean City, and the player’s character has to go through it to get to the Water Gym so he can challenge Misty for the Cascade Badge on his way to becoming a Pokémon Master.
As dungeons go, Mt. Moon is not actually that large—there’s only three screens, and only the first one is of appreciable size.
Yet Mt. Moon feels like it takes hours to traverse, because of one enemy:
This is Zubat, and Mt. Moon is absolutely crawling with them. The encounter rate in this area is so high that it seems you get into a random battle every four steps, and each time there’s a 90 percent chance that you’ll be fighting the same Zubat you fought four steps ago.
An individual Zubat is pretty weak, and you’ll dispatch it in a couple of turns at most. In aggregate, however, they’re a huge time suck and the main barrier to your progress through the cave.
To make matters worse, it’s really easy to get lost. Graphics on the Original Game Boy weren’t exactly HD under the best circumstances, but Mt. Moon didn’t do the 2.6 inch, 160px × 144px, 4-color screen any favors with its gray-on-gray cave tileset.
Between the lack of visual landmarks and the constant interruptions, my memory of trying to get through this cave the first time as a kid was one of losing my bearings and wandering around in circles, fighting Zubats the entire time, until I finally got frustrated enough to turn the game off and go outside for a walk.
You know what finally got me through that cave? A map. I downloaded a map of Mt. Moon off the internet (pour one out for GameFAQs) and referred to it whenever I got out of a Zubat fight, so that I was always walking in the right direction. The Zubats were still frustrating, but by sticking to the most efficient path I didn’t have to fight as many of them, and pretty soon I was browsing bikes I couldn’t afford in Cerulean City.
You probably see where I’m going with this. In this tortured metaphor, the map is the IT work plan. Those tickets and random panicked Slack messages from your boss that keep you from the work you’d planned to do? Those are Zubats.
You can’t plan for every task, anymore than you can have a map of Mt. Moon that tells you where every Zubat will be so you can avoid it.
But having a plan lets you maximize progress in the time between Zubats. It means no matter how many times you’re interrupted, you know where you’re at and where you’re going, and you can track the progress you’re making. Without a plan you’re flying blind as, well...
Read other posts in this series:
Getting started on your plan: deciding what’s important
The first step to creating a good plan is to take stock of what actually needs to be done. Fortunately, the situation audit you just did probably revealed a bounty of landmines that are just waiting for you to defuse them. The great thing about IT is that when you’re looking for trouble, you don’t need to look very far. Usually it will find you.
It’s a good idea to start by with a rough idea of the relative importance and size of each project or task, irrespective of other particulars.
You might think this is obvious, but don’t skip this step—you are probably wrong about both the importance and size in ways that won’t become obvious until you see all the projects laid out side by side. I recommend doing this exercise on paper. It’s tool-agnostic, though. If you prefer a spreadsheet, a Trello board, or some other project management solution, go for it.
First, what are your non-negotiables? These are projects that absolutely, positively, must get done. They’re usually pretty obvious—often it’s something you’ve specifically been told is non-negotiable. If there’s a real, specific deadline and it’s not something you or your boss made up, that’s another good indicator that you’re dealing with a task in this category. Examples might be an office move, a phone system that has to be implemented before the sales team begins a hiring surge, or a security audit.
You can set these projects aside for this step. Since they have to be in the plan, they’re less a part of the planning process and more of a constraint on it.
Next, rank what’s left in order of importance, most important thing first. Since “importance” is subjective, here are some questions to ask yourself about each item to help suss it out:
- What work will be saved later by doing this now?
- If I don’t address this now, will the size of this problem grow?
- Is it possible to attach a dollar amount to the impact of this project, even if I don’t know what that amount is?
- What is the worst possible outcome of not addressing this issue?
- Is this something that might affect customers?
- How many people in the company would be affected by this project?
- If I fix this and say nothing, will anyone notice? Who will notice?
- How likely is it that this will present as a problem in the next 6 months?
- Will I be personally inconvenienced by not addressing this? Will other people? How often will this happen in a given week?
If you’re really stuck on how to assess the importance of something, an excellent way to do this is to compare it specifically to another item you’re already reasonably sure about: if you had to rank it, would the item in question go above or below the one with the known value?
You can even rank the entire list with this method, essentially doing a bubble sort. Although this isn’t a computationally efficient sorting method, the advantage is that you can do it without a computer using nothing more than your subjective impressions. While humans tend to be pretty bad at assigning an absolute value to a single item, many psychology studies have shown that we’re surprisingly accurate when making relative comparisons between items, especially for more complex judgment calls like evaluating workplace performance.
Getting started on your plan: Forecasting workload
Once you’ve got your list of projects ranked by importance, the next step is to predict the size of each project and how long it will take. It might be helpful to include the non-negotiables you set aside in the last step, or you might want to take each project and parse it out into its constituent work tasks so you can evaluate it separately.
It’s helpful to do this as a second step because importance can warp your perception of time, and vice versa. It’s really easy to convince yourself that you totally have the capacity to take on an important-but-time-consuming project, or that a task you can knock out in an hour will have a big impact simply because you know you’d get it done. You have a limited amount of time in which to work, so accuracy counts here.
We can rely on the same relative comparison trick we used in the last step to get a reasonably accurate forecast of how long each task will take. This is a technique that often gets used in agile project planning & forecasting, and it’s most accurate if you use a consensus-based method like Planning Poker to take advantage of the wisdom of crowds effect.
But it also works if you’re doing it solo, and we’ll give a simple method for that here. This method works really well if you write each task on an index card, but again, a spreadsheet, Trello, or whatever tool you like will work, too.
- Figure out which project you think will take the least time to complete. Are there any other tasks you think will take roughly the same amount of time? If so, you can group these tasks together with it. This is your base, your 1x group.
- Next, look at the rest of your tasks and ask yourself which tasks will take roughly twice as long as your base task. Group these together as 2x.
- Do the same comparison between your 2x group and the rest of your tasks to create a 4x group. Keep doing this for 8x, 16x, 32x, 64x, etc., until every task is in a group.
- There might be a few that it’s really hard to categorize this way. It’s usually best if you try to sort them into one of these main groups, rounding up. It lacks precision, but since we’re trying to create a ballpark estimate so we can plan, it’s good enough. If you really dislike that, though, feel free to stick them between two categories, e.g. “This task is between 4x and 8x as long as the first.”
From here, there’s two ways you can go forward with this. The easiest is simply to assume a default duration for your base group (30 minutes works well). Since this is probably a pretty small task, though, another way is just to time yourself doing it and work from that.
Either way, once you have an estimate for your base task, you also have an estimate for ALL of your tasks. That is to say, if your base task takes 30 minutes to do, then your 2x group takes an hour, your 4x group takes two hours, your 8x group takes about a half a workday, your 16x takes a full day, and so on. If you couldn’t resist creating intermediate groupings, this still gives you an estimate— in the last example, something between the 4x and 8x group is going to take 2-4 hours.
Putting it together: turning estimates into a plan
Now that you’ve got a good idea of what the most important tasks are and a rough estimate of how long they’ll take, it’s time to actually plan the work you’ll take on.
There’s roughly 480 hours of work in 90 calendar days. So that's the best case scenario for how much work you can get done in a quarter, assuming you don’t put in any overtime and you also work to plan for every single second you’re in the office. But in addition to being something out of a dystopian nightmare, that kind of work schedule is not especially realistic. Among other things, it assumes there will be no Zubats.
And as we all know: there’s always Zubats.
If you start from an assumption that you’ll spend a large amount of time each week on unforeseen, urgent tasks and another big chunk of time on non-negotiables, you’ll have a better idea of how much you can reasonably expect to take on. Armed with your time estimates and your impact ranking, you’re in a better position to figure out which projects you should choose to fill the available space.
It’s best not to try to get too precise with your accounting of projects. You don’t need to account for every single hour of every single day. Just start by taking each of your non-negotiable projects and plotting out their timelines on the calendar.
This will give you a better understanding of where you’re already full up with work and where you potentially have more space for other projects. If you’ve got weeks where there seems to be less that has to get done, either because you’ll be in between deadlines or you’ll be waiting for responses back on work you’ve already done, that’s a good place to start scheduling your more ambitious tasks.
Don’t get too precious about this, however. You should plan to be working on a mix of projects at all times, with the expectation that you may not get to everything if a flock of Zubats decides to bum rush you.
As far as project mix goes, it may be tempting to front-load all of the highest-value stuff from your list, even if they’re all complex projects that will take a while to bear fruit. Resist that, however. You do also want to stack up some short-term wins as well, both to keep yourself motivated and so that you can begin raising your profile with demonstrable progress. (More on this in a later post)
Limit your planning to relatively large swaths of time, e.g. create a 30, 60, and 90 day plan. What do you want to spend those periods working on, and what do you want to have accomplished?
It’s okay if the near term is more fleshed out than the long term—the 90 day plan will sometimes feel more like a wish than a goal. Do be realistic, however. Your plan is what you’ll be communicating to superiors and using to evaluate yourself, so you it’s better that it be unambitious than unachievable. In IT, reality is usually closer to your worst case scenario than your loftiest dreams, and your plan should reflect that.
Ultimately, planning is about staying reasonably grounded in your work, and making sure you’re not becoming overly focused on any one thing to the detriment of the rest. Your plan is like a map -- it’s more important that it be useful for getting you where you want to go than that it be precise in every particular.
Once you start planning, you might feel discouraged by how little time you seem to have for work you want done. In the beginning, it’s not unreasonable to expect your breakdown will look something like this:
- 40% of your time: Fighting Zubats.
- 40% of your time: Accomplishing non-negotiables.
- 20% of your time: Other high value projects.
This is perfectly fine! If all you have is 20 percent of your time to spend on high-value projects, then that’s what you have. The important thing is that you not let the Zubats steal even that from you. The goal is for the work you do in that 20 percent of the time to make the work in the other two categories easier, so you can then spend more time on time-saving work in a virtuous cycle.
In the next post in the series, we’ll zoom in a bit and talk about scheduling your day to day, as well as strategies for triaging projects, so you can decide which Zubats you should stomp and which you can safely run from.