« Agile Development: Think Big, Start Small!
Contingency Planning »

Manage multitasking

April 7, 2008 | Author: admin | Filed under: Time Management, Project Management Best Practices

Manage multitasking
By Kailash Awati

The costs of multitasking are well known. Firstly, it takes time for the human brain to switch from one task to another. This is analogous to the overhead of context switching in computers (the term “multitasking” itself originated in computer science). Secondly, multitasking delays the delivery of all tasks simply because a given task is not finished in a single go.

The evils of multitasking have been commented on in the popular press, with CNN, Time and even the occasional newspaper article warning against it. Despite the general awareness that it is counterproductive, developers working in corporate IT departments are routinely expected to juggle several tasks in the course of their day-to-day work. Furthermore, I often find that the ”ability to multitask” is stated as a requirement in job advertisements. For example, here are excerpts from a few IT development job ads that appeared recently in seek.com:

  • Software engineer in Auckland: …Must have the ability to multi task and prioritise…
  • Web designer / Applications engineer in Sydney: … Must be able to multi-task…
  • Systems implementation specialist in Sydney: …Should be able to multitask and work on multiple projects…

The expectation is that employees must be able to juggle tasks and even projects (!) as required. Given this, are there things a frontline technical / project manager can do to alleviate multitasking-stress on their teams? Yes there are, and here are a few that’ve worked for me:

  • Prioritise work: You’re never going to get everything done concurrently. Given the workload on your team, some things may never get done at all. It is, therefore, paramount that work be done in order of business priority. Obviously the prioritisation needs to be decided in consultation with the business. Under no circumstance should it be based on technology (I’ve seen this happen) or developer preference (seriously - I’ve seen this too!).

  • Get a high-level view of everyone’s workload: As a part of the weekly routine, get each team member to send you a rolling workplan for the next month or two (I go with 4 weeks). The plan should list tasks that the person anticipates doing each week, along with a time estimate per task. The estimate should be at a granularity of no less than 0.5 days or, ideally, 1 day (see next point). This gives you a high level view of each person’s workload, and alerts you to potential multitasking problems.

  • Align task switches with the end of the day or week: Encourage people to work on a single task per day, or whole multiple of a day (unless it’s a shorter duration task, of course). This way, task switches happen at the end of a work day, thereby allowing time for the mind to orient itself to working on another task.

  • Plan on a four day week for development work: Assume that programmers have only four dev days - i.e. days for development work. Keep a whole day aside for other stuff such as ad-hoc requests, support, meetings and administrative work. Depending on the situation in your shop, you may even have to reduce the number of dev days to three.

  • Insist on decent work hours: It is OK to work overtime once in a way - when a project deadline approaches, for instance. However, it is definitely not OK to expect the team to sustain unreasonable work hours over an indefinite period.

  • Minimise Distractors: Don’t clutter developer work weeks with distractors like unnecessary (or unnecessarily long!) meetings. Your job is to remove distractors, not add to them.

  • Provide Support: As Joel Spolsky mentions in an interview - “I always think of it” (i.e. management) as more of a support role - like moving furniture out of the way so they can get things done - than an actual leadership role.” Specifics on how one might do this will vary from situation to situation. In some cases you may need to act as a gatekeeper - filtering requests from the business. In others, you may need to answer high-level questions and provide guidance. In a nutshell - do whatever it takes to help your team do their job.

  • …But don’t interfere: I don’t think I need to elaborate on this. You don’t want to give people the impression that you aren’t confident in their ability to handle their work. Such behaviour is tantamount to micromanagement which, as I’ve mentioned in an earlier post, is a definite no-no.

  • Know when to push back on your managers: Take a stand when your management makes unreasonable demands. Explain why it won’t work, and suggest alternatives. This is a an opportunity to earn your stripes as a manager (and your team’s respect).

Given the increasing workload and resource constraints that corporate IT works under, there’s often no option but to multitask. This can have negative consequences on team performance and morale. Some of the techniques discussed here may help avoid and/or manage these consequences.

Original article can be found at http://eight2late.wordpress.com/2007/10/16/manage-multitasking/

Kailash Awati currently manages IT development at a multinational in Australia. Over the last several years, he has managed IT projects at companies ranging from startups to established firms. He has also worked as a business and technology consultant for companies in Europe and the US.

On the technical side, he is a seasoned database architect and administrator with wide experience in designing, implementing and administering databases for transactional and analytical applications.

Earlier, in what seems to him like another life, he did research in fluid dynamics and other areas of physics.

For what it’s worth, he holds doctoral degrees in physics and chemical engineering together with assorted certifications in project management and database administration. An admittedly strange mix, which he sometimes finds hard to explain.

He blogs at eight to late, where he writes about project management and other (at times distantly) related topics. Oh, and he also maintains a web presence at www.orafusion.com where he publishes longer articles on his professional interests and the occasional cryptic crossword.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

This entry was posted on Monday, April 7th, 2008 and is filed under Time Management, Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories