Estimating and overtime

[Steven Jong <SteveFJong -at- AOL -dot- COM>]

What a coincidence that the two threads on reducing overtime and adhering to
estimates have come up together! They are, of course, closely related.

It's hard not to be a little cynical about an initiative to reduce overtime. I
presume the staff in question is professional, that is, salaried, so that
overtime wages are not paid. Well, I can solve that company's overtime problem
in one month, guaranteed: start paying professional employees time-and-a-half
for overtime. As soon as the company has to start paying nearly double
salaries to people putting in 65-hour weeks, the problem will stop 8^)
Seriously, I think excessive overtime is an issue of exploitation, skimping on
staff, and, yes, poor estimating of work.

A previous poster touched upon the "whatever it takes" culture of some
companies. In my opinion, that culture is bad for two reason. First, it
assumes people's performance doesn't break down under the stress of heavy or
prolonged overtime; but we know that it really does. (I saw a study that says
after six weeks of 60-hour weeks, productivity sags to 40-hour levels.) Second
is the danger that, as the Doobie Brothers said, what were once vices are now
habits; when estimating work (and there's the other thread), it becomes
implicitly assumed that the staff will do "whatever it takes," forgetting that
they already are.

Corporate culture is fostered and encouraged by management.  I would be
pessimistic that a worker's committee asked to solve the overtime problem can
work.

To address the estimating thread, I think management expects (and needs) its
workforce to behave the way an auto mechanic does, as several other posters
point out: an estimate is not exceeded. The analogy hasn't been drawn
completely, though. Let's take a muffler-repair chain for clarity. You can
expect not to have to pay more than the estimate, because it's well grounded
in experience. However, if while the car is on the lift, you say, "I want you
to do the brakes, too," you have no right to expect the firm to honor the
previous estimate. What really happens to technical writers is that the scope
of the work changes constantly: new features appear without warning,
development is delayed, or some joker pops up and demands a new approach. Yet
we are pressured to meet our original dates!

Tom DeMarco has written extensively on software development, and his findings
apply to technical writers as well. He devotes many pages to estimation, and
blasts current practice as political. Management (yes, them again) tends to
press for the most optimistic possible dates, and strings them all together.
If you think of a time estimate as a measurement, with an upper bound, a lower
bound, and a most-likely point in the middle, then software development
schedules are very often pegged right at the lower bound. Naturally, the only
way to go from there is down; that is, the actual dates are always later that
the estimates.

Managers who push for unrealistic estimates, DeMarco writes, deserve what they
get. (And, of course, in the company that already does "whatever it takes,"
there's nobody left to take up the slack.) Believe it or not, I've seen
schedules busted when people started to take vacations in the middle of the
summer (how dare they!), because no one came in on Thanksgiving/Christmas/New
Year's Day (how could we have known?!), and because the software was not bug-
free from the first build on and had to be fixed (scandal!! it's Test's
fault).

To solve the first problem--overtime--requires a solution to the
second--estimating. If and when a company learns to estimate realistically
based on 40-hour weeks, then the problem of overtime goes away. My
publications group at Digital (sniffle) did a good job of laying out
contingencies in the documentation plan. There was a "risks and issues"
section that tried to predict what might go wrong and what we would do about
it. That tended to include the "fudge factor" several posters have recommended
without being furtive about it.

Another helpful hint is to make the estimate BEFORE committing to the date. I
was once asked to provide an estimate for creating a short document. I was
pleased to be asked; based on the previous version, I said I thought it would
only take a couple of weeks. There was an uncomfortable silence on the phone,
and the person said, "I only budgeted for one week of your time in our
proposal, and the customer has already accepted it. Besides, the training
class is scheduled for next week." Oh. Based on this new information, I
thought hard and estimated that It would be done by the end of the week 8^( I
can't say the book was very well done, but what the hell...

          -- Steve

=========|=========|=========|=========|=========|=========|=====
Steven Jong, Documentation Group Manager ("Typo?  What tpyo?")
Lightbridge, Inc., 67 South Bedford St., Burlington, MA 01803 USA
mailto:jong -at- lightbridge -dot- com -dot- nospam          781.359.4902 [voice]
Home Sweet Homepage: http://members.aol.com/SteveFJong