Manuals Often Get Shorted

It's a scenario I've seen over and over again with technical writing projects.  Early in the life of the project a schedule is drawn up.  Milestones are established for the outline, rough draft, and final delivery of the technical manual.  Everybody is happy.

Then, life happens.  Something causes a delay in the design process.  One of the components doesn't pass the acceptance test and has to go back to the vendor for rework.  The assembly of the unit uncovers an unforseen clearance problem and part of the unit has to be redesigned.  The customer revises the requirements and the changes cause delays.   It is just the nature of the beast.  Many times, these issues impact the technical manual, because source data changes result in corresponding changes to the manual.

So the project gets delayed, but the client wants to still meet that final delivery milestone (and rightfully so). The end result is that the window of time available for the technical writer to create his document gets compressed.  Nobody wants that last milestone to move if it is at all possible.

This used to frustrate me, but now I have come to expect it.  This scenario is more the rule than the exception.  Consequently, when I'm bidding a project I always include some contingency for overtime in the later stages of the project.  That's one of the ways Allard can bid projects on a firm, fixed-price basis.  Years of experience have taught us a lot about the "schedule compression syndrome".

So, if you're a project manager, please do everyone a favor and get the technical writing team involved as early in the process as you can.  The more work that can be done on the front end, the less damaging these delays will be.