If we could measure the cost of "uncertainty" in a project,
we'd have a better way of determining what the cost of 
reorganizing is.  (Currently, it's treated as a "no cost" 
event, because losses in productivity aren't measured.)

Examples:

Cost of putting Argus, Pygmalion on hold.

Cost of not knowing that your office will be moved.  Don't do some 
of the organizing activities that help day-to-day, because it is 
assumed that everything will change again soon.  So you stay in 
a disorganized state for a long time -- since the state of uncertainty
seems to usually extend past the predictions.  (Mark Twain -- nothing 
so surprising as an event, long predicted, that finally comes.)

Cost of not converting software to Motif.  Converting runrules. 
People try to avoid doing things twice, so they put off doing things 
that would help if they know they're likely to have to do it again.

What would the measurement look like?  Can we do it pre hoc  or only 
post hoc?


1.  People spend varying amounts of time organizing their work -- as 
opposed to doing it.  Filing, creating piles, scheduling work, 
organizing papers, etc. do not accomplish anything per se, but 
allow people to prioritize their work and get important/large things
done.  (If the input appears faster than the ability to do it, 
even if only in cycles, then this is necessary.  cf "The twigging 
of overload".)

Sometimes this organization has to do with organizing the environment 
to remind people, or make certain things easy to find, or to place
like projects together.  (e.g. there's a cost to switching among 
tasks, so the organizing cost of placing like tasks together can 
produce an overall reduction in the time spent on tasks, even if 
the organizing costs time, because of the reduced "startup time" 
for each task.  This only works if the tasks appear in random order,
rather than pre-categorized.  Thus, a manager with a secretary who 
pre-categorizes work may save the manager time -- a different person 
in the organization pays the cost than the person who gets the 
benefits.

2.  I claim that "uncertainty" in work reduces people's incentives to
spend what seems like "non-productive" time on organizing -- causing
an overall decrease in productivity.  If a project is "on hold" for an
undetermined amount of time, if people are "about to move", etc., then
behavior changes.  People must make the trade-off.  If you think 
you'll move soon, wait to do the org activity after the move, to make 
it more productive.  If you think it will be a long time -- do the 
org behavior now and get on with things...act as the uncertainty isn't 
there.  Could we measure productive/less productive people -- or people 
at different times in their work lives in more or less uncertain 
times and find out if there is an overall productivity cost?
If so, is this really the reason?

3.  Productivity solution: Act as if you're going to stay put.


(Earthquake example -- people forced to spend time organizing.  Also,
pre and post trips.)

Relationship to innovation -- people can do process innovation (ie their 
own work process) when they think about what they're doing and how to 
prioritize.  If they always put this off -- it may cost a lot in lost 
potential process innovation.

Relationship to interference -- ??  People's work in one area can
interfer with another.  (Car high-beam example -- 4 1/2 years with it
one way, rental car does it a different way.  Twisty, empty roads at
night, so really need it.  Finally figure it out by pushing and
pulling every whichway.  When return home, forget how to do it on
other (original) car.  Frustrating.  Finally remember when remembering
why it was surprising on the rental car and working backwards.
Complete interference.  Note that the same thing happens with text
editors.  The switching cost is VERY high -- cite Stu's reference that
you can't get automaticity if you keep switching.  Potential strong
anti-innovation effect -- reduces users to lowest common denominator
actions (survival).  May also result in innovations when the clash 
between two different systems is discovered...

More on this in another note.


====

Lens as distinguished from mail readers --

Many of the things you want lens to do interact with the mail 
handler.  Thus, all the annotation stuff works best if you 
can see the annotations when you look at the mail.



