ZeePedia

PROJECT RISK MANAGEMENT:Components of Risk, Categories of Risk, Risk Planning

<< COMMUNICATION IN THE PROJECT MANAGEMENT:Cost of Correspondence, CHANNEL
PROJECT PROCUREMENT, CONTRACT MANAGEMENT, AND ETHICS IN PROJECT MANAGEMENT:Procurement Cycles >>
img
Project Management ­MGMT627
VU
LESSON 44
PROJECT RISK MANAGEMENT
BROAD CONTENTS
What is Risk?
Primary Components
Tolerance of Risk
Risk Management
Categories of Risk
Risk Planning
Risk Identification
Risk Assessment (identification and analysis)
Risk Handling
In the early days of project management on many commercial programs, the majority of project
decisions heavily favored cost and schedule. This favoritism occurred because we knew more about cost
and scheduling than we did about technical risks. Technology forecasting was very rarely performed
other than by extrapolating past technical knowledge into the present.
Today, the state of the art of technology forecasting is being pushed to the limits. For projects with time
duration of less than one year, we normally assume that the environment is known and stable,
particularly the technological environment. For projects over a year or so in length, technology
forecasting must be considered. Computer technology doubles in performance about every two years.
Engineering technology is said to double every three or so years. How can a project manager accurately
define and plan the scope of a three- or four-year project without expecting engineering changes
resulting from technology improvements?
44.1
What are the Risks?
A Midwest manufacturing company embarked on an eight-year project to design the manufacturing
factory of the future. The plant is scheduled to go into the construction phase in the year 2000. How do
we design the factory of the future without forecasting the technology? What computer technology will
exist? What types of materials will exist and what types of components will our customers require?
What production rate will we need and will technology exist to support this production level?
Economists and financial institutions forecast interest rates. The forecasts appear in public newspapers
and journals. Yet, every company involved in high tech does some form of technology forecasting, but
appears very reluctant to publish the data. Technology forecasting is regarded as company proprietary
information and may be part of the company's strategic planning process.
We read in the newspaper about cost overruns and schedule slips on a wide variety of large-scale
development projects. Several issues within the control of the buyer, seller, or major stakeholders can
lead to cost growth and schedule slippage on development projects. These causes include, but are not
limited to:
·  Starting a project with a budget and/or schedule that is inadequate for the desired level of
performance or scope (e.g., integration complexity).
·  Having an overall development process (or key parts of that process) that favors performance
(or scope) over cost and schedule.
·  Establishing a design that is near the feasible limit of achievable performance or integration
complexity at a given point in time.
·  Making major project design decisions before the relationships between cost, performance,
schedule, and risk are understood.
352
img
Project Management ­MGMT627
VU
These four causes will contribute to uncertainty in forecasting technology and the associated design
needed to meet performance requirements. And the inability to perfectly forecast technology and the
associated design will contribute to a project's technical risk, and can also lead to cost and schedule risk.
Today, the competition for technical achievement has become fierce. Companies have gone through
life-cycle phases of centralizing all activities, especially management functions, but are decentralizing
technical expertise. By the mid 1980s, many companies recognized the need to integrate technical risks
with cost and schedule risks, and other activities (e.g., quality). Risk management processes were
developed and implemented where risk information was made available to key decision-makers.
The risk management process, however, should be designed to do more than just identify the risk.
The process must also include: a formal planning activity, analysis to quantify the likelihood and predict
the impact on the project, a handling strategy for selected risks, and the ability to monitor the progress
in reducing these selected risks to the desired level.
A project, by definition, is something that we have not done previously and will not do again in the
future. Because of this uniqueness, we have developed a ''live with it" attitude on risk and attribute it as
part of doing business. If risk management is set up as a continuous, disciplined process of planning,
assessment (identification and analysis), handling, and monitoring, then the system will easily
supplement other systems as organization, planning and budgeting, and cost control. Surprises that
become problems will be diminished because emphasis will now be on proactive rather than reactive
management.
Risk management can be justified on almost all projects. The level of implementation can vary from
project to project, depending on such factors as size, type of project, who the customer is, relationship to
the corporate strategic plan, and corporate culture. Risk management is particularly important when the
overall stakes are high and a great deal of uncertainty exists. In the past, we treated risk as a "let's live
with it." Today, risk management is a key part of overall project management. It forces us to focus on
the future where uncertainty exists and develop suitable plans of action to prevent potential issues from
adversely impacting the project.
Risk is a measure of the probability and consequence of not achieving a defined project goal. Most
people agree that risk involves the notion of uncertainty. Can the specified aircraft range be achieved?
Can the computer be produced within budgeted cost? Can the new product launch date be met? A
probability measure can be used for such questions; for example, the probability of not meeting the new
product launch date is 0.15. However, when risk is considered, the consequences or damage associated
with occurrence must also be considered.
Goal A, with a probability of occurrence of only 0.05, may present a much more serious (risky) situation
than goal B, with a probability of occurrence of 0.20, if the consequences of not meeting goal A are, in
this case, more than four times more severe than failure to meet goal B. Risk is not always easy to
assess, since the probability of occurrence and the consequence of occurrence are usually not directly
measurable parameters and must be estimated by statistical or other procedures.
44.2
Components of Risk
Risk has two primary components for a given event:
·  A probability of occurrence of that event
·  Impact of the event occurring (amount at stake)
353
img
Project Management ­MGMT627
VU
Figure 44.1: Overall risk is a function of its components.
Figure 44.1 shows the components of risk.
Conceptually, risk for each event can be defined as a function of likelihood and impact; that is,
In general, as either the likelihood or impact increases, so does the risk. Both the likelihood and impact
must be considered in risk management.
Risk constitutes a lack of knowledge of future events. Typically, future events (or outcomes) that are
favorable are called opportunities, whereas unfavorable events are called risks.
Another element of risk is the cause of risk. Something, or the lack of something, can induce a risky
situation. We denote this source of danger as the hazard. Certain hazards can be overcome to a great
extent by knowing them and taking action to overcome them. For example, a large hole in a road is a
much greater danger to a driver who is unaware of it than to one who travels the road frequently and
knows enough to slow down and go around the hole. This leads to the second representation of risk:
Risk increases with hazard but decreases with safeguard. The implication of this equation is that good
project management should be structured to identify hazards and to allow safeguards to be developed to
overcome them. If enough safeguards are available, then the risk can be reduced to an acceptable level.
44.3
Tolerance of Risk
There is no single textbook answer on how to manage risk. The project manager must rely upon sound
judgment and the use of the appropriate tools in dealing with risk. The ultimate decision on how to deal
with risk is based in part upon the project manager's tolerance for risk.
The three commonly used classifications of tolerance for risk appear in Figure 44.2. They include the
risk averter or avoider, the neutral risk taker, and the risk seeker or lover. The Y axis in Figure 44.2
represents "utility," which can be defined as the amount of satisfaction or pleasure that the individual
receives from a payoff. (This is also called the project manager's tolerance for risk.) The X axis in this
case is the amount of money at stake.
Figure 44.2: Risk preference & utility function
354
img
Project Management ­MGMT627
VU
With the risk averter, utility rises at a decreasing rate. In other words, when more money is at stake, the
project manager's satisfaction or tolerance diminishes. With the risk lover, the project manager's
satisfaction increases when more money is at stake (i.e., an increasing slope to the curve). A risk averter
prefers a more certain outcome and will demand a premium to accept risk.
A risk lover prefers the more uncertain outcome and may be willing to pay a penalty to take a risk.
44.4
Risk Management
Risk management is the act or practice of dealing with risk. It includes planning for risk, assessing
(identifying and analyzing) risk issues, developing risk handling options, and monitoring risks to
determine how risks have changed.
Risk management is not a separate project office activity assigned to a risk management department, but
rather is one aspect of sound project management. Risk management should be closely coupled with key
project processes, including but not limited to: overall project management, systems engineering, cost,
scope, quality, and schedule.
Proper risk management is proactive rather than reactive. As an example, an activity in a
network requires that a new technology be developed. The schedule indicates six months for
this activity, but project engineers think that nine months is closer to the truth. If the project
manager is proactive, he might develop a Risk Handling Plan right now. If the project manager
is reactive (e.g., a "problem solver"), then he will do nothing until the problem actually occurs.
At that time the project manager must react rapidly to the crisis, and may have lost valuable
time when contingencies could have been developed. Hence, proper risk management will
attempt to reduce the likelihood of an event occurring and/or the magnitude of its impact.
44.5
Categories of Risk
The Project Management Institute categorizes risks as follows:
External­unpredictable: Government regulations, natural hazards, and acts of God
External­predictable: Cost of money, borrowing rates, raw material availability
The external risks are outside of the project manager's control but may affect the direction of the project.
Internal (nontechnical): Labor stoppages, cash flow problems, safety issues, health and benefit plans.
The internal risks may be within the control of the project manager and present uncertainty that may
affect the project.
Technical: Changes in technology, changes in state of the art, design issues, operations/maintenance
issues. Technical risks relate to the utilization of technology and the impact it has on the direction of the
project.
Legal: Licenses, patent rights, lawsuits, subcontractor performance, contractual failure
To identify risk issues, evaluators should break down program elements to a level where they can
perform valid assessments. The information necessary to do this varies according to the phase of the
program. During the early phases, requirement and scope documents, and acquisition plans may be the
only program-specific data available. They should be evaluated to identify issues that may have adverse
consequences.
Another method of decomposition is to create a Work Breakdown Structure (WBS) as early as possible
in a program, and use this in a structured approach to evaluate candidate risk categories against
candidate system or lower level designs. To use this approach, each element at level three of the WBS is
further broken down to the fourth or fifth level and is subjected to a risk analysis. Items at system,
segment or group, or subsystem levels, as well as management items, are assessed using attributes such
as maturity and complexity of hardware and software items or the dependency of the item on existing
systems, facilities, or contractors to evaluate their risk levels.
355
img
Project Management ­MGMT627
VU
Another approach is to evaluate risk associated with some key processes (e.g., design and
manufacturing) that will exist on a project. Information on this approach is contained in the government
DoD directive 4245.7-M, which provides a standard structure for identifying technical risk areas in the
transition from development to production. The structure is geared toward programs that are mid-to-late
in the development phase but, with modifications, could be used for other projects. The directive
identifies a template for each major technical activity. Each template identifies potential areas of risk.
Overlaying each template on a project allows identification of mismatched areas, which are then
identified as "at risk." Having used all applicable templates, the program manager will have created a
"watch list" of production transition risk areas and can prioritize control actions-- many of which will
be the responsibility of systems engineering. DoD Directive 4245.7-M describes technical methods for
reducing the risk in each identified area.
High-risk areas may reflect missing capabilities in the project manager's organization or in supporting
organizations. They may also reflect technical difficulties in the design or development process. In
either case, "management" of risk involves using project management assets to reduce the identified
risks.
The value in each of these approaches to risk identification lies in the methodical nature of the approach,
which forces disciplined, consistent treatment of risk. However, using any method in a "cookbook"
manner may cause unique risk aspects of the project to be overlooked. Before acting on the outcome of
any assessment, the project manager must review the strengths and weaknesses of the approach and
identify other factors that may introduce technical, schedule, cost, program, or other risks.
Certainty, Risk, and Uncertainty
Decision-making falls into three categories: certainty, risk, and uncertainty. Decision-making under
certainty is the easiest case to work with. With certainty, we assume that all of the necessary
information is available to assist us in making the right decision, and we can predict the outcome with a
high level of confidence.
Decision-Making under Certainty
Decision-making under certainty implies that we know with 100 percent accuracy what the states of
nature will be and what the expected payoffs will be for each state of nature. Mathematically, this can be
shown with payoff tables.
To construct a payoff matrix, we must identify (or select) the states of nature over which we have no
control. We then select our own action to be taken for each of the states of nature. Our actions are called
strategies. The elements in the payoff table are the outcomes for each strategy.
A payoff matrix based on decision-making under certainty has two controlling features.
·  Regardless of which state of nature exists, there will be one dominant strategy that will produce
larger gains or smaller losses than any other strategy for all the states of nature.
·  There are no probabilities assigned to each state of nature.
Decision-Making under Risk
In most cases, there usually does not exist one dominant strategy for all states of nature. In a realistic
situation, higher profits are usually accompanied by higher risks and therefore higher probable losses.
When there does not exist a dominant strategy, a probability must be assigned to the occurrence of each
state of nature.
Risk can be viewed as outcomes (i.e., states of nature) that can be described within established
confidence limits (i.e., probability distributions). These probability distributions are obtained from well-
defined experimental distributions.
Decision-making under Uncertainty
The difference between risk and uncertainty is that under risk there are assigned probabilities, and under
uncertainty meaningful assignments of probabilities are not possible. As with decision making under
356
img
Project Management ­MGMT627
VU
risk, uncertainty also implies that there may exist no single dominant strategy. The decision-maker,
however, does have at his disposal four basic criteria from which to make a management decision. The
decision about which criterion to use will depend on the type of project as well as the project manager's
tolerance to risk.
Risk Management Process
It is important that a risk management strategy is established early in a project and that risk is
continually addressed throughout the project life cycle. Risk management includes several related
actions involving risk: planning, assessment (identification and analysis), handling, and monitoring:
· Risk planning: This is the process of developing and documenting an organized, comprehensive, and
interactive strategy and methods for identifying and tracking risk issues, developing risk handling plans,
performing continuous risk assessments to determine how risks have changed, and assigning adequate
resources.
· Risk assessment: This process involves identifying and analyzing program areas and critical technical
process risks to increase the likelihood of meeting cost, performance, and schedule objectives.
·Risk identification is the process of examining the program areas and each critical technical process to
identify and document the associated risk. Risk analysis is the process of examining each identified risk
issue or process to refine the description of the risk, isolate the cause, and determine the effects.
· Risk handling: This is the process that identifies, evaluates, selects, and implements options in order
to set risk at acceptable levels given program constraints and objectives. This includes the specifics on
what should be done, when it should be accomplished, who is responsible, and associated cost and
schedule. Risk handling options include assumption, avoidance, control (also known as mitigation), and
transfer. The most desirable handling option is selected, and a specific approach is then developed for
this option.
· Risk monitoring: This is the process that systematically tracks and evaluates the performance of risk
handling actions against established metrics throughout the acquisition process and provides inputs to
updating risk handling strategies, as appropriate.
44.6
Risk Planning
Risk planning is the detailed formulation of a program of action for the management of risk. It is the
process to:
·  Develop and document an organized, comprehensive, and interactive risk management strategy.
·  Determine the methods to be used to execute a program's risk management strategy.
·  Plan for adequate resources.
Risk planning is iterative and includes the entire risk management process, with activities to assess
(identify and analyze), handle, monitor (and document) the risk associated with a program. The result is
often the risk management plan (RMP).
Planning begins by developing and documenting a risk management strategy. Early efforts establish the
purpose and objective, assign responsibilities for specific areas, identify additional technical expertise
needed, describe the assessment process and areas to consider, define a risk rating approach, delineate
procedures for consideration of handling options, establish monitoring metrics (where possible), and
define the reporting, documentation, and communication needs.
The RMP is the roadmap that tells the project team how to get from where the program is today to
where the program manager wants it to be in the future. The key to writing a good RMP is to provide
the necessary information so the program team knows the objectives, goals, and the risk management
process. Since it is a roadmap, it may be specific in some areas, such as the assignment of
responsibilities for project personnel and definitions, and general in other areas to allow users to choose
the most efficient way to proceed. For example, a description of techniques that suggests several
methods for evaluators to use to assess risk is appropriate, since every technique has advantages and
disadvantages depending on the situation.
357
img
Project Management ­MGMT627
VU
44.7
Risk Assessment
Risk assessment is the problem definition stage of risk management, the stage that identifies, analyzes,
and quantifies program issues in terms of probability and consequences, and possibly other
considerations (e.g., the time to impact). The results are a key input to many subsequent risk
management actions. It is often a difficult and time-consuming part of the risk management process.
There are no quick answers or shortcuts. Tools are available to assist evaluators in assessing risk, but
none are totally suitable for any program and are often highly misleading if the user does not understand
how to apply them or interpret the results. Despite its complexity, risk assessment is one of the most
important phases of the risk management process because the caliber and quality of assessments can
have a large impact on program outcomes.
The components of assessment-- identification and analysis-- are performed sequentially with
identification being the first step.
Risk identification begins by compiling the program's risk issues. Project issues should be examined and
identified by reducing them to a level of detail that permits an evaluator to understand the significance
of any risk and its causes (e.g., risk issues). This is a practical way of addressing the large and diverse
number of potential risks that often occur in moderate- to large-scale programs.
For example, a WBS level 4 or 5 element may be made up of several risk issues associated with a
specification or function.
Risk analysis is a technical and systematic process to examine identified risks, isolate causes, determine
the relationship to other risks, and express the impact in terms of probability and consequence of
occurrence.
44.8
Risk Identification
The second step in risk management is to identify all potential risk issues. This may include a survey of
the program, customer, and users for concerns and problems.
Some degree of risk always exists in project, technical, test, logistics, production, and engineering areas.
Project risks include cost, funding, schedule, contract relationships, and political risks. (Cost and
schedule risks are often so fundamental to a project that they may be treated as stand-alone risk
categories.) Technical risks, such as related to engineering and technology, may involve the risk of
meeting a performance requirement, but may also involve risks in the feasibility of a design concept or
the risks associated with using state-of-the-art equipment or software. Production risk includes concerns
over packaging, manufacturing, lead times, and material availability. Support risks include
maintainability, operability, and trainability concerns. The understanding of risks in these and other
areas evolves over time.
Consequently, risk identification must continue through all project phases.
The methods for identifying risk are numerous. Common practice is to classify project risk according to
its source. Most sources are either objective or subjective.
Objective sources: Recorded experience from past projects and the current project as it proceeds
·  Lessons learned files
·  Program documentation evaluations
·  Current performance data
Subjective sources: Experiences based upon knowledgeable experts
·  Interviews and other data from subject matter experts
Risks can also be identified according to life-cycle phases, as shown in Figure 44.3. In the early life-
cycle phases, the total project risk is high because of lack of information. In the later life-cycle phases,
the financial risk is the greatest.
358
img
Project Management ­MGMT627
VU
Figure 44.3: Life-cycle risk analysis
Any source of information that allows recognition of a potential problem can be used for risk
identification. These include:
·  Systems engineering documentation
·  Life-cycle cost analysis
·  Plan/WBS decomposition
·  Schedule analysis
·  Baseline cost estimates
·  Requirements documents
·  Lessons learned files
·  Assumption analysis
·  Trade studies/analyses
·  Technical performance measurement (TPM) planning/analysis
·  Models (influence diagrams)
·  Decision drivers
·  Brainstorming
·  Expert judgment
Expert judgment techniques are applicable not only for risk identification, but also for forecasting and
decision-making. Two expert judgment techniques are the Delphi method and the nominal group
technique. The Delphi method has the following general steps:
Step 1: A panel of experts is selected from both inside and outside the organization. The experts do
not interact on a face-to-face basis and may not even know who else sits on the panel.
Step 2: Each expert is asked to make an anonymous prediction on a particular subject.
Step 3: Each expert receives a composite feedback of the entire panel's answers and is asked to
make new predictions based upon the feedback. The process is then repeated as necessary.
Closely related to the Delphi method is the nominal group technique, which allows for face-to-face
contact and direct communication. The steps in the nominal group technique are as follows:
Step 1: A panel is convened and asked to generate ideas in writing.
Step 2: The ideas are listed on a board or a flip chart. Each idea is discussed among the panelists.
Step 3: Each panelist prioritizes the ideas, which are then ranked mathematically. Steps 2 and 3 may
be repeated as necessary.
359
img
Project Management ­MGMT627
VU
Expert judgment techniques have the potential for bias in risk identification and analysis. Factors
affecting the bias include:
·  Overconfidence in one's ability
·  Insensitivity to the problem or risk
·  Proximity to project
·  Motivation
·  Recent event recall
·  Availability of time
·  Relationship with other experts
There exist numerous ways to classify risks. In a simple business context, risk can be defined as:
·  Business risk
·  Insurable risk
Business risks provide us with opportunities of profit and loss. Examples of business risk would be
competitor activities, bad weather, inflation, recession, customer response, and availability of resources.
Insurable risks provide us with only a chance for a loss. Insurable risks include such elements as:
Direct property damage: This includes insurance for assets such as fire insurance, collision insurance,
and insurance for project materials, equipment, and properties.
Indirect consequential loss: This includes protection for contractors for indirect losses due to third
party actions, such as equipment replacement and debris removal.
Legal liability: This is protection for legal liability resulting from poor product design, design errors,
product liability, and project performance failure. This does not include protection from loss of
goodwill.
Personnel: This provides protection resulting from employee bodily injury (worker's compensation),
loss of key employees, replacement cost of key employees, and several other types of business losses
due to employee actions.
On construction projects, the owner/customer usually provides ''wrap-up" or "bundle" insurance, which
bundles the owner, contractor, and subcontractors into one insurable package. The contractor may be
given the responsibility to provide the bundled package, but it is still paid for by the owner/customer.
44.9
Risk Handling
Risk handling includes specific methods and techniques to deal with known risks, identifies who is
responsible for the risk issue, and provides an estimate of the cost and schedule associated with reducing
the risk, if any. It involves planning and execution with the objective of reducing risks to an acceptable
level. The evaluators who assess risk should begin the process by identifying risks and developing
handling options and approaches to propose to the program manager, who selects the appropriate one(s)
for implementation. There are several factors that can influence our response to a risk, including but not
limited to:
·
Amount and quality of information on the actual hazards that caused the risk (descriptive
uncertainty)
·
Amount and quality of information on the magnitude of the damage (measurement uncertainty)
·
Amount and quality of information on probability of occurrence
·
Personal benefit to project manager for accepting the risk (voluntary risk)
·
Risk forced upon project manager (involuntary risk)
·
Confusion and avoidability of the risk
·
The existence of cost-effective alternatives (equitable risks)
·
The existence of high-cost alternatives or possibly lack of options (inequitable risks)
·
Length of exposure to the risk
Risk handling must be compatible with the RMP and any additional guidance the program manager
provides. A critical part of risk handling involves refining and selecting the most appropriate handling
360
img
Project Management ­MGMT627
VU
option(s) and specific approach (es) for selected risk issues (often those with medium or higher risk
levels).
Personnel who evaluate candidate risk handling options may use the following criteria as starting points
for evaluation:
·  Can the option be feasibly implemented and still meet the user's needs?
·  What is the expected effectiveness of the handling option in reducing program risk to an
acceptable level?
·  Is the option affordable in terms of dollars and other resources (e.g., use of critical materials,
and test facilities)?
·  Is time available to develop and implement the option, and what effect does that have on the
overall program schedule?
·  What effect does the option have on the system's technical performance?
Risk handling options include: risk assumption, risk avoidance, risk control, and risk transfer.
Although the control option (often called mitigation) is commonly used in many high technology
programs, it should not automatically be chosen. All four options should be evaluated, and the best one
chosen for each risk issue.
The options for handling risk fall into the following categories:
Risk assumption (i.e., retention): The project manager says, ''I know the risk exists and am aware of the
possible consequences. I am willing to wait and see what happens. I accept the risk and its impact
should it occur."
Risk avoidance: The project manager says, "I will not accept this option because of the potentially
unfavorable results."
Risk control (i.e., prevention or mitigation): The project manager says, "I will take the necessary
measures required to control this risk by continuously reevaluating it and developing contingency plans
or fall-back positions. I will do what is expected."
Risk transfer: The project manager says, "I will share this risk with others through insurance or a
warranty, or transfer the entire risk to them. Perhaps I can convert the risk into an opportunity."
361
Table of Contents:
  1. INTRODUCTION TO PROJECT MANAGEMENT:Broad Contents, Functions of Management
  2. CONCEPTS, DEFINITIONS AND NATURE OF PROJECTS:Why Projects are initiated?, Project Participants
  3. CONCEPTS OF PROJECT MANAGEMENT:THE PROJECT MANAGEMENT SYSTEM, Managerial Skills
  4. PROJECT MANAGEMENT METHODOLOGIES AND ORGANIZATIONAL STRUCTURES:Systems, Programs, and Projects
  5. PROJECT LIFE CYCLES:Conceptual Phase, Implementation Phase, Engineering Project
  6. THE PROJECT MANAGER:Team Building Skills, Conflict Resolution Skills, Organizing
  7. THE PROJECT MANAGER (CONTD.):Project Champions, Project Authority Breakdown
  8. PROJECT CONCEPTION AND PROJECT FEASIBILITY:Feasibility Analysis
  9. PROJECT FEASIBILITY (CONTD.):Scope of Feasibility Analysis, Project Impacts
  10. PROJECT FEASIBILITY (CONTD.):Operations and Production, Sales and Marketing
  11. PROJECT SELECTION:Modeling, The Operating Necessity, The Competitive Necessity
  12. PROJECT SELECTION (CONTD.):Payback Period, Internal Rate of Return (IRR)
  13. PROJECT PROPOSAL:Preparation for Future Proposal, Proposal Effort
  14. PROJECT PROPOSAL (CONTD.):Background on the Opportunity, Costs, Resources Required
  15. PROJECT PLANNING:Planning of Execution, Operations, Installation and Use
  16. PROJECT PLANNING (CONTD.):Outside Clients, Quality Control Planning
  17. PROJECT PLANNING (CONTD.):Elements of a Project Plan, Potential Problems
  18. PROJECT PLANNING (CONTD.):Sorting Out Project, Project Mission, Categories of Planning
  19. PROJECT PLANNING (CONTD.):Identifying Strategic Project Variables, Competitive Resources
  20. PROJECT PLANNING (CONTD.):Responsibilities of Key Players, Line manager will define
  21. PROJECT PLANNING (CONTD.):The Statement of Work (Sow)
  22. WORK BREAKDOWN STRUCTURE:Characteristics of Work Package
  23. WORK BREAKDOWN STRUCTURE:Why Do Plans Fail?
  24. SCHEDULES AND CHARTS:Master Production Scheduling, Program Plan
  25. TOTAL PROJECT PLANNING:Management Control, Project Fast-Tracking
  26. PROJECT SCOPE MANAGEMENT:Why is Scope Important?, Scope Management Plan
  27. PROJECT SCOPE MANAGEMENT:Project Scope Definition, Scope Change Control
  28. NETWORK SCHEDULING TECHNIQUES:Historical Evolution of Networks, Dummy Activities
  29. NETWORK SCHEDULING TECHNIQUES:Slack Time Calculation, Network Re-planning
  30. NETWORK SCHEDULING TECHNIQUES:Total PERT/CPM Planning, PERT/CPM Problem Areas
  31. PRICING AND ESTIMATION:GLOBAL PRICING STRATEGIES, TYPES OF ESTIMATES
  32. PRICING AND ESTIMATION (CONTD.):LABOR DISTRIBUTIONS, OVERHEAD RATES
  33. PRICING AND ESTIMATION (CONTD.):MATERIALS/SUPPORT COSTS, PRICING OUT THE WORK
  34. QUALITY IN PROJECT MANAGEMENT:Value-Based Perspective, Customer-Driven Quality
  35. QUALITY IN PROJECT MANAGEMENT (CONTD.):Total Quality Management
  36. PRINCIPLES OF TOTAL QUALITY:EMPOWERMENT, COST OF QUALITY
  37. CUSTOMER FOCUSED PROJECT MANAGEMENT:Threshold Attributes
  38. QUALITY IMPROVEMENT TOOLS:Data Tables, Identify the problem, Random method
  39. PROJECT EFFECTIVENESS THROUGH ENHANCED PRODUCTIVITY:Messages of Productivity, Productivity Improvement
  40. COST MANAGEMENT AND CONTROL IN PROJECTS:Project benefits, Understanding Control
  41. COST MANAGEMENT AND CONTROL IN PROJECTS:Variance, Depreciation
  42. PROJECT MANAGEMENT THROUGH LEADERSHIP:The Tasks of Leadership, The Job of a Leader
  43. COMMUNICATION IN THE PROJECT MANAGEMENT:Cost of Correspondence, CHANNEL
  44. PROJECT RISK MANAGEMENT:Components of Risk, Categories of Risk, Risk Planning
  45. PROJECT PROCUREMENT, CONTRACT MANAGEMENT, AND ETHICS IN PROJECT MANAGEMENT:Procurement Cycles