I know, this time we'll make sure every 30 minutes is accounted for in the schedule! Our project plan is so detailed it's got to be right!
Oh oh. Headed for trouble. Don't worry, I've made this mistake too. For whatever reason, our brains tend to equate large amounts of detail with accuracy. Too bad, because it's most often not the case with software projects. Not only is there not a direct cause and effect relationship, but I'm not even sure the 2 are correlated. Hmmm, that's a lot of not's in one paragraph.
God bless the PM's who are so eager to produce a great plan that they spend hours agonizing over hundreds of tasks in their Gantt charts, trying to make sure they absolutely have not forgot anything... They want oh so badly to get it right. Should installing and configuring the database server be a half-day or full day? (The correct answer by the way is: 3 days ;)).
My advice is to spend that time trying to pre-assess the risks that are most likely to throw the major tasks off track, and don't waste time haggling with yourself about a few hours here or there. If you're spending any amount of time budgeting by the hour, that's too much time and too much detail. Get out of the weeds.
I'm sure there are at least one or two types of software projects where this is not true, but in most cases, the optimal granule of time to be planning for is 1 to 3 days per task. It has to do with our perception of time. We've grown up on daily cycles. A day is a large enough chunk of time to have some wiggle room for the little things that take us a half hour or so. On any particular day, if you've got a bunch of things to do, you can still re-prioritize or make choices if you start running out of time. Do this, don't do that. If you're trying to estimate down to the half hour, you're leaving yourself absolutely no time for error. You know what can trip you up if you're budgeting in such small increments? Any of the following:
- Traffic
- Meetings
- Talkative co-workers or any juicy bit of office gossip
- Having to unexpectedly reboot your machine (I was debugging a memory leak problem once and it took me 15 whole minutes to reboot - shutting down services manually, giving the machine time to swap stuff in and out of the page file, and finally shutting down and reloading all of my startup programs and dev studio)
- A bad taco at lunch (um, he's been in there a while...)
You just have about 0% chance of being consistently accurate on time estimates of such seemingly small tasks. Any little thing can throw you off on a half-hour task by as much as 2 or 3 times your original estimate.
There's a serious diminishing return on the time you spend taking a schedule from a resolution of 1 to 3 day tasks, down to 1 hour tasks. It's not a good use of anyone's time.
Worse, it leads to a false sense of security because you work soooo hard on it, that you automatically expect there will be some return for all your extra effort, in the form of increased accuracy. It's an illusion.
What is good about spending some time trying to think of the little things that tend to add up (after all, 8 one hour tasks takes up an awfully big chunk of your 10 hour day), is that it can tend to lead to more accurate estimates of the larger tasks. So encourage that, but don't stick it in the schedule. Schedules are hard enough to manage and re-arrange with 40 or 50 tasks, let alone a few hundred.
What sinks software projects are the big things like: changing requirements, unclear specs and distractions. If you can devise ways of managing these things instead of trying to plan to the hour, you stand a much better chance of meeting your schedule. Spend your precious time wisely and find those leverage points that will have the greatest impact on your success.
Sounds easy, I know. But it's not. It's hard. Getting seduced by the 1 hour resolution on schedules reminds me of the anecdote about how the advent of the computer word processor led to a decline in the quality of writing, because people concentrated too much on fonts and layout, and not enough on the quality of the content - same deal with scheduling.
Comments