Concurrent writing and revision

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

Christina Hutchings writes:

>And, again unfortunately, this is the way it seems to work at most
>companies. No matter how hard Tech Pubs puts its foot down about
>revisions, schedules, etc., it seems that the squeaky wheel gets the
>oil. There is always someone with more clout than the last guy who
>demands that his/her project be given higher priority or special
>handling, and if Tech Pubs tries to enforce its rules, it is accused of
>"not being a team player."

Oh, you can beat the system.  It's so easy, it's almost criminal.  Publish
your schedule, update it often, and have a comment field that puts all the
dirty laundry right out in public:  "On hold: {list of SME's} not responding
to queries," "Slipped one week: we screwed up," "Slipped two weeks:
excessive revisions,"  "On hold: Priority lowered by {Big Boss} to make room
for {Pet Project}."

The important things are:

1. Act as if you really believe in your ability to schedule projects, and
that the only issue on the floor is where to fit a given project on the
Gantt chart.

2. Be merciless in assigning reasons for slippage, but be merciless to
yourself as well, and be lavish in your praise when things come together the
way they should.  This will be seen as fair.

3. People really hate to have their misbehavior pointed out in public, but
they will usually put up with it with reasonably good grace if the ground
rules were defined in advance and you gave them fair (that is, excessive)
warning.  Always warn people of impending slippage.

4. Be cheerful about all this (and everything, really).  You have a
department that can only work so fast.  Trying to push things reduces the
overall pace of work, causes quality to plummet, and hurts morale.  The
groups who think otherwise are fooling themselves.  They'd know this if they
analyzed the data, which is why they never analyze the data.  Point this out
to anyone who'll stand still, but be cheerful and upbeat.  The whole point
is to shove the consequences of stupid decisions back on the people who make
them.  If a manager wants to accelerate one project even though it will
crater quality and cost him double (two weeks' advance in this project, but
four weeks' slip in others), then maybe he really NEEDS it.  Confine the
damage to the decision-maker's own projects, and you will be seen as fair,
and will be appreciated for it.  Though few people will bother to tell you.

5. The scheduling game is fairly seductive in its own right.  Start waving
to-do lists and Gantt charts around when people come to ask for changes.
Get them involved in the trade-offs for at least a couple of minutes.  When
they break into a sweat and run away, you can be sure they'll step more
lightly next time.

6. Same as #1.  If you fall into the trap of admitting that you can't
schedule your way out of a paper bag, and one person's schedule is much the
same as another's, then you've given authority over your department to
anyone who wants to walk in and take it.  To some extent, a schedule is
always something you commit to first and figure out how to adhere to later,
but this needs to YOUR guesswork, not theirs.

        -- Robert
--
Robert Plamondon * High-Tech Technical Writing
36475 Norton Creek Road * Blodgett OR 97326
541-453-5841 * Fax: 541-453-4139
mailto:robert -at- plamondon -dot- com * http://www.pioneer.net/~robertp