I regularly see a lot of confusion out there about which organizational model is best for managing a software project: the To-do List, the Calendar, or the Schedule.
You might be wondering, which one is the best? But that’s kind of like asking, “Which is better, a saw or a hammer?” The answer depends on what you’re trying to do, of course.
Where I find people get off on the wrong track with managing software projects is that they haven’t necessarily stopped to think about which tool is right for which job. I personally believe all 3 have a place in a software shop. Knowing what to use where is the trick.
To-do Lists
To-do Lists are perfect for tracking activities that take less than a couple hours each and someone is worried about them slipping through the cracks. Big things get all of the attention. The little things tend to get forgotten (and if you’ve ever read anything I’ve ever written, you know that I believe it’s the little things that often separate a good product from a great product).
To-do Lists are great for tracking the little things. Since a To-do list is a queue (optionally with a priority, maybe some due dates or a few other tidbits of information), they work best when “managed” as a queue. That is, keep throwing things on the end as they come up (the “push”), and keep lifting them off the list whenever you have time to tick a few off (the “pop”). Every once in a while, you can re-order things so that the more important ones get done first.
They’re great for tracking things that aren’t yet scheduled, or for wish-lists that will later be moved from the To-do List to the Schedule.
To-do Lists are terrible for scheduling when you’ve got more than one person on a project. Because of their linear nature, To-do Lists trick you into using over simplified calculations like “add up all the work and divide by the number of people” to figure out when all of the work will be complete. This method of estimating finish date is wrong almost all of the time.
The Calendar
Calendars are great rallying tools. Stick a couple high-level goals on them and put them on the wall in high traffic areas. The 30 little boxes are just great for about 1 or 2 phrases on a couple of dates, or a couple big red X’s. Try to put anything more than that and they become downright unusable (they have very limited visualization capabilities). I’ve seen quite a few people try to run a schedule off a calendar by drawing ovals that span across several days to show they last a while. It gets far too messy when you’re talking about activities that span weeks or straddle a month-end border. If your work breaks down from big activities into little activities (like most software activities do), then you’re hosed.
I should also mention that I AM a very big fan of using Calendar tools (Outlook, Mail, whatever) for tracking of personal time after the fact. That is, by jotting down a new item in a personal calendar every time you spend an hour on this or 2 hours on that, it’s way easier to look back at how time is actually spent on a weekly basis. What I’m saying here is that a Calendar isn’t a great tool for planning anything other than meetings, in the future.
The Schedule
The most popular visualization of a Schedule is the Gantt chart. That word “Gantt” is sometimes enough to make some people laugh or cry depending on their disposition. I even hate to use the word sometimes because it tends to be synonomous with a particular project management tool that many people love to hate.
I think part of the mis-trust of Gantt charts stems from the fact that a lot of people have had bad experiences while trying to get it to be the one be-all-and-end-all view of a project – something it cannot do. However, neither can the Calendar or the To-do List.
The Gantt chart is however, probably the single best visualization of an overall schedule for multiple people working on a project concurrently – especially if the work is complex enough that it breaks down from larger activities or goals into smaller activities or goals.
By now, you should be able to see where I’m going with this…
All 3 Have Their Place
You wouldn’t try to build a house with just a hammer (makes measuring and sawing awfully difficult). Why would you try to manage a complex software project with only one view of your project? Well you probably would try because you thought it would be simpler than having multiple views, right?
Let me suggest an alternative:
Everyone on the team should have their own To-do List for the fiddly little bits that are on their plate, to be done some time during the project. These lists can be public (at least visible) to the team so everyone knows who’s on the hook for what fiddly-bits.
There should be a master “team” To-do List. Fiddly-bits first get thrown onto the team’s To-do List and then get moved from there to some team member’s To-do List when the appropriate person is identified. Fiddly-bits are less than a few hours work by definition. They’re important, but too micro to be gumming up a Schedule or Calendar view.
There should be a team calendar with only a few big milestones on it, that are important to the whole team. These are rallying points. Don’t go gumming it up with individual milestones, fiddly-bits, or to try to use it as a Schedule. The less big red X’s on any given month, the more focus each will receive.
Use a Schedule for activities that are bigger than 1 day’s work each. Use the Schedule to break down big chunks of work into little chunks of work. It’s your main tool for managing a whole team of people working concurrently. You can prioritize, shift work around and get a “whole project” view (even though you may be breaking your whole project into iterations or sprints, kudos if you are).
Each of these views has something different to offer, and the best managed project will typically make use of all of them to their best advantage.
People get the most frustrated when they either try to use one view in particular to manage the whole project, or start off with something simple because that’s all they need at the time (a To-do List or Calendar for example), then get into that awkward phase where their needs have outgrown the “single view” but they haven’t quite realized it yet. If that sounds like the stage you’re getting to, hopefully this article helped you spot it!
