When planning projects a lot of IT managers and execs forget the interrupt driven nature of our field, or do not properly account for it. No matter how well you plan, no matter how well you isolate an individual they WILL be interrupted, and likely fairly often.

So how do you plan for that? I've heard a lot of theories over the years.

Double the estimate each level of management you go up (the Scotty method)
60/40 - assume only 60% of your time is on projects 40% is on interrupts (the MS project method)

Whatever method you are using, it's likely frustrating you and your upper management as things aren't getting done on time. This has more to do with your time management than your planning actually. Your work habits, prioritization and interruptions are causing these delays. I'll touch on only interruptions here.

I had a boss once who gave me a gem of a phrase:

Your lack of planning will not become my problem.

This sums it up well. People will always come to you with what they think are emergencies. A large part of your job is managing expectations, and calming them down. Some are real, most are not. Remember it is our job to help people, but also to weigh business needs and prioritize appropriately.

How do you do that? Transparency and involvement in IT planning from business folks. But that's another article :)

The cost of interruptions

The biggest thing to realize is that being interrupted has cost. Some of these costs are obvious... the time it takes to do the interrupting task for instance. Some are hidden costs such as the mental time it takes to switch gears and moral. Measuring each is not always easy but I'll try and touch on the main ones.

Context switching

Many studies have shown that it takes 5-10 minutes to get back into the swing of a project after being interrupted. If people on your team are interrupted 5-6 times in a day, a small number, you've now lost half an hour of productive time each just to context switching. The reality is closer to 10-15 interruptions in a day which means you loose almost a hour per person just to context switching. On an 8 person team that means you are loosing an employee a day.

Moral

Lets face it... finishing something feels good. People like to complete tasks. People naturally work harder in the last sprint before the end as they want that high. Often times love of problem solving is what drove people into IT in the first place. Interruptions mean a delay in that fix, a delay in your motivation.

No one likes to be behind either, it's frustrating. As soon as you get behind frustration builds and productivity goes down. I won't repeat all the articles recently on the power of positive management, but those dance around a basic moral issue. People like to be productive, people like to meet deadlines, people like to solve problems. Let them, and their moral goes up.

Perception

No one other than the person interrupting ever sees the interruptions. All everyone else sees is that a project was delayed. They are blind to the fact a lot of other people interrupted as well, that their "short task" added a lot of time in context switching etc etc. This also leads to a decrease in moral and a loss of productivity.

Maintenance

The worst part of interrupt tasks is that they incur a debt. Due to all of the above, the first inclination is to solve the problem in the fastest possible way without digging into it to expedite a return to the original project. This incurs a debt if the problem was not solved in the right way, one that you will have to pay with another interruption later.

The solution

The good news is this is controllable, the bad news is you are going to have to stop blaming other people. It's between you and your boss how you structure your workload and your day, no one else's fault. If a project is behind, there was a failure somewhere. Accept that and these solutions become a little more self-evident.

Plan your day, plan your team

Read any article about the habits of successful people and you find a single trend, a structured day. At least part of it. Ever wonder why IT guys like to work at night? It's because that's when there is uninterrupted work and they feel the most productive. Fine, work with that.

I hd a team once that had a super morning person and a super night owl. I was somewhere in the middle. This was phenomenal. The morning person got two to three hours before anyone else came in, and I kept people off them for another one or two while I went through my morning routine. After lunch the third member would be in and we would swap. The first guy now took a break and dealt with tickets, people walking up etc. I went to work on projects and the third started his morning routine.

By the time I was ready to head home, I would assign out out of hours tasks for one to work on at night, once he got his project time, and for the first to do in the morning.

This allowed each person to get (mostly) uninterrupted time, have a flow to their day and deal with what they had to do. It also allowed us to service the needs of the company as one of us was always available to be interrupted. The key here was that since we knew ahead of time what part of the day we would be interrupted, we would only work on very short, low context cost projects during that time.

Cross train

No one person should be the sole repository of knowledge for anything. This guarantees interruptions. Have them teach the reset of the team, at least the day to day tasks. This will make people happy as they are learning new things, and it will help you to have a more well rounded team.

Specializations are ok and expected, those are where the projects get assigned. Anything that comes up on a regular basis however, your entire team should know how to deal with from support up through engineering.

Learn to push back, politely

There is a right way and a wrong way to ask someone to wait, but if done right this will enhance your department's reputation, not harm it.

We have a really important project going on right now, do you mind if I find you this afternoon?

You haven't said no, you are giving them the chance to tell you it's important, but you also aren't dropping everything to help them right now. Often people are pretty understanding about this and will agree. The important part is to follow up when you said you will. This builds trust.

Ask for project priority

Often people will not realize how much they have asked you to do, even if it is the same person. If it's multiple people there is no chance they know. Instead of saying no, or asking them to wait, have them sort it out internally.

I'm already working on [project] for [name] in your department, can you tell me which project is more important to you guys?

Again you have not said no, I cannot stress the importance of this enough in maintaining relations. What you have done is pushed responsibility for prioritizing on to those asking for the items. Who knows better which matters more to them, you, or the people it's for?

Maintain a priorities discussion

Notice I didn't say meeting, I said discussion. This can be as simple as a spreadsheet with tasks that everyone can see or as complicated as an online Kanban board or ticketing system either of which have a weekly email thread or Yammer message. The important part is the running dialog that sets expectations. If people can see you are busy, they are less likely to interrupt and more likely to be understanding of delays. Don't be afraid of transparency.

Personally I schedule a meeting for this with stake holders once a week, and then use the meeting as a threat in case our Yammer thread does not produce agreement. Usually it's canceled, but it's important to keep it on the books.

Keep a task list

One of the surest ways to avoid interruptions is to promote faith in a response to some form of task list. This is usually a ticketing system but can be pretty much anything except email.

They key here is build faith. If people get a quick response to their issues when submitted, they will use the system. If they don't, they will walk up and bug you which is exactly what you are trying to avoid. Keep discipline on response and resolution time, and keep your project load to the point your team has time for response.

Tools like Zendesk have wonderful metrics to help you track this.

Again don't be afraid of transparency, publish these metrics, be proud of them, or admit fault if needed and show you have a plan. You'll be surprised how easy it is to get more staff when needed if you have been showing people constantly what you are up to. You will also get a lot more understanding of delays when it's understood and agreed the project list matches business alignment.

Learn to let things wait

In this age of immediate gratification it's easy to get sucked into the trend of instant response. We're programmed to do it. My OCD demands that I click as soon as a notification comes in that I have a new message.

Discipline yourself that during your project time, you wait until you have a natural break in your work to look at that email or IM. You will avoid a lot of context switching this way. You'll also find that people will naturally tune to your teams rhythm once it's developed. If Steve is always available in the afternoon, and Brian in the morning, they will unconsciously start going to them.

By following these guides, you will find you get a lot more done with the same amount of people. Moral of the team will go up, which turns into a positive cycle of increased reputation for your team. Happier people are more friendly, friendlier people are easier to deal with, everyone wins.