A few years after graduating from college, I landed a job as an RF
design engineer at Comsat, in Clarksburg, MD. The work involved both circuit and system
level design for satellite Earth station equipment. That was about 20 years ago, and
we were building quadrature mod/demod circuit out of mixers, power dividers/combiners,
and phase shifters, using a potentiometer to tweak out the unintended sideband and null
the carrier. Nowadays, of course, all that circuitry is in a single surface mount RFIC.
There was a very experienced engineer there (an independent contractor, actually)
that I had the good fortune to work with who despised making project schedules. Managers
put up with his reluctance to do so because his design skills were so exceptional.
If you asked why he wouldn't make schedules, he would say it was because although
he could keep his own part of the project on time, the dependencies on other people
always made his part late. That actually was the case, and I soon learned the same thing
for my own parts of the project. Software development would hold up testing, the PCB
layout guys would be backed up and not able to get things done in time for having boards
fabbed and populated, etc.
Being a crafty guy, said engineer finally came up
with a clever solution. Since Microsoft Project was either very new or maybe non-existent
at the time, we made up our schedules in a spreadsheet (DOS version of Lotus 123) to
feed to project managers for integration into a top level schedule. Paul's (his real
name) solution was simple. He referenced the end dates of all his tasks to a single
cell that he could change as needed to re-adjust the schedule as needed if things began
to lag - just have the spreadsheet add that number of days to all the end dates and
voilà, the entire schedule could be updated and printed just before the morning's meeting.
I don't ever recall any PM calling him on it.