I'd contemplated titling this article "The art of saying no" but realized that ran contrary to my overall philosophy that if done right, IT should never be saying no. That is another topic however.

What is really going to come down to is advice on how to properly prioritize to save yourself time and headache. Over the years I've noticed the biggest challenge IT faces beyond interruptions is very poor priority planning.

Part of this stems from the fact IT has always been the odd man out in a company. They are sometimes under finance, some times facilities and some times if they are really lucky, engineering. Few of these people know what to do with us however.

Even when under engineering I've seen management schemes that work very well for development (Agile, SCRUM etc) trying to be applied to IT to eventual disaster and the frustration of both parties.

Why? Because IT rarely has a single set of definable priorities. We rarely even have a definable SOURCE of priorities and are getting projects from many departments. Even if they do consolidate, it will change tomorrow, not two weeks from now. At the velocity of modern business you simply need a system that supports the level of flexibility that is expected.

Philosophy

Goals

Like any project when deciding how to tackle it you need to start with identifying your goals. What are you trying to accomplish? My list usually comes down to:

Sanity
Transparency
Business involvement
Flexibility
Organization
Metrics

Except for the first, I've found four of these antithetical to typical thinking in IT. They go against everything we have been taught.

How can you be transparent when no one understands what we do?
Business getting involved just causes headaches.
Flexibility means never getting anything done.
Organization? Have you ever seen how often I get interrupted?!?

These are the responses I almost universally get when I have this conversation, even with management in IT. So I'll address them here in the same way.

Transparency is simply necessary to properly manage your workload and get the budget you want. Transparency is the source of trust. It is the only source of trust we have in an industry that typically gets ignored until things break. This is how you stay in people's minds and let them know you are working in between down times. Yes, it's painful and scary at first on both sides, but it gets better I promise. Building trust will open a world of doors to you typically thought locked forever to IT. What should you be transparent about? Everything!

Business involvement is how you accomplish that. Managers in other departments need to be involved in your prioritization, your hiring process, your budgets etc. Getting this sort of agreement up-front saves you endless amounts of pain. Once the need and/or benefit of your projects is explained and agreed upon, the path is cleared by those with the power to do so. You'd also be surprised what other departments DO value and consider important. I found I was doing a lot of unnecessary work once I involved business folks in my decision making.

Flexibility means setting the expectation with yourself and others that things can and will change from the beginning. Don't say a project will take a week, say it will take a week of man hours or a week of dedicated time. This leads to proper resource discussions. Trust me when I say business folk understand this language a lot better than we do.

So how can you stay organized and remain that flexible? Build flexibility into your process and expectations from your business partners. It sounds counter intuitive but it can be done, I'll show you how with the right tools.

Metrics are data, data is good. Data driven decisions are usually much better than emotional ones. Data also helps you a lot with transparency. The finance team may not understand what you do, but they will understand a chart showing a 50% increase in requests over the last six months when you ask for more staff.

Metrics also allow you to identify problems and trends you might not otherwise have seen and actually reduce your workload. More on that in a different article.

Consistency

The most important part of changing how you work is to be consistent. People are naturally change adverse. Stick to your plan and people will fall into the routine you need once they see the benefit to themselves. Expect resistance at first and overcome it with kindness not adversity. Explain why you need people to change and ask for their help.

Visualization

Be sure whatever tools and systems you end up using have a visual component. Either charts of data, color coding etc. These easy visuals will make your life much easier as your brain is wired to think that way. It kicks in the pattern recognition portion of your neural cortex which is the biggest advantage humans have over machines.

Time multiplier projects

Here is where your metrics come in. When prioritizing projects look at where your team spends most of their time. Use your data to determine what the biggest recurring tasks or problems you have, and automate or solve those.

An example of this... at one company we spent a lot of time on machine prep and account creation as they were hiring very quickly. The team was spending 8-10 hours a week on this all in. I had the data to back this up so was able to secure budget for imaging software and time to write some integration. The roll out took us about two weeks of man hours in prep with no visible benefit to the company as they still ended up with the same machine. For us however it was an investment that payed for itself in a few months, and freed up time. We got back almost a full man-day a week and rid ourselves of a repetitive task no one liked doing anyway. Moral improved, efficiency improved, accuracy improved. Our staffing needs declined as a ratio to growth.

That is what I mean by focusing on time multipliers. Spend a few hours to gain back many more. When you have the data to back it up, this isn't hard to sell.

Time allocation

This will always vary by industry and company needs but as a general guide here is how I have found the most efficient way to break up folks in IT's day:

Support:

65% ticket response
10% research
10% maintenance
15% assisting engineering on projects

Engineering:

60% project time
- 40% business request/improvement time
- 20% automation
15% resarch/learning
15% ticket response
10% cross training with support or other engineers

Important thing to notice here is that in both jobs, support type roles and engineering centric roles, only ~60% of their time is blocked, and plenty is assumed for interrupt driven tasks.

Notice I've also blocked about 30 minutes day for cross training. Part of this is just discussing what you are doing with other team members. It doesn't have to be formal.

The time assigned to support folk to work with engineers is something I have found hugely valuable and way under-done in the industry. This is the surest way to keep the moral of a support person up by giving them interesting tasks and learning. It trains them so eventually they can become entry level engineers knowledgeable in your systems. Most of all it lets engineers assign out repetitive tasks that are uninteresting to them, but something new to support folks. Win win for everyone.

Tools

Right tool for the right job

You wouldn't use a network traffic analyzer to troubleshoot a failed hard drive, so why do you try and force projects into tools not designed for that purpose?

Too often I've seen ticketing systems used as todo lists for projects. In IT we have two types of tasks. We have the incoming issues and problems which usually have a set or quick resolution. This is what ticketing systems are for. We also have long term projects. These do not fit into that model and typically scew or make worthless the metrics that can be derived from that system.

My personal favorite setup is a ticketing system and a Kanban board. The first is for all the incoming requests, the second for long term projects.

Don't get carried away separating your systems however or people will not use them. Integrate as much as possible. More on that later.

Ticketing system

The biggest goal here is issue tracking and data. I cannot stress the value of data from this system enough. This is where your project prioritization begins. This is where your hiring decisions begin. Find a system that has tagging, tracks resolution times and closures etc.

The reason you want tagging is simple, visualization. You can see how many times you've had to fix a printer in accounting over the last three months. If it gets too high, you have the data to back up a recommendation the fix it. If they complain it's always broken, and you have touched it once, you can show this data as well and ask why the issue was not reported. Explain they need to report this for proper tracking, and request they contact you before they get so upset next time, you are happy to help.

The other feature I have found useful is SLA tracking. If your first reaction to that statement was typical "I'm not a vendor" then you are thinking about your job wrong. IT is a service department, end of story. Your customers are the rest of your company. They are the reason you have a job, not an annoyance. Treat them as customers. Part of that is an SLA on responding to them, the same as you'd expect from your vendors. Never forget they see you as their ISP, helpdesk etc. Expectations are the same.

When something comes in that should be a project, consider it a ticket who's real request is "open a project to do this" and close it once you have. Remember, right system for right job.

Projects

My preference here is Kanban. I know it stinks of other management methods I mentioned above, but it's a very useful tool if implemented with the right goals in mind. It also makes sense to people even if they don't know what the cards mean. They can at least see quantity. It's simplicity is also it's greatest strength in that it has a lot of flexibility and granularity.

The most useful part of this system I've found is the concept of the lanes, and a limit on those lanes. One team can only handle so much work at once without suffering from context switching issues (discussed in my previous article). Kanban is a great way to visualize that limit and enforce it both at a management and individual contributor level.

At first setting these limits low will be very frustrating, but believe me it's necessary. You will get a lot more done if you force yourself to finish things before moving on. The simple act of moving a card out of a "working" lane into a "todo or waiting" is usually enough to dissuade people from changing track.

This discipline will simply let you get more done in a shorter amount of time, thus helping your team over all. It also doesn't hurt the team's reputation.

When having your priorities meeting with other groups, it's also a great visual aid when you pull it up to add their tasks, and they can see the load they are competing against for your attention. This goes back to transparency.

In most online kanban systems adding a card is simple, some times even just sending an email. This lets you add a task when you are thinking about it and then go back to what you were working on. When you sit down to re-prioritize, it will be there and can be properly tagged, prioritized and assigned. This frees up your mental energy at that moment, which is critical to avoiding context switching.

Moral is a big component of this as well as people can see how much work they have gotten done.

Spreadsheets

Don't... just don't. If you are thinking of using a spreadsheet, you are not thinking about automation and metrics which should be your first goals. There is no good way to use a spreadsheet for project tracking and prioritization, end of story.

The hardest thing to admit in IT is that you are providing a service, and that is all. Prioritization should not be done by you except as an adviser. You will have to learn to be very open to accomplish this however and gain some diplomatic skills to keep all the different sources of projects happy.