Project Management
Planning Successful Projects
Part II
By Mike Corrigan and Steven Greffenuis
Editor's Note: Part I of this article appeared in the January/February 2003 issue of the Boston Broadside.
Here's a good question: Why can't I just jot some notes on my pad and use that as my project plan? Personal notes do serve as an excellent planning tool when you work by yourself. When you work as part of a team, though, the project plan must be more formal, a document that everyone can understand and use.
Let's take a simple example. Suppose your target date for completion of the project is June 1, and you must begin your draft no later than April 1 to meet the June 1 target. That means much of your planning and research occurs during March. Here is how your schedule for the project might look:
| Task |
Date |
Person Responsible |
| Submit outline for review and approval. |
March 15 |
Lead writer |
| Complete review of the outline. |
March 20 |
Project manager |
| Submit initial version. |
April 20 |
Lead writer |
| Complete review of the initial version. |
April 25 |
Project manager |
| Incorporate customer's comments. Submit final version. |
May 15 |
Lead writer |
| Complete review of the final version. |
May 20 |
Project manager |
| Incorporate customer's comments. Submit proof copy. |
May 25 |
Lead writer |
| Correct the proof copy and approve for publication. |
May 30 |
Project manager |
| Send the corrected copy to the printer. |
June 1 |
Lead writer |
As the schedule's layout suggests, a plan of this type induces cooperation between the technical publications team and the engineers responsible for development of the product. Members of each group receive regular communication from their collaborators. Moreover, both writers and engineers must respond to what they receive. As a result, both groups share responsibility for advancing the project toward completion, and both groups know what the other team members are thinking as the document takes shape.
If the schedule changes—and schedules change pretty often—at least
everyone knows why. If no published schedule exists to begin with, no one knows
what the target dates are, let alone why various deadlines keep receding into
the future. When research, writing, and publication take too long, the project
manager wants to know why. Careful planning and conscientious collaboration
can't prevent all delays, but at least everyone on the team knows where the
document is in its development, what has to happen next, and when the next task
will be complete.
Mike Corrigan is an embedded systems engineer, and president of MHC Enterprises in Wilmington, MA.
Steven Greffenius is CEO of TechWrite Publishing, a technical publishing company in Westwood, MA.
|
