This is the base of professional technical communication.
There are two parts to every project: project management and product development. Project management is about what to do and product development is about how to do it. PRINCE2 is an example of project management methodology and Agile is an example of product development methodology.
If you understand project management, you know it is common sense planning applied consistently to a recognised standard. The difference between different flavours of project management is usually apparent in their consistency and rigour.
In the documentation world, Technical Writers can be project managers and they can be document (product) developers. Sometimes the documentation is the whole project. At other times the documentation is one of many products coming out of a project. In 1994 Dr. JoAnn Hackos published a common sense methodology for managing documentation projects. The methodology is summarised in Figure 1.
(Based on the work of Dr. JoAnn Hackos, including Managing Your Documentation Projects ISBN: 0-471-59099-1 and Information Development ISBN-13: 978-0-471-77711-3.)
This process is scalable. You can apply it to a presentation due in a few hours. To a project involving 50 engineers with five or six technical writers over several months. To the stream of documentation that is produced in a 1,000 work-year Defence project. The percentage allocation of the time does not change. (We will discuss every aspect of that graph in more detail in future articles.)
The project management side of Figure 1 is managing the timetable and the resources for each activity. The product development side is under the Implementation heading.
(In PRINCE2 terminology, depending on the product, the Information Plan content goes into the Project Brief and Project Approach documents. The Content Specification's content goes into the Project Initiation Document, Stage Plan and the Work packages.
The Information Plan focuses on your document's audience. It answers questions such as:
If you are the customer (the person paying for this documentation work), you approve this Plan before work starts on the Content Specification.
The Content Specification states what the document will contain. (A mere Table of Contents, in isolation, is probably the least useful planning tool.) The Content Specification:
If you are the customer (the person paying for this documentation) you approve this Plan before work starts on the Detailed Design and Writing stages.
A version of the Project Plan is usually delivered with each document. The Project Plan should be accompanied by a Degree of Difficulty calculation to show the impact of the complexity of the job relative to historical metrics for that type of work.
The Delivery phase in Figure 1 includes a Wrap-up Report that honestly appraises progress against the plan. It compares planned hours against actual hours worked. It also includes another Degree of Difficulty calculation to assess the actual impact of the complexity. It also examines the estimates and especially any significant difference from actuals.
In parallel with writing the Information Plan and Content Specification, you may need to gather business requirements, create the first draft of a preliminary design or a first draft of a solution to provide the substance for each document. This is common when responding to tenders.
The tools for this type of data gathering include Issue Trees, storyboards and the PRINCE2 Product Breakdown Structure and the Product Flow Diagram (which makes creating the first project plan easy).
This data gathering activity concludes with a Solution Walk-through or Preliminary Design Review with all interested parties.
You will receive the following measurable benefits from applying the proper practices to your documentation projects: