Chapter One

Introduction to IT Project Management

Why you study IT PM?

 Failure of many IT Projects.

To see the importance of project management, specifically IT project management let’s have
a look on the following facts. According to some reports the United States Internal Revenue
System was to abandon its tax system modernization program after having spent $4 billion;
The state of California spent $1 billion on its non-functional welfare database system; The
€339 million United Kingdom air traffic control system was reported as being two years
behind schedule;

Though there are such interesting facts and figures that indicate how the field is growing
rapidly, there are large numbers of projects going to failure or terminating prematurely. For
example, there are documents indicating that in 1995 there were 16.2% IT projects which
were successful and 31% failed before completion costing over $81 billion in the US.

Beyond the above facts and figures, famous business authors and consultants are stressing the
importance of project management. That’s why IT project management is includes as basic
contents for the IT curriculum.

1.1.Importance of IT project management

What is a Project?

Organizations perform work. Work generally involves either operations or projects, although
the two may overlap. Operations and projects share many characteristics; for example, they
are:

 Performed by people
 Constrained by limited resources
 Planned, executed, and controlled
A project is a temporary endeavor undertaken to create a unique product or service. Projects
are often implemented as a means of achieving an organization’s strategic plan. Operations
and projects differ primarily in that operations are ongoing and repetitive while projects are
temporary and unique.

Temporary means that every project has a definite beginning and a definite end. Unique
means that the product or service is different in some distinguishing way from all other
products or services. For many organizations, projects are a means to respond to those
requests that cannot be addressed within the organization’s normal operational limits.

Projects are undertaken at all levels of the organization. They may involve a single person or
many thousands. Their duration ranges from a few weeks to more than five years. Projects
may involve a single unit of one organization or may cross organizational boundaries, as in
joint ventures and partnering. Projects are critical to the realization of the performing
organization’s business strategy because projects are a means by which strategy is
implemented. Examples of projects include:

 Developing a new product or service.

 Effecting a change in structure, staffing, or style of an organization.
 Designing a new transportation vehicle.
 Constructing a building or facility.
 Building a water system for a community in a developing country.
 Implementing a new business procedure or process.

Example of IT projects

 A new reservation system developed for airlines

 Development of new software or enhance existing systems to perform many business
functions as projects, etc.
Attributes of a project

a. Unique purpose: Projects involve doing something that has not been done before and
which is, therefore, unique. A product or service may be unique even if the category to
which it belongs is large. The presence of repetitive elements does not change the
fundamental uniqueness of the project work. Every project should have a well-defined
objective.
b. Temporary: means that every project has a definite beginning and a definite end. The
end is reached when the project’s objectives have been achieved, or when it becomes
clear that the project objectives will not or cannot be met, or the need for the project no
longer exists and the project is terminated. Temporary does not necessarily mean short in
duration; many projects last for several years. In every case, however, the duration of a
project is finite; projects are not ongoing efforts.

Projects are often defined broadly when they begin, and as time passes, the specific
details of the project become clearer. Therefore, projects should be developed in
increments. A project team should develop initial plans and then update them with more
detail based on new information. For example, suppose a few people submitted ideas for
the information technology collaboration project, but they did not clearly address how the
ideas would support the business strategy of improving operations. The project team
might decide to prepare a questionnaire for people to fill in as they submit their ideas to
improve the quality of the inputs.

The objectives of projects and operations are fundamentally different. The objective of a
project is to attain the objective and close the project. The objective of an operation is
normally to sustain the business. Projects are fundamentally different because the project
ceases when its declared objectives have been attained, while non-project undertakings
adopt a new set of objectives and continue to work.
The temporary nature of projects may apply to other aspects of the endeavor as well:

 The opportunity or market window is usually temporary—most projects have a limited

time frame in which to produce their product or service.
 The project team, as a team, seldom outlives the project—most projects are performed by
a team created for the sole purpose of performing the project, and the team is disbanded
when the project is complete.
c. A project requires resources, often from various areas: Resources include people,
hardware, software, and other assets. Many projects cross departmental or other
boundaries to achieve their unique purposes. For the information technology
collaboration project, people from information technology, marketing, sales, distribution,
and other areas of the company would need to work together to develop ideas. The
company might also hire outside consultants to provide input. Once the project team has
selected key projects for implementation, they will probably require additional resources.
And to meet new project objectives, people from other companies’ product suppliers and
consulting companies may be added. Resources are used effectively to meet project and
other corporate goals.
d. A project should have a primary customer or sponsor: Most projects have many
interested parties or stakeholders, but someone must take the primary role of sponsorship.
The project sponsor usually provides the direction and funding for the project. Once
further information technology projects are selected, however, the sponsors for those
projects would be senior managers in charge of the main parts of the company affected
by the projects. For example, if the vice president of sales initiates a project to improve
direct product sales using the Internet, he or she might be the project sponsor.
e. A project involves uncertainty: Because every project is unique, it is sometimes
difficult to define its objectives clearly, estimate how long it will take to complete, or
determine how much it will cost. External factors also cause uncertainty, such as a
supplier going out of business or a project team member needing unplanned time off.
This uncertainty is one of the main reasons project management is so challenging,
especially on projects involving new technologies.
 An effective project manager is crucial to a projects success. Project managers work
with the project sponsors, the project team, and the other people involved in a project to
meet project goals.

The Triple Constraint

To create a successful project, a project manager must consider scope, time, and cost and
balance these three often-competing goals. Every project is constrained in different ways by
its:

Scope: What work will be done as part of the project?

Time: How long should it take to complete the project?
Cost: What should it cost to complete the project? What is the project s budget?
It is the project manager’s duty to balance these three often competing goals.

Figure 1 the triple constraint

Causes of Project Management Failure

 Bad Communications
 Poor schedule or resource Management (mismanagement)
 Weak requirements definitions (leads to inadequate planning)
 Inadequate planning, assumptions, risks, or resources
 Use of new or unproven technologies/methods
 Ineffective (or nonexistent) quality controls
 Managing multiple projects at once or multi-tasking resources
 Scope creep or poor impact analysis
 Lack of qualified resources

What is Project Management?

Project management is the application of knowledge, skills, tools, and techniques to project
activities to meet project requirements. A more tangible description is that project
management is everything you need to make a project happen on time and within budget to
deliver the needed scope and quality. Project management is accomplished through the use of
the processes such as: initiating, planning, executing, controlling, and closing. The project
team manages the work of the projects, and the work typically involves:

 Competing demands for: scope, time, cost, risk, and quality.

 Stakeholders with differing needs and expectations.
 Identified requirements.

It is important to note that many of the processes within project management are iterative in
nature.

The term project management is sometimes used to describe an organizational approach to

the management of ongoing operations. This approach, more properly called management by
projects, treats many aspects of ongoing operations as projects to apply project management
techniques to them.
Using formal project management principles is advantageous for the following reasons:

 Better control of financial, physical, and human resources

 Improved customer relations
 Shorter development times
 Lower costs
 Higher quality and increased reliability
 Higher profit margins
 Improved productivity
 Better internal coordination
 Higher worker morale
1.2. The Stakeholder of a Project

Stakeholders are the people involved in or affected by project activities and include the
project sponsor, project manager, project team, users, suppliers, and even opponents of the
project. These stakeholders often have very different needs and expectations. For example,
building a new house is a well-known example of a project. There are several stakeholders
involved in a home construction project.

 The project sponsors would be the potential new homeowners. They would be the people
paying for the house and could be on a very tight budget, so they would expect the
contractor to provide accurate estimates of the costs involved in building the house. They
would also need a realistic idea of when they could move in and what type of home they
could afford given their budget constraints. The new homeowners would have to make
important decisions to keep the costs of the house within their budget. Can they afford to
finish the basement right away? If they can afford to finish the basement, will it affect the
projected move-in date? In this example, the project sponsors are also the users for the
product, which is the house.
 The project manager in this example would normally be the general contractor
responsible for building the house. He or she needs to work with all the project
stakeholders to meet their needs and expectations.
 The project team for building the house would include several construction workers,
electricians, carpenters, and so on. These stakeholders would need to know exactly what
work they must do and when they need to do it. They would need to know if the required
materials and equipment will be at the construction site or if they are expected to provide
the materials and equipment. Their work would need to be coordinated since there are
many interrelated factors involved. For example, the carpenter cannot put in kitchen
cabinets until the walls are completed.
 Building a house requires many suppliers. The suppliers would provide the wood,
windows, flooring materials, appliances, and so on. Suppliers would expect exact details
on what items they need to provide, where and when to deliver those items, and so on.
 There may or may not be opponents of a project. In this example, there might be a
neighbor who opposes the project because the workers are making so much noise that she
cannot concentrate on her work at home, or the noise might wake her sleeping children.

1.3. Project Management Framework

The following figure shows the tasks and activities done during managing a certain project as
well as the knowledge areas that any project manager needs to carry out his/ her task. The
picture starts from stakeholder needs and expectations. To make these needs and expectations
true there are various knowledge areas, tools and techniques applied for. And it is the whole
sum efforts of these integrated activities that lead the project to be successful.

Figure 2 project management framework

Knowledge areas describe the key competencies that project managers must develop

 4 core knowledge areas lead to specific project objectives (scope, time, cost, and quality)

 4 facilitating knowledge areas are the means through which the project objectives are
achieved (human resources, communication, risk, and procurement management)

 1 knowledge area (project integration management) affects and is affected by all of the
other knowledge areas.

1.4. Software Tools for Project Management

Project management tools and techniques assist project managers and their teams in various
aspects of project management. Some specific ones include

 Project Charter, scope statement and WBS (which assists in managing scope)

 Gantt charts, network diagrams, critical path analysis, (which assists in managing
time)

 Cost estimates and earned value management (which assists for cost management)
 Chapter Two

Project Planning
2.1. Integration Management

Project integration management includes the processes required to ensure that the various
elements of the project are properly coordinate. It involves making tradeoffs among
competing objectives and alternatives to meet or exceed stakeholders and expectations. It
consists of project plan development, project plan execution, and integrated change control.
Project integration management is the processes and activities needed to integrate the various
elements of project management, which are identified, defined, combined, unified, and
coordinated within the Project Management Process Groups.

2.1.1 Project Integration Management Processes

1. Project Plan Development: taking the results of other planning processes and putting
them into a consistent, coherent document—the project plan

2. Project Plan Execution: carrying out the project plan

3. Integrated Change Control: coordinating changes across the entire project

These processes interact with each other and with the processes in the other knowledge areas
as well. Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project. Each process generally occurs at least once in
every project phase. Project integration management comes into play when a cost estimate is
needed for a contingency plan, or when risks associated with various staffing alternatives
must be identified. However, for a project to be completed successfully, integration must also
occur in a number of other areas as well. For example:

 The work of the project must be integrated with the ongoing operations of the performing
organization.
 Product scope and project scope must be integrated.
2.1.2 Project Plan Development
Project plan development uses the outputs of the other planning processes, including strategic
planning, to create a consistent, coherent document that can be used to guide both project
execution and project control. This process is almost always iterated several times.

The project scope of work is an iterative process that is generally done by the project team
with the use of a Work Breakdown Structure (WBS), allowing the team to capture and then
decompose all of the work of the project. All of the defined work must be planned, estimated
and scheduled, and authorized with the use of detailed integrated management control plans
sometimes called Control Account Plans, or CAPs. The sum of all the integrated
management control plans will constitute the total project scope.

The project plan is used to:

 Guide project execution.

 Document project planning assumptions.
 Document project planning decisions regarding alternatives chosen.
 Facilitate communication among stakeholders.

Attributes of Project Plans

 Just as projects are unique, so are project plans

 Plans should be dynamic and flexible
 Plans should be updated as changes occur
 Plans should first and foremost guide project execution

Common Elements of a Project Plan

 Introduction or overview of the project
 Description of how the project is organized
 Management and technical processes used on the project
 Work to be done, schedule, and budget information
Outputs from Project Plan Development

The project plan is a formal, approved document used to manage project execution. The
project schedule lists planned dates for performing activities and meeting milestones
identified in the project plan. The project plan and schedule should be distributed as defined
in the communications management plan (e.g., management of the performing organization
may require broad coverage with little detail, while a contractor may require complete details
on a single subject). In some application areas, the term integrated project plan is used to
refer to this document. There are many ways to organize and present the project plan, but it
commonly includes all of the:

 Project charter.
 A description of the project management approach or strategy (a summary of the
individual management plans from the other knowledge areas).
 Scope statement, which includes the project objectives and the project deliverables.
 WBS to the level at which control will be exercised, as a baseline scope document.
 Cost estimates, scheduled start and finish dates (schedule), and responsibility assignments
for each deliverable within the WBS to the level at which control will be exercised.
 Performance measurement baselines for technical scope, schedule, and cost i.e., the
schedule baseline (project schedule) and the cost baseline (time phased project budget).
 Major milestones and target dates for each.
 Key or required staff and their expected cost and/or effort.
 Risk management plan, including: key risks, including constraints and assumptions, and
planned responses and contingencies (where appropriate) for each.
 Subsidiary management plans, namely:
 Scope management plan
 Schedule management plan
 Cost management plan
 Quality management plan
 Staffing management plan
 Communications management plan
  Risk response plan
 Procurement management plan

1. Project Plan Execution

 Project plan execution involves managing and performing the work described in the
project plan.
 The majority of time and money is usually spent on execution.
 The application area or the project directly affects project execution because the products
of the project are produced during execution.

Project plan execution is the primary process for carrying out the project plan the vast
majority of the project’s budget will be expended in performing this process. In this process,
the project manager and the project management team must coordinate and direct the various
technical and organizational interfaces that exist in the project. It is the project process that is
most directly affected by the project application area in that the product of the project is
actually created here. Performance against the project baseline must be continuously
monitored so that corrective actions can be taken based on actual performance against the
project plan. Periodic forecasts of the final cost and schedule results will be made to support
the analysis.

Important Skills for Project Execution

 General management skills like leadership, communication, and political skills
 Use of specialized tools and techniques

Tools and Techniques for Project Execution

 Work Authorization System: a method for ensuring that qualified people do work at the
right time and in the proper sequence.

 Status Review Meetings: regularly scheduled meetings used to exchange project

information.

 Project Management Software: special software to assist in managing projects.

2. Integrated Change Control

Integrated change control is concerned with

a) Influencing the factors that create changes to ensure that changes are agreed upon
b) Determining that a change has occurred, and
c) Managing the actual changes when and as they occur

The original defined project scope and the integrated performance baseline must be
maintained by continuously managing changes to the baseline, either by rejecting new
changes or by approving changes and incorporating them into a revised project baseline.
Integrated change control requires:

 Maintaining the integrity of the performance measurement baselines.

 Ensuring that changes to the product scope are reflected in the definition of the project
scope
 Coordinating changes across knowledge areas. For example, a proposed schedule change
will often affect cost, risk, quality, and staffing.

Change Control System

 A formal, documented process that describes when and how official project documents
and work may be changed.

 Describes who is authorized to make changes and how to make them.

 Often includes a Change Control Board (CCB), configuration management, and a process
for communicating changes.

Change Control Boards (CCBs)

 A formal group of people responsible for approving or rejecting changes on a project.

 Provides guidelines for preparing change requests, evaluates them, and manages the
implementation of approved changes.

 Includes stakeholders from the entire organization.

2.1 Scope Management

 Project Scope Management includes the processes required to ensure that the project
includes all the work required, and only the work required, to complete the project
successfully. It is primarily concerned with defining and controlling what is or is not
included in the project. Scope refers to all the work involved in creating the products of
the project and the processes used to create them.

 Project scope management includes the processes involved in defining and controlling
what is or is not included in the project.

 The project team and stakeholders must have the same understanding of what products
will be produced as a result of a project and what processes will be used in producing
them.

The major project scope management processes:

1. Initiation—authorizing the project or phase.

2. Scope Planning—developing a written scope statement as the basis for future project
decisions.
3. Scope Definition—subdividing the major project deliverables into smaller, more
manageable components.
4. Scope Verification—formalizing acceptance of the project scope.
5. Scope Change Control—controlling changes to project scope.

In the project context, the term scope may refer to:

 Product scope—the features and functions that characterize a product or service.

 Project scope—the work that must be done to deliver a product with the specified
features and functions.

Completion of the project scope is measured against the project plan, but completion of the
product scope is measured against the product requirements. Both types of scope
management must be well integrated to ensure that the work of the project will result in
delivery of the specified product.
1. Initiation
Initiation is the process of formally authorizing a new project or that an existing project
should continue into its next phase. This formal initiation links the project to the ongoing
work of the performing organization. In some organizations, a project is not formally
initiated until after completion of a needs assessment, a feasibility study, a preliminary plan,
or some other equivalent form of analysis that was itself separately initiated. Some types of
projects, especially internal service projects and new product development projects, are
initiated informally, and some limited amount of work is done to secure the approvals needed
for formal initiation. Projects are typically authorized as a result of one or more of the
following:
 A market demand (e.g., a car company authorizes a project to build more fuel-efficient
cars in response to gasoline shortages).
 A business need (e.g., a training company authorizes a project to create a new course to
increase its revenues).
 A customer request (e.g., an electric utility authorizes a project to build a new substation
to serve a new industrial park).
 A technological advance (e.g., an electronics firm authorizes a new project to develop a
video game player after advances in computer memory).

Project Initiation: Strategic Planning and Project Selection

 The first step in initiating projects is to look at the big picture or strategic plan of an
organization
 Strategic planning involves determining long-term business objectives
 IT projects should support strategic and financial business objectives

Identifying Potential Projects

Many organizations follow a planning process for selecting IT projects

 First develop an IT strategic plan based on the organization’s overall strategic plan
  Then perform a business area analysis
 Then define potential projects
 Then select IT projects and assign resources
For initiating a project and to determine on its scope, the potential projects should be
identified first.

Figure 3 Information Technology Planning Process

Methods for Selecting Projects

There are usually more projects than available time and resources to implement them in the
organization. Thus, it is important to follow a logical process for selecting IT projects to
work on methods include focusing on broad needs, categorizing projects, and weighted
scoring models.

a. Focusing on Broad Organizational Needs

It is often difficult to provide strong justification for many IT projects, but everyone agrees
they have a high value. Three important criteria for projects:

 There is a need for the project

 There are funds available
 There’s a strong will to make the project succeed
 b. Categorizing IT Projects

One categorization is whether the project addresses

 a problem
 an opportunity, or
 a directive
Another categorization is how long it will take to do and when it is needed. Another is the
overall priority of the project.

c. Weighted Scoring Model

 A weighted scoring model is a tool that provides a systematic process for selecting
projects based on many criteria.

 First identify criteria important to the project selection process

 Then assign weights (percentages) to each criterion so they add up to 100%

 Then assign scores to each criterion for each project

 Multiply the scores by the weights and get the total weighted scores

 The higher the weighted score, the better

Project Charters

 After deciding what project to work on, it is important to formalize projects.

 A project charter is a document that formally recognizes the existence of a project and
provides direction on the project’s objectives and management.

 Key project stakeholders should sign a project charter to acknowledge agreement on the
need and intent of the project.

2. Scope Planning and the Scope Statement

 A scope statement is a document used to develop and confirm a common understanding

of the project scope. It should include

 a project justification

 a brief description of the project’s products

 a summary of all project deliverables

 a statement of what determines project success

3. Scope Definition

After completing scope planning, the next step is to further define the work by subdividing
the major project deliverables into smaller and manageable pieces. Good scope definition
helps to:

 Improve the accuracy of cost, duration, and resource estimates

 Define a baseline for performance measurement and control
 Facilitate clear responsibility assignments

Proper scope definition is critical to project success. “When there is poor scope definition,
final project costs can be expected to be higher because of the inevitable changes which
disrupt project rhythm, cause rework, increase project time, and lower the productivity and
morale of the workforce.”. This is done during the WBS preparation and the subsequent
planning process.

The Work Breakdown Structure

 A work breakdown structure (WBS) is an outcome-oriented analysis of the work

involved in a project that defines the total scope of the project.

 It is a foundation document in project management because it provides the basis for

planning and managing project schedules, costs, and changes.
 Tabular form with numbering of the WBS or Intranet

1. Intranet
1.1. concept
1.1.1. Evaluate current systems
1.1.2. Define requirements
1.1.2.1. Define user requirement
1.1.2.2. Define content requirement
1.1.2.3. Define system requirement
1.1.2.4. Define server owner requirement
1.1.3. Define specific functionality
1.1.4. Define risk and risk management approach
1.1.5. Develop project plan
1.1.6. Brief Web development team
1.2. Web site design
1.3. Web site development
1.4. Roll out
1.5. Support

Approaches to Developing WBSs

 Using guidelines: Some organizations, like the DoD, provide guidelines for preparing
WBSs

 The analogy approach: It often helps to review WBSs of similar projects

 The top-down approach: Start with the largest items of the project and keep breaking
them down

 The bottom-up approach: Start with the detailed tasks and roll them up

4. Scope Verification and Scope Change Control

Throughout the executing and controlling processes, you’ll constantly be verifying the fact
that you are creating the deliverables that you planned to create. Verification is simply the
process of checking that you have built what you intended. It is very difficult to create a good
scope statement and WBS for a project and it is even more difficult to verify project scope
and minimize scope changes. Due to this unexpected growth of scope (scope creep) is
common. As a result, many IT projects suffer from scope creep and poor scope verification.
Scope verification is the process of obtaining formal acceptance of the project scope by the
stakeholders (sponsor, client, customer, etc.). It requires reviewing deliverables and work
results to ensure that all were completed correctly and satisfactorily. If the project is
terminated early, the scope verification process should establish and document the level and
extent of completion. Scope verification differs from quality control, scope verification is
primarily concerned with acceptance of the work results while quality control is primarily
concerned with the correctness of the work results. These processes are generally performed
in parallel to ensure both correctness and acceptance.

A scope change is any modification to the agreed-upon project scope as defined by the
approved WBS. Scope changes often require adjustments to cost, time, quality, or other
project objectives. Project scope changes are fed back through the planning process, technical
and planning documents are updated as needed, and stakeholders are notified as appropriate.

Scope change control is concerned with

a) Influencing the factors that create scope changes to ensure that changes are agreed upon,

b) Determining that a scope change has occurred, and

c) Managing the actual changes when and if they occur.

Scope change control must be thoroughly integrated with the other control processes
(schedule control, cost control, quality control, and others)

2.2 Stepwise Project Planning

2.2.2 Overview of Project Planning

Project planning defines the project activities and end products that will be performed and
describes how the activities will be accomplished. The purpose of project planning is to
define each major task, estimate the time and recourses required and provide a frame work
for management review and control. The project planning activities and goals include
defining:

 The specific work to be performed and goals that define and bind the project.
 Estimates to be documented for planning, tracking, and controlling the project.
 Commitments that are planned, documented, and agreed to by affected groups.
 Project alternatives, assumptions, and constraints.
2.3 Main Steps in Project Planning
The planning process consists of the following basic tasks:
 Define the technical approach used to solve the problem.
 Define and sequence the task to be performed and identify all deliverables associated
with project.
 Define the dependency relations between tasks.
 Estimate the resources required to perform each task.
 Schedule all tasks to be performed
 Define a budget for performing the task.
 Define the organizations used to execute the project.
 Identify the known risks in executing the project.
 Define the process used for ensuring quality.
 Define the process used for specifying and controlling requirements.
 Chapter Three

Project Scheduling
Project Time Management

Project Time Management includes the processes required to ensure timely completion of the
project.

Project Time Management Process

 Activity Definition—identifying the specific activities that must be performed to produce

the various project deliverables
 Activity Sequencing—identifying and documenting interactivity dependencies
 Activity Duration Estimating—estimating the number of work periods that will be
needed to complete individual activities
 Schedule Development—analyzing activity sequences, activity durations, and resource
requirements to create the project schedule.
 Schedule Control—controlling changes to the project schedule.

These processes interact with each other and with the processes in the other knowledge
areas as well. Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project. Each process generally occurs at least once
in every project phase. On some projects, especially smaller ones, activity sequencing,
activity duration estimating, and schedule development are so tightly linked that they are
viewed as a single process (e.g., they may be performed by a single individual over a
relatively short period of time).

1. Activity Definition

Activity definition: - identifying the specific activities that must be performed to produce the
various project deliverables.

Project schedules grow out of the basic document that initiate a project

a. Project charter includes start and end dates and budget information
 b. Scope statement and WBS help define what will be done

These are the inputs and activity list are the output for activity duration by using
decomposition as a tool and technique. The major difference between decomposition here
and in Scope Definition’s that the final out puts here are described as activities rather than as
deliverables. The WBS and the activity list are usually developed sequentially, with the WBS
being the basis for development of the final activity list. In some application areas, the WBS
and the activity list are developed concurrently. Defining activities involves identifying the
specific actions that will produce the project deliverables in enough detail to determine
resource and schedule estimates. The project team reviews the schedule management plan,
scope baseline, enterprise environmental factors, and organizational process assets to begin
defining activities. Outputs of this process include an activity list, activity attributes, a
milestone list, and project management plan updates.

The activity list is a tabulation of activities to be included on a project schedule. The

list should include the activity name, an activity identifier or number, and a brief description
of the activity. The activity attributes provide more schedule-related information
about each activity, such as predecessors, successors, logical relationships, leads and lags,
resource requirements, constraints, imposed dates, and assumptions related to the activity.

A milestone on a project is a significant event that normally has no duration. It often

takes several activities and a lot of work to complete a milestone, but the milestone itself
is like a marker to help in identifying necessary activities. Milestones are also useful tools
for setting schedule goals and monitoring progress. For example, milestones on a project
like the one in the chapter’s opening case might include completion and customer sign-off
of documents, such as design documents and test plans; completion of specific products,
such as software modules or installation of new hardware; and completion of important
process-related work, such as project review meetings and tests. The goal of defining
activities is to ensure that the project team completely understands all the work it must do as
part of the project scope so the team can start scheduling the work.
2. Activity Sequencing

Activity sequencing involves identifying and documenting interactivity logical relationships

or reviewing activities and determining dependencies. Activities must be sequenced
accurately to support later development of a realistic and achievable schedule.

 Mandatory dependencies: inherent in the nature of the work. They often involve
physical limitations. (On a construction project, it is impossible to erect the superstructure
until after the foundation has been built; on an electronics project, a prototype must be
built before it can be tested.) Mandatory dependencies are also called hard logic.
 Discretionary dependencies: defined by the project management team. They should be
used with care (and fully documented), since they may limit later scheduling options.
Discretionary dependencies are usually defined based on knowledge of Best practices
within a particular application area. Discretionary dependencies may also be called
preferred logic, preferential logic, or soft logic.
 External dependencies: involve relationships between project and non-project activities.
For example, the testing activity in a software project may be dependent on delivery of
hardware from an external source, or environmental hearings may need to be held before
site preparation can begin on a construction project.
 Milestones: events need to be part of the activity sequencing to assure that the
requirements for meeting the milestone(s) are met.

The above listing are inputs for activity sequencing and you must determine dependencies in
order to use critical path analysis.

Tools and Techniques for Activity Sequencing

Precedence Diagramming Method (PDM)

This is a method of constructing a project network diagram that uses boxes or rectangles
(nodes) to represent the activities and connects them with arrows that show the dependencies.
This technique is also called activity-on-node (AON).
 Activities are represented by boxes

 Arrows show relationships between activities

 More popular and used by project management software

 Better at showing different types of dependencies

It includes four types of dependencies or precedence relationships:

 Finish-to-start—the initiation of the work of the successor depends upon the completion
of the work of the predecessor.
 Finish-to-finish—the completion of the work of the successor depends upon the
completion of the work of the predecessor.
 Start-to-start—the initiation of the work of the successor depends upon the initiation of
the work of the predecessor.
 Start-to-finish—the completion of the successor is dependent upon the initiation of the
predecessor.
Project Network Diagrams

 Project network diagrams are the preferred technique for showing activity sequencing

 A project network diagram is a schematic display of the logical relationships among, or

sequencing of, project activities.

 Arrow Diagramming Method (ADM) also called activity-on-arrow (AOA) project

network diagrams

 Activities are represented by arrows

 Nodes or circles are the starting and ending points of activities

 Can only show finish-to-start dependencies

Activities Immediate Predecessors Expected time (wk)

A - 1
B - 2
C - 3
D A 4
E B 5
F B 4
G C 6
 H D, E 6
I G 2
J F, H, I 3

A. Draw Network diagram for the above data (AoA).

B. Identify the critical path.

C. Compute the total time to complete this project.

D. Compute slack time of this project.

Process for creating AOA diagrams

1. Find all of the activities that start at node 1. Draw their finish nodes and draw arrows
between node 1 and those finish nodes. Put the activity letter or name and duration
estimate on the associated arrow.
2. Continue drawing the network diagram, working from left to right. Look for bursts and
merges. Bursts occur when a single node is followed by two or more activities. A merge
occurs when two or more nodes precede a single node.
3. Continue drawing the project network diagram until all activities are included on the
diagram that have dependencies.
4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should
cross on an AOA network diagram.

3. Activity Duration Estimating

Activity duration estimating is the process of taking information on project scope and
resources and then developing durations for input to schedules. The inputs for the estimates
of duration typically originate from the person or group on the project team who is most
familiar with the nature of a specific activity. After defining activities and determining their
sequence, the next step in time management is duration estimating. Duration includes the
actual amount of time worked on an activity plus elapsed time. People doing the work should
help create estimates, and an expert should review them.

Estimating the number of work periods required to complete an activity will often require
consideration of elapsed time as well. For example, if “concrete curing” will require four
days of elapsed time, it may require from two to four work periods, based on a) which day of
the week it begins, and b) whether or not weekend days are treated as work periods. Most
computerized scheduling software will handle this problem by using alternative work-period
calendars.

Reserve time (contingency)

Project teams may choose to incorporate an additional time frame, called time reserve,
contingency, or buffer, that can be added to the activity duration or elsewhere in the schedule
as recognition of schedule risk. This reserve time can be a percentage of the estimated
duration, or a fixed number of work periods. The reserve time can later be reduced or
eliminated, as more precise information about the project becomes available. Such reserve
time should be documented along with other data and assumptions.

4. Schedule Development
Schedule development uses results of the other time management processes to determine the
start and end date of the project and its activities. Ultimate goal is to create a realistic project
schedule that provides a basis for monitoring project progress for the time dimension of the
project.
Tools and Techniques for Schedule Development
Include Gantt charts, PERT analysis and critical path analysis.

Gantt chart: It provide a standard format for displaying project schedule information by
listing project activities and their corresponding start and finish dates in a calendar format.

 Symbols include:
 A black diamond: milestones or significant events on a project with zero duration
 Thick black bars: summary tasks
 Lighter horizontal bars: tasks
 Arrows: dependencies between tasks

Gantt chart for project X

Program Evaluation and Review Technique /PERT/

Graphical representation of activities and events. It shows dependency relationships between

tasks/activities in a project. Clearly shows tasks that must precede (precedence) or follow
(succeeding) other tasks in a logical manner. Clear representation of plan – a powerful tool
for planning and controlling project.
Example1

Activity Description Immediate predecessors

A Buy Plastic Body -

B Design Component -

C Make Component B

D Assemble product A, C

Immediate predecessors for a particular activity are the activities that, when completed,
enable the start of the activity in question.

 Can start work on activities A and B anytime, since neither of these activities depends
upon the completion of prior activities.

 Activity C cannot be started until activity B has been completed

 Activity D cannot be started until both activities A and C have been completed.

Develop the network for a project with following activities and immediate predecessors.

Example 2 Activity Immediate predecessors

A -
 B -
C B
D A, C
E C
F C
G D, E, F

 Note how the network correctly identifies D, E, and F as the immediate predecessors for
activity G.

 Dummy activities are used to identify precedence relationships correctly and to eliminate
possible confusion of two or more activities having the same starting and ending nodes.

 Dummy activities have no resources (time, labor, machinery, etc.) – purpose is to

PRESERVE LOGIC of the network.

Examples of the Dummy Activity

 Earliest start & earliest finish time

 We are interested in the longest path through the network, i.e., the critical path.

 Starting at the network’s origin (node 1) and using a starting time of 0, we compute an
earliest start (ES) and earliest finish (EF) time for each activity in the network.

 The expression EF = ES + t can be used to find the earliest finish time for a given
activity.

For example, for activity A, ES = 0 and t = 5; thus, the earliest finish time for activity A
is

EF = 0 + 5 = 5
Example3: Activity Immediate predecessors Completion Time (week)
A - 5
B - 6
C A 4
D A 3
E A 1
F E 4
G D, F 14
H B, C 12
I G, H 2 Total …… 51

Earliest start time rule:

The earliest start time for an activity leaving a particular node is equal to the largest of the
earliest finish times for all activities entering the node. Forward pass calculation

Latest start & latest finish time

 To find the critical path we need a backward pass calculation.

 Starting at the completion point (node 7) and using a latest finish time (LF) of 26 for
activity I, we trace back through the network computing a latest start (LS) and latest
finish time for each activity.

 The expression LS = LF – t can be used to calculate latest start time for each activity. For
example, for activity I, LF = 26 and t = 2, thus the latest start time for activity I is

LS = 26 – 2 = 24
Latest finish time rule:

The latest finish time for an activity entering a particular node is equal to the smallest of the
latest start times for all activities leaving the node.

Slack or Free Time or Float

Slack is the length of time an activity can be delayed without affecting the completion date
for the entire project. For example, slack for C = 3 weeks, i.e. Activity C can be delayed up
to 3 weeks (start anywhere between weeks 5 and 8).

Critical Path Method (CPM)

 CPM is a project network analysis technique used to predict total project duration.

 A critical path for a project is the series of activities that determines the earliest time by
which the project can be completed.

 The critical path is the longest path through the network diagram and has the least
amount of slack or float.

 To find the critical path first develop a good project network diagram and add the
durations for all activities on each path through the project network diagram. Then,
identify the longest path which is the critical path.
From the previous example 3

1. What is the total time to complete the project?

26 weeks if the individual activities are completed on schedule.
2. What are the scheduled start and completion times for each activity?
ES, EF, LS, LF are given for each activity.
3. What activities are critical and must be completed as scheduled in order to keep the
project on time?
Critical path activities: A, E, F, G, and I.
4. How long can non-critical activities be delayed before they cause a delay in the project’s
completion time

Slack time available for all activities are given

Activity Earliest Latest start Earliest Latest Finish Slack(LS-ES) Critical path
start (ES) (LS) finish (EF) (LF)

A 0 0 5 5 0 Yes
B 0 6 6 12 6
C 5 8 9 12 3
D 5 7 8 10 2
E 5 5 6 6 0 Yes
F 6 6 10 10 0 Yes
G 10 10 24 24 0 Yes
H 9 12 21 24 3
AI 24 24 26 26 0 Yes

Techniques for Shortening a Project Schedule

Shortening durations of critical tasks for adding more resources or changing their scope.
Crashing tasks by obtaining the greatest amount of schedule compression for the least
incremental cost. The main advantage of crashing is shortening the time needed to finish a
project. The main disadvantage of crashing is that it often increases total project costs. And
Fast-tracking tasks by doing them in parallel or overlapping them. The main advantage of
fast tracking, like crashing, is that it can shorten the time needed to finish a project. The main
disadvantage is that it can lengthen the project schedule because starting some tasks too soon
often increases project risk and results in rework.
5. Schedule Control
Schedule control is concerned with a) influencing the factors that create schedule changes
to ensure that changes are agreed upon, b) determining that the schedule has changed, and
c) managing the actual changes when and as they occur. Schedule control must be
thoroughly integrated with the other control processes.
 Perform reality checks on schedules
 Allow for contingencies
 Don’t plan for everyone to work at 100% capacity all the time
 Hold progress meetings with stakeholders and be clear and honest in
communicating schedule issues.
 Chapter Four

Project Cost Management

Importance and Principles of Project Cost Management

Cost is a resource sacrificed or fore-gone to achieve a specific objective or something given

up in exchange. Costs are usually measured in monetary units like birr, dollar, etc. Project
cost management includes the processes required to ensure that the project is completed
within an approved budget. Project managers must make sure their projects are well defined,
have accurate time and cost estimates and have a realistic budget that they were involved in
approving.

Project Cost Management Processes

1. Resource planning: determining what resources (people, equipment, materials) and

quantities of them should be used.

2. Cost estimating: developing an estimate of the costs and resources needed to complete a
project.

3. Cost budgeting: allocating the overall cost estimate to individual work items to establish
a baseline for measuring performance.

4. Cost control: controlling changes to the project budget

These processes interact with each other and with the processes in the other knowledge areas
as well. Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project. Each process generally occurs at least once in
every project phase. Project cost management is primarily concerned with the cost of the
resources needed to complete project activities. However, project cost management should
also consider the effect of project decisions on the cost of using the project’s product.
1. Resource Planning

The nature of the project and the organization will affect resource planning. Some

questions to consider:

 How difficult will it be to do specific tasks on the project?

 Is there anything unique in this project’s scope statement that will affect resources?

 What is the organization’s history in doing similar tasks?

 Does the organization have or can they acquire the people, equipment, and materials

that are capable and available for performing the work?

Resource requirements: The output of the resource planning process is a description of what types

of resources are required and in what quantities for each element at the lowest level of the WBS.

Resource requirements for higher levels within the WBS can be calculated based on the lower-level

values. These resources will be obtained either through staff acquisition or procurement.

2. Cost Estimating

 An important output of project cost management is a cost estimate

 There are several types of cost estimates, and tools and techniques to help create them

 It is also important to develop a cost management plan that describes how cost variances

will be managed on the project.

Types of Cost Estimates

Types of Estimate When Done Why Done How Accurate

Rough Order of Very early in the project Provides rough -25%, +75%
Magnitude (ROM) life cycle, often 3-5 years ballpark of cost for
before project completion selection decisions
 Budgetary Early, 1-2 years out Puts dollars in the -10%, +25%
budget plans
Definitive Later in the project, < 1 Provides details for -5%, +10%
year out purchases, estimate
actual cost

 A ROM estimate that actually cost $100,000 would range between $75,000 to $175,000.

 A budgetary estimate that actually costs $100,000 would range between $90,000 to
$125,000.

 A definitive estimate that actually costs $ 100,000 would range between $95,000 to
$110,000.

Cost Estimation Tools and Techniques

 Analogous or top-down: use the actual cost of a previous, similar project as the basis
for the new estimate.

 Bottom-up: estimate individual work items and sum them to get a total estimate.

 Parametric: use project characteristics in a mathematical model to estimate costs.

 Computerized tools: Computerized tools, such as project management software

spreadsheets and simulation/statistical tools are widely used to assist with cost
estimating.
Typical Problems with Cost Estimates

 Developing an estimate for a large software project is a complex task requiring a

significant amount of effort. Remember that estimates are done at various stages of the
project.

 Many people doing estimates have little experience doing them. Try to provide training
and mentoring.

 People have a bias toward underestimation. Review estimates and ask important
questions to make sure estimates are not biased.

 Management wants a number for a bid, not a real estimate. Project managers must
negotiate with project sponsors to create realistic cost estimates.

3. Cost Budgeting

Cost budget involves allocating the project cost estimate to individual work items and

providing a cost baseline. For example, in the Business Systems Replacement project, there

was a total purchased cost estimate for FY97 of $600,000 and another $1.2 million for

Information Services and Technology. WBS, project scheduling and risk management plan

(often includes cost contingency, which can be determined on the basis of the expected

accuracy of the estimate) are the inputs to cost budgeting.

4. Cost Control

Project cost control includes

 monitoring cost performance

 ensuring that only appropriate project changes are included in a revised cost baseline

 informing project stakeholders of authorized changes to the project that will affect costs

Earned value management is an important tool for cost control

Earned Value Management (EVM)

 EVM is a project performance measurement technique that integrates scope, time, and cost data

 Given a baseline (original plan plus approved changes), you can determine how well the project is

meeting its goals

 You must enter actual information periodically to use EVM.

Earned Value Analysis is an industry standard way to:

 measure a project’s progress,

 forecast its completion date and final cost, and

 provide schedule and budget variances along the way.

Earned Value Management Terms

 Planned value (PV), formerly called the budgeted cost of work scheduled (BCWS), also called the

budget, is that portion of the approved total cost estimate planned to be spent on an activity

during a given period.

 Actual cost (AC), formerly called actual cost of work performed (ACWP), is the total of direct and

indirect costs incurred in accomplishing work on an activity during a given period.

 Earned value (EV), formerly called the budgeted cost of work performed (BCWP), is the

percentage of work actually completed multiplied by the planned value.

To estimate what it will cost to complete a project or how long it will take based on

performance to date, divide the budgeted cost or time by the appropriate index.
 Negative numbers for cost and schedule variance indicate problems in those areas. The project is
costing more than planned or taking longer than planned
 CPI and SPI > 1.0 indicate exceptional performance
 CPI and SPI < 1.0 indicate poor performance

Example: Suppose you have a budgeted cost of a project at Birr 900,000. The project is to be

completed in 9 months. After a month, you have completed 10% of the project at a total

expense of Birr 100,000. The planned completion should have been 15%.

Given: Budget At Complete (BAC) = Birr 900,000 AC = Birr 100,000

Planned Value = Planned Completion (%) * BAC

= 15% * Birr 900,000

= Birr 135,000

Earned Value = Percent Completed (%) * BAC

= 10% * Birr 900,000
The project is costing
= Birr 90,000 more than planned
because CV is less
than zero.
• CV = EV – AC = 90,000 – 100,000
= -10,000
• SV = EV – PV = 90,000 – 135,000
The project is taking
= - 45,000 longer than planned
because SV is less
than zero.
• CPI= EV / AC
= 90,000 / 100,000
= 0.90
• SPI= EV/PV It shows Poor
Performance
= 90,000 / 135,000 because CPI and
SPI are less than
= 0.67 one.
Forecasting Cost

 If the project continues at the current performance, what is the true cost of the project?

 Estimate At Complete

= Budget At Complete (BAC) / CPI

= Birr 900,000 / 0.90 = Birr 1,000,000

At the end of the project, the total project costs will be Birr 1,000,000

Establish Ranges to Guide Traffic Light Status

 Traffic Light status is useful in conveying overall project’s status with one color

 Establish objective SPI and CPI ranges to determine the true project color.

 Average of CPI & SPI i.e. (CPI+SPI)/2

Good
Green [1.0 - 0.95]
Warning
Yellow [0.94 - 0.85]
Red [0.84 - 0] Bad

Therefore, for the above example,

Overall project’s traffic light status
= (CPI+SPI)/2
= (0.90+0.67)/2
= 0.78 Bad
 Chapter Five

Project Quality Management

 The International Organization for Standardization (ISO) defines quality as the totality of
characteristics of an entity that bear on its ability to satisfy stated or implied needs.

 Other experts define quality based on

 conformance to requirements: meeting written specifications

 fitness for use: ensuring a product can be used as it was intended

Project Quality Management includes the processes required to ensure that the project will
satisfy the needs for which it was undertaken. The purpose of project quality management is
to ensure that the project will satisfy the needs for which it was undertaken. Recall that
project management involves meeting or exceeding stakeholder needs and expectations. The
project team must develop good relationships with key stakeholders, especially the main
customer for the project, to understand what quality means to them. After all, the customer
ultimately decides if quality is acceptable. Many technical projects fail because the project
team focuses only on meeting the written requirements for the main products being created
and ignores other stakeholder needs and expectations for the project.

Project Quality Management Processes

 Quality planning: identifying which quality standards are relevant to the project and
how to satisfy them

 Quality assurance: evaluating overall project performance to ensure the project will
satisfy the relevant quality standards

 Quality control: monitoring specific project results to ensure that they comply with the
relevant quality standards while identifying ways to improve overall quality

Project quality management must address both the management of the project and the
product of the project. The project management team should also be aware that modern
quality management complements project management.
Modern Quality Management

 Modern quality management

 requires customer satisfaction

 prefers prevention to inspection

 recognizes management responsibility for quality

Quality Planning

Scope statement. The scope statement is a key input to quality planning since it documents
major project deliverables, as well as the project objectives that serve to define important
stakeholder requirements. It is an input for defining quality planning.

 It is important to design in quality and communicate important factors that directly

contribute to meeting the customer’s requirements

 Design of experiments helps identify which variables have the most influence on the
overall outcome of a process

 Many scope aspects of software projects affect quality like functionality, features, system
outputs, performance, reliability, and maintainability.

Quality standards can also apply to IT services. For example, you can set standards for how
long it should take to get a reply from a help desk or how long it should take to ship a
replacement part for a hardware item under warranty. The main outputs of planning quality
management are a quality management plan, a process improvement plan, quality metrics,
quality checklists, and project documents updates. A metric is a standard of measurement.
Examples of common metrics include failure rates of products, availability of goods and
services, and customer satisfaction ratings.

Quality management plan: The quality management plan should describe how the project
management team will implement its quality policy. It should describe the project quality
system: “the organizational structure, responsibilities, procedures, processes, and resources
needed to implement quality management”. The quality management plan provides input to
the overall project plan and must address quality control, quality assurance, and quality
improvement for the project. The quality management plan may be formal or informal,
highly detailed, or broadly framed, based on the requirements of the project.

Quality Assurance

Quality assurance includes all the activities related to satisfying the relevant quality standards
for a project. Another goal of quality assurance is continuous quality improvement. Input are
Quality management plan, Results of quality control measurements and Operational
definitions.

Several tools used in quality planning can also be used in quality assurance. Design of
experiments, as described under quality planning, can also help ensure and improve
product quality. Benchmarking involves comparing actual or planned project practices to
those of other projects to generate ideas for improvement and to provide a standard by which
to measure performance. The other projects may be within the performing organization or
outside of it, and may be within the same application area or in another. An important tool is
Quality audits help identify lessons learned that can improve performance on current or
future projects.

Quality assurance is all the planned and systematic activities implemented within the quality
system to provide confidence that the project will satisfy the relevant Quality standards. The
activities described under quality planning were widely included as part of quality assurance.
Quality assurance is often provided by a Quality Assurance Department or similarly titled
organizational unit, but it does not have to be. Assurance may be provided to the project
management team and to the management of the performing organization (internal quality
assurance), or it may be provided to the customer and others not actively involved in the
work of the project (external quality assurance).

Quality Control

Quality control involves monitoring specific project results to determine if they comply with
relevant quality standards, and identifying ways to eliminate causes of unsatisfactory results.
 It should be performed throughout the project. Project results include both product results,
such as deliverables, and project management results, such as cost and schedule performance.
Quality control is often performed by a Quality Control Department or similarly titled
organizational unit, but it does not have to be.

 Inputs to Quality Control

 Work results. Work results include both process results and product results.
Information about the planned or expected results (from the project plan) should be
available along with information about the actual results.
 Quality management plan.
 Operational definitions.
 Checklists.

 The main outputs of quality control are

 acceptance decisions

 rework

 process adjustments

 Some tools and techniques include

 pareto analysis

 quality control charts

 testing

Pareto Analysis

 Pareto analysis involves identifying the vital few contributors that account for the most
quality problems in a system

 Also called the 80-20 rule, meaning that 80% of problems are often due to 20% of the
causes

 Pareto diagrams are histograms that help identify and prioritize problem areas
Sample Pareto Diagram

Quality Control Charts and the Seven Run Rule

 A control chart is a graphic display of data that illustrates the results of a process over
time. It helps prevent defects and allows you to determine whether a process is in control
or out of control

 The seven run rule states that if seven data points in a row are all below the mean, above
the mean, or increasing or decreasing, then the process needs to be examined for non-
random problems

Testing
 Many SW professionals think of testing as a stage that comes near the end of SW product
development

 Testing should be done during almost every phase of the SW product development life
cycle

Improving Software Project Quality

Several suggestions for improving quality for Software projects include

 Leadership that promotes quality

“It is most important that top management be quality-minded. In the absence of sincere
manifestation of interest at the top, little will happen below.” (Juran, 1945). A large
percentage of quality problems are associated with management, not technical issues

 Understanding the cost of quality

The cost of quality is

 the cost of conformance or delivering products that meet requirements and fitness
for use

 the cost of nonconformance or taking responsibility for failures or not meeting

quality expectations

Cost Categories Related to Quality

 The Cost of Quality category codes are the following:

 Prevention Costs

Prevention costs are investments made ahead of time in an effort to ensure conformance to
requirements. Examples include activities such as orientation of team members, training, and
the development of project standards and procedures.

 Appraisal Costs

Appraisal costs are costs incurred to identify defects after the fact. Examples include
activities such as walk-throughs and testing
 Internal Error Costs

Internal error costs are the costs of rework and repair before delivery to a customer. An
example is fixing faults detected during internal testing.

 External Error Costs

External error costs are the costs of rework and repair after delivery to a customer. One
example would be rework and repair resulting from acceptance testing. Another example
would be the actual costs incurred during warranty support.

 Measurement and test equipment costs

Measurement and test equipment costs: capital cost of equipment used to perform prevention
and appraisal activities.

ISO 9000

 An international set of standards for quality management.

 Applicable to a range of organisations from manufacturing to service industries.

 ISO 9001 applicable to organisations which design, develop and maintain products.

 ISO 9001 is a generic model of the quality process that must be instantiated for each
organisation using the standard.

ISO 9000 certification

 Quality standards and procedures should be documented in an organisational quality

manual.

 An external body may certify that an organisation’s quality manual conforms to ISO
9000 standards.

 Some customers require suppliers to be ISO 9000 certified although the need for
flexibility here is increasingly recognised.
 Chapter Six

Project Human Resource Management

Project human resource management is a subset of project management that includes the
processes required to make the most effective use of the people involved within a project. It
includes all the project stakeholders—sponsors, customers, partners, individual contributors,
and others.

Project Human Resource Management Processes

 Organizational planning: identifying, documenting, and assigning project roles,

responsibilities, and reporting relationships.
 Staff acquisition: getting the human resources needed assigned to and working on the
project.
 Team development: developing individual and group competencies to enhance project
performance.
These processes interact with each other and with the processes in the other knowledge areas
as well. Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project.

Keys to Managing People

 Important areas related to project human resource management include
 motivation
 influence and power
 effectiveness

1. Motivation
Psychologists, managers, coworkers, teachers, parents, and most people in general still
struggle to understand what motivates people to do what they do. Intrinsic motivation
causes people to participate in an activity for their own enjoyment. For example, some
people love to read, write, or play an instrument because it makes them feel good.
Extrinsic motivation causes people to do something for a reward or to avoid a penalty.
For example, some young children would prefer not to play an instrument, but they do
because they receive a reward or avoid a punishment for doing so.

Abraham Maslow developed a hierarchy of needs to illustrate his theory that people’s
behaviors are guided by a sequence of needs. Maslow argued that human beings possess
unique qualities that enable them to make independent choices, thus giving them control of
their destiny.
Maslow’s Hierarchy of Needs

Herzberg’s Motivational and Hygiene Factors

 Frederick Herzberg wrote several famous books and articles about worker motivation. He
distinguished between
 Motivational factors: achievement, recognition, the work itself, responsibility,
advancement, and growth, which produce job satisfaction.
 Hygiene factors: cause dissatisfaction if not present, but do not motivate workers
to do more. Examples include larger salaries, more supervision, and a more
attractive work environment
McGregor’s Theory X and Y
 Douglas McGregor popularized the human relations approach to management in the 1960s
 Theory X: assumes workers dislike and avoid work, so managers must use coercion,
threats and various control schemes to get workers to meet objectives
 Theory Y: assumes individuals consider work as natural as play or rest and enjoy the
satisfaction of esteem and self-actualization needs
 Theory Z: introduced in 1981 by William Ouchi and is based on the Japanese approach to
motivating workers, emphasizing trust, quality, collective decision making, and cultural
values.

Thamhain and Wilemon’s Influence and Power

Many people working on a project do not report directly to project managers, and project
managers often do not have control over project staff who report to them. For example,
people are free to change jobs. If they are given work assignments they do not like, many
workers will simply quit or transfer to other departments or projects. H. J. Thamhain and D.
L. Wilemon investigated the approaches that project managers use to deal with workers and
how those approaches relate to project success. They identified nine influence bases that are
available to project managers:

1. Authority: the legitimate hierarchical right to issue orders

2. Assignment: the project manager's perceived ability to influence a worker's later work
assignments
3. Budget: the project manager's perceived ability to authorize others' use of discretionary
funds
4. Promotion: the ability to improve a worker's position
5. Money: the ability to increase a worker's pay and benefits
6. Penalty: the project manager's ability to cause punishment
7. Work challenge: the ability to assign work that capitalizes on a worker's enjoyment of
doing a particular task
8. Expertise: the project manager's perceived special knowledge that others deem important
9. Friendship: the ability to establish friendly personal relationships between the project
manager and others.
Power

Power is the potential ability to influence behavior to get people to do things they would not
otherwise do. Types of power include:

 Coercive: The ability of a manager to force an employee to follow an order by threatening

the employee with punishment if the employee does not comply with the order

 Legitimate: It is based on the reality that a person holds a particular position in an

organization. It's also based on the perception of an employee that someone holding that
position has authority to exert control over her.

 Expert: A power based upon employees' perception that a manager or some other member
of an organization has a high level of knowledge or a specialized set of skills that other
employees or members of the organization do not possess

 Reward: Power that arises from the ability of a person to influence the allocation of
incentives in an organization. These incentives include salary increments, positive
appraisals and promotions.

 Referent: It arises from interpersonal relationships that a person cultivates with other
people in the organization. People possess reference power when others respect and like
them. Referent power arises from charisma, as the charismatic person influences others
via the admiration, respect and trust others have for her.

Improving Effectiveness - Covey’s 7 Habits

Project managers can apply Covey’s 7 habits to improve effectiveness on projects

1) Be proactive
2) Begin with the end in mind
3) Put first things first
4) Think win/win
5) Seek first to understand, then to be understood
6) Synergize
 7) Sharpen the saw

1. Organizational Planning
Organizational planning involves identifying, documenting, and assigning project roles,
responsibilities, and reporting relationships. Roles, responsibilities, and reporting
relationships may be assigned to individuals or to groups. The individuals and groups may be
part of the organization performing the project, or they may be external to it. Internal groups
are often associated with a specific functional department such as engineering, marketing, or
accounting.

Outputs and processes include

a. project organizational charts

b. work definition and assignment process
c. responsibility assignment matrixes
d. resource histograms
Sample organizational chart for a large it project

Work Definition and Assignment Process

 Sample Responsibility Assignment Matrix (RAM)

2. Staff Acquisition

Staff acquisition involves getting the needed human resources (individuals or groups)
assigned to and working on the project. In most environments, the “best” resources may not
be available, and the project management team must take care to ensure that the resources
that are available will meet project requirements.

Staffing plans and good hiring procedures are important in staff acquisition, as are incentives
for recruiting and retention. Some companies give their employees one dollar for every hour
a new person they helped. Some organizations allow people to work from home as an
incentive. Research shows that people leave their jobs because they don’t make a difference,
 don’t get proper recognition, aren’t learning anything new, don’t like their coworkers, and
want to earn more money.

Resource Loading and Leveling

Resource loading refers to the amount of individual resources an existing project schedule
requires during specific time periods. Resource histograms show resource loading. Over-
allocation means more resources than are available are assigned to perform work at a given
time. Resource leveling is a technique for resolving resource conflicts by delaying tasks. The
main purpose of resource leveling is to create a smoother distribution of resource usage and
reduce over-allocation.

Tools and Techniques for Staff Acquisition

1. Negotiations. Staff assignments must be negotiated on most projects. For example, the
project management team may need to negotiate with:
 Responsible functional managers to ensure that the project receives appropriately
competent staff in the necessary time frame.
 Other project management teams within the performing organization to assign scarce
or specialized resources appropriately.
2. Reassignment. In some cases, staff may be reassigned to the project. This is often the case
when
 a) The project is the result of a competitive proposal, and specific staffs were promised as
part of the proposal, or
b) The project is an internal service project, and staff assignments were defined within the
project charter.

Outputs from Staff Acquisition

1. Project staff assigned: The project is staffed when appropriate people have been reliably
assigned to work on it. Staff may be assigned full time, part time, or variably, based on
the needs of the project.
2. Project team directory: A project team directory lists all the project team members and
other stakeholders. The directory may be formal or informal, highly detailed or broadly
framed, based on the needs of the project.

3. Team Development

Team development includes both enhancing the ability of stakeholders to contribute as

individuals as well as enhancing the ability of the team to function as a team. Individual
development (managerial and technical) is the foundation necessary to develop the team.
Development as a team is critical to the project’s ability to meet its objectives.

 It takes teamwork to successfully complete most projects

 Training can help people understand themselves, each other, and how to work better in
teams
 Team building activities include
 physical challenges
 psychological preference indicator tools

General Advice on Teams

 Focus on meeting project objectives and producing positive results
 Fix the problem instead of blaming people
 Establish regular, effective meetings
 Nurture team members and encourage them to help each other
 Acknowledge individual and group accomplishments

Software can help in producing RAMs and resource histograms

 Project management software includes several features related to human resource

management such as
 viewing resource usage information
 identifying under and over allocated resources
 leveling resources
 Chapter Seven

Project Communication Management

Project Communications Management includes the processes required to ensure timely and
appropriate generation, collection, dissemination, storage, and ultimate disposition of project
information. It provides the critical links among people, ideas, and information that are
necessary for success. Everyone involved in the project must be prepared to send and receive
communications, and must understand how the communications occur in which they are
involved as individuals affect the project as a whole.

Importance of Good Communications

 The greatest threat to many projects is a failure to communicate

 Our culture does not portray SW professionals as being good communicators

 Research shows that SW professionals must be able to communicate effectively to

succeed in their positions

 Strong verbal skill is a key factor in career advancement for SW professionals

Project Communications Management Processes

1. Communications planning: determining the information and communication needs of

the stakeholders. who needs what information, when they will need it, and how it will be
given to them.
2. Information distribution: making needed information available in a timely manner.
3. Performance reporting: collecting and disseminating performance information. This
includes status reporting, progress measurement, and forecasting.
4. Administrative closure: generating, gathering, and disseminating information to
formalize phase or project completion.
1. Communications Planning
Communications planning is often tightly linked with organizational planning since the
project’s organizational structure will have a major effect on the project’s communications
requirements. Identifying the informational needs of the stakeholders and determining a
suitable means of meeting those needs is an important factor for project success. Every
project should include some type of communications management plan, a document that
guides project communications. Creating a stakeholder analysis for project communications
also aids in communications planning.

Tools and Techniques for Communications Planning

Stakeholder analysis: The information needs of the various stakeholders should be analyzed
to develop a methodical and logical view of their information needs and sources to meet
those needs. The analysis should consider methods and technologies suited to the project that
will provide the information needed. Care should be taken to avoid wasting resources on
unnecessary information or inappropriate technology.

Outputs from Communications Planning

Communications management plan: A communications management plan is a document

that provides:

 A description of a collection and filing structure for gathering and storing various types
of information
 A distribution structure describing what information goes to whom, when, and how
 A format for communicating key project information
 A project schedule for producing the information
 Access methods for obtaining the information
 A method for updating the communications management plans as the project progresses
and develops
 A stakeholder communications analysis
Sample Stakeholder Analysis for Project Communication

Stakeholders Document Name Document Contact Person Due

Format
Customer Monthly Status Hard copy Gail Feldman, First of month
Management Report Tony Silva
Customer Monthly Status Hard copy Julie Grant, First of month
Business Staff Report Jeff Martin
Customer Monthly Status E-mail Evan Dodge, First of month
Technical Staff Report Nancy Michaels
Internal Monthly Status Hard copy Bob Thomson First of month
Management Report
Internal Monthly Status Intranet Angie Liu First of month
Business and Report
Technical Staff
Training Training Plan Hard Copy Jonathan Kraus 11/1/1999
Subcontractor
Software Software E-mail Barbara Gates 6/1/2000
Subcontractor Implementation
Plan

2. Information Distribution

 Getting the right information to the right people at the right time and in a useful format is
just as important as developing the information in the first place.
 Important considerations include
 using technology to enhance information distribution
 formal and informal methods for distributing information

The Impact of The Number of People on Communications Channels

Outputs from Information Distribution

1. Project records: Project records may include correspondence, memos, and documents
describing the project. This information should, to the extent possible and appropriate, be
maintained in an organized fashion. Project team members may often maintain personal
records in a project notebook.
2. Project reports: Formal project reports on project status and/or issues.
3. Project presentations: The project team provides information formally, or informally, to
any or all of the project stakeholders. The information is relevant to the needs of the
audience, and the method of presentation is appropriate.

3. Performance Reporting

Performance reporting involves collecting and disseminating performance information to

provide stakeholders with information about how resources are being used to achieve project
objectives. This process includes:

 Status reports describe where the project stands at a specific point in time- for example,
status related to schedule and budget metrics.

 Progress reports describe what the project team has accomplished during a certain
period of time for example, percent complete to schedule, or what is completed versus
what is in process.

 Project forecasting predicts future project status and progress based on past information
and trends.

Performance reporting should generally provide information on scope, schedule, cost, and
quality.

4. Administrative Closure

The project or phase, after either achieving its objectives or being terminated for other
reasons, requires closure. Administrative closure consists of documenting project results to
formalize acceptance of the product of the project by the sponsor, or customer. It includes
collecting project records; ensuring that they reflect final specifications; analyzing project
success, effectiveness, and lessons learned; and archiving such information for future use.

Administrative closure activities should not be delayed until project completion. Each phase
of the project should be properly closed to ensure that important and useful information is not
lost. In addition, employee skills in the staff pool database should be updated to reflect new
skills and proficiency increases.

 SW is concerned with generating, gathering, and disseminating information to formalize

phase or project completion

 Administrative closure produces

 project archives

 formal acceptance

 lessons learned

Outputs from Administrative Closure

Project Closure: Confirmation that the project has met all customer requirements for the
product of the project (the customer has formally accepted the project results and
deliverables and the requirements of the delivering organization—for example, staff
evaluations, budget reports, lessons learned, etc.).

Conflict Handling Modes, in Preference Order

 Confrontation or problem-solving: directly face a conflict

 Compromise: use a give-and-take approach

 Smoothing: de-emphasize areas of differences and emphasize areas of agreement

 Forcing: the win-lose approach

 Withdrawal: retreat or withdraw from an actual or potential disagreement

Conflict Can Be Good

 Conflict often produces important results, such as new ideas, better alternatives, and
motivation to work harder and more collaboratively

 Groupthink can develop if there are no conflicting viewpoints

 Research by Karen Jehn suggests that task-related conflict often improves team
performance, but emotional conflict often depresses team performance

Running Effective Meetings

 Define the purpose and intended outcome of the meeting

 Determine who should attend the meeting

 Provide an agenda to participants before the meeting

 Prepare handouts, visual aids, and make logistical arrangements ahead of time

 Run the meeting professionally

 Build relationships

Developing a Communications Infrastructure

A communications infrastructure is a set of tools, techniques, and principles that provide a

foundation for the effective transfer of information

 Tools include e-mail, project management software, groupware, fax machines,

telephones, teleconferencing systems, document management systems, and word
processors

 Techniques include reporting guidelines and templates, meeting ground rules and
procedures, decision-making processes, problem-solving approaches, and conflict
resolution and negotiation techniques

 Principles include using open dialog and an agreed upon work ethics
 Chapter Eight

Project Risk Management

A dictionary definition of risk is “the possibility of loss or injury”. “A risk is a combination of

constraint and uncertainty” by Larry Krantz. Project risk involves understanding potential
problems that might occur on the project and how they might impede project success and Risk
management is like a form of insurance; it is an investment.

Risk management is the systematic process of identifying, analyzing, and responding to project
risk. It includes maximizing the probability and consequences of positive events and minimizing
the probability and consequences of adverse events to project objectives.

Project Risk Management Processes

The goal of project risk management is to minimize potential risks while maximizing potential
opportunities. Major processes include:

 Risk management planning: deciding how to approach and plan the risk management
activities for the project

 Risk identification: determining which risks are likely to affect a project and documenting
their characteristics

 Qualitative risk analysis: characterizing and analyzing risks and prioritizing their effects on
project objectives

 Quantitative risk analysis: measuring the probability and consequences of risks

 Risk response planning: taking steps to enhance opportunities and reduce threats to meeting
project objectives

 Risk monitoring and control: monitoring known risks, identifying new risks, reducing
risks, and evaluating the effectiveness of risk reduction
1. Risk Management Planning
Risk management 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.

Project charter, WBS, Defined roll and responsibility and stakeholder risk tolerances are the
inputs. In addition to this, risk management plan is the main output of risk management planning.
The project team should review project documents and understand the organization’s and the
sponsor’s approach to risk. The level of detail will vary with the needs of the project.

Questions Addressed in a Risk Management Plan

 Why is it important to take/not take this risk in relation to the project objectives?
 What is the specific risk, and what are the risk mitigation deliverables?
 How is the risk going to be mitigated? (What risk mitigation approach is to be used?)
 Who are the individuals responsible for implementing the risk management plan?
 When will the milestones associated with the mitigation approach occur?
 How much is required in terms of resources to mitigate risk?

Outputs of Risk Management Planning

Risk management plan: The risk management plan describes how risk identification, qualitative
and quantitative analysis, response planning, monitoring, and control will be structured and
performed during the project life cycle. A risk management plan documents the procedures for
managing risk throughout the project.

In addition to a risk management plan, many projects also include contingency plans,
fallback plans, and contingency reserves.

 Contingency plans: are predefined actions that the project team will take if an identified risk
event occurs. For example, if the project team knows that a new release of a software
package may not be available in time to use for the project, the team might have a
contingency plan to use the existing, older version of the software.
 Fallback plans: are developed for risks that have a high impact on meeting project
objectives, and are put into effect if attempts to reduce the risk do not work. For example, a
new college graduate might have a main plan and several contingency plans for where to live
after graduation, but if these plans do not work out, a fallback plan might be to live at home
for a while. Sometimes the terms contingency plan and fallback plan are used
interchangeably.
 Contingency reserves or contingency allowances: are provisions held by the project
sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level.
Contingency reserves are for known risks, while management reserves are funds held for
unknown risks. For example, if a project appears to be off course because the staff is
inexperienced with some new technology and the team had not identified the problem as a
risk, the project sponsor may provide additional funds from contingency reserves to hire an
outside consultant to train and advise the project staff in using the new technology.
2. Risk Identification

Risk identification is the process of understanding what potential unsatisfactory outcomes are
associated with a particular project. It involves determining which risks might affect the project
and documenting their characteristics. Participants in risk identification generally include the
following, as possible: project team, risk management team, subject matter experts from other
parts of the company, customers, end users, other project managers, stakeholders, and outside
experts.

Risk management plan and Project planning outputs are inputs for risk identification. Risk
identification requires an understanding of the project’s mission, scope, and objectives of the
owner, sponsor, or stakeholders. Outputs of other processes should be reviewed to identify
possible risks across the entire project. These may include, but are not limited to:

 Project charter.
 WBS.
 Product description.
 Schedule and cost estimates.
 Resource plan.
 Procurement plan.
 Assumption and constraint lists.
Potential Risk Conditions Associated with Each Knowledge Area

Knowledge Area Risk Conditions

Integration Inadequate planning; poor resource allocation; poor integration
management; lack of post-project review
Scope Poor definition of scope or work packages; incomplete definition
of quality requirements; inadequate scope control
Time Errors in estimating time or resource availability; poor allocation
and management of float; early release of competitive products
Cost Estimating errors; inadequate productivity, cost, change, or
contingency control; poor maintenance, security, purchasing, etc.
Quality Poor attitude toward quality; substandard design/materials
/workmanship; inadequate quality assurance program

Human Resources Poor conflict management; poor project organization and

definition of responsibilities; absence of leadership
Communications Carelessness in planning or communicating; lack of consultation
with key stakeholders
Risk Ignoring risk; unclear assignment of risk; poor insurance
management
Procurement Unenforceable conditions or contract clauses; adversarial relations

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 intermediate 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 adequate
identification of risks, or the schedule may not be complete or entirely logical.

3. Qualitative Risk Analysis

Assess the likelihood and impact of identified risks to determine their magnitude and priority.
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 importance of addressing specific risks and guiding risk
responses. Qualitative risk analysis requires that the probability and consequences of the risks be
evaluated using established qualitative-analysis methods and tools. Trends in the results when
qualitative analysis is repeated can indicate the need for more or less risk-management action.
Use of these tools helps correct biases that are often present in a project plan. Qualitative risk
analysis should be revisited during the project’s life cycle to stay current with changes in the
project risks.

Inputs to Qualitative Risk Analysis

1. Risk management plan:

2. Identified risks: Risks discovered during the risk identification process are evaluated 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 understood
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. Assumptions: Assumptions identified during the risk identification process are evaluated as
potential risks.

Risk quantification tools and techniques include

1. Probability/Impact matrixes: People often describe a risk probability or consequence as being
high, medium or moderate, or low. A project manager can chart the probability and impact of
risks on a probability/ impact matrix or chart, which lists the relative probability of a risk
occurring and the relative impact of the risk occurring. Many project teams would benefit
from using this simple technique to help them identify risks that need attention. To use this
approach, project stakeholders list the risks they think might occur on their projects. Risk
probability is the likelihood that a risk will occur. Risk consequences are the effect on project
 objectives if the risk event occurs. Analysis of risks using probability and consequences helps
identify those risks that should be managed aggressively.
2. The Top 10 Risk Item Tracking technique: Top Ten Risk Item Tracking is a qualitative risk
analysis tool. In addition to identifying risks, it maintains an awareness of risks throughout
the life of a project by helping to monitor risks. Using this tool involves establishing a
periodic review of the project’s most significant risk items with management; similar reviews
can also occur with the customer. The review begins with a summary of the status of the top
ten sources of risk on the project. The summary includes each item’s current ranking,
previous ranking, number of times it appears on the list over a period of time, and a summary
of progress made in resolving the risk item since the previous review. This example includes
only the top five negative risk events. Notice that each risk event is ranked based on the
current month, previous month, and how many months it has been in the top ten.

Monthly Ranking
Risk Item This Last Number Risk Resolution Progress
of Months
Month Month
Inadequate 1 2 4 Working on revising the entire project
planning plan
Poor definition 2 3 3 Holding meetings with project
of scope customer and sponsor to clarify scope
Absence of 3 1 2 Just assigned a new project manager to
leadership lead the project after old one quit
Poor cost 4 4 3 Revising cost estimates
estimates
Poor time 5 5 3 Revising schedule estimates
estimates

3. Expert Judgement: Many organizations rely on the intuitive feelings and past experience of
experts to help identify potential project risk. Experts can categorize risks as high, medium,
or low with or without more sophisticated techniques

Outputs from Qualitative Risk Analysis

1. Overall risk ranking for the project: Risk ranking may indicate the overall risk position 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 recommendation for project initiation,
continuation, or cancellation.

2. List of prioritized risks: Risks and conditions can be prioritized by a number of criteria. 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.

4. Quantitative Risk Analysis

Often follows qualitative risk analysis, but both can be done together or separately. Large,
complex projects involving leading edge technologies often require extensive 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.
The main techniques for quantitative risk analysis include data gathering, analysis and modeling
techniques, and expert judgment. Data gathering often involves interviewing experts and
collecting probability distribution information. This process uses techniques such as Monte Carlo
simulation and decision tree 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 contribution 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 determine 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.

Decision Trees and Expected Monetary Value (EMV)

 A decision tree is a diagramming method used to help you select the best course of action in
situations in which future outcomes are uncertain
 EMV is a type of decision tree where you calculate the expected monetary value of a
decision based on its risk event probability and monetary value

Example: Project X has a 60% Probability of success with an impact of Birr 50,000 and has a
40% chance of failure with an impact of Birr-20,000. What is the Expected Monetary Value of
this Project?
EMV of success = Birr 50,000 * 60% = Birr 30,000
EMV of failure = Birr -20,000 * 40% = Birr -8,000
Total EMV = Birr 22,000
In all cases, a positive EMV indicates that it is an opportunity while a negative EMV indicates a
Risk/Threat.
Expected Monetary Value (EMV) Example

Simulation

Simulation uses a representation or model of a system to analyze the expected behavior or

performance of the system. Monte Carlo analysis simulates a model’s outcome many time to
provide a statistical distribution of the calculated results. To use a Monte Carlo simulation, you
must have three estimates (most likely, pessimistic, and optimistic) plus an estimate of the
likelihood of the estimate being between the optimistic and most likely values

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. After
identifying and quantifying risk, you must decide how to respond to them.

Four main strategies:

 Risk avoidance: eliminating a specific threat or risk, usually by eliminating its causes or
protect the project objectives from its impact
  Risk mitigation: reducing the impact of a risk event by reducing the probability of its
occurrence. 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.
 Risk transference: shifting the consequence of a risk and responsibility for its
management to a third party. It 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 exposure. 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, warranties, and guarantees
 Risk acceptance: accepting the consequences should a risk occur. The project team has
decided not to change the project plan to deal with a risk or is unable to identify any other
suitable 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 identify risks that arise during the project. Developing a
contingency plan in advance can greatly reduce the cost of an action should the risk occur.
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
acceptable level of risk exposure, for the risks that have been accepted.

Possible Risk Strategies

 Can I avoid the risk?
 Can I reduce the risk impact or
Can I reduce the risk probability? Risk
 Can I limit the risk? Reduction
(Contingency)? Staircase
 Can I transfer the risk?
 Can I accept the risk?
General Risk Mitigation Strategies for Technical, Cost, And Schedule Risks

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.
 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 implemented.
 Specific actions to implement the chosen response strategy.
 Budget and times for responses.
 Contingency plans and fallback plans.

6. Risk Monitoring and Control

 Monitoring risks involves knowing their status
 Controlling risks involves carrying out the risk management plans as risks occur
 Workarounds are unplanned responses to risk events that must be done when there are no
contingency plans
 The main outputs of risk monitoring and control are corrective action, project change
requests, and updates to other plans
 Risk response control involves executing the risk management processes and the risk
management plan to respond to risk events
 Risks must be monitored based on defined milestones and decisions made regarding risks
and mitigation strategies
 Sometimes workarounds or unplanned responses to risk events are needed when there are no
contingency plans.