Estimating time needed for actions & projects

[Michael Grant]

One aspect that neither GTD nor Covey have much to say about is
estimating how much time it will actually take to complete an action or
project, and scheduling accordingly. Julia Morgenstern's time
management book does deal with that issue, but otherwise I wasn't all
that impressed with it compared to the others. As an experiment, I've
blocked out the projects I want to spend time on next week, and I'm
going to try to keep a log of how I actually spend my working hours. In
the past (pre-GTD) I haven't been too successful when trying to map out
my hours too rigidly in advance, but I'm getting to a point where I
need to pay more attention to the deadlines for my longer-term
objectives and goals, so I'm going to need to go beyond prioritizing
what I should be working on at any given moment/day/week. I may end up
needing to break out the Gantt charts. Any thoughts?

Michael


--
<http://globalocal.blogspot.com/>

Are they stupid or just evil?

[Anthony Baker]

This is the one of the biggest issues in time management that I face,
as well. Everyone wants an estimate of the time something will take --
be it a client or my wife.

That said, I've yet failed to reliably take on documenting the time
taken on items (vs. time estimated) and to also note any hitches that
came up in the process so I can later -- when estimating anew --
recall the pitfalls and look (post-project/task) and what I can do in
the future to prevent pitfalls from happening, or add possible pitfall
time to my estimates.

Would love to hear how other folks handle this...

[Ennis]

I can't claim to be successful in this area either. It's one of the
main reasons why I tend to use time goals, work 30 minutes on this,
work 2 hours on that, because those are more realistic (although even
these are problematic).

I have, however, found that tasks that repeat end up being estimatable
after a while. I do keep a time log in excel, and that lets me get a
rough idea. Then I set a timer, and try to do the goal in precisely the
amount of time specified and by prototyping I figure out how good my
estimates are.

GTD purposefully sidesteps this whole issue, it's a list driven system
b/c the assumption is that you're a busy exec who is constantly being
interrupted and can't block out time. Personally, I still need to use
Covey's QII notion of allocating time for long term important (but
sometimes not very fun) projects in order to get them done. Lists make
them too easy to skip / avoid.

[JoshD]

I hate to say "me, too," but this tends also to be a problem for me, as
well.

It's a problem with certain tasks, which don't really have a beginnig
or an end, but rather simply require attention. Things like "water
plants' are easy to estimate; do it once with a timer and you've got
it. Creative tasks are more difficult, whether coding or other.

I tend to do as Ennis does, and make a next-action to be "spend 20
minutes setting up foobar drawing," and just make hashmarks on the card
to show that I've done a block.

20 minutes is the point where I'm supposed to get up and stretch, and
it also works well with the idea of trying to make each next action as
small and atomic as possible, so you can look at a set of five cards on
the desk and think, "yup, that's my morning."

As ever, of course, have had varying levels of success, YMMV, yadda
yadda, eat your vegetables.

Cheers,
Josh

[Miguel]

Excellent topic. I have a lot of trouble estimating time as well. I
suspect *a lot* of people have this issue. I'm anxious to find out what
successful prognoticators do to calculate the time needed for different
tasks and projects.

Miguel

[Bob Koss]

Size matters, and contrary to what you might have heard elsewhere,
small is good. The larger, more complex, and longer duration a task
is, the less accurate the estimate.

[Martin Wood]

> On Tue, 25 Jan 2005 11:40:06 -0000, Miguel <miguel...@gmail.com> wrote:
> >
> > Excellent topic. I have a lot of trouble estimating time as well. I
> > suspect *a lot* of people have this issue. I'm anxious to find out what
> > successful prognoticators do to calculate the time needed for different
> > tasks and projects.
> >
> > Miguel

For estimating software projects (some items might be applicable to
other tasks) then some good straight-forward advice can be found here:

http://www.joelonsoftware.com/articles/fog0000000245.html

[Josh Rothman]

I've discovered that, in general, my estimates for large creative
projects are usually only being 30% and 50% of the total time required.
Now I estimate things, and then *immediately* multiply them by three;
on the whole I find that I'm closer to 1/3rd of true required time in
my estimates.

Keep a log of your estimated times, then note the actual elapsed times;
maybe you'll find your own ratio.

[JoshD]

Josh Rothman wrote:

> Keep a log of your estimated times, then note the actual elapsed
times;
> maybe you'll find your own ratio.

On that subject, does anyone have advice for good time tracking
software?

I'd love something on my mac that tracks how long I've had what window
open. Although I'm sure I'd hate to see the answer to that, some days.
:)

[JoshD]

Martin Wood wrote:

> For estimating software projects (some items might be applicable to
> other tasks) then some good straight-forward advice can be found
here:
>
> http://www.joelonsoftware.com/articles/fog0000000245.html

That is, indeed, an excellent article.

But I wanted to highlight an excerpt that shows that there is *always*
an exception:

> As I write this, Netscape's 5.0 web browser is almost two years late.
Partially, this is because they
> made the suicidal mistake of throwing out all their code and starting
over: the same mistake that
> doomed Ashton-Tate, Lotus, and Apple's MacOS to the recycle-bins of
software history.

Well, you know....

Two out of three ain't bad. :)

Cheers,
Josh

(Yes, I know, OS X didn't actually throw out all code and start over,
also see Carbon, and in 2000 that *was* the publicly-stated strategy,
and all that. Let me snark, it's been a rough week already. :))

[Ennis]

I'm a PC user, but I just use excel.
Excel has a macro built in for time, I think it's Control-Colon (C-:).
You put start time in one column and finish time in another, and you
look at elapsed duration. Then you have have several columns after that
for categories, and you just add the time elapsed from each task into
your category so that you have a running count of how much time you
spend where. I have a name field at the beginning and a memo field at
the right for more info on the task.

Another way to do this is to figure out what your atomic focus unit is
- how long can you guarantee to work without interruption? 10 minutes?
20? 2 hours? Then you could how many focus quanta you use per task.
This is good b/c it makes the work a bit purer, but also acknowledges
that you have to take breaks along the way.

As for ratios, I find mine varies pretty highly depending on level of
alertness, time of day (related), and type of task. I'm only well able
to predict repetitive tasks after several iterations, and more creative
or new tasks not at all (which is why I use time / word targets)

[wtp...@gmail.com]

> I'd love something on my mac that tracks how long I've had what
window
> open. Although I'm sure I'd hate to see the answer to that, some
days.
> :)

I am using a trial version of WorkTime 3 from
http://www.nestersoft.com/worktime. Here is a description:

WorkTime is a project tracker surveys the time you spent working with
your PC. It gathers statistics about projects you worked with, programs
you run and time you spent running them. WorkTime displays various
statistics about your working time. WorkTime can remind you to take
regular breaks to prevent computer-related injuries.

todd.

[tttopaz]

There will usually be some projects, particularly long-term projects
with multiple steps, that will benefit from advance planning and reverse
scheduling. Keeping a log of how you actually spend your time is a
great start. Oftentimes we have no idea how longs things actually
take. If you are a GTD'er, then you know you need to assess how much
time you need to collect and process each day and to complete your
weekly review. When I logged my time, I realized I needed to allow more
time for emptying my paper inboxes. It's helpful to get an idea of how
long your routines take and to work around them when planning your
schedule. The problem with scheduling activities is that people tend to
be overly optimistic about what they can accomplish and hence
overschedule their day and week. Of course, for many projects it will
be difficult to estimate how much time they will take. That is one
reason it helps to know how much time your routines take and then leave
adequate time for less consistent items.

In addition to regular routines (commuting, eating, sleeping, reading
e-mail, cleaning, whatever), as a GTD'er I like to have a fairly sizable
amount of time each day to work straight off of my next action lists.
However, I also allow time in my schedule for long-term projects. I do
this by reverse scheduling. Basically, I break my project down into
small steps and estimate how much time I think each step will take. I
add up the time and usually round up the time estimate by 25-30% to
account for underestimation or other delays (e.g., getting sick, taking
a vacation). Then I work back from the due date (or the date I would
like to complete the project) and decide how much time I am going to
spend each week working on the project. It is much less intimidating to
commit to spending two to four hours per week on a project than to cram
20 hours of work into one or two weeks at the last minute. Not all
projects lend themselves to this method (e.g., painting a room), but
reverse scheduling is useful for many long-term projects with a lot of
steps.

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 1/27/05