Re: Time management resources

["Steven J. Owens" <puff -at- netcom -dot- com>]

Ronica Roth writes:
> I wonder if anyone out there can recommend any good resources on time
> management.
> 
> I'm not really looking for tech writer-specific stuff necessarily, like on
> how to estimate how long a doco project will take (although, come to think
> of it, that might help, too). More on how to estimate task lengths in
> general, and how to improve, well, time management. I enjoy multitasking
> (bored without it) but sometimes I take it too far, or multitask only fun
> tasks....anyway, read any good books lately?

     There are surely a ton of books on this topic in the business and
self-improvement sections of the bookstore, probably most of them are
fluff or snake oil.  In the past I've found that most of my more
useful reading on time and project management has been in software
development research areas.  Steve McConnell's _Code Complete_ and
_Rapid Development_ come to mind here, as does much of the work of the
SEI (Software Engineering Institute).  Check back issues of the CACM
and the IEEE Software journals for articles directed at the topic.

     One aspect of estimating time is to distinguish between the ideal
time it takes to do something and the real time it takes to do
something.  Ideal time is how long it would take in ideal
circumstances working on that specific thing.  Back in the real world
you have to deal with dependencies, tool and resource availability,
multiple responsibilities, interruptions, not to mention that you lose
considerable productivity every time you're yanked out of "workflow"
(see DeMarco's _Peopleware_).

     Of course, it's a lot easier to identify this problem than it is
to solve it.  One interesting approach suggested in Kent Beck's
_Extreme Programming Explained: Embrace Change_ is to deliberately set
and consciously tune the ideal-to-real time ratio for the entire
development team.  Another suggestion is to have a different person
track the estimates and the actual time reported for various tasks, to
help the individual developers refine their estimating ability.  Of
course this is difficult to do without the strong atmosphere of trust
and honesty created by the Extreme Programming approach...

     Extreme Programming is kind of weird in the software development
methodology world.  You mgiht want to check it out.  The thirty-second
overview of the ideas behind it are this:

     Changes are always necessary in software projects because
software essentially models some aspect of the real world.  The real
world is complex and unknowable, with the result that both the world
and our understanding of the world gradually change over the course of
the project.  Changes added later in the project cost a lot more.  The
traditional reaction is to attempt to prevent and control change by
introducing large (and unfortunately expensive and unwieldly)
processes, which in turn tend to make change even more expensive and
difficult.

     Extreme Programming accepts and embraces change, with the idea
that the course of development will be a constant series of
adjustments to the software model.  How do we afford this? 

     - By dispensing with many of the traditional, large, unwieldly
methodologies. 

     - By focusing on several small, simple, but effective practices.
Practices that everybody agrees are good but seldom can afford to
include (like testing).

     - By taking these practices to extremes (like comprehensive
testing of the project being instantly and effortlessly available at
all times - write the test before you write the cod;, when the code
passes the test you know you're done).

     You can find out more at:

     http://www.c2.com/cgi/wiki?ExtremeProgramming


     Moving along back to personal time management, a lesson I learned
several years ago is that it takes about a month's worth of doing
something consistently to craft a new habit.  If you're going to try
to change the way you do things, expect it to take at least a month
of deliberate effort for the change to  "kick in".

     As a general technique, something I find useful is to simply keep
lists of things that need to be done.  The key is to use the "To Do"
list in a much more fluid fashion.  Don't worry, when you're writing
things down, which one has to be done first, or if some are merely
two-minute details while others are hours or days long.  Just jot
enough to remind yourself that it needs to be done, and to serve as a
mnemonic jog so you can recall what the priorities and details are.

     Expect to have to recopy partial lists on occasion, or rewrite
the list on a fresh sheet of paper with extra items, sometimes break
down or consolidate some items.  And sometimes, if an item gets copied
four or five times without significant change, that's an indicator
that it's really a moot point and you should just forget about it.

     In a sense, my stack of notepads are a sort of running commentary
on my projects and jobs.  I look at it and I realize that some
particular pages end up being more important, I come back to them and
I refer to that list a lot, or I flip back and forth, or I end up
recording a lot of little details (phone numbers, names, etc) on a
particular page until I need to recopy it all cleanly.  

     Maybe in theory I should have two or three different notepads -
one for names/phone numbers/addresses, etc, one for to-do lists, and
one for general notes on topics.  But I find that, for me, doing it
all one one notepad, and flipping back and forth and occasionally
recopying, works a lot better than a daytimer or organizer.  The
overehead required for any other approach would destroy the effortless
stream-of-thought that makes this work for me.

     Someday PDA technology will be good enough to suit my needs.
Meanwhile I use a medium-sized notepad that's large enough for me to
write on comfortably and small enough to carry almost everywhere
(usually a spiral-bound steno pad).  

     I have some ideas for a project tracking/planning/estimating
softare tool that I'll probably try to write someday.  Most tools that
exist today (MS Project, etc) are merely specialized editors for
people who know how to (or even *like* to :-) write project plans.
The general approach I'd like to pursue would be a tool for free-form
entry and tracking of data, with an aspect that attempts to _derive_
project plans, specifications, estimates, from the data.  It would
combine many of the above ideas from how I use my notepads, but the
major challenge will still be the form factor - physical data entry.

Steven J. Owens
puff -at- netcom -dot- com