When you start work on an assignment, move it to a second column, to the right of the first one. Add the expected completion date, then (very important) notify both the assigner and beneficiary that you've started to work on it and when you expect to be done.
In comes an interrupter with a new top priority. You ostentatiously pull out an index card, fill it out, and add it to the top of the left-most column, gesturing at the tasks that precede it to show the requester when you expect to start working on it. This works best face-to-face. Otherwise you have to describe it -- suboptimal, but still workable.
If the interrupter isn't satisfied and tells you it's a higher priority than other items -- especially if he tells you to stop what you're doing to work on the new assignment instead -- don't argue. Agree -- so long as the interrupter calls the assigner and beneficiary of the task you're working on to let them know delivery will be delayed, as well as calls your manager to get approval for the rearrangement of your priority queue.
What if there's just one chronic interrupter and it's your boss or your boss's boss? This same technique works even better: You've shown your boss (or boss's boss) the impact of their mandated change in your priorities and asked them to take official responsibility for it. Beyond that, you have no cause for concern.
Do you feel just like a bureaucrat? If so, it's probably because somewhere along the way we decided as a culture that planning is bureaucratic -- improvisation is how all real red-blooded Americans get things done. You need to recognize this is an unfortunate aspect of our culture, not an unfortunate aspect of planning.
How it should work
It doesn't have to be this contentious. Often the triple-I effect is the result of managers failing to respect the chain of command. Depending on the circumstances, either your manager, a steering committee, or an algorithm should determine the relative priority of the tasks sitting in your queue.
For that matter, it probably shouldn't be your queue at all. It should be the team's queue, which can be managed very much as outlined above.
The original question
The last piece of the puzzle is an important dimension of the original question: how to handle circumstances in which minor but real emergencies intervene frequently enough that they -- not people with an overabundance of enthusiasm -- are the primary source of interruptions.
I know of two solutions. The first works well in larger IT shops and is to always have a designated on-call emergency responder. This responsibility can either rotate, be a permanent part of the junior-most team member's job, or serve as the official penalty for being the last one to show up for a staff meeting.
The second alternative is even simpler, and it works for small shops: Statistically speaking, you know you'll be interrupted an average of x number of times per week, with the interruptions averaging y minutes apiece.
Build that knowledge into your schedule. Call it the Interruption Fudge Factor (IFF for the TLA-philic among us). Add it to your estimates for every assignment and worry no more. You have the triple-I factor covered.
This story, "The end of multitasking as you know it," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.