News & Views Project Management:
A Recipe for Taking Control

News & Views Feature Article


by Lauren Hansen, Technical Writer
DuPont Corporation
(Wilmington, Delaware)

Originally published in News & Views January, 1996 issue.

Copyright 1996 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.


Our roles as technical communicators are often dictated to us by other people. Clients come to us after their product has already been developed, saying, "I need a manual," or "I've written the necessary procedures--just make them look nice." It's easy to fall into the trap of just doing what we're told when we're told to do it. When this happens, we let our projects control us. We must take charge of communication projects and manage them to meet the needs of the customer, the overall project schedule, and the budget. Project management enables us to control our projects, rather than letting them control us.

Many aspects of the project management techniques I'll describe are based on the methodologies discussed in JoAnn Hackos' book, Managing Your Documentation Projects (John Wiley & Sons, Inc., 1994). This book is an excellent resource for anyone who oversees development of information products.

The information product development cycle

"Information product" is a catch-all term to describe what we business and technical communicators develop--materials designed to help someone perform tasks or understand concepts. An information product can be in any medium. Examples include paper manuals and data sheets, online help systems, training videos, and World-Wide Web pages.

We can become better project managers by understanding the information product development cycle and following some basic guidelines for completing the work called for in each phase of that cycle. Planning, development, production, and evaluation are the four basic phases in the cycle, as shown in Figure 1. The project manager plays an important role in each phase.

Figure 1: Information Product Development Cycle

Phase 1: Planning

Planning is the foundation of any successful project and makes up about 30% of the total project time. The project manager plays a key role in this phase by developing two planning documents--the Information Plan (IP) and Content Plan (CP).
Tip: Don't skimp on planning. You don't have time not to plan.

Creating an Information Plan (IP) to get started

The IP is a document the project manager develops and uses to scope out a project. You first perform a needs analysis of the entire information development project, document the findings in the IP, and use that information to create a preliminary schedule and budget.

The IP should contain the following information:

  • Product description

  • Audience profile

  • Project's purpose

  • Information products' purpose

  • Task description. List the high-level tasks, decisions, or results that users of the information product need to perform or know.

  • User/task matrix. In matrix form, use a scale of High, Medium, and Low to indicate the likelihood that each audience will perform each task identified. Figure 2 shows an example of a user/task matrix.

    Figure 2: User/Task Matrix
    TrainersTechniciansService ManagersSales Reps
    Troubleshoot device
    H
    H
    M
    L
    Perform preventive
    maintenance
    M
    H
    M
    L
    Describe device's features
    M
    L
    L
    H

  • Usability goals for the information product. Describe how you'll ensure that the audiences use the information product correctly.

  • Design implications and media selection. Describe how the user/task analyses will affect the information product design and what media you'll use to deliver the information products.
    Tip: Not all jobs call for a top-quality product. That's not an excuse for doing shoddy work. Allocate resources according to the quality requirements for a particular project.

  • Development strategies and concerns. Describe your approach to this project.

  • Constraints and dependencies. Describe anticipated constraints, such as product stability, information availability, cooperation of subject matter experts, and audience familiarity. Rate each constraint on a scale of 1 to 5, where 1 is best case and 5 is worst case. Use those ratings to assign the appropriate dependency to each constraint as shown in Figure 3. You'll use these dependencies later when developing a project estimate.

Figure 3: Dependencies
Constraint
Rating
Corresponding
Dependency
1
0.90
2
0.95
3
1.00
4
1.05
5
1.10
  • Roles and responsibilities
    Tip: Involve all members of your project team as early as possible. Tell them what the project is about, what you'll need them to do, and when you'll need them to do it.

  • Project schedule. Create a project schedule that lists each information development task, who will do it, and when they'll do it. Using the schedule helps alert you right away when a project starts to get off track.

    Tips for developing and maintaining a project schedule:
    Create and maintain one schedule that covers all information products in a project.
    Start with the project deadline and work backward. That lets you see when each task must be done to meet the final deadline. Try to keep some slack time in your schedule. Tasks often take longer than you think. Allow time for usability testing to ensure that the information product meets the audiences' needs.
    Post your project schedule where you can see it.
    Revise your schedule whenever the overall project timeline changes.
    Create an abridged "milestone" version of your schedule to share with your clients.

  • Project estimate. An estimate is a probability, not a pledge or prediction. Your project estimate should list the number of pages and total cost. Although this estimating methodology refers to "pages," which implies a paper document, you should use the estimating unit that is appropriate for your project. Figure 4 shows examples of estimating units for different information product types.

Figure 4: Estimating Units
Information Product TypeEstimating Unit
Paper documentPage
Online documentTopic or screen
Classroom or computer-based trainingHour of training
VideoMinute of video

Estimating the project

The fastest way to estimate the number of pages is to compare this project to a similar project, taking into account the unique aspects of the current one. For example, say you worked on a similar project last year that was 150 pages. Your current project has a slightly broader scope, so you might estimate it at 175 pages. If you don't have a basis for comparison, think about your audience and the purpose of the information development project to come up with a rough estimate of the page count. You'll refine this estimate when you specify the content.

To estimate the total cost, start with the dependencies you calculated earlier. Multiply all dependencies by each other to get one composite score. For example, if your dependencies were 1.10, 1.10, 0.95, 1.00, 1.10, and 0.95, you'd calculate the composite score as follows: 1.10 x 1.10 x 0.95 x 1.00 x 1.10 x 0.95 = 1.20.

Multiply the composite score by the average number of hours needed to produce a page. If you don't have the average hours per page for your situation, 5.00 hours per page is a good average to start with. Continuing with the previous example: 1.20 x 5.00 hours per page = 6.00 hours per page.

To estimate the total project hours, multiply the number of pages by the project hours per page: 175 pages x 6.00 hours per page = 1050 hours. Multiply the total project hours by your billing rate and you have your cost estimate.

After you've finished the IP, you're ready to move on to the Content Plan. (For more information about this estimating method, see the review of PUB$ Estimator on page 12.)

Creating a content plan (CP)

A CP specifies the detailed design of the content of one information product. Each information product in a project requires its own CP. A CP should contain the following information:

  • Detailed product description

  • Specific audience profile

  • Information product overview and objectives. Explain how this information product relates to others covered by the IP and what unique needs this information product meets.

  • Usability goals and testing

  • Information product organization. Describe how you plan to organize the information product and why you've chosen to do it that way.

  • Simple outline. Include first- and second-level headings.

  • Extended outline. Create a detailed outline of the entire information product that also specifies the objective of each section.

  • Estimated page and graphics counts for each section
  • Revised schedule
  • Estimate. Refine your IP estimate based on new information about the project to develop an estimate specific to this particular information product.

Phase 2: Development

Information product development is the longest phase of the cycle, taking at least 50% of the total project time. I don't use a specific methodology for overseeing this phase. Focus on "common sense" tasks to move the project along and stay aware of what's happening, such as:

  • Monitoring the project. Monitor development activities such as designing, writing, and editing; monitor project changes; and track time spent on the project.

  • Controlling the project. Coordinate draft reviews, coordinate usability testing, estimate the effect of project changes, and revise the schedule and budget if necessary.
    Tip: Remind your client that scope changes cost money. If someone comes to you with a "great idea" late in the project, tell them, "That's a good idea. I'll let you know how much it'll cost to do that."
    Tip: If you have only limited control over what happens in a project, manage what you can and let go of the rest. There's no point in struggling to manage something that's beyond your control.

  • Leading draft reviews and approvals

  • Communicating project status. Provide regular reports to your clients, your project team, and anyone else who needs to know how the project is going.
    Tip: Maintain contact with all project team members.

The project moves to the production phase after the final draft has been approved.

Phase 3: Production

This phase includes all the remaining activities necessary to produce the information product in its final form. Production can be very short or can include almost 20% of the total project time, depending on the project and the product medium. Your role in this phase is to carefully track each aspect of production.

Production activities may be beyond your control. You must therefore be familiar with each of these activities and be able to plan accordingly. By knowing what should happen and what actually is happening, you can deal with problems before they become showstoppers.

Phase 4: Evaluation

Project evaluation is a small but important part of the information product development cycle. This phase typically takes about 1% of the total project time. The project manager's role in this phase is to evaluate both the information product development process and the information product itself.

One of the most effective ways to get feedback is to hold a post-mortem meeting to answer questions such as:

  • What worked well?
  • What could we have done better? What would you do differently next time?
  • Are you satisfied with the information product? Why or why not?
Some projects call for a more rigorous evaluation, especially if the information product will be revised soon.

The tangible result of the process evaluation is a closing report I give to my supervisor and information development team members. It contains the following information:

  • Brief statement of the project's purpose
  • Estimated and actual project duration
  • Estimated and actual scope
  • Project statistics, such as cost, hours spent, final page count, and hours per page. Include a comparison to the estimated statistics that you specified earlier.
  • Things that went especially well or were otherwise helpful
  • Things to do differently next time
  • Any other insights or key lessons learned
Don't be discouraged if the "actual" numbers are very different from the original estimates. Use the data to understand what to consider when estimating the next project.

Tip: Treat all projects as learning experiences. If something goes wrong, don't take it personally. Learn from your mistakes.

Take heart! And take control

Project management is an acquired skill that improves with practice. It enables you to complete projects efficiently, on time, and within budget. You can then control your projects rather than letting them control you.


Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Last updated: November 8, 1996 (rst)