<< . .

. 10
( : 22)



. . >>

Perry knows that by managing risk, he can identify priorities, thereby focusing his energies and resources as
well as developing a meaningful project plan. The analysis of risk indicates the strengths and the weaknesses
of the project, so that he can maximize his assets and minimize his losses. It helps him to identify and put into
place the most important controls, rather try to control everything.
To perform risk management, Perry needs information, time, expertise, and perspective. The information is
necessary to understand the major processes and components, the accompanying threats, and the controls that
should be in place. It will take time to collect the information and assemble it in some meaningful form. He
will use his expertise in project management to apply risk management while maintaining a broad perspective
to avoid focusing on just one area (e.g., technical issues at the expense of business ones).
Exposure
Several factors can expose projects to higher than normal risk.
• Team size. The larger the team, the higher the probability of a problem arising. For example,
communications can be more difficult as the number of participants increases. The number of
interactions among people increases and thus they require greater coordination.
• History. Newer projects are riskier because the processes have not been refined. The more times a
project of a similar nature has been done, the greater the likelihood of success.
• Staff expertise and experience. If the staff lacks direct experience and knowledge of the subject,
people will struggle to learn as they go along, robbing the project of time and possibly introducing
errors.
• Complexity. The more sophisticated a project, the greater the opportunity of a mistake or slipup.
Untested technologies, such as ones dealing with information systems or biotechnologies, are risk
laden.
• Management stability. The more senior management plays “musical chairs,” the greater the risks of
a problem arising. With every new management comes the possibility of changed priorities and
directions. Management stability implies unity of direction, which in turn means reaching goals.
Management irritability can lead to unrealistic scheduling and inefficient use of resources.
• Time compression. If a schedule is highly compressed, then the risks are magnified. Having more
time means greater flexibility and the opportunity to prevent or mitigate the impact of errors.
• Resource availability. The more resources that are available, the greater the ability to respond to
problems as they arise. For example, more money brings greater ability to secure equipment or people
when needed. Plentiful resources, of course, do not guarantee protection from risk; however they do
provide the means to respond to it.

Categories of risk
Risks can be viewed as business, technical, or operational. An example of a business risk is misuse of project
funds. A technical risk is the inability to build the product that will satisfy requirements. An operational risk is
the inability of the customer to work with core team members.
Risks are either acceptable or unacceptable. An acceptable risk is one that negatively affects a task on the
noncritical path. An unacceptable risk is one that negatively affects the critical path.
Risks are either short or long term. A short-term risk has an immediate impact, such as changing the
requirements for a deliverable. A long-term risk has an impact sometime in the distant future, such as
releasing a product without adequate testing.
Risks are viewed as either manageable or unmanageable. A manageable risk is one you can live with, such as
a minor requirement change. An unmanageable risk is impossible to accommodate, such as a huge turnover of
core team members.
Finally, risks are either internal or external. An internal risk is peculiar to a project, such as the inability to get
the parts of a product to work. An external risk originates from outside the scope of the project, such as when
senior management arbitrarily cuts funding by 20 percent.
Categorizing risks is, of course, mainly an academic exercise. These classifications can help you determine
the source, relative importance, and impact to the project.

Key Concepts in Risk Management
When performing risk management, Perry remembers the following concepts.
• A component is a basic element of an overall system. A project is a system consisting of components
that, in turn, can consist of subcomponents. Components can be processes, deliverables, or both.
Examples of a component are a process like “determining requirements” or a deliverable like a
“requirements document.”
• A threat is the occurrence of an event that negatively affects a project in some manner. A threat
exploits a vulnerability, or exposure. An example of a threat is when there is no customer buy-in of a
schedule or requirement. A vulnerability is the inherent degree of weakness of a component, such as a
schedule having no acceptance by the customer.
• Probability is the odds that something, like a threat, will occur any-where from 0 to 100 percent.
Probability determines the extent to which a risk will occur and the level of vulnerability.
• Control is a measure in place to mitigate, prevent, or correct the impact of a threat. A control can be
physical, such as a required signature, or logical, such as a peer review.
Keeping the above concepts in mind, Perry can perform risk management using two approaches: quantitative
or qualitative.


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 quantitative approach relies on statistical calculation to determine risk, its probability of occurrence, and
Title
its impact on a project. A common example of the quantitative approach is decision tree analysis, applying
probabilities to two or more outcomes. Another example is the three-point estimating technique described in
Chapter 7. Still another approach is the Monte Carlo simulation, which generates a value from a probability
distribution and other factors.
-----------
The qualitative approach relies on judgments, using criteria to determine outcomes. A common qualitative
approach is a precedence diagramming method, which uses ordinal numbers to determine priorities and
outcomes. Another approach is heuristics, or rules of thumb, to determine outcomes.
An example of a qualitative approach is to list in descending order specific processes of a project, the risk or
risks associated with each process, and the control or controls that may or should exist for each risk. See
Exhibit 12-1.

Ways to Handle Risk
There are four basic ways to deal with risk.
1. Accept the risk, known as risk acceptance. Perry can do nothing to prevent or mitigate the impact of
a risk. For example, he continues to
Exhibit 12-1. Example of a qualitative approach.
Process Risk Control
1. Obtain involvement of Inability to make regular Mail or e-mail duplicate
client. contact. copies of project management
documentation to the client.
2. Determine requirements. Unclear requirements. Conduct periodic reviews.
Unavailable requirements. Draft requirements and review
them with client.
address the same requirements despite management having reduced the budget.
2. Adapt to the risk, known as risk adaptation. Perry can take measures that will mitigate the impact of
a risk. For example, he reduces requirements to reflect the corresponding cutback in funding.
3. Avoid the risk, known as risk avoidance. Perry takes action that will keep a risk from seriously
impacting his project. For example, he decides to narrow the scope of the project to avoid certain high
risks.
4. Transfer the risk, known as risk transfer. Perry lets someone else assume the risk. For example, he
contracts out or outsources certain high-risk tasks rather than let the core team handle them.
When performing the contingency planning, Perry will identify the expected event or threat, its probability of
occurrence, and its impacts (e.g., economic, technical, operational), and then devise an appropriate response.
He uses a simple form to capture this information, as shown in Exhibit 12-2.
Perry also reviews the schedule to identify possible risks. He considers options like changing the
dependencies, durations, requirements, resource assignments, or time estimates.

Risk Reporting
Risk reporting occurs after risk identification, analysis, and control are complete. Perry has the option to
develop either a written or an oral report. In either case, however, the content of the report will be basically
the same.
A risk report should be clear, concise, and self-explanatory. It should contain categories of risks (e.g.,
business and technical); components; risks for each component, to include probability of occurrence and
impact; background and scope of project; and recommendations or actions to strengthen controls or respond
to risks when they become actual problems (e.g., contingency plans).
Exhibit 12-2. Risk response form.
Probability of
Description Occurrence Impacts Response
Cancellation of air Low • Less attendance at Set up charter flight
transportation reception or wedding
• Delays in arrivals

The Key: Risk Management, Not Elimination
In a dynamic environment, a project will always face risks. The key is not to try to eliminate risks but to
manage them. Perry identifies and analyzes risks. He then implements controls to mitigate or eliminate their
potential impact. However, he also communicates the list of risks and their accompanying controls to all
people who have a need to know. By developing and distributing documentation on risks and their controls,
Perry can either prevent related problems or minimize their effects when they occur.

Questions for Getting Started
1. Did you identify the major components and processes for your project?
2. Did you identify the major threats to your project? Did you identify their probability of occurrence?
3. Did you identify the controls that should exist for preventing or mitigating risks to each component
or process?
4. Did you conduct research to determine what controls actually exist?
5. For all control weaknesses, did you determine whether contingency plans should be in place? If so,
did you prepare the appropriate response?


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



Title
Chapter 13
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.
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.
1. Define acronyms the first time they appear and spell out abbreviations at first use. The reader may
not know what you mean.
2. Define special terms. The reader needs to understand what you are saying.
3. Avoid clich©s. They are a tired way of expressing what you mean. Be original -- but always clear
in your meaning.
4. Check for typographical and spelling errors. They distract from the message and show sloppiness.
5. Use positive expressions. Avoid “do not” or “cannot” because such phrases create a mental block
in the reader™s mind. Be positive.
6. Use the active rather than the passive voice. The active voice is strong language; the passive voice
is weak and reveals a tentative writer.
7. Watch your organization. Ideas should flow logically, such as from the general to the specific, or
vice versa. Chronological order is also good.
8. Avoid wordiness. Keep sentences short (less than 15 words) and paragraphs brief (usually less
than 5 sentences). Ideas are easier to grasp this way.
9. Integrate text and graphics. If using both, ensure that the text references the graphics and that the
two match information.
10. 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.
1. 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
2. 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
Project:

Date:

Start (baseline):

Finish (baseline):

Management estimate at
completion (MEAC) date:

Variance:

Original total cost estimate:

Estimated cost to date:

Actual cost to date:

Management estimate at
completion (MEAC) cost:

Variance:

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.
1. 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.



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



Exhibit 13-2. Sequential format.
Title
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.
-----------
Project: A Date: B

Schedule:
Start Baseline: C
Finish Baseline: D
Management Estimate at Completion Date: E
Variance: F
Budget:
Original Total Cost Estimate: G
Estimated Cost to Date: H
Actual Cost to Date: I
Management Estimate at Completion: J
Variance: K
Overall Performance Evaluation: L
Completing the Monthly Status Report Form
This procedure describes how to complete the Monthly Status Report form.
1. Obtain a copy of the form from the project office.
2. 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.
PROJECT MANAGER
1. Obtain a copy of the Monthly Status Report Form.
2. Complete the Monthly Status Report Form.
3. Date and sign the form.
4. Make two (2) photocopies.
a. Retain one copy for the project history file.
b. Attach the other copy to the master document.
PROGRAM OFFICE
1. Review the Monthly Status Report Form for completeness.
2. If incomplete:
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.
3. If complete:
a. Date-stamp the master document and photocopy.
b. File the master copy.
c. Return the copy to the project manager.

<< . .

. 10
( : 22)



. . >>