<< . .

. 11
( : 22)



. . >>


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.
3. 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.
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.
4. 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.
1. Use symbols consistently. Provide a key to the symbols.
2. Put the flowcharts under version control. Different versions can quickly be released, thereby
confusing people.
3. Use a software toot to generate the diagrams. Revisions will be easier and the charts clearer.
4. 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.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



When flowcharting, follow these four steps:
Title
1. Determine the topic, just as you would with written procedures.
2. 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.
3. Prepare, review, revise, and publish the flowchart. This step is the same for procedures.
-----------
4. 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:
1. Determine its purpose (e.g., capturing schedule or cost data).
2. Determine who will complete the form and who will process it.
3. Identify the exact data to capture.
4. Determine its source and destination.
5. Prepare the instructions for its completion.
6. Prepare a draft of the form (e.g., using a graphics or spreadsheet program).
7. Circulate the form for evaluation (e.g., to people who can complete it and to others who will use
data that it captures).
8. Make revisions, if necessary.
9. Determine the number of copies and how the copies will be made.
10. Reproduce the form.
11. 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.
Distribution Methods
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.
1. Determine the topics requiring forms. These are topics for which he will need information
throughout the project.
2. 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.
3. Distribute a first draft of the forms. Perry gives everyone involved a chance to revise the forms and
sharpen their design.
4. 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
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.
Project Name: Date:
Schedule:

Start date (baseline):
Finish date (baseline):
Management Estimate at Completion Date:
Variance:
Budget:
Original Total Cost Estimate:
Estimated Cost to Date:
Actual Cost to Date:
Management Estimate at Completion Cost:
Variance:
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:
1. 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.
2. 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.
3. 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.
4. He determines the frequency of generation. Weekly? Biweekly? Monthly? Ad hoc?
5. 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.
6. 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.
7. 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. 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.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



To fulfill these purposes, however, memos must be clear, concise, direct, legible, and organized. Exhibit 13-8
Title
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.
Date: February 28, 19XX
To: Gina Davies 713-1
Cynthia Fralusinski 714-2
Raymond Leazowitz 713-2
David Rockford 713-3
Vy Toon 714-3
Hank Wilson 715-1
Henry Winkless 716-8
cc: Eva Brewster 716-7
Larry Eisenberg 715-4

Subject: Planning Meeting for Bridal Shower
On March 10, we will hold a planning session for the Smythe bridal shower in the Rainbow Conference
Room on the second floor of the Corporate Headquarters Building.
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.
Perry
Project Manager, Smythe Wedding
Mailstop 713-4

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. 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:
1. He identifies their contents, e.g., as being only recent sets of schedules, or all previous versions.
2. He determines their organization, e.g., by topic or date.
3. He controls their removal, e.g., by means of a check-in/check-out sheet.
4. 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.
1. He determines the contents, e.g., by interviewing team members or reviewing the statement of work.
2. He organizes the contents, e.g., arranging them by topic or phase.
3. He determines the number of copies, e.g., by using the size of the team as the basis.
4. He assigns responsibility for maintaining the manual, e.g., to someone working on a noncritical task.
5. He publishes and distributes the manuals, e.g., electronically or as hard copy.
6. He seeks feedback from the users of the manual, e.g., by providing tear sheets on which they can
submit suggestions.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



The Project Library
Title

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:
1. He identifies the contents, e.g., by interviewing team members for their suggestions.
2. He determines the organization, e.g., arranging documents by title, code, or author.
3. He controls the removal of documents, e.g., by providing a check-in/check-out sheet.
4. 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
III. RESPONSIBILITIES
A. Organization chart
B. Job descriptions and responsibilities
IV. POLICIES, PROCEDURES, AND WORKFLOWS
Copies relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
V. FORMS
Copies relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
VI. REPORTS
Samples relating to these topics:
1. People
2. Scheduling
3. Qualities
4. Costs
5. Other
VII. REFERENCE LISTINGS
A. Phone listings
B. Functional priorities
C. Documentation matrix
D. Other
VIII. OTHER ADMINISTRATIVE TOPICS
IX. APPENDICES

Questions for Getting Started
1. If developing procedures, did you:
• Identify the topics?
• Determine the types of procedures needed?
• Receive reviews by all relevant people?
• Distribute the procedures?

<< . .

. 11
( : 22)



. . >>