Project Documentation: Procedures, Forms, Memos, and Such

Project Documentation: Procedures, Forms, Memos, and Such

Perry recognizes that documentation is essential for leading, defining, planning, organizing, controlling, and closing a project. He also realizes that too much documentation is as much a problem as too little. A balance must exist, depending largely on the size and importance of the project.

Good documentation serves as an excellent communication tool. It provides an audit trail for analysis and project reviews. It lends order and structure to the project by giving direction and setting parameters. It increases efficiency and effectiveness because everyone follows the same sheet of music. And it gives team members confidence, especially when things appear chaotic or there are too many unknowns.

Project documentation consists of the following items:

Procedures

Flowcharts

Forms

Reports

Memos

Project manual

Project library

Newsletters

History files

Procedures

For many projects, particularly large ones, procedures facilitate management. They help achieve efficiency by ensuring consistency of action. They improve effectiveness by ensuring that people achieve project goals. They reduce the learning curve by providing guidance on the way things are done. Finally, they improve productivity because people with questions can refer to the documentation rather than interrupt other people.

To develop a good set of procedures, you need the following:

Information to write about the topic

Time to prepare, review, and publish the documents

People with good research, writing, and editing skills

Management and user buy-in to ensure people follow the procedures

Feedback loop to ensure completeness, currency, and usability

Procedures are often less than adequate on projects, for several reasons. For one, the project manager may view writing procedures as something that must be done only to satisfy requirements. The results are poorly written and incomplete procedures. Or the project manager may assign the task to someone who knows little about the project or whose role is minimal. Sometimes the project manager prepares the procedures late in the project, mainly to satisfy reviewers and auditors. Finally, the procedures are prepared and then set on a shelf, never to be used by anyone.

Perry, of course, ensures good procedures by following four simple steps.

Identify the topics. Perry can either develop a set of topics on his own or solicit help from the team. He chooses the latter, as well as conducts research on previous projects to find similar procedures.
Some specific topics include:

Change control

Forms

Meetings

Organizational structure

Purchases

Reports

Resource usage

Responsibilities

Schedules

Statusing

Determine the format for the procedures. There are four possible procedure formats: narrative (Exhibit 13-1), sequential (Exhibit 13-2), playscript (Exhibit 13-3), and item-by-item (Exhibit 13-4). As Exhibit 13-1 demonstrates, the narrative format has an essaylike appearance. Although a narrative presentation is easy to read, information within it is often hard to find quickly. Also, it causes eyestrain, since the blocks of text minimize white space. And it is difficult to update or revise because it lacks modularity.

The sequential format, as shown in Exhibit 13-2, has a step-by-step appearance. Each sentence is a generally brief command. Its brevity, abundant white space, and simplicity make it easy to follow and find information. It is best used for procedures involving one person.

Exhibit 13-1. Narrative format

Exhibit 13-2. Sequential format

Exhibit 13-3. Playscript format

As with the sequential format, the playscript format (Exhibit 13-3) has a step-by-step appearance and possesses the same structure. Similarly, its brief style, abundant white space, and simplicity make it easy to follow and to find information. It is best used for procedures involving two or more people.

The item-by-item format, shown in Exhibit 13-4, has all the characteristics and advantages of the sequential and playscript formats. It works best, however, when a procedure covers a mixture of topics.

Prepare, review, revise, and publish the procedure. This step should involve as much participation as possible by members of the team, so as to seek buy-in from those who must follow the procedures. Here is an outline of a typical procedure:

I. Purpose

II. Scope

III. Contents

IV. Approvals

V. Appendices

Exhibit 13-4. Item-by-item format

Follow the procedures. At first the comment might sound academic; however, many projects have written procedures, let alone plans, that no one follows. In the end, the procedures serve no function other than to occupy a bare spot on a shelf.

Flowcharts

Many times, pictures and diagrams are preferred over text or are treated as supplements to text. Flowcharts indeed are worth a thousand words.

Flowcharts are easier to understand than written procedures and communicate more with less. However, even using flowcharts requires effort. It takes time to prepare them. They must be updated to maintain relevancy. And users and management must buy in to them if the project manager expects people to follow them.

When developing flowcharts, keep the following points in mind.

Use symbols consistently. Provide a key to the symbols.

Put the flowcharts under version control. Different versions can quickly be released, thereby confusing people.

Use a software toot to generate the diagrams. Revisions will be easier and the charts clearer.

Keep it simple. Avoid putting too much on a page. A cluttered page can be as mentally taxing as large blocks of small text on a page.

There are a number of flowcharting techniques. Some charts show the flow of control (e.g., do step 1, then step 2, and, if positive, do step 3). Others show the flow of data (e.g., the use of early and late dates and durations to calculate float). Exhibits 13-5 and 13-6 have flowcharts showing flow of control and data flow, respectively.

When flowcharting, follow these four steps:

Determine the topic, just as you would with written procedures.

Determine the type of diagram and whether it is a substitute or a complement to a procedure. Flow of control is the most popular, followed by data flow diagrams.

Prepare, review, revise, and publish the flowchart. This step is the same for procedures.

Follow the flowchart. Like procedures, they can quickly end up covering a bare spot on a bookshelf.

Forms

Although many people dislike completing forms, Perry sees their value in managing his project. Forms capture and communicate information. They also provide audit trails to help learn from past experience, compile statistics, and conduct postimplementation reviews.

Unfortunately, many forms are not user-friendly. The instructions for completion and distribution are unclear. The fields do not flow logically. They ask for way too much information. And there are usually too many forms of too many varieties.

Ideally, forms should have these qualities:

Be logically organized

Be readily available

Not exceed one page

List a source and destination

Have clear and concise instructions for completion and submission

Have adequate space for filling in information

Request only the necessary information

For use in project management, forms can capture information on such topics as activity descriptions, Activity estimating, assignments, change management, estimated labor usage, labor and nonlabor costs, problem identification and tracking, and status of activities.

Exhibit 13-5. Flow of control.

Exhibit 13-6. Data flow.

Here are some guidelines on how to prepare a usable form:

Determine its purpose (e.g., capturing schedule or cost data).

Determine who will complete the form and who will process it.

Identify the exact data to capture.

Determine its source and destination.

Prepare the instructions for its completion.

Prepare a draft of the form (e.g., using a graphics or spreadsheet program).

Circulate the form for evaluation (e.g., to people who can complete it and to others who will use data that it captures).

Make revisions, if necessary.

Determine the number of copies and how the copies will be made.

Reproduce the form.

Distribute it either electronically or in hard copy.

Exhibit 13-7 is an example of a well-defined form.

Perry performs four steps to draw up forms for his project.

Determine the topics requiring forms. These are topics for which he will need information throughout the project.

Design the forms. As with procedures and flowcharts, Perry will obtain input from the major participants. This action increases peoples buy-in and their willingness to use the forms. When designing the forms, he also chooses an open layout that is easy to use.

Distribute a first draft of the forms. Perry gives everyone involved a chance to revise the forms and sharpen their design.

Perry prepares the forms in their final form, for either electronic use or as printed hard copies. Each form includes instructions on submitting the completed form and also handling changes to the form at a later date.

Reports

The right amount of feedback can make the difference between the success and failure of a project. Reports are vehicles for giving reliable feedback.

Reports communicate information. They help project managers monitor and track individual and overall performance, indicating when to take corrective action. And they give feedback to everyone involved about their contributions to the project.

Exhibit 13-7. Overall performance evaluation

Monthly Status Report Form

For reports to offer these advantages, however, they must have certain characteristics. They must:

Be easily understood

Be produced and available in a timely manner

Have timely, meaningful information

Not be too numerous

To use reports on his project, Perry performs the following seven steps:

He identifies the topics. Will he need reports on the schedule? Costs? Quality? Typical reports are activity relationship reports, bar charts, cost reports, histograms, network diagrams, problem reports, project status reports, and resource usage reports.

For each report, Perry determines information requirements and the means to collect it. He reviews the statement of work for reporting requirements, determines the readership for each report, and interviews recipients to determine their informational needs.

He lays out the report, keeping in mind clarity, logic, and relevancy. He remembers to keep the report simple and focuses on obtaining the information thats needed.

He determines the frequency of generation. Weekly? Biweekly? Monthly? Ad hoc?

He distributes the reports. Often, he will generate these reports via a software package on a personal computer to give him the ability to experiment with communications modes.

He obtains feedback. Sometimes the reports will not contain enough information; other times, they might have too much and be distracting. Because generating reports takes time and effort, he wants to minimize frustration by keeping the reports helpful and concise.

He stores a copy of each report, in case he needs an audit trail or to develop lessons learned in the project.

Memos

Many people hate to write memos. Thats unfortunate, because a well-written memo can have tremendous impact on coworkers.

A memo provides a record of results. It encourages commitment to an idea or cause. It offers traceability. It raises issues and helps resolve them. Above all, memos are excellent tools for communicating with other people.

To fulfill these purposes, however, memos must be clear, concise, direct, legible, and organized. Exhibit 13-8 is an example of a well-written memo.

Perry will always prepare a memo to clarify a policy or subject, document the results of a meeting, raise an issue and get it resolved, record an accident, or schedule events. Thus, a memo should contain a date, addressee, subject, message statement, giving the who, what, when, where, and why of a subject, information on a response if desired, and signature. Memos can be prepared and sent electronically or via hard copy.

Newsletters

Not every project is big enough to warrant its own newsletter. For large projects, however, a newsletter can be invaluable.

A newsletter can enhance communications, informing everyone of important happenings and giving new information. It provides the project manager with the opportunity to get the word out, especially about matters that directly affect project performance. It also serves as a record of significant activities and accomplishments. Finally, it answers questions and dispels rumors before they arise.

Exhibit 13-8. Example of a well-written memo

There are, however, several issues related to publishing a newsletter. For example, the newsletter can become a political rather than a communications tool, serving merely to pacify political sensitivities. It is time-consuming and labor intensive to develop. Writing, proofreading, printing, and distributing a newsletter, whether in hard copy or electronic form, is no easy task. It requires, too, people who can write and edit, talents that are not too common apparently.

A newsletter can cover many topics, including team successes, challenges, biographies of participants, and new techniques developed. The key to keeping a newsletter active is to encourage team members, and the internal customer, to submit articles for the publication. That encourages people to read it and feel it is not a propaganda rag.

History files

During the fog of managing a project, important documentation can be lost or misplaced. To ensure that does not happen, Perry sets up project history files.

These files can be a drawer in a filing cabinet or a directory on a personal computer or file server. In any form, they provide the ability to reconstruct situations for an audit trail, review problems, and satisfy audit requirements. They help reduce the learning curve of new team members, as they review titles to become familiar with critical issues and they provide background information for further work.

Project history files frequently contain: bar charts of schedules, drafts of documents, work estimates, completed forms, memorandums, minutes of meetings, network diagrams, procedures, reports, responsibility matrices, statements of work, and work breakdown structures.

Perry must keep the files up to date, from the start to the end of the project. Thats why he establishes them as early as posible. He also establishes a procedure for removing and tracking files to avoid losing or misplacing documentation. For example, he might provide a check-in/checkout sheet that people sign when removing and returning a file. He designates an area where everyone can access the files. (Often, by accident, project managers lock the files in their drawers or do not store them on the file server, thereby making accessibility difficult.) Finally, he assigns someone to maintain the files.

Perry performs four basic steps to set up project history files:

He identifies their contents, e.g., as being only recent sets of schedules, or all previous versions.

He determines their organization, e.g., by topic or date.

He controls their removal, e.g., by means of a check-in/check-out sheet.

He makes their location obvious and provides the information needed to access them, e.g., by writing an announcement and distributing it via newsletter or e-mail.

Project Manual

It is often handy to have certain information readily available, such as phone numbers and task listings. Perry knows that a project manual can be that reference. It is an essential reference book for project management. The project manual, however, does more than provide its readers with useful information. It is also a communication tool, enabling people to interact efficiently and effectively.

Exhibit 13-9 is the table of contents for the Smythe Project manual. Of course, there is no restriction on content other than being useful, relevant, and readable.

Ideally, the manual should be prepared early on and be maintained throughout the project cycle. Everyone should have ready access to it, either in hard copy or electronic form.

To compile the project manual, Perry performs these six steps.

He determines the contents, e.g., by interviewing team members or reviewing the statement of work.

He organizes the contents, e.g., arranging them by topic or phase.

He determines the number of copies, e.g., by using the size of the team as the basis.

He assigns responsibility for maintaining the manual, e.g., to someone working on a noncritical task.

He publishes and distributes the manuals, e.g., electronically or as hard copy.

He seeks feedback from the users of the manual, e.g., by providing tear sheets on which they can submit suggestions.

The Project Library

The project library, like the history files, stores information. The major difference is that the library contains more than project management information. The project library also stores company and project-specific policies and procedures, history files, newsletters, journal publications, and related books, and technical documentation.

As he did to set up the history files, Perry follows these steps to set up the library:

He identifies the contents, e.g., by interviewing team members for their suggestions.

He determines the organization, e.g., arranging documents by title, code, or author.

He controls the removal of documents, e.g., by providing a check-in/check-out sheet.

He determines the location of the library, e.g., providing a readily accessible site; he also determines the procedures for accessing material.

Determining the Paper Trails Length

Too much or too little documentation can negatively affect a project. Perry recognizes that the key is to have the right amount of documentation to satisfy the right needs. He knows that the content of documents should be current, clear, concise, and organized to be useful to team members. He ensures, too, that the documentation is accessible to everyone, such as through a project manual or library.

Exhibit 13-9. Table of contents for the Smythe Project manual

Questions for Getting Started

If developing procedures, did you:

Identify the topics?

Determine the types of procedures needed?

Receive reviews by all relevant people?

Distribute the procedures?

Document the procedures?

Place the procedures under configuration control?

Seek feedback?

If developing flowcharts, did you:

Identify the topics?

Determine the types of diagrams to use?

Issue standard templates?

Determine whether the flowchart will supplement or replace a procedure?

Distribute the flowchart?

Seek feedback?

If developing forms, did you:

Determine what forms you need?

Design each form according to the characteristics described in this chapter?

Determine how people can obtain a copy of the form?

Determine how and where people can submit a completed form?

Institute a way for people to provide feedback on the forms?

If developing reports, did you:

Determine the necessary types of reports to use?

Design each report according to the characteristics described in this chapter?

Inform everyone who need to receive the reports?

Develop a distribution list?

Determine the frequency of generation for each report?

Determine where to store the reports?

Seek feedback from users?

If you need to prepare a memo, did you:

include a date, subject title, address, signature block, and purpose statement?

Answer the who, what, when, where, and why questions?

Check for clarity, conciseness, directives, legibility, and structure?

If you decide to publish a newsletter, did you determine: Who will prepare the newsletter?

The frequency of the publication?

Who must review it prior to each publication?

The topics?

The layout?

The method of distribution?

If you decide to have a project manual, did you:

Determine the method for keeping the manual -- that is, hard copy, electronic copy, Web site?

Determine the contents?

Develop a structure, reflected in the form of a table of contents?

Determine the number of copies?

Select the mode of binding?

Assign responsibilities for keeping the manual current?

Set up a format for reviewing the contents?

Seek feedback?

If you elected to set up project history files, did you:

Determine the contents?

Determine the organizational structure?

Assign responsibility for maintaining them?

Establish a procedure for accessing, removing and replacing them?

Communicate their location and procedure for accessing, removing, and returning them?

If you decide to set up a project library, did you:

Determine the contents?

Determine the filing system?

Assign responsibility for maintaining it?

Establish a procedure for accessing, removing, and replacing material?

Communicate the location and procedure for accessing, removing, and returning material?