views:

623

answers:

9

I am often involved in multiple programming projects at the same time. I sometimes find it hard to time-share between those projects efficiently.

For example:

  • Some projects get too little attention, either because they are less fun or because I forget about them.
  • Sometimes it feels like the context-switching between projects takes too much time.
  • It is difficult to prioritize between projects, and to determine how much the priority should affect the schedule.
  • Interruptions occur (both from external sources and by suddenly coming up with something myself), forcing me to suddenly move to another project.

Do you have any good methods, tools or other suggestions for coping with multiple projects running in parallel?

+4  A: 
  • Make sure all stakeholders on all projects are aware of your involvement in all projects and negotiate how much time you have allocated for each project. (This could be very easy is you are the only stakeholder in all projects :-)).
  • Use scrum to prioritize your tasks and create your schedule and sprint backlog.
  • Add some buffer to each sprint for unscheduled interruptions.
  • Have daily meeting (if working on a team) or set aside time every day (if working on your own) to track your progress against the sprint backlog. Having a burndown chart really help you visualize your progress and motivate you to stick with the plan.
Franci Penov
It would've been nice to get a comment what's wrong with my answer...
Franci Penov
Franci, I like what you have to say. +1 for you!
itsmatt
+7  A: 

A time management class might be the best thing for you.

Most of us work on many different projects on a day to day basis. In an effort to battle the task switching penalty there are a number of different things you can do:

  1. Shut your door, turn off the phone, close the email and IM clients. Basically do what it takes to ensure you have a fair amount of time blocked off to do some work.

  2. Schedule the times when you are available to be interrupted. Like, just after lunch, or in the morning, or whenever works best for you.

  3. If you come up with an idea for a different project your working on, write it down in a notebook for that project and forget about it until you're ready to actually switch tasks.

Basically, just focus on the task at hand and close yourself off from the interruptions.

Chris Lively
Good points, Chris.
itsmatt
+1  A: 

Try to allocate at least a half a day as a block per project. Maintain proper to-do lists and divide the work into sensible packages. Have an idea of how it all fits together with deadlines.

Marcin
+1  A: 

I'd suggest you consider the possibility that you're not able to work on multiple projects, that you're not an efficient task switcher. If your style is such that you need to be heads-down and focused, or maybe just heads-down and focused on a specific project, then accept that and structure your work accordingly.

For example, I can keep multiple code windows going at the same time and keep track of what I'm doing in each, but if I'm going to write text, like I am here, I have to just sit and focus and not look at anything else. It's just how I work.

Aside: Some people say that nobody is an efficient task switcher, and I'll argue against that, but that's not my point here.

Andy Lester
Actually, I am a lot more efficient when working on multiple projects compared to having only one. But I feel that there is room for improvement.
matli
+1  A: 

I have used the following strategies to deal with this:

  1. First, you have to keep very good note, and I would recommend a notebook for each project and take notes about questions, decisions and the like. I am usually pretty good at keeping track of one project in my head, but you start getting 2 or 3 and they all start running together. This will also give you a way to document what it is you are doing for each individual project without having to sift through notes on other projects.

  2. Try to reduce the context switching, and make sure you context switch at convient times. For instance, if you can work on project A for a full day, and then switch to project B the next, that is a lot easier than switching in the middle of the day.

  3. Push back when you feel your productivity is greatly threatened. If you are being forced to context switch constantly throughout the day, you need to push back and let everyone know that you will not get anything done if they keep making you change what you are working on.

These techiniques have helped me at least.

Craig H
+5  A: 

I'm often working on multiple projects and what works for me is the following:

Clear understanding by those involved on each of those projects (that aren't single-person ones) that on X day I'm only working on the ABC project and that any questions will be answered on the next day for that project.

I don't context switch back and forth during the day. I work on one thing and get that to a point where I can change to another project. I find too much flip-flopping between projects causes me to do less than 'my best' on them.

I utilize a prioritized to-do list of things that need to be done. Even if I'm on a single project during a certain period, I still utilize this. Then I don't have to try to hold that stuff in my brain. What I write down, I don't have to try to remember.

I keep a folder (literally a paper folder) for each project and an electronic folder for each of the projects I work on. Everything goes in the folder when I'm done working on it. All my notes are kept separate and then I'm not flipping through a notebook with multiple notes for multiple projects interspersed. I have an electronic calendar for each of my projects that is rolled up into a master one so I can pick the granularity of my "let me check my calendar" situations.

Everyone has to be "on board" with my multi-project work. Those that I report to need to be aware of it (and reminded of it, as necessary) so that they don't try to get 100% of my time whenever they want it.

I have to remain a little flexible on the off chance a fire drill pops up. But it needs to be a real fire drill. While I'm not that into the "self help" books, I do like the Covey idea about determining whether things are important or not important, urgent or not urgent.

If needed, I turn down or postpone work that I simply can't take on. I'm one guy. I don't have a problem saying 'no' but I only say it when I mean it. Make sure you aren't overcommitting yourself. The last thing you want to do is over-commit and under-deliver. It needs to be the other way around.

Anyhow, that's how I do things and it generally works well for me.

Best of luck!

itsmatt
Interestingly enough, that's the gist of what I said as well; you just elaborated a bit more on it. Yet you get upvote and I get downvote... :-)
Franci Penov
I liked what you wrote, Franci. I gave you an upvote, for what it is worth.
itsmatt
A: 

My previous job involved juggling work on 3-4 different projects simultaneously. My strategy for managing this involved 2 things:

  • Maintaining a hierarchical & prioritized multi-project to-do list that was easy to use. I found that todoist was perfect for the job - very easy to use, didn't get in the way and could handle multiple projects.
  • To handle context shifts, I maintained project diaries (basically a notebook, 1 for each project) which I religiously used. In these I noted not only what I was working on, but designs, problems, conversations, meeting minutes, action points, and importantly what I needed to work on next. So if I had to return to a project after an interruption, I was able to pick up exactly where I left off by reading the project diary.

At my current job, the Software Development methodology used is Agile/XP. We have a visible "task board" (a whiteboard with index cards with the tasks to be done, who they are assigned to and the progress). How does this help?

  • Well to handle task priorities, Agile/XP mandates the 'customer' (or someone who represents the end user) dictates which tasks they would like done within the current release cycle (or iteration). Hence the responsibility of what to do next is shifted to the 'customer'. Since detailed metrics are recorded, estimation becomes easy, and the customer knows that they can't have everything, so they'll prioritize what they'd like to see in the next release.
  • Context shifts? I still maintain a detailed project diary. It takes a bit of discipline to use it, but I've found it to be very beneficial.
Prembo
+1  A: 

Developers working on multiple projects experience many of the same time-management issues that system administrators deal with, so I'd like to recommend Time Management for System Administrators by Tom Limoncelli. It's got plenty of detail on the things that work for the author, and it's short enough that reading it doesn't become yet another large project you'll have to work into your schedule.

From the Amazon page:

Among other skills, you'll learn how to:

  • Manage interruptions
  • Eliminate timewasters
  • Keep an effective calendar
  • Develop routines for things that occur regularly
  • Use your brain only for what you're currently working on
  • Prioritize based on customer expectations
  • Document and automate processes for faster execution
TimB
Added to shopping list.
matli
A: 

If there are no clear priorities, or if all of the projects need to be finished at the same time, I usually spend most of my time on the project(s) I like the least. Then, when I need a break or get stuck, I work on the projects I like the most. After I reached a milestone or completed some functionality in the likable project, I'll switch back.

Jrgns