Fog Creek Software
Discussion Board

Good task management practices?

I look after a web programming/product engineering team at a company here in Australia. We as usual under-resourced and over-worked and we deal with work requests coming in from diverse areas of the company.  We don't produce software in would I would call the classical way. Rather we have a work request come in, we service that request and then we move onto the next request.

One issue I'm having is scheduling my teams time. At any one time we'll have a bunch of small requests requiring attention that typically take anywhere from 1 hour to 1-2 days. At the same time, we'll have longer term tasks that may span a period of weeks, so each person will have one long task and a bunch of smaller tasks at any given time.

The problem I'm having is how to schedule this type of work. One problem is that content producers etc always want things yesterday and requirements change so it involves some shuffling around. Excel is an option but I'm wondering if others have bumped up against this and what is the best way to deal with this. Project I've looked at briefly but it doesn't seem to deal woth individuals doing ongoing work to well.


Graeme Merrall
Wednesday, May 28, 2003 and look for the outlook plugin

Wednesday, May 28, 2003

I don't really like task management - it tends to fragment a team into a bunch of isolated individuals... a team in name only, not in the way they work together.

I would set some kind of objective around the type of work you expect... "official request/project" vs "drop-in". 

Joe AA
Wednesday, May 28, 2003

I have found this a fairly common setup.  Large requests with small 1 to 20 hour requests.  Here is how we handle it.

Everything gets an estimate.  This is usually done by the person most familiar with the area.  Be certain they include the entire estimate, not just coding hours.

Assign a priority, even if it is your own, within each group
1 to 4 hours
4 to 8 hours
9 to 16 hours

Now when someone is working on a large change, but waiting for user or process feedback, they can attack these smaller ones.  [i.e. The change owner is out until next week, I can take on a 9 to 16 hour change]. 

However, they should always select at an hour level 1 less than they can do.  This will avoid an issue if they get a faster response than expected or if the estimate was incorrect.  If the estimate is really off (16 hours instead of 6), they should put it back into the 16+ hour pile.

Each site takes some fine tuning, but it does work once you get it setup.

Mike Gamerland
Wednesday, May 28, 2003

I wrote something that does this, based on the Excel method that Joel talks about.

Tim Sullivan
Wednesday, May 28, 2003

I like as it's free, web-based, and very straightforward.

However, I'd like to know why you need task management.  Is the work not getting done?

Brent P. Newhall
Wednesday, May 28, 2003

Sure the work is getting done but there's 2.5 developers (I'm the half) attempting to service all requests that come in that have varying urgencies and completion times in hours to weeks.
I have to manage my own team of people as well as develop when I can and juggle these tasks and I'm finding it a bit difficult keeping everything in the air at once. Plus when someone wants to trump someone elses request I've got a clear understanding of what will be affected.


Graeme Merrall
Wednesday, May 28, 2003

Check out the book _Getting Things Done_ (ISBN 0142000280). Nothing to do with software, but rather a system of managing all the crap that you have to deal with.

I never got to finishing the book though my life is about to hit work overload for the next 2 months. The basic idea is to get everything down on paper so it's not floating around in your mind, and some techinques at doing it.

Wednesday, May 28, 2003

I recommend an extremely low-tech solution:  index cards.  Write down each task on an index card.  Then you can physically post them somewhere and point to them when somebody complains about your schedule.

One of the drawbacks of technological solutions is that they tend to become complicated.  I find that it's usually best to start out with a simple, powerful system and grow it only if if proves inadequate.

One of the advantages of index cards is that they're highly visible.  They provide a weight to the amount of work to be done.

Brent P. Newhall
Thursday, May 29, 2003

A lot of these ideas - chunking up tasks, writing them down on index cards sound like XP.... not the pair programming part, the project planning part. [1]

In a nutshell, divide the tasks into 1-3 day fragments, combining smaller tasks and fragmenting larger tasks. Then allow the programmers to choose the tasks they work on.

Every two weeks see how many tasks have been done. that's as many tasks as you can expect to get done in the next two weeks and so on. This numbr will change from time to time, especially when the project changes, but during the project's lifecycle, it's a useful estimate. Or so XP says.

The Joel Excel method is nice, but when I started using it I realized... I wish Excel took things like weekends into account and then realized that MS Project did that.

I've always found MS Project's UI to be clumsy, and it's difficult to unbreak things that are broken, but someone that knows what they're doing (certainly not me) can get it to do some cool things.

Sunday, June 1, 2003

*  Recent Topics

*  Fog Creek Home