Musing on Metrics column
Joining the Wagon Train

You say the project schedule is impossible, but no one listens to your objections? The engineers won't return your phone calls, let alone your drafts? And everyone ignores your milestones? I've heard it all before.

If you've been reading my column, you know the importance I attach to a solid process for creating documentation. But a process can't exist in a vacuum; you need to be aboard the product development cycle wagon train. And the leader of that train is the project manager. If they're around, you should be seeking them out. Most development organizations have project managers; all of them should.

Project managers are accountable for the successful completion of a project. The project manager defines the necessary resources, coordinates their schedules, verifies that subtasks are progressing together, and resolves any problems that arise. Sometimes, especially when they're hectoring you for overdue drafts, it can feel like you work for them. But you can turn the tables, and have them work for you. You can have the project manager become your best friend and ally in the company. How? You need to have your milestones incorporated into the overall milestones at the start of the project.

If you (or your doc team) manage your projects on your own, subsuming your documentation plan into the overall project schedule is a nontraditional approach. I've been part of self-reliant documentation teams, and I've always done my own planning. But I've come to see the importance of getting with the program. The trick is to get up-front agreement on dates, so that the project manager is driving everyone else to meet your dates, not the other way around.

To play the game, you need to use the terminology. Getting review comments is a dependency; not getting them is a blocking problem. Getting signoff approval is on “the critical path.” Project managers know that what is not measured is not done, so they measure progress. Like it or not, your progress is measured in pages or topics drafted as a portion of the estimated whole, so you’d better start thinking in those terms. At the same time, you can educate your project manager on your process: writing is not typing; of course every document needs to be reviewed; and, by the way, they need approval, too! You will need engineers to budget one day per 100 pages or so (your mileage may vary) for review at a given point in the cycle.

This approach offers many advantages. First and foremost, review will no longer be a chore the engineers can blow off; it becomes a milestone they have to achieve. Your deadlines become their deadlines. Second, it provides you with visibility. You become a part of the team; you're seen to be busy and productive. Third, your problems become the project's problems--and the project manager's responsibility to solve. If you're not getting review comments, it's no longer your fault; it's the fault of the reviewers. Imagine not having to bribe people with chocolate like trained monkeys just to get a question answered! Imagine having someone whose job it is to chase down reclusive engineers! That's what the project manager can do for you.

Working as part of the team does have its risks. Your schedule has to mesh with the project schedule. If you work with the project manager up front, you at least have a chance to adjust the overall schedule to fit your needs, but more likely you'll have to adjust yours. The pressure will be on you to estimate your work accurately, report your progress meaningfully, and deliver your documents on time--you can't pause at 90% of completion while you polish your prose!

Unfortunately, if your organization doesn't have project managers, you're stuck. You'll need to manage your own projects; good luck.

As JoAnn Hackos points out, it's impossible to be much more organized than the organization around you. But at least it's a valuable skill to acquire for when your organization matures, or you move on to a better situation.

Next time