Chapter 11 Project Risk Management

Risk management is the systematic process of identifying, analyzing, and

responding to project risk. It includes maximizing the probability and conse-

quences of positive events and minimizing the probability and consequences of

adverse events to project objectives.  Figure 11-1  provides an overview of the fol-

lowing major processes:

11.1

Risk Management Planning

—deciding how to approach and plan the risk man-

agement activities for a project.

11.2

Risk Identification

—determining which risks might affect the project and doc-

umenting their characteristics.

11.3

Qualitative Risk Analysis

—performing a qualitative analysis of risks and con-

ditions to prioritize their effects on project objectives.

11.4

Quantitative Risk Analysis

—measuring the probability and consequences of

risks and estimating their implications for project objectives.

11.5

Risk Response Planning

—developing procedures and techniques to enhance

opportunities and reduce threats to the project’s objectives.

11.6

Risk Monitoring and Control

—monitoring residual risks, identifying new risks,

executing risk reduction plans, and evaluating their effectiveness throughout the

project life cycle.

These processes interact with each other and with the processes in the other

knowledge areas. Each process generally occurs at least once in every project.

Although processes are presented here as discrete elements with well-defined inter-

faces, in practice they may overlap and interact in ways not detailed here. Process

interactions are discussed in detail in Chapter 3.

Project risk is an uncertain event or condition that, if it occurs, has a positive

or a negative effect on a project objective. A risk has a cause and, if it occurs, a

consequence. For example, a cause may be requiring a permit or having limited

personnel assigned to the project. The risk event is that the permit may take

longer than planned, or the personnel may not be adequate for the task. If either

of these uncertain events occur, there will be a consequence on the project cost,

schedule, or quality. Risk conditions could include aspects of the project envi-

ronment that may contribute to project risk such as poor project management

practices, or dependency on external participants that cannot be controlled.

Project risk includes both threats to the project’s objectives and opportunities

to improve on those objectives. It has its origins in the uncertainty that is present

in all projects. Known risks are those that have been identified and analyzed

project managers may address them by applying a general contingency based on

past experience with similar projects.

Organizations perceive risk as it relates to threats to project success. Risks that

are threats to the project may be accepted if they are in balance with the reward

that may be gained by taking the risk. For example, adopting a fast-track schedule

that may be overrun is a risk taken to achieve an earlier completion date. Risks

that are opportunities may be pursued to benefit the project’s objectives.

To be successful, the organization must be committed to addressing risk man-

agement throughout the project. One measure of the organizational commitment is

its dedication to gathering high-quality data on project risks and their characteristics

11.1  RISK MANAGEMENT PLANNING

Risk management planning is the process of deciding how to approach and plan

the risk management activities for a project. It is important to plan for the risk

management processes that follow to ensure that the level, type, and visibility of

risk management are commensurate with both the risk and importance of the

project to the organization.

11.1.1  Inputs to Risk Management Planning

.

1

Project charter.

The project charter is discussed in Section 5.1.3.1.

.

2

Organization’s risk management policies.

Some organizations may have prede-

fined approaches to risk analysis and response that have to be tailored to a par-

ticular project.

.

3

Defined roles and responsibilities.

Predefined roles, responsibilities, and authority

levels for decision-making will influence planning.

.

4

Stakeholder risk tolerances.

Different organizations and different individuals

have different tolerances for risk. These may be expressed in policy statements or

revealed in actions.

.

5

Template for the organization’s risk management plan.

Some organizations have

developed templates (or a pro-forma standard) for use by the project team. The

organization will continuously improve the template, based on its application

and usefulness in the project.

.

6

Work breakdown structure (WBS).

The WBS is described in Section 5.3.3.1

11.1.3  Outputs from Risk Management Planning

.

1

Risk management plan.

The risk management plan describes how risk identifi-

cation, qualitative and quantitative analysis, response planning, monitoring, and

control will be structured and performed during the project life cycle. The risk

management plan does not address responses to individual risks—this is accom-

plished in the risk response plan, which is discussed in Section 11.5.3.1. The risk

management plan may include the following.

ٱ

Methodology.  Defines the approaches, tools, and data sources that may be used

to perform risk management on this project. Different types of assessments

may be appropriate, depending upon the project stage, amount of information

available, and flexibility remaining in risk management.

ٱ

Roles and responsibilities.  Defines the lead, support, and risk management

team membership for each type of action in the risk management plan. Risk

management teams organized outside of the project office may be able to per-

form more independent, unbiased risk analyses of project than those from the

sponsoring project team.

ٱ

Budgeting.  Establishes a budget for risk managment for the project.

ٱ

Timing.  Defines how often the risk management process will be performed

throughout the project life cycle. Results should be developed early enough to

affect decisions. The decisions should be revisited periodically during project

execution.

ٱ

Scoring and interpretation.  The scoring and interpretation methods appropriate

for the type and timing of the qualitative and quantitative risk analysis being

performed. Methods and scoring must be determined in advance to ensure

consistency.

ٱ

Thresholds.  The threshold criteria for risks that will be acted upon, by whom,

and in what manner. The project owner, customer, or sponsor may have a

different risk threshold. The acceptable threshold forms the target against

which the project team will measure the effectiveness of the risk response

plan execution.

ٱ

Reporting formats.  Describes the content and format of the risk response plan

described in Section 11.5.3.1. Defines how the results of the risk management

processes will be documented, analyzed, and communicated to the project

team, internal and external stakeholders, sponsors, and others.

ٱ

Tracking.  Documents how all facets of risk activities will be recorded for the

benefit of the current project, future needs, and lessons learned. Documents

if and how risk processes will be audited.

Organizational risks—such as cost, time, and scope objectives that are inter-

nally inconsistent, lack of prioritization of projects, inadequacy or interruption

of funding, and resource conflicts with other projects in the organization.

ٱ

External risks—such as shifting legal or regulatory environment, labor issues,

changing owner priorities, country risk, and weather.  Force majeure  risks such

as earthquakes, floods, and civil unrest generally require disaster recovery

actions rather than risk management.

.

4

Historical information.

Information on prior projects may be available from the

following sources:

ٱ

Project files—one or more of the organizations involved in the project may

maintain records of previous project results that can be used to identify risks.

These may be final project reports or risk response plans. They may include

organized lessons learned that describe problems and their resolutions, or be

available through the experience of the project stakeholders or others in the

organization.

ٱ

Published information—commercial databases, academic studies, bench-

marking, and other published studies may be available for many application

areas.

11.2.2  Tools and Techniques for Risk Identification

.

1

Documentation reviews.

Performing a structured review of project plans and

assumptions, both at the total project and detailed scope levels, prior project files,

and other information is generally the initial step taken by project teams.

.

2

Information-gathering techniques.

Examples of information-gathering techniques

used in risk identification can include brainstorming; Delphi; interviewing; and

strengths, weaknesses, opportunities, and threats (SWOT) analysis.

ٱ

Brainstorming . Brainstorming is probably the most frequently used risk iden-

tification technique. The goal is to obtain a comprehensive list of risks that can

be addressed later in the qualitative and quantitative risk analysis processes.

The project team usually performs brainstorming, although a multidisci-

plinary set of experts can also perform this technique. Under the leadership of

a facilitator, these people generate ideas about project risk. Sources of risk are

identified in broad scope and posted for all to examine during the meeting.

Risks are then categorized by type of risk, and their definitions are sharpened.

ٱ

Delphi technique . The Delphi technique is a way to reach a consensus of

experts on a subject such as project risk. Project risk experts are identified but

participate anonymously.

A facilitator uses a questionnaire to solicit ideas about the important project

risks. The responses are submitted and are then circulated to the experts for

further comment. Consensus on the main project risks may be reached in a

few rounds of this process. The Delphi technique helps reduce bias in the data

and keeps any person from having undue influence on the outcome.

ٱ

Interviewing . Risks can be identified by interviews of experienced project man-

agers or subject-matter experts. The person responsible for risk identification

identifies the appropriate individuals, briefs them on the project, and provides

identify risks on the project based on their experience, project information,

and other sources that they find useful.

ٱ

Strengths, weaknesses, opportunities, and threats (SWOT) analysis . Ensures

examination of the project from each of the SWOT perspectives to increase the

breadth of the risks considered.

.

3

Checklists.

Checklists for risk identification can be developed based on historical

information and knowledge that has been accumulated from previous similar

projects and from other sources of information. One advantage of using a check-

list is that risk identification is quick and simple. One disadvantage is that it is

impossible to build an exhaustive checklist of risks, and the user may be effec-

tively limited to the categories in the list. Care should be taken to explore items

that do not appear on a standard checklist if they seem relevant to the specific

project. The checklist should itemize all types of possible risks to the project. It is

important to review the checklist as a formal step of every project-closing pro-

cedure to improve the list of potential risks, to improve the description of risks.

.

4

Assumptions analysis.

Every project is conceived and developed based on a set of

hypotheses, scenarios, or assumptions. Assumptions analysis is a technique that

explores the assumptions’ validity. It identifies risks to the project from inaccu-

racy, inconsistency, or incompleteness of assumptions.

.

5

Diagramming techniques.

Diagramming techniques may include:

ٱ

Cause-and-effect diagrams (also known as  Ishikawa  or  fishbone  diagrams)—

useful for identifying causes of risks (described in Section 8.1.2.3).

ٱ

System or process flow charts—show how various elements of a system inter-

relate and the mechanism of causation (described in Section 8.1.2.3).

ٱ

Influence diagrams—a graphical representation of a problem showing causal

influences, time ordering of events, and other relationships among variables

and outcomes.

11.2.3  Outputs from Risk Identification

.

1

Risks.

A risk is an uncertain event or condition that, if it occurs, has a positive or

negative effect on a project objective.

.

2

Triggers.

Triggers, sometimes called risk symptoms or warning signs, are indications

that a risk has occurred or is about to occur. For example, failure to meet interme-

diate milestones may be an early warning signal of an impending schedule delay.

.

3

Inputs to other processes.

Risk identification may identify a need for further action

in another area. For example, the WBS may not have sufficient detail to allow ade-

quate identification of risks, or the schedule may not be complete or entirely logical.

11.3 QUALITATIVE RISK ANALYSIS

Qualitative risk analysis is the process of assessing the impact and likelihood of

identified risks. This process prioritizes risks according to their potential effect on

project objectives. Qualitative risk analysis is one way to determine the impor-

tance of addressing specific risks and guiding risk responses. The time-criticality

of risk-related actions may magnify the importance of a risk. An evaluation of the

quality of the available information also helps modify the assessment of the risk.

Qualitative risk analysis requires that the probability and consequences of the

risks be evaluated using established qualitative-analysis methods and tools

Use of these tools helps correct biases

that are often present in a project plan. Qualitative risk analysis should be revis-

ited during the project’s life cycle to stay current with changes in the project risks.

This process can lead to further analysis in quantitative risk analysis (11.4) or

directly to risk response planning (11.5).

11.3.1  Inputs to Qualitative Risk Analysis

.

1

Risk management plan.

This plan is described in 11.1.3.

.

2

Identified risks.

Risks discovered during the risk identification process are eval-

uated along with their potential impacts on the project.

.

3

Project status.

The uncertainty of a risk often depends on the project’s progress

through its life cycle. Early in the project, many risks have not surfaced, the design

for the project is immature, and changes can occur, making it likely that more risks

will be discovered.

.

4

Project type.

Projects of a common or recurrent type tend to have better under-

stood probability of occurrence of risk events and their consequences. Projects

using state-of-the-art or first-of-its-kind technology—or highly complex projects—

tend to have more uncertainty.

.

5

Data precision.

Precision describes the extent to which a risk is known and under-

stood. It measures the extent of data available, as well as the reliability of data. The

source of the data that was used to identify the risk must be evaluated.

.

6

Scales of probability and impact.

These scales, as described in Section 11.3.2.2,

are to be used in assessing the two key dimensions of risk, described in Section

1

1

.3.2.1.

.

7

Assumptions.

Assumptions identified during the risk identification process are

evaluated as potential risks (see Sections 4.1.1.5 and 11.2.2.4).

11.3.2  Tools and Techniques for Qualitative Risk Analysis

.

1

Risk probability and impact.

Risk probability and risk consequences may be

described in qualitative terms such as very high, high, moderate, low, and very low.

Risk probability  is the likelihood that a risk will occur.

Risk consequences  is the effect on project objectives if the risk event occurs.

These two dimensions of risk are applied to specific risk events, not to the

overall project. Analysis of risks using probability and consequences helps iden-

tify those risks that should be managed aggressively.

ratings (very low, low, moderate, high, and very high) to risks or conditions based

on combining probability and impact scales. Risks with high probability and high

impact are likely to require further analysis, including quantification, and aggres-

sive risk management. The risk rating is accomplished using a matrix and risk

scales for each risk.

A risk’s  probability scale  naturally falls between 0.0 (no probability) and 1.0

(certainty). Assessing risk probability may be difficult because expert judgment

is used, often without benefit of historical data. An ordinal scale, representing rel-

ative probability values from very unlikely to almost certain, could be used. Alter-

natively, specific probabilities could be assigned by using a general scale (e.g.,

.1

/ .3 / .5 / .7 / .9).

The risk’s  impact scale  reflects the severity of its effect on the project objective.

Impact can be ordinal or cardinal, depending upon the culture of the organization

conducting the analysis. Ordinal scales are simply rank-ordered values, such as

very low, low, moderate, high, and very high. Cardinal scales assign values to

these impacts. These values are usually linear (e.g., .1 / .3 / .5 / .7 / .9), but are

often nonlinear (e.g., .05 / .1 / .2 / .4 / .8), reflecting the organization’s desire to

avoid high-impact risks. The intent of both approaches is to assign a relative value

to the impact on project objectives if the risk in question occurs. Well-defined

scales, whether ordinal or cardinal, can be developed using definitions agreed

upon by the organization. These definitions improve the quality of the data and

make the process more repeatable.

Figure 11-2  is an example of evaluating risk impacts by project objective. It

illustrates its use for either ordinal or cardinal approach. These scaled descriptors

of relative impact should be prepared by the organization before the project begins.

Figure 11-3  is a Probability-Impact (P-I) matrix. It illustrates the simple mul-

tiplication of the scale values assigned to estimates of probability and impact, a

common way to combine these two dimensions, to determine whether a risk is

considered low, moderate, or high. This figure presents a non-linear scale as an

example of aversion to high-impact risks, but linear scales are often used. Alter-

natively, the P-I matrix can be developed using ordinal scales. The organization

must determine which combinations of probability and impact result in a risk’s

being classified as high risk (red condition), moderate risk (yellow condition),

and low risk (green condition) for either approach. The risk score helps put the

risk into a category that will guide risk response actions.

.

3

Project assumptions testing.

Identified assumptions must be tested against two

criteria: assumption stability and the consequences on the project if the assump-

tion is false. Alternative assumptions that may be true should be identified and

their consequences on the project objectives tested in the qualitative risk-analysis

process.

.

4

Data precision ranking.

Qualitative risk analysis requires accurate and unbiased

data if it is to be helpful to project management. Data precision ranking is a tech-

nique to evaluate the degree to which the data about risks is useful for risk man-

agement. It involves examining:

ٱ

Extent of understanding of the risk.

ٱ

Data available about the risk.

ٱ

Quality of the data.

ٱ

Reliability and integrity of the data

The use of data of low precision—for instance, if a risk is not well understood—

may lead to a qualitative risk analysis of little use to the project manager. If a

ranking of data precision is unacceptable, it may be possible to gather better data.

11.3.3  Outputs from Qualitative Risk Analysis

.

1

Overall risk ranking for the project.

Risk ranking may indicate the overall risk posi-

tion of a project relative to other projects by comparing the risk scores. It can be

used to assign personnel or other resources to projects with different risk rankings,

to make a benefit-cost analysis decision about the project, or to support a recom-

mendation for project initiation, continuation, or cancellation.

.

2

List of prioritized risks.

Risks and conditions can be prioritized by a number of cri-

teria. These include rank (high, moderate, and low) or WBS level. Risks may also

be grouped by those that require an immediate response and those that can be

handled at a later date. Risks that affect cost, schedule, functionality, and quality

may be assessed separately with different ratings. Significant risks should have a

description of the basis for the assessed probability and impact.

.

3

List of risks for additional analysis and management.

Risks classified as high or

moderate would be prime candidates for more analysis, including quantitative

risk analysis, and for risk management action.

Trends in qualitative risk analysis results.

As the analysis is repeated, a trend of

results may become apparent, and can make risk response or further analysis

more or less urgent and important.

11.4 QUANTITATIVE RISK ANALYSIS

The quantitative risk analysis process aims to analyze numerically the probability

of each risk and its consequence on project objectives, as well as the extent of

overall project risk. This process uses techniques such as Monte Carlo simulation

and decision analysis to:

ٱ

Determine the probability of achieving a specific project objective.

ٱ

Quantify the risk exposure for the project, and determine the size of cost and

schedule contingency reserves that may be needed.

ٱ

Identify risks requiring the most attention by quantifying their relative con-

tribution to project risk.

ٱ

Identify realistic and achievable cost, schedule, or scope targets.

Quantitative risk analysis generally follows qualitative risk analysis. It requires

risk identification. The qualitative and quantitative risk analysis processes can be

used separately or together. Considerations of time and budget availability and the

need for qualitative or quantitative statements about risk and impacts will deter-

mine which method(s) to use. Trends in the results when quantitative analysis is

repeated can indicate the need for more or less risk management action.

11.4.1  Inputs to Quantitative Risk Analysis

.

1

Risk management plan.

This plan is described in Section 11.1.3.

.

2

Identified risks.

These are described in Section 11.2.3.1.

.

3

List of prioritized risks.

This is described in Section 11.3.3.2.

.

4

List of risks for additional analysis and management.

This is described in Section

1

1

.3.3.3.

.

5

Historical information.

Information on prior, similar completed projects, studies

of similar projects by risk specialists, and risk databases that may be available

from industry or proprietary sources (see Section 11.2.1.4).

.

6

Expert judgment.

Input may come from the project team, other subject matter

experts in the organization, and from others outside the organization. Other sources

of information include engineering or statistical experts (see Section 5.1.2.2).

.

7

Other planning outputs.

Most helpful planning outputs are the project logic and

duration estimates used in determining schedules, the WBS listing of all cost ele-

ments with cost estimates, and models of project technical objectives.

11.4.2  Tools and Techniques for Quantitative Risk Analysis

.

1

Interviewing.

Interviewing techniques are used to quantify the probability and con-

sequences of risks on project objectives. A risk interview with project stakeholders

and subject-matter experts may be the first step in quantifying risks. The infor-

mation needed depends upon the type of probability distributions that will be

used. For instance, information would be gathered on the optimistic (low), pes-

simistic (high), and the most likely scenarios if triangular distributions are used,

or on mean and standard deviation for the normal and log normal distributions.

Examples of three-point estimates for a cost estimate are shown in  Figure 11-4 .

Continuous probability distributions are usually used in quantitative risk

analysis. Distributions represent both probability and consequences of the project

component. Common distribution types include the uniform, normal, triangular,

beta, and log normal. Two examples of these distributions are shown in  Figure

11-5

(where the vertical axis refers to probability and the horizontal axis to impact).

Documenting the rationale of the risk ranges is an important component of

the risk interview, because it can lead to effective strategies for risk response in

the risk response planning process, described in Section 11.5

.

2

Sensitivity analysis.

Sensitivity analysis helps to determine which risks have the

most potential impact on the project. It examines the extent to which the uncer-

tainty of each project element affects the objective being examined when all

other uncertain elements are held at their baseline values.

.

3

Decision tree analysis.

A decision analysis is usually structured as a decision tree.

The decision tree is a diagram that describes a decision under consideration and

the implications of choosing one or another of the available alternatives. It incor-

porates probabilities of risks and the costs or rewards of each logical path of

events and future decisions. Solving the decision tree indicates which decision

yields the greatest expected value to the decision-maker when all the uncertain

implications, costs, rewards, and subsequent decisions are quantified. A decision

tree is shown in  Figure 11-6 .

.

4

Simulation.

A project simulation uses a model that translates the uncertainties

specified at a detailed level into their potential impact on objectives that are

expressed at the level of the total project. Project simulations are typically per-

formed using the Monte Carlo technique.

For a cost risk analysis, a simulation may use the traditional project WBS as its

model. For a schedule risk analysis, the Precedence Diagramming Method (PDM)

schedule is used (see Section 6.2.2.1).

A cost risk simulation result is shown in  Figure 11-7 .

11.4.3  Outputs from Quantitative Risk Analysis

.

1

Prioritized list of quantified risks.

This list of risks includes those that pose the

greatest threat or present the greatest opportunity to the project together with

a measure of their impact.

.

2

Probabilistic analysis of the project.

Forecasts of potential project schedule and

cost results listing the possible completion dates or project duration and costs

with their associated confidence levels.

.

3

Probability of achieving the cost and time objectives.

The probability of achieving

the project objectives under the current plan and with the current knowledge of

the risks facing the project can be estimated using quantitative risk.

.

4

Trends in quantitative risk analysis results.

As the analysis is repeated, a trend of

results may become apparent.

11.5  RISK RESPONSE PLANNING

Risk response planning is the process of developing options and determining actions

to enhance opportunities and reduce threats to the project’s objectives. It includes

the identification and assignment of individuals or parties to take responsibility for

each agreed risk response. This process ensures that identified risks are properly

addressed. The effectiveness of response planning will directly determine whether

risk increases or decreases for the project.

Risk response planning must be appropriate to the severity of the risk, cost

effective in meeting the challenge, timely to be successful, realistic within the

project context, agreed upon by all parties involved, and owned by a responsible

person. Selecting the best risk response from several options is often required.

11.5.1  Inputs to Risk Response Planning

.

1

Risk management plan.

This plan is described in Section 11.1.3.

.

2

List of prioritized risks.

This list from qualitative risk analysis is described in Section

11.3.3.2.

.

3

Risk ranking of the project.

This is described in Section 11.3.3.1

.

4

Prioritized list of quantified risks.

This list from quantitative risk analysis is described

in Section 11.4.3.1.

.

5

Probabilistic analysis of the project.

This is described in Section 11.4.3.2.

.

6

Probability of achieving the cost and time objectives.

This is described in Section

11.4.3.3.

.

7

List of potential responses.

In the risk identification process, actions may be iden-

tified that respond to individual risks or categories of risks.

.

8

Risk thresholds.

The level of risk that is acceptable to the organization will influ-

ence risk response planning (see Section 11.1.3).

.

9

Risk owners.

A list of project stakeholders able to act as owners of risk responses.

Risk owners should be involved in developing the risk responses.

.

0

Common risk causes.

Several risks may be driven by a common cause. This situ-

ation may reveal opportunities to mitigate two or more project risks with one

generic response.

.

1

1

Trends in qualitative and quantitative risk analysis results.

These are described in

Sections 11.3.3.4 and 11.4.3.4. Trends in results can make risk response or fur-

ther analysis more or less urgent and important.

11.5.2  Tools and Techniques for Risk Response Planning

Several risk response strategies are available. The strategy that is most likely to

be effective should be selected for each risk. Then, specific actions should be

developed to implement that strategy. Primary and backup strategies may be

selected

1

Avoidance.

Risk avoidance is changing the project plan to eliminate the risk or

condition or to protect the project objectives from its impact. Although the project

team can never eliminate all risk events, some specific risks may be avoided.

Some risk events that arise early in the project can be dealt with by clarifying

requirements, obtaining information, improving communication, or acquiring

expertise. Reducing scope to avoid high-risk activities, adding resources or time,

adopting a familiar approach instead of an innovative one, or avoiding an unfa-

miliar subcontractor may be examples of avoidance.

.

2

Transference.

Risk transfer is seeking to shift the consequence of a risk to a third

party together with ownership of the response. Transferring the risk simply gives

another party responsibility for its management; it does not eliminate it.

Transferring liability for risk is most effective in dealing with financial risk expo-

sure. Risk transfer nearly always involves payment of a risk premium to the party

taking on the risk. It includes the use of insurance, performance bonds, war-

ranties, and guarantees. Contracts may be used to transfer liability for specified

risks to another party. Use of a fixed-price contract may transfer risk to the seller

if the project’s design is stable. Although a cost-reimbursable contract leaves more

of the risk with the customer or sponsor, it may help reduce cost if there are mid-

project changes.

.

3

Mitigation.

Mitigation seeks to reduce the probability and/or consequences of an

adverse risk event to an acceptable threshold. Taking early action to reduce the

probability of a risk’s occurring or its impact on the project is more effective than

trying to repair the consequences after it has occurred. Mitigation costs should

be appropriate, given the likely probability of the risk and its consequences.

that will reduce the problem—e.g., adopting less complex processes, conducting

more seismic or engineering tests, or choosing a more stable seller. It may involve

changing conditions so that the probability of the risk occurring is reduced—e.g.,

adding resources or time to the schedule. It may require prototype development

to reduce the risk of scaling up from a bench-scale model.

Where it is not possible to reduce probability, a mitigation response might

address the risk impact by targeting linkages that determine the severity. For

example, designing redundancy into a subsystem may reduce the impact that

results from a failure of the original component.

.

4

Acceptance.

This technique indicates that the project team has decided not to

change the project plan to deal with a risk or is unable to identify any other suit-

able response strategy. Active acceptance may include developing a contingency

plan to execute, should a risk occur. Passive acceptance requires no action,

leaving the project team to deal with the risks as they occur.

A  contingency plan  is applied to identified risks that arise during the project.

Developing a contingency plan in advance can greatly reduce the cost of an

action should the risk occur. Risk triggers, such as missing intermediate mile-

stones, should be defined and tracked. A  fallback plan  is developed if the risk has

a high impact, or if the selected strategy may not be fully effective. This might

include allocation of a contingency amount, development of alternative options,

or changing project scope.

The most usual risk acceptance response is to establish a  contingency allowance ,

or reserve, including amounts of time, money, or resources to account for known

risks. The allowance should be determined by the impacts, computed at an accept-

able level of risk exposure, for the risks that have been accepted.

11.5.3  Outputs from Risk Response Planning

.

1

Risk response plan.

The risk response plan (sometimes called the  risk register )

should be written to the level of detail at which the actions will be taken. It

should include some or all of the following:

ٱ

Identified risks, their descriptions, the area(s) of the project (e.g., WBS element)

affected, their causes, and how they may affect project objectives.

ٱ

Risk owners and assigned responsibilities.

ٱ

Results from the qualitative and quantitative risk analysis processes.

ٱ

Agreed responses including avoidance, transference, mitigation, or acceptance

for each risk in the risk response plan.

ٱ

The level of residual risk expected to be remaining after the strategy is imple-

mented.

ٱ

Specific actions to implement the chosen response strategy.

ٱ

Budget and times for responses.

ٱ

Contingency plans and fallback plans.

.

2

Residual risks.

Residual risks are those that remain after avoidance, transfer, or

mitigation responses have been taken. They also include minor risks that have

been accepted and addressed, e.g., by adding contingency amounts to the cost or

time allowable.

.

3

Secondary risks.

Risks that arise as a direct result of implementing a risk

response are termed  secondary risks . These should be identified and responses

planned

each party’s responsibility for specific risks, should they occur, and for insurance,

services, and other items as appropriate to avoid or mitigate threats.

.

5

Contingency reserve amounts needed.

The probabilistic analysis of the project

(11.4.3.2) and the risk thresholds (11.1.3.1) help the project manager determine

the amount of buffer or contingency needed to reduce the risk of overruns of

project objectives to a level acceptable to the organization.

.

6

Inputs to other processes.

Most responses to risk involve expenditure of addi-

tional time, cost, or resources and require changes to the project plan. Organi-

zations require assurance that spending is justified for the level of risk reduction.

Alternative strategies must be fed back into the appropriate processes in other

knowledge areas.

.

7

Inputs to a revised project plan.

The results of the response planning process must

be incorporated into the project plan, to ensure that agreed actions are imple-

mented and monitored as part of the ongoing project.

11.6  RISK MONITORING AND CONTROL

Risk monitoring and control is the process of keeping track of the identified risks,

monitoring residual risks and identifying new risks, ensuring the execution of risk

plans, and evaluating their effectiveness in reducing risk. Risk monitoring and

control records risk metrics that are associated with implementing contingency

plans. Risk monitoring and control is an ongoing process for the life of the

project. The risks change as the project matures, new risks develop, or antici-

pated risks disappear.

Good risk monitoring and control processes provide information that assists

with making effective decisions in advance of the risk’s occurring. Communica-

tion to all project stakeholders is needed to assess periodically the acceptability

of the level of risk on the project.

The purpose of risk monitoring is to determine if:

ٱ

Risk responses have been implemented as planned.

ٱ

Risk response actions are as effective as expected, or if new responses should

be developed.

ٱ

Project assumptions are still valid.

ٱ

Risk exposure has changed from its prior state, with analysis of trends.

ٱ

A risk trigger has occurred.

ٱ

Proper policies and procedures are followed.

ٱ

Risks have occurred or arisen that were not previously identified.

Risk control may involve choosing alternative strategies, implementing a con-

tingency plan, taking corrective action, or replanning the project. The risk

response owner should report periodically to the project manager and the risk

team leader on the effectiveness of the plan, any unanticipated effects, and any

mid-course correction needed to mitigate the risk. 

11.6.1  Inputs to Risk Monitoring and Control

.

1

Risk management plan.

The risk management plan is described in Section 11.1.3.

.

2

Risk response plan.

The risk response plan is described in Section 11.5.3.1.

.

3

Project communication.

Work results and other project records described in Sec-

tion 10.3.1 provide information about project performance and risks. Reports

commonly used to monitor and control risks include  Issues Logs ,  Action-Item Lists ,

Jeopardy Warnings , or  Escalation Notices .

.

4

Additional risk identification and analysis.

As project performance is measured and

reported, potential risks not previously identified may surface. The cycle of the six

risk processes should be implemented for these risks.

.

5

Scope changes.

Scope changes often require new risk analysis and response

plans. Scope changes are described in Section 5.5.3.1.

11.6.2  Tools and Techniques for Risk Monitoring and Control

.

1

Project risk response audits.

Risk auditors examine and document the effective-

ness of the risk response in avoiding, transferring, or mitigating risk occurrence

as well as the effectiveness of the risk owner. Risk audits are performed during

the project life cycle to control risk.

.

2

Periodic project risk reviews.

Project risk reviews should be regularly scheduled.

Project risk should be an agenda item at all team meetings. Risk ratings and pri-

oritization may change during the life of the project. Any changes may require

additional qualitative or quantitative analysis.

.

3

Earned value analysis.

Earned value is used for monitoring overall project per-

formance against a baseline plan. Results from an earned value analysis may

indicate potential deviation of the project at completion from cost and schedule

targets. When a project deviates significantly from the baseline, updated risk

identification and analysis should be performed. Earned value analysis is

described in Section 10.3.2.4.

.

4

Technical performance measurement.

Technical performance measurement com-

pares technical accomplishments during project execution to the project plan’s

schedule of technical achievement. Deviation, such as not demonstrating func-

tionality as planned at a milestone, can imply a risk to achieving the project’s scope.

.

5

Additional risk response planning.

If a risk emerges that was not anticipated in the

risk response plan, or its impact on objectives is greater than expected, the

planned response may not be adequate. It will be necessary to perform additional

response planning to control the risk. 

11.6.3  Outputs from Risk Monitoring and Control

.

1

Workaround plans.

Workarounds are unplanned responses to emerging risks that

were previously unidentified or accepted. Workarounds must be properly docu-

mented and incorporated into the project plan and risk response plan.

.

2

Corrective action.

Corrective action consists of performing the contingency plan

or workaround.

.

3

Project change requests.

Implementing contingency plans or workarounds fre-

quently results in a requirement to change the project plan to respond to risks.

The result is issuance of a change request that is managed by integrated change

control, as described in Section 4.3.

.

4

Updates to the risk response plan.

Risks may occur or not. Risks that do occur

should be documented and evaluated. Implementation of risk controls may

reduce the impact or probability of identified risks. Risk rankings must be

reassessed so that new, important risks may be properly controlled. Risks that do

not occur should be documented and closed in the risk response plan.

.

5

Risk database.

A repository that provides for collection, maintenance, and

analysis of data gathered and used in the risk management processes. Use of this

database will assist risk management throughout the organization and, over

time, form the basis of a risk lessons learned program.

.

6

Updates to risk identification checklists.

Checklists updated from experience will

help risk management of future projects. 

Read More

Bab 2 Proyek Perencanaan

Dua dari makalah ini diringkas dengan metode manajemen proyek. Pertama, berjudul sistem manajemen proyek, muncul dalam jurnal informasi dan manajemen. Berikutnya, berjudul mengelola proyek pengembangan perangkat lunak untuk produktivitas maksimum, muncul dalam transaksi pada rekayasa perangkat lunak. Karya ini kemudian diterbitkan ulang pada tahun 1988 di buku manajemen proyek rekayasa perangkat lunak, disunting oleh Richard Thayer. Makalah  pertama berkaitan dengan metode manajemen proyek secara umum, sementara yang kedua, agak lebih rinci, berurusan dengan manajemen proyek untuk proyek-proyek pengembangan perangkat lunak.

Makalah ini memperkenalkan dekomposisi manajemen proyek menjadi dua bagian terpisah namun berhubungan: Proyek perencanaan dan proyek eksekusi. Masing-masing bagian ini terdiri dari lima kegiatan. Perencanaan proyek terdiri dari:

1. subdivisi bekerja

2. Kuantifikasi

3. Sekuensing kerja

4. Penganggaran

5. Penjadwalan

Pelaksanaan proyek terdiri dari:

1. Akuntansi biaya

2. Pengerjaan pengukuran

3. Varians pelacakan dan perubahan kontrol

4. Evaluasi kinerja

5. Produktivitas pengukuran

Dalam bab ini kita memberikan ruang yang cukup untuk menjelaskan proyek kegiatan perencanaan dan bagaimana untuk menggunakan komputer desktop dengan buku disediakan oleh alat ini untuk melakukan proyek berencana. kemudian bab-bab ini kita membahas proyek eksekusi, yang dalam hal ini adalah bagian yang lebih mudah, dan bagaimana menggunakan ini untuk proyek desktop dengan alat kendali.

Dalam bab ini, suatu definisi ringkas atau keterangan masing-masing dari lima kegiatan perencanaan proyek diberikan. Juga termasuk adalah sebuah diskusi tentang alasan untuk kegiatan ini, disajikan dalam kerangka praktek bisnis. Praktek-praktek ini telah terbukti penting dalam aplikasi yang konsisten dari metode manajemen proyek modern dan membangun kredibilitas antara seorang manajer proyek dan manajer proyek klien(dengan). Mereka ada untuk memastikan bahwa tim manajemen proyek memahami tujuan klien, tanggung jawab mereka, dan kebutuhan untuk konsisten dan terus perencanaan dan kontrol. Selain itu, aplikasi mereka konsisten memastikan bahwa hasil metode yang terkandung dalam praktek-praktek berulang.

2.1-  subdivisi dari karya penting

 ide di balik proyek perencanaan adalah subdivisi dari karya menjadi potongan-potongan dikelola. Potongan-potongan ini disebut pekerjaan paket. Untuk alasan ini, subdivisi dari karya ini sering disebut sebagai 'Kemasan pekerjaan.' Pekerjaan paket adalah elemen dari pekerjaan yang cukup kecil bahwa tanggung jawab untuk melakukan mereka dapat ditugaskan untuk seorang individu. Ini tidak berarti individu yang benar-benar melakukan semua pekerjaan paket kerja. Memang, orang yang bertanggung jawab untuk paket kerja mungkin seorang manajer yang memberikan pekerjaan kepada orang lain. Tapi fakta bahwa masing-masing paket kerja memiliki seorang individu yang tanggung jawab hasperformance adalah sebuah konsep yang mendasar dalam manajemen proyek.

Setiap paket kerja secara individual diperkirakan dan dijadwalkan. Khususnya bagaimana hal ini dilakukan dijelaskan nanti dalam bab ini. Dalam bagian ini, itu sudah cukup untuk menganggap bahwa karena pekerjaan paket konseptual 'kecil', itu selalu mungkin untuk dengan mudah memperkirakan secara akurat berapa banyak waktu dan uang yang dibutuhkan untuk menyelesaikan setiap pekerjaan paket. Asumsi berguna yang lain, yang perlu dilaksanakan sebagai kebijakan, adalah bahwa masing-masing paket kerja pendek. Proyek selalu pelaporan periode. Periode pelaporan mungkin seminggu atau sebulan atau periode waktu nyaman lain yang berguna untuk suatu proyek tertentu. Pada akhir setiap periode pelaporan, status dari masing-masing paket kerja aktif dilaporkan, bersama dengan biaya yang sebenarnya dan tenaga kerja-jam dikeluarkan untuk tanggal pada paket. Asumsi bahwa paket kerja durasi pendek berarti bahwa itu mencakup paling sedikit pelaporan periode.

Total biaya proyek di setiap titik waktu dan status proyek berasal dari pengeluaran dan status informasi untuk setiap paket kerja. Khususnya bagaimana hal ini dilakukan dijelaskan dalam bab 3. Subdivisi pekerjaan penting dalam manajemen proyek karena itu memfasilitasi pengelolaan pekerjaan, itu memfasilitasi perkiraan jumlah dan biaya pekerjaan, dan menyediakan sarana untuk menghitung biaya dan status proyek pada setiap titik dalam waktu. Ada metode khusus untuk tiba di apa yang harus paket kerja. Daripada membagi pekerjaan menjadi tugas individu yang akan ditampilkan dalam jadwal proyek dan kemudian mengumpulkan tugas bersama-sama ke dalam paket seperti yang dianjurkan oleh beberapa, kami memilih untuk melanjutkan dalam mode 'top-down'. Pendekatan top-down ini mencerminkan cara kerja secara keseluruhan akan melanjutkan. Biasanya, ada cara yang khusus pekerjaan dilakukan pada sebuah proyek. Misalnya, jika proyek terdiri dari membangun sebuah bangunan bertingkat sepuluh,

Untuk memudahkan kita berpikir tentang manajemen proyek, kita sekarang memperkenalkan sebuah proyek contoh yang telah dirancang untuk menjadi sangat sederhana. Kami akan menggunakan proyek contoh ini dalam apa yang berikut untuk menjelaskan konsep-konsep manajemen proyek dan bagaimana menggunakan alat bantu manajemen proyek yang dilengkapi dengan buku ini. Proyek contoh ini tidak dimaksudkan untuk menjadi sepenuhnya realistis; Sebaliknya, ini dirancang untuk menjadi sederhana, namun cukup realistis akan berguna. Proyek contoh adalah cara membangun sebuah kecil, 5.000 meter persegi bangunan.

Dalam rangka membangun bangunan ini, maka akan diperlukan pertama untuk membangun sebuah dasar, kemudian membangun struktur, dan akhirnya untuk menginstal sistem pipa, sistem listrik dan sistem pemanas dan AC. Akibatnya, kita pertama membagi proyek ke tiga subkomponen yang akan kita sebut komponen dasar, struktur komponen dan komponen sistem. Pada kenyataannya, kami memperkenalkan beberapa terminologi baru untuk membedakan komponen pembagian kami. Kita sebut komponen ini paket kontrol, sebagai lawan dari pekerjaan paket. Alasan untuk ini adalah bahwa mereka terlalu besar untuk disebut pekerjaan paket; Namun mereka adalah bermakna komponen kedua konseptual dan, kemudian, pengendalian proyek. Jadi kita akan memiliki kontrol paket yang akan kita sebut sebagai 'Foundation,' 'Struktur', dan 'Sistem.' Kami dapat mewakili ini hirarki seperti yang ditunjukkan dalam gambar 2-1.

Perhatikan bahwa posisi hirarki paket kontrol ini diberi label 1, 2, dan 3. Perhatikan juga bahwa kita memperlakukan seluruh proyek sebagai paket kontrol, yang berada pada posisi hirarki '0.' Kita diberi nama untuk proyek 'top-level' atau total paket kontrol, yaitu 'contoh proyek.' Ini adat ke label kontrol paket dengan cara ini. Selanjutnya kita membagi paket kontrol ini lebih lanjut. Sebagai contoh, kita membagi Yayasan kontrol paket ke empat paket baru bahwa kami label 1.1, 1.2, 1.3 dan 1.4. Ini adalah cara yang sama bahwa bagian dalam dokumen yang sering diberi label. Label ini disebut paket pengidentifikasi atau paket id. Mereka digunakan untuk menunjukkan bagaimana konten kerja diungkapkan dalam banyak cara yang sama yang bagian dalam sebuah buku yang menunjukkan bagaimana isi buku diungkapkan. Melanjutkan pembagian kami pengendalian paket, kami membagi kontrol paket 1 (Foundation) ke dalam paket ini:

1.1 situs persiapan

1.2 bentuk instalasi Penghapusan

1.3 Rebar, Mesh, Jangkar beton

1.4 Beton dituangkan dan diselesaikan sedemikian rupa,

Kami membagi kontrol paket 2 ke dalam paket ini:

2.1 Framing dan Misc. Pertukangan

2.2 Sheetrock Tape, tidur, dan Float

 2.3 atap

2.4 lukisan

Dan kita membagi kontrol paket 3 ke dalam paket ini:

3.1 pipa

3.2 listrik

3.3 HVAC (pemanasan, ventilasi, dan AC)

Pengurai ini halus konten kerja yang ditunjukkan dalam gambar 2-2. Untuk menjaga contoh kecil, weassume bahwa kami sekarang memiliki didekomposisi pekerjaan cukup jauh untuk kebutuhan perencanaan proyek dan kontrol. Dengan kata lain, kami percaya bahwa paket terbaru ini cukup kecil untuk dapat pekerjaan paket. Kita bisa menyimpulkan memiliki tingkat tambahan paket kontrol antara paket top-level kontrol dan pekerjaan paket, tapi demi kesederhanaan, proyek contoh berhenti di sini. Dalam apa yang berikut kita akan mengacu ke salah satu paket-paket ini sebagai kontrol paket tetapi hanya tingkat terendah paket (misalnya, 1.1, 1.2, 1.3) sebagai pekerjaan paket. Struktur paket kontrol yang telah kita hanya dijelaskan untuk proyek contoh dirujuk sebagai struktur rincian kerja atau hanya WBS, untuk proyek. Diagram hierarki dalam gambar 2-2 merupakan contoh WBS.

Ada subdivisi lain bermakna pekerjaan selain struktur rincian kerja. Membagi pekerjaan oleh disiplin (kerajinan) mungkin berguna untuk mendukung pelaporan tenaga kerja bulanan; Misalnya, listrik atau tukang kayu atau batu kegiatan bisa dikelompokkan bersama-sama. Hal ini sering diperlukan untuk memiliki pekerjaan dibagi oleh struktur organisasi (misalnya, melalui Divisi, Departemen, atau bagian). Subdivisi organisasi sangat umum yang sering giventhe nama organisasi kerusakan struktur atau OBS.

Hal ini juga praktek standar untuk membagi pekerjaan oleh biaya kode untuk mendukung akuntansi biaya dan kode buku besar untuk mendukung akuntansi umum atau pajak bentuk persiapan. Pembagian tersebut sering disebut sebagai biaya kerusakan struktur. Akhirnya, di banyak industri, terutama mereka yang melakukan bisnis dengan pemerintah federal, pekerjaan mungkin perlu dipecah sepanjang lini produk, seperti berbagai subsistem sistem secara keseluruhan (misalnya, subsistem avionik dan sistem kontrol penerbangan pesawat). Pembagian tersebut disebut sebagai produk kerusakan struktur. Militer, seperti kita lihat dalam Bab 8, merujuk kepada struktur rincian produk ini sebagai struktur rincian kerja.

Apapun kebutuhan subdivisi tambahan pekerjaan, sangat penting bahwa mereka berhubungan dengan cara yang berarti untuk WB Cara kita berhubungan biaya kerusakan struktur WBS dijelaskan dalam bagian 2.5. Cara kita berhubungan OBS WBS adalah melalui hirarki kedua (atau alternatif). Ini dijelaskan dalam Bab 6. Hirarki OBS akan memiliki paket kerja yang sama sebagai WBS tetapi kontrol yang berbeda paket di atas tingkat paket kerja dalam hirarki OBS. Hal ini mungkin alasannya karena kami aturan yang bekerja paket akan cukup kecil untuk ditugaskan untuk satu orang. Karena setiap orang adalah anggota dari beberapa bagian atau Departemen atau divisi, paket kerja yang ditetapkan ke pengguna di unit organisasi tertentu akan dianggap menjadi milik paket kontrol yang mewakili unit organisasi ini dalam hirarki OBS diagram.S. Dalam proyek contoh kami akan mempertimbangkan tiga subdivisi berbeda. Selain WBS, akan ada rincian biaya berdasarkan kode General Ledger (GL) dan struktur organisasi rincian. Pembahasan dalam bagian dan bab berikut menunjukkan bagaimana subdivisi tambahan yang didukung dalam toolset proyek Modern yang dilengkapi dengan buku ini.

Ada satu hal lagi yang harus disebutkan tentang WBS. Bahkan jika klien membutuhkan bahwa WBS Nya menjadi struktur rincian produk atau OBS, kebijakan kami masih akan membagi pekerjaan dengan cara di mana dilakukan dan memanfaatkan alternatif hierarki pelaporan untuk menyediakan klien dengan nya diminta laporan. Membagi pekerjaan dengan cara itu benar-benar tercapai menyediakan manajemen proyek dan membantu Departemen dengan pengertian terbaik tentang bagaimana untuk mencapai tujuan proyek. Pentingnya membagi pekerjaan dengan cara yang akan benar-benar dilakukan tidak bisa terlalu ditekankan. Jika WBS tidak mencerminkan cara di mana pekerjaan akan benar-benar dilakukan, WBS tidak benar-benar berguna untuk manajer proyek sebagai komunikasi dan mekanisme kontrol.

alternatif Tinjauan proyek yang bermakna untuk organisasi yang berbeda. Setiap dari hirarki pelaporan ini akan memiliki serangkaian pekerjaan paket yang sama. Mereka akan berbeda hanya dengan cara kontrol paket diatas pekerjaan paket yang terorganisasi. Perlu dicatat bahwa tidak semua hierarki pelaporan ini alternatif akan memiliki jumlah tingkat yang sama. WBS adalah sering diharapkan memiliki tingkat lebih daripada OBS, tapi ada pengecualian untuk aturan ini. Akhirnya, perlu dicatat bahwa, bahkan dalam WBS, masing-masing cabang WBS tidak boleh diharapkan untuk memiliki jumlah tingkat yang sama. Beberapa bagian dari karya secara alami dapat diharapkan untuk menjadi lebih rumit daripada bagian lain, dan ini mungkin digambarkan dalam WBS oleh cabang dengan timpang jumlah tingkat kontrol paket sebelum pekerjaan paket ditemui.

Dengan mengakomodasi beberapa sub-pembagian pekerjaan ( misalnya, yang obs ) melalui beberapa hierarchies, yang secara kolektif akan disebut sebagai melaporkan hierarchies, alat desktop ini memungkinkan sebuah proyek untuk menyediakan seluruh komponen sebuah organisasi dengan laporan tentang proyek yang bermakna bagi mereka. Pada dasarnya, melaporkan hierarchies memberikan alternatif ini.

2.2 Kuantifikasi pekerjaan

Langkah berikutnya setelah membagi pekerjaan adalah kuantifikasi pekerjaan. Kuantifikasi pekerjaan terdiri dari menetapkan satuan ukuran yang sesuai untuk setiap paket kontrol dan kemudian menugaskan kuantitas untuk pekerjaan isi dari paket yang quantifies jumlah pekerjaan dalam paket dalam unit ukuran. Cara ini dilakukan memerlukan beberapa penjelasan. Kami pertama membahas bagaimana hal ini dilakukan untuk pekerjaan paket. Isi paket kerja kerja terbagi menjadi tugas atau kegiatan. Syarat tugas dan kegiatan yang dipertukarkan dalam buku ini. Tugas-tugas individu ini adalah hal yang akhirnya dijadwalkan, biasanya dengan paket perangkat lunak penjadwalan otomatis. Hal ini menghasilkan tanggal mulai dan tanggal akhir untuk setiap tugas. Tapi ini tidak menjadi perhatian kami pada saat ini. Yang penting untuk memahami sekarang adalah bahwa setiap tugas yang perlu diberikan satuan ukuran.

Ini adalah tanggung jawab manajer paket pekerjaan untuk membagi pekerjaan paket yang dia atau dia yang bertanggung jawab dalam tugas-tugas yang sesuai. Hal ini juga tanggung jawab manajer ini untuk mengukur dan memperkirakan tugas ini. Kira paket kerja manager untuk '' siteprep' paket kerja, setelah pertimbangan hati-hati dan mungkin konsultasi dengan orang-orang yang benar-benar akan melakukan pekerjaan, memutuskan untuk membagi paket kerja ke empat tugas, mengatakan:

Tugas 1: membersihkan dan grub situs

Tugas 2: menghapus kelebihan bumi

 tugas 3: kelas

Tugas 4:menggali situs untuk yayasan

Satuan ukuran untuk tugas 1 mungkin 'kaki persegi,' karena situs yang harus dipersiapkan untuk struktur cenderung diukur dalam kaki persegi. Di sisi lain, satuan ukuran untuk tugas 2 mungkin 'kubik meter,' karena ' earthmovers ' biasanya memperkirakan jumlah bumi dihapus kubik meter dari bumi. Di sisi lain, jika proyek-proyek pengembangan perangkat lunak komputer dan aktivitas adalah untuk menulis sebuah program komputer, satuan ukuran mungkin 'sumber garis kode.' jika aktivitas menulis sebuah bab dari sebuah buku, satuan ukuran mungkin 'halaman.' manajer proyek pertama kali sering dihadapkan dengan klaim dari beberapa anggota tim proyek kepada siapa tugas yang telah ditetapkan bahwa jenis pekerjaan belum pernah dilakukan sebelumnya dan sehingga tidak ada dikenal satuan ukuran untuk tugas ini.hal ini sering terjadi pada proyek-proyek penelitian atau pengembangan. Sementara ini tidak pernah benar-benar kasus, hal ini sering lebih mudah bagi manajer proyek untuk hanya menetapkan tugas ini satuan ukuran yang disebut setiap (disingkat 'ea'), daripada berdebat tentang hal itu. Kemudian kuantitas 1 dapat ditugaskan untuk tugas di ea satuan ukuran. Ini berarti bahwa tugas ini dianggap sebagai satu unit.

Efek pada keseluruhan proyek untuk melakukan hal ini kadang-kadang  biasanya tidak besar, karena pekerjaan paket diasumsikan pendek dan, oleh karena itu, sehingga adalah tugas. Tapi, seperti pembaca akan lihat dalam bab 3, menetapkan satuan ukuran ea akan membatasi pilihan untuk menggunakan manajer paket kerja untuk mengambil kredit parsial untuk pengerjaan laporan berkala status. Ini dapat menyebabkan pemimpin tugas untuk tidak muncul untuk membuat kemajuan sampai tugas selesai. Hal ini biasanya menyebabkan tugas para pemimpin untuk berharap mereka akan mengambil waktu untuk mengukur tugas-tugas mereka dengan benar di tempat pertama. Untuk project manager, hal ini tidak masalah. Kebanyakan manajer proyek lebih memilih pendekatan konservatif untuk mengklaim kredit untuk bekerja di kemajuan, bagaimanapun, dan menetapkan tugas unit ukuran ea sangat konservatif. Pemimpin tugas tidak mendapatkan kredit untuk setiap tugas sampai benar-benar selesai ketika satuan ukuran ea.

Manajer proyek yang berpengalaman memiliki jenis kuantifikasi seragam pada proyek mereka untuk mempertahankan kemajuan konservatif pengukuran. Tapi kami anggap ekstrem ukuran yang harus dihindari. Alasannya adalah bahwa biaya lebih baik dan tenaga kerja perkiraan dapat dibuat jika pekerjaan paket diukur bermakna. Pepatah lama antara manajer proyek dan biaya penduga adalah: 'jika pekerjaan tidak dapat diukur, itu tidak dapat diperkirakan.' hal ini penting bagi anggota tim proyek untuk memahami hal ini dan melakukan yang terbaik untuk menghasilkan kuantifikasi bermakna.

Setelah setiap tugas dalam paket kerja telah diukur, paket kerja itu sendiri perlu dapat diukur. Sekali lagi, tanggung jawab kuantifikasi paket kerja yang bersandar dengan manajer paket kerja. Dan lagi, kuantifikasi paket pekerjaan melibatkan memilih unit sesuai ukuran untuk paket dan jumlah yang sesuai untuk paket dinyatakan dalam satuan ukuran ini. Sering, itu adalah kasus bahwa satuan ukuran paket kerja adalah sama dengan satuan ukuran untuk salah satu tugas dalam paket kerja. Sebagai contoh, siteprep kerja paket dalam proyek contoh, seperti yang kita lihat dalam bagian 2.3.3, memiliki tugas 1 dan 3 dengan satuan ukuran square feet (sf) dan tugas 2 dan 4 dengan satuan ukuran kubik meter (cy). Kita juga akan melihat di bagian 2.3.3 satuan ukuran yang dipilih untuk siteprep kerja paket yang sf, daripada cy atau beberapa ukuran.

Hal ini mencerminkan keyakinan manajer paket kerja yang kuantifikasi paket pekerjaan siteprep yang terbaik dilakukan melalui sf, dibandingkan dengan cy atau beberapa ukuran. Dalam kasus seperti ini, kadang-kadang dikatakan bahwa di antara unit-unit ukuran untuk tugas-tugas, sf adalah dominan satuan ukuran, karena menentukan satuan ukuran untuk paket. Tidak seperti kuantifikasi pekerjaan paket, kuantifikasi kontrol paket di atas tingkat paket kerja adalah tanggung jawab manajer proyek. Kuantifikasi pada tingkat ini tidak mempengaruhi langkah-langkah kemajuan dan kinerja yang didasarkan pada informasi status di tingkat paket kerja. Meskipun demikian, penting bahwa manajer proyek atau manajer proyek staf memilih bermakna quantifications untuk paket ringkasan tingkat kontrol. Hal ini memungkinkan orang-orang yang membaca laporan untuk langkah-langkah kemajuan di tingkat ringkasan berkaitan dengan sesuatu yang bermakna secara intuitif.

Misalnya, kita akan melihat dalam wbs daftar laporan (gambar 2-6) bahwa satuan ukuran untuk ringkasan tingkat 'foundation' kontrol paket adalah cy (dari beton). Jika laporan kemajuan menunjukkan paket kontrol ini 50% selesai, pembaca laporan dapat berhubungan ini untuk 290 cy dari beton kuantifikasi untuk paket dan membayangkan bahwa sekitar 145 meter kubik beton telah menuangkan sejauh.

2.3 menggunakan modern proyek

Membuat wbs sebelum pindah ke sebuah diskusi tentang sequencing pekerjaan, kita pertama membahas bagaimana untuk memasuki struktur rincian kerja database proyek. Toolset desktop yang disebut proyek modern juga disertakan dengan buku ini. Untuk menjalankan alat-alat yang tersedia di toolset ini, sangatlah penting bagi anda untuk memiliki microsoft akses 97, atau versi yang lebih baru, seperti access 2000, diinstal pada komputer anda. Proyek modern adalah alat bantu belajar yang dimaksudkan untuk menunjukkan bagaimana seperangkat alat desktop dapat mendukung teknik manajemen proyek yang dibahas dalam buku ini. Proyek modern telah diuji pada proyek contoh yang dijelaskan dalam buku tetapi tidak telah mengalami pengujian lengkap. Tidak penulis atau penerbit mengambil tanggung jawab untuk pengoperasian yang benar dari toolset ini. Hal ini dimaksudkan untuk menjadi berguna pada proyek-proyek yang digunakan, tetapi pembaca harus memahami bahwa itu adalah untuk risiko sendiri.

Ada file pada media elektronik yang disediakan dengan buku yang anda butuhkan untuk menyalin ke salah satu drive disk anda. Jika anda menggunakan akses 97, maka file adalah satu bernama example97.mde. Jika anda menggunakan access 2000, maka file adalah satu bernama example2k.mde. Untuk kesederhanaan, kita hanya akan menggunakan nama file example.mde dalam apa yang berikut bukan berulang kali membedakan antara keduanya. Example.mde adalah database yang akhirnya akan berisi data proyek contoh yang akan digunakan di seluruh buku untuk menggambarkan konsep-konsep manajemen proyek dan penggunaan modern projectafter anda telah menyelamatkan file example.mde ke drive disk anda, anda mungkin perlu mengubah atribut hanya membaca. Misalnya, jika anda menggunakan microsoft windows explorer untuk menyalin file dari cd ke drive disk anda, ini akan menetapkan atribut hanya baca untuk 'benar' karena cd yang disertakan dengan buku adalah membaca hanya menengah. Ini akan mencegah anda dari memasuki setiap data ke contoh database sampai anda mengubah membaca hanya atribut  ' palsu. '

Untuk mengubah atribut hanya baca ke false, pertama kali membuka file dengan microsoft access. Sebuah jendela akan muncul yang terlihat seperti gambar 2-3. Sekarang klik pada tombol kontrol file, dan pilih pilihan database properties dengan mengklik pada opsi entri dalam menu file yang jatuh. Ini akan menyebabkan jendela properties untuk muncul. Pastikan jendela properties menampilkan umum (properti) dengan atribut: menampilkan di bagian bawah jendela. Jika tidak, klik pada tab umum di bagian atas jendela properties.

Sekarang lihat pada atribut ' hanya membaca '. Jika memiliki tanda centang di kotak di depan itu, klik pada kotak untuk menghapus tanda centang. Jika ada tidak ada tanda centang di kotak atribut hanya baca, tidak ada yang berubah. Berikutnya, klik pada tombol ok kontrol di bagian bawah jendela properties. Anda sekarang harus mampu menulis data ke dalam database contoh. Anda akan mulai belajar bagaimana melakukan hal ini segera.

Jika anda tidak memiliki microsoft akses 97 atau microsoft access 2000 yang diinstal pada komputer anda, itu tidak boleh mengganggu kemampuan anda untuk memahami metode manajemen proyek, filsafat, dan alat-alat yang dibahas dalam buku ini. Selama tiga dekade, banyak manajer proyek telah menggunakan metode-metode dan kebijakan secara manual, tanpa bantuan komputer. Pada proyek besar ini memerlukan staf yang cukup besar, tetapi telah dilakukan dan terus dilakukan.

Dikemas dalam example.mde adalah toolset proyek modern. Ketika anda membuka example.mde dengan microsoft access menu utama untuk proyek modern toolset akan ditampilkan seperti yang ditunjukkan dalam gambar 2-3. Dengan asumsi anda memiliki salah satu versi ini dari microsoft access tersedia pada komputer anda, mulai itu dan membuka database contoh (example.mde). Layar komputer anda sekarang harus terlihat seperti gambar 2-3.

Read More

Chapter 2— Project Planning

The author has described project management in a number of papers, talks, and classes during the past twenty years.

Two of these papers summarized the methods of project management. The first, titled Project

Management Systems, appeared in the Journal of Information and Management. The next, titled Managing Software Development Projects for Maximum Productivity, appeared in Transactions on Software Engineering. The later paper was republished in 1988 in the book Software Engineering Project Management, edited by Richard Thayer. The first paper deals with project management methods in general, while the second, which is somewhat more detailed, deals with project management for software development projects.

Those papers introduced a decomposition of project management into two separate but related parts: project planning and project execution. Each of these parts consists of five activities. Project planning consists of:

1. Subdivision of work

2. Quantification

3. Sequencing of work

4. Budgeting

5. Scheduling

Project execution consists of:

1. Cost accounting

2. Progress measurement

3. Variance tracking and change control

4. Performance evaluation

5. Productivity measurement

In this chapter we devote considerable space to explaining the activities of project planning and how to use the desktop computer tools provided with this book to do project planning. In later chapters we discuss project execution, which in a way is the easier part, and how to use these desktop tools for project control.

In this chapter, a concise definition or description of each of the five activities of project planning is given. Also included is a discussion of the rationale for these activities, presented within the framework of business practices. These practices have proven essential in the consistent application of the methods of modern project management and in the establishing of credibility between a project manager and the project manager's client(s). They exist to ensure that the project management team understands the client's objectives, their responsibilities, and the need for consistent and continuing planning and control. Furthermore, their consistent application ensures that the results of the methods embodied in the practices are repeatable.

2.1— Subdivision of the Work

The essential idea behind project planning is the subdivision of the work into manageable pieces. These pieces are called work packages. For this reason, subdivision of the work is often referred to as "packaging the work." Work packages are elements of work that are small enough that the

responsibility for performing them can be assigned to a single individual. This does not mean that individual actually performs all the work of the work package. Indeed, the person responsible for a work package may be a manager who assigns the work to others. But the fact that each work package has a single individual who hasperformance responsibility is a fundamental concept in project management.

Each work package is individually estimated and scheduled. Specifically how this is done is

explained later in this chapter. In this section it suffices to assume that since the work packages are conceptually "small," it is always possible to easily estimate accurately how much time and money it will take to complete each work package. Another useful assumption, which needs to be enforced as a policy, is that each work package is of short duration. Projects always have reporting periods. The

reporting period may be a week or a month or any other convenient time period that is useful for a specific project. At the end of each reporting period, the status of each active work package is reported, together with the actual cost and labor-hours expended to date on the package. The assumption that a work package is of short duration means that it spans at most a few reporting periods.

The total cost of the project at any point in time and the status of the project are derived from the expenditure and status information for each work package. Specifically how this is done is explained in Chapter 3. The subdivision of the work is important in project management because it facilitates the management of the work, it facilitates the estimation of the amount and cost of the work, and it provides a means for calculating the cost and status of the project at any point in time. There is a specific method for arriving at what the work packages should be. Rather than dividing the work into the individual tasks that will appear in the project schedule and later gathering the tasks together into packages as advocated by some, we prefer to proceed in a "top-down" fashion. This top-down approach reflects the way the overall work will proceed. Usually, there is a specific way the work is conducted on a project. For example, if the project consists of building a ten-story building, one would not expect to begin building the tenth story first, before the foundation was laid and the lower nine stories were constructed.

In order to facilitate our thinking about project management, we now introduce an example project that has been devised to be extremely simple. We will use this example project in what follows to explain project management concepts and how to use the project management tools furnished with this book. This example project is not intended to be entirely realistic; rather, it was designed to be simple, yet realistic enough to be useful. The example project is to build a small, 5,000 square-foot building.

In order to build this building, it will be necessary first to construct a foundation, then to build the structure, and finally to install the plumbing system, the electrical system, and the heating and airconditioning system. Consequently, we first subdivide the project into three subcomponents that we will call the foundation component, the structure component, and the systems component. In fact, we introduce some new terminology here for distinguishing the components of our subdivision. We call these components control packages, as opposed to work packages. The reason for this is that they are too large to be work packages; yet they are meaningful components both conceptually and, later, for project control. So we will have control packages that we will refer to as "Foundation," "Structure," and "Systems." We can represent this hierarchically as shown in Figure 2-1.

Figure 2-1.

Subdivision of example project into control packages.

Notice that the hierarchy positions of these control packages are labeled 1, 2, and 3. Notice also that we are treating the whole project as a control package, which is at hierarchy position " 0." We have given a name to the "top-level" or total project control package, namely "Example Project." It is customary to label control packages this way.

Next we subdivide these control packages further. For example, we subdivide the Foundation

control package into four new packages that we label 1.1, 1.2, 1.3, and 1.4. This is the same way that sections in a document are often labeled. These labels are called the package identifiers or package IDs. They are used to show how the work content unfolds in much the same way that sections in a book show how the content of the book unfolds. Continuing our subdivision of these control packages, we subdivide control package 1 (Foundation) into these packages:

1.1 Site Preparation

1.2 Forms Installation & Removal

1.3 Rebar, Mesh, & Anchors

1.4 Concrete Pour, Cure, & Finish

Similarly, we subdivide control package 2 into these packages:

2.1 Framing & Misc. Carpentry

2.2 Sheetrock Tape, Bed, & Float

2.3 Roofing

2.4 Painting

And we subdivide control package 3 into these packages:

3.1 Plumbing

3.2 Electrical

3.3 HVAC (Heating, Ventilation, and Air-conditioning)

This finer decomposition of the work content is shown in Figure 2-2. For the purpose of keeping the example small, weassume that we have now decomposed the work far enough for the needs of project planning and control. In other words, we believe that these latest packages are small enough to be work packages. We could have had additional levels of control packages between the top-level control package and the work packages, but, for the sake of simplicity, the example project stops here. In what follows we will refer to any of these packages as control packages but to only the lowest-level packages (e.g., 1.1, 1.2, 1.3) as work packages. This structure of control packages we have just described for the example project is referred to as the Work Breakdown Structure or simply the WBS, for the project. The hierarchical diagram in Figure 2-2 represents the example WBS.

There are other meaningful subdivisions of the work besides the work breakdown structure.

Subdividing the work by discipline (craft) may be useful for supporting monthly labor reporting; for example, electrical or carpentry or masonry activities could be grouped together. It is often necessary to have the work subdivided by organizational structure (e.g., by division, department, or section). These organizational subdivisions are so common that they are often giventhe name Organizational Breakdown Structure or OBS.

It is also standard practice to subdivide the work by cost codes to support cost accounting and by general ledger codes to support general accounting or tax form preparation. Such subdivisions are often referred to as cost breakdown structures. Finally, in many industries, especially those that do business with the federal government, the work may need to be broken down along product lines, such as the various subsystems of an overall system (e.g., the avionics subsystem and the flight control system of an aircraft). Such subdivisions are referred to as product breakdown structures. The military, as we see in Chapter 8, refers to these product breakdown structures as work breakdown structures.

Whatever the need for these additional subdivisions of work, it is important that they be related in a meaningful way to the WBS. In the example project we will consider three different subdivisions. In addition to the WBS, there will be a cost breakdown based on General Ledger (GL) codes and an organizational breakdown structure. The discussion in the following sections and chapters shows how these additional subdivisions are supported in the Modern Project toolset provided with this book.

The way we relate the cost breakdown structure to the WBS is explained in Section 2.5. The way we relate the OBS to the WBS is via a second (or alternate) hierarchy. This is explained in Chapter 6. The OBS hierarchy will have the same work packages as the WBS but different control packages above the work package level in the OBS hierarchy. The reason this is possible is because of our rule that work packages be small enough to be assigned to a single person. Since each person is a member of some section or department or division, the work packages assigned to a person in a given organizational unit will be considered to belong to the control package that represents this organizational unit in the OBS hierarchy diagram.

Figure 2-2.

WBS for example project.

There is one more thing that should be mentioned about the WBS. Even if a client requires that his or her WBS be a product breakdown structure or an OBS, our policy will still be to subdivide the work in the manner in which it is to be done and to utilize alternate reporting hierarchies to provide the client with his or her required reports. Subdividing the work in the manner that it will actually be accomplished provides project management and assisting departments with the best understanding of how to accomplish the project's objectives. The importance of subdividing the work in the way it will actually be performed cannot be overemphasized. If the WBS does not reflect the way in which the work will actually be done, the WBS is not really useful to the project manager as a communications and control mechanism.

alternate views of the project that are meaningful to different organizations. Each of these reporting hierarchies will possess the same set of work packages. They will differ only in the way the control packages above the work packages are organized. It should be noted that not all of these alternate reporting hierarchies will have the same number of levels. A WBS is often expected to have more levels than an OBS, but there can be exceptions to this rule. Finally, it should be noted that, even within the WBS, each branch of the WBS should not be expected to have the same number of levels. Some parts of the work may naturally be expected to be more complicated than other parts, and this may be reflected in the WBS by branches with unequal numbers of levels of control packages before work packages are encountered.

By accommodating multiple subdivisions of the work (e.g., the OBS) via multiple hierarchies, which collectively will be referred to as reporting hierarchies, these desktop tools allow a project to provide all the components of an organization with reports about the project that are meaningful for them. Essentially, these alternate reporting hierarchies provide

2.2— Quantification of the Work

The next step after subdividing the work is quantification of the work. Quantification of the work consists of assigning an appropriate unit of measure to each control package and then assigning a quantity to the work content of the package that quantifies the amount of work in the package in terms of its unit of measure. The way this is done requires some explanation. We first discuss how it is done for work packages. The work content of a work package is further subdivided into tasks or activities. The terms task and activity are interchangeable in this book. These individual tasks are the things that are eventually scheduled, usually with an automated scheduling software package. This produces a start date and an end date for each task. But this is not our concern at the moment. The important thing to understand just now is that each task needs to be assigned a unit of measure.

It is the responsibility of the work package manager to subdivide the work packages for which he or she is responsible into appropriate tasks. It is also this manager's responsibility to quantify and estimate these tasks. Suppose the work package manager for the ''Siteprep" work package, after careful consideration and perhaps consultation with those who will actually perform the work, decides to subdivide the work package into four tasks, say:

Task 1: Clear and Grub the Site

Task 2: Remove Excess Earth

Task 3: Grade the Site

Task 4: Excavate for a Foundation

The unit of measure for Task 1 might be "square feet," since the site that is to be prepared for the structure is likely to be measured in square feet. On the other hand, the unit of measure for Task 2 might be "cubic yards," since earthmovers usually estimate the amount of earth to be removed in cubic yards of earth. On the other hand, if the project is a computer software development project and the activity is to write a computer program, the unit of measure might be "source lines of code." If the activity is to write a chapter of a book, the unit of measure might be "pages." First-time project managers are often faced with the claim from some member of the project team to whom a task has been assigned that this type of work has never been done before and so there is no known unit of measure for this task. This often happens on research or development projects. While this is never really the case, it is often easier for the project manager to just assign this task the unit of measure called each (abbreviated "EA"), rather than argue about it. Then a quantity of 1 can be assigned to the task in the EA unit of measure. This means that this task is considered as a single unit.

The effect on the overall project of doing this occasionally is not usually great, since work packages are assumed to be of short duration and, therefore, so are tasks. But, as the reader will see in Chapter 3, assigning a unit of measure of EA will curtail the options for a work package manager to take partial credit for work in progress on the periodic status reports. This can cause the task leader to appear not to be making progress until the task is completed. This usually leads task leaders to wish they had taken time to quantify their tasks correctly in the first place. For the project manager, this is not a problem. Most project managers prefer a conservative approach for claiming credit for work in progress, anyway, and assigning a task a unit of measure of EA is extremely conservative. Task leaders do not get credit for any task until it is completely finished when the unit of measure is EA.

Some experienced project managers force this type of quantification uniformly on their project to maintain a conservative progress measurement policy. But we consider this an extreme measure that should be avoided. The reason is that better cost and manpower estimates can be made if the work packages are quantified meaningfully. An old saying among project managers and cost estimators is: "If the work can't be quantified, it can't be estimated." It is important for project team members to understand this and to do their best to produce a meaningful quantification.

After each task in a work package has been quantified, the work package itself needs to be

quantified. Again, the responsibility for the quantification of a work package rests with the work package manager. And again, quantification of a work package involves selecting an appropriate unit of measure for the package and an appropriate quantity for the package expressed in this unit of measure. Often, it is the case that the unit of measure for a work package is the same as the unit of measure for one of the tasks within the work package.

For instance, the Siteprep work package in the example project, as we will see in Section 2.3.3, has Tasks 1 and 3 with a unit of measure of Square Feet (SF) and Tasks 2 and 4 with a unit of measure of Cubic Yards (CY). We will also see in Section 2.3.3 that the unit of measure chosen for the Siteprep work package is SF, rather than CY or some other measure.

This reflects the belief of the work package manager that quantifying the Siteprep work package is best done via SF, as opposed to CY or some other measure. In a case like this, it is sometimes said that among the units of measure for the tasks, SF is the dominant unit of measure, since it determines the unit of measure for the package.

Unlike quantification of work packages, quantification of control packages above the work package level is the responsibility of the project manager. Quantification at this level does not affect the progress and performance measures that are based on the status information at the work package level. Nonetheless, it is important that the project manager or the project manager's staff select meaningful quantifications for the summary level control packages. This enables those reading reports to relate the progress measures at summary levels to something intuitively meaningful.

For instance, we will see in the WBS Listing report (Figure 2-6) that the unit of measure for the summary level "Foundation" control package is CY (of concrete). If a progress report shows this control package is 50% complete, the reader of the report can relate this to the 290 CY of concrete quantification for the package and envision that about 145 cubic yards of concrete has been poured so far.

2.3 Using Modern Project© to Create a WBS

Before moving on to a discussion of sequencing the work, we first cover how to enter a work

breakdown structure into the project database. A desktop toolset called Modern Project is included with this book. In order to run the tools provided in this toolset, it is necessary for you to have Microsoft Access 97, or a later version, such as Access 2000, installed on your computer. Modern Project is a learning aid intended to demonstrate how a set of desktop tools can support the project management techniques covered in this book. Modern Project has been tested on the example project described in the book but has not been subjected to exhaustive testing. Neither the author nor the publisher takes any responsibility for the correct operation of this toolset. It is intended to be useful on projects on which it is used, but the reader must understand that it is to be used at his or her own risk.

There is a file on the electronic media provided with the book that you need to copy to one of your disk drives. If you are using Access 97, then the file is the one named example97.mde. If you are using Access 2000, then the file is the one named example2K.mde. For simplicity, we will just use the filename example.mde in what follows instead of repeatedly distinguishing between the two. Example.mde is a database that will eventually contain the example project data that will be used throughout the book to illustrate project management concepts and the use of Modern ProjectAfter you have saved the file example.mde to your disk drive, you may need to change the read only attribute. For instance, if you use Microsoft Windows Explorer to copy the file from the CD to your disk drive, it will set the read only attribute to "true" since the CD supplied with the book is a read only medium. This will prevent you from entering any data into the example database until you change the read only attribute to "false."

To change the read only attribute to false, first open the file with Microsoft Access. A window should appear that looks like Figure 2-3. Now click on the File control button, and select the Database Properties option by clicking on the option's entry in the File menu that dropped down. This will cause the Properties window to appear. Make sure the Properties window is displaying the General (properties) with Attributes: showing at the bottom of the window. If not, click on the General tab at the top of the Properties window.

Now look at the "read only" attribute. If it has a checkmark in the box in front of it, click on the box to remove the checkmark. If there is no checkmark in the read only attribute box, there is nothing to change. Next, click on the OK control button at the bottom of the Properties window. You should now be able to write data into the example database. You will begin learning how to do this shortly.

If you do not have either Microsoft Access 97 or Microsoft Access 2000 installed on your computer, it should not interfere with your ability to understand the project management methods, philosophy, and tools discussed in this book. During the past three decades, many project managers have used these methods and policies manually, without the aid of a computer. On large projects this requires a considerable staff, but it has been done and continues to be done.

Packaged within example.mde is the Modern Project toolset. When you open example.mde with Microsoft Access the Main Menu for the Modern Project toolset will be displayed as shown in Figure 2-3. Assuming you have one of these versions of Microsoft Access available on your computer, start it up and open the example database (example.mde). Your computer screen should now look like Figure 2-3.

Read More