Document Project Management

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.  

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:

• Who is the real audience?
• What is the real purpose of the job?
• What are the real needs?
• Manuals: what are all the tasks anybody associated with this product will perform?
• Brochure: what are the customer's needs?
• What are the implications on the product?

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:

• Specifies what information is needed and why.
• Specifies where it will be located in the document and often, why.
• Specifies the overall structure of the document.
• Provides a draft Table of Contents.
• Specifies the Useability Test(s) to know if the document will work as intended.
• Provides guidance for Reviewers — they can see what you intend to  achieve.

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.

Requirements, preliminary design or solution activities

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.

Benefits of applying the right process and procedures

You will receive the following measurable benefits from applying the proper practices to your documentation projects:

• At least double the average original-page writing productivity of your current documentation projects
• Fewer people needed for documentation tasks
• Fewer work hours per person to deliver higher quality material
• More time for technical people to focus on the solution (for proposals, the cost models)
• Better estimates of the size and scope of documentation tasks
• Less time wasted on re-writing content
• Improved productivity and control when working with distributed documentation teams.

Lasotell project management and product development skills

• Project Startup, Initiating a Project, Controlling a Project Stage, Managing Product Delivery, Managing Stage Boundaries, Closing a Project, Planning, Directing a Project
• Business Case preparation, Organisation, Plans, Project Controls, Risk Management, Quality Management, Configuration Management, Change Control
• Product Based Planning, Quality Reviews, Issue Management
• Scheduling
• Managing resources (and the necessary diplomacy)
• Ensuring cost effective work methods
• Specification writing and editing - any place, any time, any subject
• Prototyping
• Staff Management and motivation
• Maintenance Planning - designing and producing low maintenance documents
• Maintenance watchdog - highlighting potential product maintenance traps
• Style guide(s).