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:
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.
Key Insights for Preparing Procedures
Developing procedures is more than just writing words on paper. Regardless of your writing ability, consider the following when developing procedures.
Define acronyms the first time they appear and spell out abbreviations at first use. The reader may not know what you mean.
Define special terms. The reader needs to understand what you are saying.
Avoid clichés. They are a tired way of expressing what you mean. Be original -- but always clear in your meaning.
Check for typographical and spelling errors. They distract from the message and show sloppiness.
Use positive expressions. Avoid “do not” or “cannot” because such phrases create a mental block in the reader’s mind. Be positive.
Use the active rather than the passive voice. The active voice is strong language; the passive voice is weak and reveals a tentative writer.
Watch your organization. Ideas should flow logically, such as from the general to the specific, or vice versa. Chronological order is also good.
Avoid wordiness. Keep sentences short (less than 15 words) and paragraphs brief (usually less than 5 sentences). Ideas are easier to grasp this way.
Integrate text and graphics. If using both, ensure that the text references the graphics and that the two match information.
Track your revisions. Assign a version number to each and note the date, so everyone uses the most recent version.
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:
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
Completing and Submitting the Monthly Status Report Form
Original total cost estimate:
Estimated cost to date:
Actual cost to date:
Overall performance evaluation:
This procedure describes how to complete and submit the Monthly Status Report (MSR) form, which is shown above.
The MSR must be completed to track and monitor the performance of your project. It is therefore important to complete all fields and submit the form on time.
In the project field, write the name of the project. Be sure to add the project number if one has been assigned. In the date field, write the date you are completing the form, using the month/day/year format (e.g., 11/26/00). In the start (baseline) field, write the original start date using the same format as the one for the date field. Do the same for the finish (baseline) field. In the management estimate at completion (MEAC) date field, record the actual progress to date plus the remaining estimate of the work to be completed. In the variance field, write the difference in days between the MEAC and the original finish date. In the total cost estimate field, write the original estimated cost for the project. . . .1
After completing the MSR, make three copies. Keep one copy for your records. Submit one copy to your next higher level of management or to the chairman of your steering committee, if applicable. Then attach the remaining copy to the original and submit both to the Project Review Office (PRO) at mail stop 78H1.
One final note. The PRO must have possession of the MSR no later than the final working day of a month.
Authors’ note: This example of the narrative format would actually have been one paragraph longer; however, we deleted the instructions for the last five fields to spare our readers.
Exhibit 13-2. Sequential format
Monthly Status Report Form
Instructions: Complete each field according to the procedure Completing the Monthly Status Report Form, below. Make a copy for your records and forward the original to the Program Office, mailstop 3X-41.
Start Baseline: C
Finish Baseline: D
Management Estimate at Completion Date: E
Original Total Cost Estimate: G
Estimated Cost to Date: H
Actual Cost to Date: I
Management Estimate at Completion: J
Overall Performance Evaluation: L
Completing the Monthly Status Report Form
This procedure describes how to complete the Monthly Status Report form.
Obtain a copy of the form from the project office.
Answer each field on the form by matching the applicable letter below with the corresponding one shown in the figure on the next page.
A. Name of the project
B. Date you completed the form
C. The original start date in month/day/year format
D. The original finish date in month/day/year format
E. The date reflecting actual progress-to-date plus the remaining estimate of the work to be completed in month/day/year format
F. The difference in days between the management estimate at completion and the original finish date
G. The original estimated cost for the project
H. The original estimated cost up to a specific date
I. The costs accrued up to a specific date
J. The actual costs accrued up to a specific date plus the remaining estimated costs to complete the project
K. The original total estimated cost minus management at completion cost
L. Your opinion about the overall progress of the project as well as a description of the major cost, budget, requirements, and technical issues impacting the project
Exhibit 13-3. Playscript format
Processing the Monthly Status Report Form
The procedure describes how to process the Monthly Status Report Form. It does not explain how to complete it. For that, refer to the procedure Completing the Monthly Status Report Form.
Obtain a copy of the Monthly Status Report Form.
Complete the Monthly Status Report Form.
Date and sign the form.
Make two (2) photocopies.
a. Retain one copy for the project history file.
b. Attach the other copy to the master document.
Review the Monthly Status Report Form for completeness.
a. Prepare a memo noting the shortcomings.
b. Attach a copy of the memo to the master document.
c. File the copy.
d. Return the memo and master copy to the project manager.
a. Date-stamp the master document and photocopy.
b. File the master copy.
c. Return the copy to the project manager.
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:
Exhibit 13-4. Item-by-item format
Handling All Reports for Competitive-Sensitive Projects
This procedure describes how to handle reports generated for projects designated proprietary.
I. Cost Report
A. Review the report.
B. Store one copy of the report in a secure room, drawer, or safe.
C. Shred any additional copies.
II. Schedule Report
A. Review the report.
B. Store one copy of the report in a secure room, drawer, or safe.
C. Shred any additional copies.
III. Monthly Status Report
A. Complete the report.
B. Upon receiving the date-stamped copy from the program office, shred the original.
C. Store the retained copy in a secure room, drawer, or safe.
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.
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.
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.
There are essentially two ways to present forms, reports, memos, and the like.
Hard copy. Traditional papers, usually typed or printed. It has the advantage of being familiar; the downside is that it can be costly to maintain, labor-intensive to revise, difficult to keep current, highly prone to human error, and takes up file space.
Electronic copy. On computer disk or tape. Electronic copies can reduce the need for storage space, lower labor-intensive actions (e.g., revisions), and make updating easier. Unfortunately, electronic copies still remain susceptible to human error, although less so with the recent advances in electronic storage. Hard copy backups have been the norm, here.
Electronic storage has its challenges, too. It requires investing in and maintaining a technology infrastructure (e.g., local area network or Web site), training people to use the technology, and dealing with administrative issues such as disaster recovery and backup.
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 people’s 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.
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
Instructions: Complete each field according to the procedure 'Completing the Monthly Status Report Form.' Make one copy for your records and forward the original to the Program Office, Mailstop 3X-41.
Start date (baseline):
Finish date (baseline):
Management Estimate at Completion Date:
Original Total Cost Estimate:
Estimated Cost to Date:
Actual Cost to Date:
Management Estimate at Completion Cost:
Overall Performance Evaluation:
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 that’s 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.
Many people hate to write memos. That’s 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.
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
Date: February 28, 19XX
Subject: Planning Meeting for Bridal Shower
March 10, we will hold a planning session for the Smythe bridal shower in the
Rainbow Conference Room on the second floor of the
Prior to the meeting, prepare and bring a list of action items to share with the group.
If you have any questions or comments, please feel free to contact me at extension 4127.
Project Manager, Smythe Wedding
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.
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. That’s 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.
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 Trail’s 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
Table of Contents
I. INTRODUCTORY SEGMENT
A. Purpose of the manual
B. How to use the manual
C. Who to contact for revisions
II. PROJECT BACKGROUND INFORMATION
A. Statement of work
B. Project declaration
A. Organization chart
B. Job descriptions and responsibilities
IV. POLICIES, PROCEDURES, AND
VII. REFERENCE LISTINGS
A. Phone listings
B. Functional priorities
C. Documentation matrix
VIII. OTHER ADMINISTRATIVE TOPICS
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?
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?
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 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?
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?
Adauga cod HTML in site