a proposed generic framework for qualitative risk … › smash › get › diva2:225091 › ...a...

��

�

A proposed Generic Framework for Qualitative Risk

Analysis Based on PMBOK

�

�

�

Master’s Thesis

Department of Project, Innovation and Entrepreneurship

Linköping Institute of Technology

By

Ershad Zarkani

Supervisor

Rune Olsson

�

LIU-IEI-TEK-A--09/00635--SE� �

A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK�

�

��

�

Abstract

This thesis presents a generic framework for project managers and/or other stakeholders to assist them in

qualitatively assessing and evaluating project risks. The main structure of this framework is constructed

based on risk management area in PMBOK (Project Management Body of Knowledge) standard.

Additionally, different best practices and methods in the field of risk management and decision making

are studied and embedded in the framework. In spite of being theoretical in nature, the framework can

contribute to the project risk management area developed by PMBOK, opening the possibility of further

research for its verification.��


�

��

�

Acknowledgment

This master thesis is the author’s finishing of the Master of Science program in Manufacturing

Management at Linköping Institute of Technology.��

First I would like to thank to my supervisor, MR. Rune Olsson, for his help, guidance, and

patience throughout this project.

Then I would like to thank to all the friends who gave me supports and motivations for

accomplishing this paper.

Finally, I wish to express my love and gratitude to my beloved family; for their understanding

and endless love, through the duration of my studies.

May 2009-05-21

Ershad Zarkani �


�

��

�

��1. Introduction��

1.1.� Background��

1.2.� Purpose��

1.3.� Method��

1.4.� Limitations��

1.5.� Outline��

2. General Concepts of Project Management��

2.1. Project Concept��

2.1.1. Temporary characteristic of Project��

2.1.2. Uniqueness characteristic of Project��

2.2. Project Life Cycle��

2.2.1. Basic Project Life Cycle��

2.2.2. Phased development Life Cycle��

2.2.3. Prototyping project life cycle��

2.3. Project Management Concept��

2.3.1. Project Management VS. General Management��

2.4. Project Management Methodologies��

2.4. PMBOK and Knowledge Areas��

3. Project Risk Management: An Overview��

3.1. Risk Concept��

3.1.1. Risk Classification��

3.1.2. Risk Attitude��

3.1.3. Project Risk Management Concept��

3.2. PMBOK’s Project Risk Management Processes ��

3.2.1. Risk Management Planning��

3.2.2. Risk Identification��

3.2.3. Qualitative Risk Analysis��

3.2.4. Quantitative Risk Analysis��

3.2.5. Risk Response Planning��

3.2.6. Risk Monitoring and Control��

3.3. PMBOK -A structured and comprehensive model for Project Risk Management-��


�

��

�

3.4. Risk Assessment based on Explicit or Tacit knowledge��

4. A Proposed Generic Qualitative Project Risk Assessment Framework��

4.1 Preface��

4.2 A Framework��

4.2.1 Forming a team of decision makers��

4.2.2 Gathering all possible information about risks��

4.2.3 Checking the availability, quality, and reliability of the collected information��

4.2.4 Developing Risk Breakdown Structure (R.B.S) based on internal and external sources of risk��

4.2.5 Risks screening��

4.2.6 Developing a Probability-Impact Matrix for both internal & external risks��

4.2.7 Making sure not to over focus on certain type of risk��

4.2.8 Updating risk register��

5. Conclusion��

Bibliography��

Appendix A: Characteristics of Good Project Management (3)��

Appendix B: The process groups of project management according to PMBOK (Third edition 2004) (6)

��

Appendix C: Mapping of the Project Management Processes to the Project Management Process

Groups and the Knowledge Areas (6)��

Appendix D: The General Possible Risks with their Impacts (39)��

Appendix E: These are some sample of Risk Assessment Methods (39)��

Appendix F: These are some samples of checklists that can be used in Risk Identification and

Assessment processes (26)��

�

�

� �


�

��

�

��

��

�� !"��

��#�!"�$�$��#%�&��

��&'"�!%�&��#��""��#"��

��(&��!��&"�!&$��!##�&��!%�&��#��""��#"��&�#��

��)��*��+!&!��%�&��,&�*��$��-��!"�!&$��""�"��

��.��"��/�"'��"010��"��"��&��&%�&��

��)��*��/�"'�+!&!��%�&��

��/�"'�+!&!��%�&��""��*�2�!��!%��

�� ! ��!&$�(%#!��+!��3��

��+4),�!&$��"'�%!&!��%�&��

��5�!��!��/�"'�-&!��"�"�!"�!�4�!�'� �3��

��-��#�"��6�&��!%�*��'��5�!��!��/�"'�-&!��"�"��

��"�0��%��7.��/��&��"��

��-&��3!%#��6�&��/4.��

��/�"'�/!&'�&��%��

��/�"'��%#�&�&�"��

��!&��3!%#��)�$�&!�� ! ��!&$�(%#!��+!��3��

��!&��3!%#��!�$�&!�� ! ��!&$�(%#!��+!��3��

�

��

�8! ��0�/�"'�+!&!��%�&��!&&�&��#��""��%#�&�&�"��

8! ��0�/�"'�($�&��!��&�#��""��%#�&�&�"��

8! ��0�5�!��!��/�"'�-&!��"�"�#��""��%#�&�&�"��

8! ��0�5�!&��!�� /�"'�-&!��"�"�#��""��%#�&�&�"��

8! ��0�/�"'�/�"#�&"��#�!&&�&��#��""��%#�&�&�"��

8! ��0�/�"'�+�&��&��!&$��&��#��""��%#�&�&�"��

8! ��9�-&��3!%#��"'�!&$��"#�&"� ��"�:��;��

8! ��0�/�"'�2�"��#��&"�:�3��!��$��%�/�"'��&�"�!&$�.��&!��"�8! ��;�:��;��

8! ��9�-&��3!%#��/�"'�/!��&�� &��<!��&��

8! �� 0�-&��3!%#��/�"'�� ! ��"��

8! ��9�-&��3!%#��/�"'��&"�=��&��:�%#!��";��

8! ��9�-&��3!%#��2��&��&"�� ! ��.�!��"�:� ;��

8! ��0�-&��3!%#��2��&��&"��&"�=��&��.�!��"�:� ;��

8! ��9�/�"'�.��/!&��"��

8! ��0�-&��3!%#��#�� ! ��!&$��%#!��%!��3��

��


�

��

�

1. Introduction

�

1.1. Background

As risks are inherent in projects, the application of risk management will help project stakeholders avoid

events that could result in negative consequences on project objectives and accept incidents leading to

positive outcome. In this context, the Project Management Institute (PMI), a global community of more

than 265000 professionals in over 170 countries, sets standards, provides education, carry out researches,

and offers training to strengthen the project management professionalism (1). It was founded in 1969 and

has been recognized by the American National Standard Institute (ANSI) as an authorized standards

developer (2).

�A guide to the Project Management Body of Knowledge (PMBOK) is a standard, developed by this

company, which offers the project management best practices to the industries and organizations. Risk

management process is covered in one of the nine areas of this standard. Regarding to PMBOK, the

process of risk analysis which is divided into Qualitative and Quantitative analysis is at the midst of risk

management process. In recent years, quantitative analysis, with the aid of several tools and techniques

such as simulation, has been paid more attention than qualitative one. Also, although PMBOK provides

general guidelines and recommendation for risk analysis, it does not say much about the modality of their

implementation. �

1.2. Purpose

The purpose of this thesis is to propose a generic framework for qualitatively evaluating and analyzing

project risks based on the PMBOK and other previous best practices. The outcome can be applied by the

project managers, project risk assessors, and other risk experts in the context of project management.

1.3. Method

The main structure of proposed framework is founded on the PMBOK platform for risk management.

Other best practices and tools in the field of risk management and decision making are embedded in the

framework in order to enhance the platform and provide the modality of implementation of PMBOK

guidelines.

1.4. Limitations

Because of lacking access to the last version of PMBOK standard – Forth edition, 2008 – the third edition

of this standard which was published in 2004 has been used in this thesis. The framework presented in

this study mainly focuses on using explicit knowledge i.e. codified and stored organizational knowledge

about project risk from past projects such as risk profiles and documents and does not put emphasis on

tacit knowledge which is based on experts’ personal knowledge. However, in order to prevent biases

which may caused by experts’ tacit knowledge some guidelines have been prepared in the study. Also, the

framework has not been implemented in any real project so its main limitation is its theoretical validity.

1.5. Outline

The current thesis is divided in five chapters. Starting with an introduction that provides the readers with

the background to the thesis, the first chapter also contains the project’s purpose, method, and limitation.


�

��

�

Chapter 2 describes general concepts of project management and chapter 3 presents key concepts of risk

and risk management as well as managing project risk according to PMBOK. Both chapters aim at

making those readers knowledgeable who may not be familiar with these areas. In chapter 4, following

from theoretical foundations developed in chapters 2 and 3, the output of thesis – the framework – is

presented. Finally, the conclusions from the thesis are provided in chapter 5.��


�

��

�

2. General Concepts of Project Management In this chapter some fundamental concepts related to project and project management are explained. It

provides the readers with the basic definition of project and project management, and PMBOK1

processes.

2.1. Project Concept

There are a number of different definitions about project concept regarding to current lexicons. Some

state project as a planned or scheduled activity while others stress on non-repetitive and unique properties

of an activity in contrast with routine activities. However, there is an opaque frontier between these two

kinds of activities i.e. Projects and ongoing ones.

OGC – The Office of Government Commerce – defines a project:

“as a unique set of coordinated activities, with definite starting and finishing points, undertaken by an

individual or team to meet specific objectives within defined time, cost and performance parameters as

specified in the business case (3).

APM – The UK-based Association for Project Management – describes a project as "a unique set of

coordinated activities, with definite starting and finishing points, undertaken by an individual or

organization to meet specific objectives within defined time, cost and performance parameters" (4).

In another definition, Kerzner (5) states “A project can be considered to be any series of activities and

tasks that:

• Have a specific objective to be completed within certain specifications

• Have defined start and end dates

• Have funding limits (if applicable)

• Consume human and nonhuman resources (i.e., money, people, equipment)

• Are multifunctional (i.e., cut across several functional lines)”

Generally, main activities of organizations can be divided into “ongoing operations” and “projects”. The

major difference between these two types is operations are ongoing and continuous while projects are

temporary and unique. In spite of this distinction these two approaches most of the time have the same

points. Some of them are as followed (6):

- Both require people to be carried out

- Both confined by limited resources including people, money…

- Both first have to be planned, then executed and finally be controlled.

In PMBOK, project is defined in this way: “A project is a temporary endeavor undertaken to create a

unique product, service or, result” (6). According to this definition, two important characteristics of

project i.e. temporary and unique product or service can be obtained which will be discussed further.

Moreover, to determine its completion, project needs well-defined goals.

�

��Project Management Body of Knowledge�


�

��

�

2.1.1. Temporary characteristic of Project

Every project happens in a definite and finite period of time. It has a specific beginning and end points.

Furthermore, temporary can refer to either the limited time frame of projects to make their output or the

nature of project teams which are broken up at the time of project completion (6). In general, duration and

specified completion date of a project cannot be infinite because it is not a continuous job.

2.1.2. Uniqueness characteristic of Project

Uniqueness points to unique deliverables including products, services, and results. Project is organized to

meet temporary needs and is one-of-kind undertaking (7). Each project has some factors that make it

unique and distinct from other similar projects. For instance, two different dam construction projects have

quite different final product. Here, some degree of customization is such a factor.

2.2. Project Life Cycle

�

Life cycle refers to this fact that every project finally ends. Like bio-systems, projects are born, live,

grow, and then eventually die. Project life cycle consists of sequential phases that connect the beginning

of a project to its end (6). Better understanding of these phases can help executives to better manage

resources in order to obtain goals (5). Clements (8) presents a generic life cycle in 4 phases based on the

relative amount of time and effort required for each phase. (See figure 2.1)

�

��

Regarding complex nature and diversity of projects, there is no particular life cycle that can be valid for

all projects (9). Here, three kinds of generic project life cycles are discussed:


�

��

�

2.2.1. Basic Project Life Cycle

This model which was first introduced by Weiss and Wysocki (10) comprises five phases. Figure 2.2

illustrates these stages as well as the sequence of works. “Define phase” mainly deals with feasibility

studies and decisions that whether project should go forward or not i.e. “go/ no go decision”. The output

of this stage is POS - project overview statement – which provides brief outline about the goals and scope

of the project.

In “Plan phase” project activities are identified and sequenced budgets are estimated and project staffs are

determined. The aim of “organize phase” is organizing teams, tools and communications for project

execution. Lunching the project plan and monitoring of project progress are the key tasks of “Execute

phase”. In “Close phase” project is finished and final reports and documentations are carried out. Since

the change from one phase to the next one does not happen suddenly, these five phases overlap each

other. Specifically, activities of one phase may be a part of another one. (9)

�

��

2.2.2. Phased development Life Cycle

In this model, project divided into several phases forming a series of closely linked mini-project (9). Each

phase implements a part of the whole project and is evaluated by users. Feedback approach which is used

in this model provides better understanding about the next phase’s requirement. Chief activities of a

phased development life cycle are shown in figure 2.3 as a 4-phase model.


�

�

�

�� !��"�#��

2.2.3. Prototyping project life cycle

In this kind of life cycle, a prototype or model is made and shown to users so they can provide feedback.

The prototype is developed gradually through several iterations. These iterations are similar to those

phases in phased development life cycle. Difficult costs and schedules estimating as well as complicated

project control are disadvantages of prototyping project life cycle.�(9) ��

2.3. Project Management Concept

Like project, project management has also different definition for itself. With the classical management

approach, Kerzner (5) describes project management as “the planning, organizing, directing, and

controlling of company resources for a relatively short-objective that has been established to complete

specific goals and objectives”. Some others define it as the process of managing, dedicating, and timing

resources to get a certain goal in and efficient manner or alternately “The systematic integration of

technical, human, and financial resources to achieve goals and objectives” (11).

OGC in P3M32 - Portfolio, Programme and Project Management Maturity Model�9�explains project

management in this way: “Project management guides a project through a visible set of activities, from

controlled start-up, through delivery, to controlled closure, and review. There will be visible milestones

and well-managed resources, stakeholders and interdependencies, with all parties involved being clear

about their goals and individual responsibilities” (3). Appendix A, lists some characteristics required for

a good project management based on P3M3.

��P3M3 is a reference guide for improving portfolio, programme and project management processes.


�

��

�

Among different definitions, PMBOK also presents comprehensive one and since in this paper the focus

is on the PMBOK standard, forth the framework of study will be approached mainly from this standard.

PMI3 (6) defines project management as “The application of knowledge, skills, tools, and techniques to

project activities to meet project requirement” and categorizes it into five different and correlated process

groups, namely, initiating, planning, executing, monitoring, controlling, and closing.

Below, each is explained briefly:

• Initiating processes: formally allowing project or project phase to be started

• Planning processes: defining and filtering objectives as well as choosing the best of alternative

courses of action to obtain project objectives.

• Executing processes: matching up all resources such as people, tools… to accomplish the project

plan.

• Monitoring & Controlling processes: identifying problems in or variances from plan by regularly

observing project execution to enable managers to take corrective actions.

• Closing processes: formally terminating all project or phase activities and delivering the final

product of project or phase or closing the canceled projects.

These process groups organize and explain how project activities will be accomplished to meet project

goals (12). In Appendix B, schematic figures of process groups with their relationships based on version

2003 are available.

It should be mentioned that these process groups are connected with each other depending on the output

they create, that is the outputs of some processes can be inputs for other processes (6). Figure 2.4 shows

the linkage among these process groups.

�

��$��#%��"�#��(6)

��Project Management Institute�


�

�

�

Process groups may have parallel activities at different levels of project phases. This cause groups overlap

each other throughout the project. This interaction is shown in figure 2.5.

�

��&�'#��#��# ��!��#��"�#��#�� (6)

Moreover, each process group consists of three parts like a generic process (6):

• Inputs: including all documents or documentable items that may obtained from previous process

or processes.

• Tools & techniques: including all procedures, tools, techniques, and mechanism required to run

processes and create outputs.

• Outputs: including all documents or documentable items that are achieved from processes.

Before furthering on PMBOK methodology Structure, it would be beneficial to review some differences

between “Project management” and “General management”.

2.3.1. Project Management VS. General Management

While general management presents the basis for building project management (6), successful project

management requires that the project manager has a certain set of skills distinct from those possessed by

general manager. In other word, without having these abilities managers would face various problems

when overcoming obstacles such as risks, complexities, and changes in the course of managing projects.

Kerzner (5) proposes several skill requirements for project mangers such as:

• “Team building

• Leadership

• Conflict resolution

• Technical expertise

• Planning

• Organization

• Entrepreneurship

• Administration


�

��

�

• Management support

• Resource allocation”

Some differences between Project management and General management:

• Unlike general managers, project managers are responsible for completing a project not carrying

on routine tasks (13).

• Most of general management activities are naturally routine and repetitive while project

management activities often are performed similarly regarding to the uniqueness property of

projects.

• Most of the general management teams are rather constant while project teams often change

concerning to the shifting nature of the project life cycle.

2.4. Project Management Methodologies

Charvat (14) stated that “A methodology is a set of guidelines or principles that can be tailored and

applied to a specific situation. In a project environment, these guidelines might be a list of things to do. A

methodology could also be a specific approach, templates, forms, and even checklists used over the

project life cycle.”

There are different kinds of project management methodologies developed in recent decades. In general,

most of these methodologies share main common components as follows:

• Project management guideline: includes standards, best practices, approaches, checklists, and

bodies of knowledge used over the project life cycle. (e.g. PMBOK, PRINCE2, ISO, PROMPT)

• Project management life cycle: has been discussed in section 2.2

• Project management tool: primarily refers to computerized software applications developed for

designing, tracking, and controlling the project schedule and resource allocation. (e.g. Microsoft

project or Primavera project planner)

• Project management techniques: a set of techniques and skills which are required for project

managers to accomplish project activities successfully. These techniques are both “hard

techniques” such as Gantt chart, Work breakdown structure (WBS), and critical path method

(CPM) analysis and “soft techniques” such as change management, decision-making techniques,

and team-building, problem solving and leadership methods.

• Project management templates: contain a set of standard documents used by project managers

to perform projects. (e.g. change request form, timesheet form, and risk form)

Here, some well-known project management methodologies will be introduced briefly as follow:

• PMBOK (PROJECT MANAGEMENT BODY OF KNOWLEDGE)

PMBOK is a project management standard which was first released by the Project Management

Institute (PMI) in 1996. The PMBOK recognizes five process groups and nine knowledge areas

generally admitted as best practices within the project management discipline. Before, the five

process groups have been considered and also knowledge areas will be discussed in the following

section 2.4.


�

� �

�

• PRINCE2 (PROJECT IN CONTROLLED ENVIRONMENT)

This method was initially based on PROMPT. PRINCE2 which is a process-based methodology

for successful project management was published in 1996 by CCTA -the Central Computer and

Telecommunications Agency- which now forms part of the Office of Government Commerce -

OGC-. The major characteristics of this methodology are (15):

• “Its focus on business justification

• A defined organization structure for the project management team

• Its product-based planning approach

• Its emphasis on dividing the project into manageable and controllable stages

• Its flexibility to be applied at a level appropriate to the project.”

Moreover, although PRINCE2 is tailorable to the needs of a specific project it can be heavy-duty

approach for small projects if it is not tailored to the needs of the project appropriately (16).

• PROMPT (Project Resource Organization Management & Planning Techniques)

The PROMPT Methodology was established in 1975 by Simpact Systems Limited Company with

the aim of providing an appropriate framework for managing the implementation of IT projects.

This methodology consists of five main modules as follows (17):

• PROMPT I - Strategic Planning

• PROMPT II - System Development

• PROMPT III - Operations, Maintenance and Enhancement

• QSTAR Quality Assurance

• PROMPT Software Support Tools

Moreover, the PROMPT lifecycle involves different phases, these are (17):

• Initiation phase

• Specification phase

• Design phase

• Development phase

• Installation phase

• Operation phase

• IDEAL (Initiating, Diagnosing, Establishing, Acting, Learning)

IDEAL is an organizational improvement model which is developed by Software Engineering

Institute (SEI) for facilitating improvement actions. This model provides an infrastructure

directing companies to plan and implement software process improvement (SPI) projects

effectively. (18) It also consists of five phases:

• Initiating phase

• Diagnosing phase

• Establishing Phase

• Acting Phase

• Learning phase


�

��

�

• 5-STEPS (5 Steps To Ensure Project Success)

The 5-STEPS are structured methodology developed to enable project organizations to perform

projects within definite budget and timely. While 5-STEPS generally admits the structure of the

PMBOK, but mainly puts emphasis on planning and controlling process groups activities to

create and manage a sensible schedule (19). This methodology contains five steps which are

accomplished sequentially (19):

• “Organize the Project (Scope and Stakeholders)

• Plan the Work Flow (Schedule)

• Set Reasonable Objectives (Resources)

• Gain Commitment (From Stakeholders)

• Manage for Success (Execute and Control)”

• SUPRA

Supra and prince have a similar structure and framework (20). The main processes of supra are

(20):

• Project organization structure which refers to overall project and Work package level.

• Technical plan

• Project monitoring and control

• Quality assurance

• Document management��

2.4. PMBOK and Knowledge Areas

�

As mentioned in previous section, PMBOK categorizes project management knowledge and processes

into nine knowledge areas (see figure 2.6). Here these knowledge areas are succinctly reviewed below (6)

(12):

• Project Integration Management: mainly consists of processes and activities needed to make

sure that diverse elements of projects are coordinated correctly. It includes authorization,

creation, and execution of project plan as well as managing, controlling, and documenting

changes to it (12).

• Project Scope Management: includes processes and activities needed to ensure that project

encompasses only the required works, essential to complete the project (12). Corroborating the

alignment of these works with project requirements is another responsibility of this area.

• Project Time Management: consists of processes and activities needed to make sure that

project is completed timely.


�

��

�

• Project Cost Management: includes processes and activities needed to ensure that project will

be accomplished within accepted budget.

• Project Quality Management: consists of processes required to make sure to that the

deliverables of the project satisfy its requirements (12).

• Project Human Resource Management: “is the process of successfully applying the right

resource to the project work in the most effective way to accomplish the project goals while

maintaining cost and schedule” (12).

• Project Communications Management: includes timely and proper generating, collecting,

disseminating, and storing communication (12).

• Project Risk Management: is the process of planning, identifying, categorizing, weighting and

assessing the project risks to determine their positive or negative effects on the project. In chapter

three, this area will be further discussed.

• Project Procurement Management: is the process of purchasing project demands in the form of

goods or services from outside the project team (12).


�

��

�

�

��(�)!��!��*�� +�#��"�#��,#�*�� -��# ��(6)��

In Appendix C, the mapping of these processes is shown.


�

��

�

3. Project Risk Management: An Overview The purpose of this chapter is to provide readers with terms and definitions about risk and risk

management that are to be used in next chapters. It also fully explains the project risk management

processes based on PMBOK.

3.1. Risk Concept

Like project there are several various ways of defining risk. In the project management context, risk:

“is a measure of the probability and consequences of not achieving a defined project goal. Most

people agree that risk involves the notion of uncertainty.” (5).

“is the implication of the existence of significant uncertainty about the level of project

performance achievable” (21).

“is any uncertain event that, if it occurs, could prevent the project realizing the expectations of

the stakeholders as stated in the agreed business case, project brief or agreed definition. A risk

that becomes a reality is treated as an issue”. (22)

In the PMBOK framework, project risk is “an uncertain event or condition that, if it occurs, has a

positive or negative effect on at least one project objective, such as time, cost, scope or quality” (6). The

main points which can be derived from this definition are as follows:

• All projects include risks.

• Uncertainty in event or condition occurrence

• Project risk can contain both events with positive effects (opportunities) and negative

effects (threats).

• Risk may have cause or causes which result in one or more consequences.

Here the key word that distinguishes this definition from others is "opportunities" which give

notice to managers to identify risks carefully in order to respond to them effectively.

In general, risks refers to future (event has not happened yet) and uncertainty, that is if an event does not

belong to future or if there is not any doubt about its occurrence, we cannot accept it as a risk.

Often risk and uncertainty are distinguished from each other. The distinction is usually that risk

is taken to have quantifiable characteristics, while uncertainty does not. Uncertainty, in contrast, refers to

situations where it is not possible to attach a probability to the possibility of occurrence of an event (23).

3.1.1. Risk Classification

There are several various risk categorizations from different perspectives. From general viewpoint, Lanza

(24) categorized risks into:

• Known Risks: the existence and consequences of this kind of risks are known (e.g., you

know that you will be fined 1000 SEK for driving your car after inspection date)


�

��

�

• Unknown known risks: the existence of risks is known but their consequences are not (e.g.,

you do not know how much you will be fined for driving away in front of police officer after

inspection date.)

• Unknown unknowns risks: there is not any knowledge at this time about the existence and

consequences (e.g., you forgot to inspect your car and driving it past the inspection date)

In projects, while, Haimes (25) categorizes risks into:

• Hardware failures

• Software failures

• Programmatic risks including cost overrun and delay in schedule.

PMBOK classifies risks as follows (12):

• Technical, quality, or performance risks: Novel, untried, or complex technology which is

being used on the project as well as changes to the technology during the project execution can

be sources of Technical risks. Quality risks are expectation levels of impractical quality and

performance.

• Project management risks: These risks are related to the mistakes in the management of the

project e.g., abortive allocation of time, resources, and scheduling; and undesirable work results

(i.e. stakeholders do not accept the outcomes).

• Organizational risks:�Performing organization can be source of project risks, for example,

through irrational cost, time, and scope expectations; poor project prioritization; insufficient

funding or the disruption of funding.

• External risks:�Risks which are outside of the project but influence it straight such as legal

issues, labor issues, and weather.

Among different classification, we may prefer the structure which provided by Datta et.al (26). According

to that structure, projects are affected by External and Immediate (internal) environment (see figure 3.1).

Internal environment which is somehow project- related involves customers, suppliers, contractors, and

investors. External environment, on the other hand, refers to social, technological, political, legal, and

economical environments which can have significant effects on projects. Consequently, project risks can

be grouped into Internal and External risks regarding to the environments in which they likely to occur.


�

��

�

�

��.��/��%�!��010!��!��#!��#"�#��(��

3.1.2. Risk Attitude

People and corporations have different attitudes and approaches toward risk and its management which

may be affecting business performance or success. Risk attitudes can be classified as follows (27):

• Risk-averse: are those investors (conservative investors) who prefer less risk for a given level of

return.�

• Risk-seekers: are those investors who invest in vulnerable situations and are willing to pay for

the risks taken.

• Risk-aware: are those investors who look for uncertainties and take correct action.

• Risk-ignorant: are those investors who are not knowledgeable (deliberately or unwittingly) about

their risk exposure.

3.1.3. Project Risk Management Concept

All projects are undertaken to satisfy the specific goals that stakeholders agreed on. In the course of

project execution whatever impedes project team from meeting those goals is realized as a risk. Effective

project management thus necessitates a capability to cope with risks and uncertainties. There is a variety

of risk management procedures that can be established in order to handle project risks more efficiently.

Since in this paper focus is on PMBOK standard, it is better to present the project risk management

definition based on this methodology. PMI states (6):


�

��

�

“Project Risk Management includes the processes concerned with conduction risk management

planning, identification, analysis, responses, and monitoring and control on a project; most of

these processes are updated throughout the project. The objectives of Project Risk Management

are to increase the probability and impact of positive events, and decrease the probability and

impact of events adverse to the project.”

According to this standard, the project risk management knowledge area thus comprises (6):

• Risk Management Planning: making decisions about the ways in which risk management

activities for a project are approached, planned, and executed.

• Risk Identification: identifying the risks and then documenting how their occurrence might

influence the project.

• Qualitative Risk Analysis: analyzing and prioritizing the risks based on their probability of

occurring and the impact on the project

• Quantitative Risk Analysis: numerically assessing the probability and impact of the identified

risks.

• Risk Response Planning: building up actions and options to decrease the likelihood of risks

from negatively influencing the project’s objectives, and to increase the possibility of positive

risks or opportunities that can support the project.

• Risk Monitoring and Control: monitoring identified risks for signs that they may be

occurring, controlling identified risks with the agreed responses, seeking for new risks that may

move into the project, performing risk response planning, and assessing their efficiency during

the project life cycle.

All processes are quite linked together and they not only interact with each other but also with the

processes in other knowledge area. Figure 3.2 and 3.3 depict the overview and process flow diagram of

these processes respectively. In the following section the structure and processes of PMBOK’s project

risk management will be fully presented.


�

��

�

�

��)!��!��*�� /��%�+�#��"�#��(6)�


�

��

�

�� /��%�+�#��"�#��*�2��"�(6)

3.2. PMBOK’s Project Risk Management Processes 4

Here, readers will be provided with thorough information on the different components of each process.

��8��"�"��&��"��3��!��$��%�>-�6��$��+!&!��%�&��4�$��,&�*��$��:�+4),?�6��$�;�@�+(@�

� �A�:;�


�

� �

�

3.2.1. Risk Management Planning

This process which is essential for superior executing the other risk management processes should be

accomplished early during the project planning. It also consists of four inputs and one output as follows in

table 1: fully

3��0�/��%�+�#��"�#��##�#��"��#�#��

Inputs

Tools & Techniques

Outputs

1. Enterprise

environmental factors

2. Organizational process

assets

3. Project scope statement

4. Project management

plan

1. Planning meetings and analysis

1. Risk management plan

3.2.1.1. Inputs to Risk Management Planning

1. Enterprise environmental factors: Organization’s enterprise environmental factors and system

can have effect on the project’s success. Company culture, industry standards, marketplace

conditions, project management information systems, and stakeholder risk tolerances. Thus, the

approaches toward risk and risk tolerance of organizations and project human resources can

affect the project plan.

2. Organizational process assets: Points to all predefined approaches to risk management that an

organization can have such as risk categories, authority level for decision making, and roles and

responsibilities.

3. Project scope statement: The formal documentation of project deliverables (including project

output and peripheral results e.g. project management reports), objectives, and justification. It

determines project scope and provides a basis for making future project decisions. Project scope

statement may be reconsidered and edited throughout project life cycle. It also can include:

• Product scope description: Explains the project’s final result (product or service)

specifications.

• Product acceptance criteria: Refers to process and criteria for admitting finished

product.

• Project boundaries: Specifies what is entailed within and excluded from project.

• Project constraints

• Project assumptions

4. Project management plan: Directs the project manager through the Execution, monitoring and

controlling, and closing process groups which have been described in the previous chapter.

Also, it is provided and developed by project management, and stakeholders. The project

management plan includes the documentation of all planning process groups’ outputs.


�

��

�

3.2.1.2. Tools & Techniques for Risk Management Planning

�

1. Planning meetings and analysis: In the process of risk management planning, in order to

transform input to output i.e. risk management plan one or several planning meetings are used.

Normally, these meetings consist of project manager, customers, project staffs, and stakeholders

such as sponsors, end users, clients, vendors and functional managers. The major objective of

these meetings is: determining fundamental procedures for managing risk management activities

as well as assigning the risk responsibilities.

3.2.1.3. Output from Risk Management Planning

1. Risk management plan: Explains how other risk management activities throughout the process

will be planned and prepared. Specifically, it determines:�

• How project risks are identified.

• How quantitative and qualitative analysis will be accomplished.

• How risk response planning will occur.

• How project risks will be controlled and monitored.

Risk management plan typically consists of:

• Methodology: Refers to available tools, acceptable approaches, and accessible data

sources which are used for risk management.

• Roles and Responsibilities: Each type of the risk management activities within the

project plan will be assigned by individuals or groups in order to lead or support those

activities.

• �Budgeting: Budget must be allotted to the project’s risk management activities.

• Timing: Determining how often and when risk management activities should occur

throughout the project as well as embedding those activities in project schedule.

• Risk categories: Categorizing risks helps systematically identifying, organizing,

ranking, and isolating risks in the project.

• Definitions of risk probabilities and impact: Provides general definitions of

probabilities and impact levels for future use in qualitative risk analysis process.

• Probability and impact matrix: In this matrix each risk is rated on its probability of

occurring and its impact on project objective.

• Revised stakeholders’ tolerances: Risk tolerances of stakeholders may be modified in

the risk management planning process regarding to the particular project they apply to.

• Reporting formats: Describes how the outputs of the risk management processes

should be documented, examined, and communicated to management, customers, and

other stakeholders.

• Tracking: Supports continuing decisions within the current project and future projects

by documenting all actions regarding to risk management processes. It, also, serves as

source of information for management, the project team, and other stakeholders.


�

��

�

3.2.2. Risk Identification

Since new risks emerge during project life cycle, identifying risks has to be an iterative task. Risk

identification process includes five inputs and one output as follows in table 2:

3��0�/��%�' �#��#��"��#�#��

Inputs

Tools & Techniques

Outputs

1. Enterprise environmental

factors


assets



5. Project management plan

1. Documentation reviews

2. Information gathering techniques

3. Checklist analysis

4. Assumptions analysis

5. Diagramming techniques

1. Risk register

3.2.2.1. Inputs to Risk Identification

1,2,3,5 have been explained in previous section (3.2.1.1).

• Risk management plan: Information about risk categories, roles and responsibilities,

budgeting, and timing which can be found in risk management plan are key inputs to the risk

identification process.

3.2.2.2. Tools & Techniques for Risk Identification

• Documentation reviews: The project plan, scope, constraints and assumptions, and prior

project files are reviewed and examined.

• Information gathering techniques: Techniques such as brainstorming, Delphi technique,

interviewing with experts and experienced stakeholders, root cause identification, and SWOT

analysis.

• Checklist analysis: It is a simple technique for identifying risk especially when the current

project is similar to projects completed in the past. Since applying checklists may limit

decision makers to analyzing the only risk categories which have been set down on the

checklists, it is essential task for project management team to update and revise checklists to

make them accurate enough for future usage in other projects.

• Assumptions analysis: means analyzing the project assumptions to identify those risks

which arise from false assumptions.

• Diagramming techniques: The common diagramming techniques for risk identification

process are cause-and-effect (Ishikawa) diagrams, System or process flow charts, and

influence diagrams.


�

��

�

3.2.2.3. Output from Risk Identification

• Risk Register: It is a documentation of risk identification process outputs. Risk register also

includes the results of the other risk management processes. It mainly contains information as

follows:

• List of identified risks

• List of potential responses

• Root causes of risks

• Updated Risk categories

3.2.3. Qualitative Risk Analysis

Here the aim is to qualify the identified risks. The output of this analysis will be used in quantitative risk

analysis and/or risk response planning. This process contains four inputs and one output as follows in

table 3:

3��0�4��!��/��%�-#��"��#�#��

Inputs

Tools & Techniques

Outputs


assets



4. Risk register

1. Risk probability and impact

assessment

2. probability and impact matrix

3. Risk data quality assessment

4. Risk categorization

5. Risk urgency assessment

1. Risk register (updates)

3.2.3.1. Inputs to Qualitative Risk Analysis

All inputs have been discussed in previous sections.

3.2.3.2. Tools & Techniques for Qualitative Risk Analysis

• Risk probability and impact assessment: During meeting or interview with project experts

project risks are rated according to their probability and impact. Each risk is measured based

on its likelihood and its impact. Here risk probability is the likelihood that a risk event may

happen, while risk impact is the consequence that the result of the event will have on the

project objectives. Project risks can be ranked from very high to very unlikely or in cardinal

format e.g. from .01(unlikely) to 1.0 (certain).

• Probability and impact matrix: This matrix maps out the risks, their probabilities and

possible impacts. It also determines the combinations of probability and impact to rate the

risks in different priorities e.g. low, moderate, and high. Probability falls between 0 and 1.

Impact, in other hand, which measures the severity of risk effect on the project objective, can

be given ordinal or cardinal numbers depending on organizational preferences. Risks can be


�

��

�

scored by multiplying risk probability and its impact. Figure 3.3 shows a Probability and

impact matrix sample.

• Risk data quality assessment: Since the use of low quality risk data can damage the

credibility of the qualitative risk analysis, controlling data precision is essential task for

decision makers. Typically, the level of understanding of the project risks, and availability,

reliability, accuracy, quality of data risk are assessed.

Probability and impact matrix

Probability Risk Score=P*I

0.9 0.009 0.18 0.45 0.72

0.6 0.006 0.12 0.30 0.48

0.5 0.005 0.1 0.25 0.4

0.3 0.003 0.06 0.15 0.24

0.01 0.2 0.5 0.8

Impact on an objective

��$��# �'"��+��5�

• Risk categorization: Classifying risks can help project teams develop effective risk responses.

• Risk urgency assessment: Providing urgent evaluation for those risks calling for quick

responses (first, the more prior).

3.2.3.3. Output from Qualitative Risk Analysis

• Risk register (updates): The risk register which has been created in risk identification process

is updated by the results of qualitative risk analysis process. The new updated items are:

• Relative ranking or priority list of project risks

• Risks grouped by categories

• List of risks requiring response in the near-term

• List of risks for additional analysis and response

• Watchlists of low priority risks

• Trends in qualitative risk analysis results


�

��

�

3.2.4. Quantitative Risk Analysis

In this process after prioritizing risks in the qualitative risk analysis phase, those risks and their effects are

analyzed and assigned numerical ranking. Quantitative Risk Analysis process includes five inputs

and one output as follows in table 4:

��

3��$0�4��#��!� /��%�-#��"��#�#��

Inputs

Tools & Techniques

Outputs


assets



4. Risk register


1. Data gathering and representation

techniques

2. Quantitative risk analysis and

modeling techniques


3.2.4.1. Inputs to Quantitative Risk Analysis

1,2,3,4 have been discussed in previous sections.

• Project management plan: Mainly two items of project management plan are required in this

process i.e. project schedule management plan and project cost management plan.

3.2.4.2. Tools & Techniques for Quantitative Risk Analysis

• Data gathering and representation techniques: The most commonly techniques used are:

interviewing, probability distribution, and expert judgment.

• Quantitative risk analysis and modeling techniques: Here the most common techniques are:

• Sensitivity analysis: Determining which individual risks have the most impact on the

project’s success.

• Expected monetary value analysis: “Expected monetary value (EMV) analysis is a

statistical concept that calculates the average outcome when the future includes

scenarios that may or may not happen (i.e. analysis under uncertainty)” (6).

• Decision tree analysis: “Decision tree analysis is usually structured using a decision

tree diagram that describes a situation under consideration, and the implications of

each of the available choices and possible scenarios. It incorporates the cost of each

available choice, the probabilities of each possible scenario, and the rewards of each

alternative logical path” (6).

• Modeling and simulation: Project simulations enable the project team to assess

“what-if” scenarios more easily. The most common simulation technique used is

Monte Carlo.


�

��

�

3.2.4.3. Output from Quantitative Risk Analysis

• Risk register (updates): Risk register is updated at the end of the Quantitative Risk Analysis

process. The new updated items are:

• Probabilistic analysis of the project

• Probability of achieving cost and time objectives

• Prioritized list of quantified risks

• Trends in quantitative risk analysis results

3.2.5. Risk Response Planning

The risk response planning process consists of two inputs and three outputs as follows in table 5:

�

3��&0�/��%�/��#��##�#��"��#�#��

Inputs

Tools & Techniques

Outputs


2. Risk register

1. Strategies for negative risks or

threats

2. Strategies for positive risks or

opportunities

3. Strategy for both threats and

opportunities

4. Contingent response strategy



(updates)

3. Risk-related contractual

agreements

3.2.5.1. Inputs to Risk response planning

All inputs have been explained in the earlier sections.

3.2.5.2. Tools & Techniques for Risk response planning

• Strategies for negative risks or threats: For the category of negative risks there are three

strategies:

• Avoid: Eliminating the risk (threat) or keeping project objectives from its

consequences by changing the project management plan.

• Transfer: The negative risk and its management are transferred to the third party.

• Mitigate: Reducing the probability and/or impact of an identified negative risk (threat)

in the project before the risk occurs.

• Strategies for positive risks or opportunities: Typically three strategies cope with positive

risks or opportunities:


�

��

�

• Exploit: Removing the uncertainty related to an opportunity to making that

opportunity happen.

• Share: The positive risk and its management are transferred to the third party.

• Enhance: increasing the probability and/or impact of an identified positive risk

(opportunity) in the project.

• Strategy for both threats and opportunities

• Acceptance: This technique is adopted when decision makers do not change the

project management plan to respond to risk or they cannot find any other appropriate

strategy. Passive acceptance means taking no actions and accepting risks in the project

(whether upside or downside) as they occur. Active acceptance, on the other hand,

mainly refers to providing contingency plans to handle known or unknown risks.

• Contingent response strategy: Developing responses designed to respond to certain risk events

3.2.5.3. Output from Risk response planning

• Risk register (updates): risk register is upgraded at the end of the risk response planning

processes by the following items:

• “Identified risks, their descriptions, area(s) of the project (e.g., WBS –work

breakdown structure- element) affected, their causes (e.g., RBS -risk breakdown

structure- element), and how they may affect project objectives

• Risk owners and assigned responsibilities

• Outputs from the Qualitative and Quantitative Risk Analysis processes, including

prioritized lists of project risks and probabilistic analysis of the project

• Agreed-upon response strategies

• Specific actions to implement the chosen response strategy

• Symptoms and warning signs of risks' occurrence

• Budget and schedule activities required to implement the chosen responses

• Contingency reserves of time and cost designed to provide for stakeholders' risk

tolerances

• Contingency plans and triggers that call for their execution

• Fallback plans for use as a reaction to a risk that has occurred, and the primary

response proves to be inadequate

• Residual risks that are expected to remain after planned responses have been taken, as

well as those that have been deliberately accepted

• Secondary risks that arise as a direct outcome of implementing a risk response

• Contingency reserves that are calculated based on the quantitative analysis of the

project and the organization's risk thresholds” (6)


�

��

�

• Project management plan (updates): The results of risk response planning such as response

activities and strategies are incorporated in the project management plan especially in budget,

schedule and work breakdown structure -WBS- sections.

• Risk-related contractual agreements: Contractual agreements are used to determine the

responsible parties for identified risks. (e.g. insurance agreements)

3.2.6. Risk Monitoring and Control

The risk monitoring and control process includes five inputs and six outputs as follows in table 6:

3��(0�/��%�+�#��#��# ��#��"��#�#��

Inputs

Tools & Techniques

Outputs


2. Risk register

3. Approved change requests

4. Work performance

information

5. Performance reports

1. Risk reassessment

2. Risk audits

3. Variance and trend analysis

4. Technical performance

measurement

5. Reserve analysis

6. Status meetings


2. Requested changes

3. Recommended corrective

actions

4. Recommended preventive

actions

5. Organizational process assets

(updates)


(updates)

�

3.2.6.1. Inputs to Risk monitoring and control

1, 2 have been discussed previously.

• Approved change requests: These are documents which authorize any adjustments of project

plan and/or scope. Since any changes to project plan, scope, work method, and schedule can

create risks or modifications in identified risks, the examining and analyzing of those changes

become a vital task.

• Work performance information: Mostly information regarding to project deliverable’s

status, performance reports, and corrective actions are used as inputs.

• Performance reports: These reports manage and sum up the information gathered, and

present the outputs of any analysis. Here, Information associated with project work

performance may be used. (e.g. an analysis affecting the risk management processes)

3.2.6.2. Tools & Techniques for Risk monitoring and control

• Risk reassessment: This regularly scheduled task is essential for risk monitoring and control

process. As a number of risks emerge in the project, the planned responses may not be applied

for them. Project team members, therefore, should identify and reassess risks and strive to find

suitable responses for controlling the risks.


�

��

�

• Risk audits: Examines and documents how effective the risk management process is at the

responding to project risks.

• Variance and trend analysis: Reviewing the project execution trends and using variance

methods such as earned value analysis for measuring project performance.

• Technical performance measurement: The poor level of expected technical expertise of

project teams can be a source of further risks in project. This task can be done by assessing the

achievement of finishing activities throughout the project or project phases.

• Reserve analysis: Examines the contingency reserves to check whether those reserves are

sufficient for responding to the remaining risks or not.

• Status meetings: Periodic status meetings with the focus of project risk management

processes can be suitable for facilitating process activities.

3.2.6.3. Output from Risk monitoring and control

• Risk register (updates): the updated items to risk register are:

• Results of risk reassessment, risk audits, and periodic risk reviews.

• Actual results of project’s risks, and of risk responses.

• Requested changes: These are provided and handed over to integrated change control process

- a sub-process of project integration management knowledge area- since during the response

planning process project management plan may be changed resulting from applying

contingency plans.

• Recommended corrective actions: These actions are taken to reform the project to be in

concordance with the project plan� They mainly consist of workaround plans and contingency

plans. Workaround plan are unplanned responses to risks that were not recognized or accepted.

• Recommended preventive actions: Can help prevent a problem from occurring.

• Organizational process assets (updates): It includes final versions of checklists, updated

RBSs (risk breakdown structures), and risk management plan templates containing the

probability and impact matrix, and risk register.

• Project management plan (updates): Project management plan document must be modified

regarding to the approved changes affecting the project risk management processes.

3.3. PMBOK -A structured and comprehensive model for Project Risk Management-

One of the advantages of PMBOK which can be used as a reference model for managing risks is its

precise definitions of its processes involving inputs, outputs, tools and techniques. As an integrative and

operational system, a data flow diagram for managing risk based on PMBOK can be presented (figure

3.5). This flow diagram which its underlying concept is derived from Kontio (28) model is divided into

two different sections that is, initialization phase and risk analysis cycle. With respect to PMBOK, both

sections together form four process groups i.e. initiating, planning, monitoring and controlling, and

closing. The initiating, monitoring and controlling, and closing process groups are marked in the given

picture by green rectangle, blue triangle, and red oval respectively.


�

� �

�

In initiation phase formal authorization is issued by the project owners and/or stakeholders and

concurrently risk management structures including WBS descriptions, adopted methodology, scope of

work are declared to project manager. Next, in the planning processes risk management plan will be

developed with the aim of defining the responsibilities, authorities and scope of risk management. This

process activates goal review process which aims at reviewing the declared goals and defining explicit

goals and expectations.

Those goal definitions will be used in risk identification phase. Project risks are analyzed in

qualitative and quantitative levels. These analyses may result in changes in predefined goals or definition

of new goals. Control processes consist of risk control planning and risk control. The results of these

processes are issued to risk monitoring process. The risk management plan is updated each time it

receives feedbacks from risk monitoring and goal review processes. Finally, all the process activities are

registered in risk database to be used in future projects.

3.4. Risk Assessment based on Explicit or Tacit knowledge

The risk assessment throughout the project life cycle can be performed based on either explicit or tacit

knowledge. Explicit knowledge which is easily codified, documented, transferred, shared and

communicated can be formally explained (29). It is managed and shared in a formal way such as project

documents, manuals, procedures and codes. On the other hand, tacit knowledge which mainly refers to

interpersonal experiences and knowledge is difficult to articulate and can be shared through conversation

or storytelling and etcetera. In this study, it is assumed that risk assessment is chiefly carried out based on

explicit knowledge i.e. available information of past project documents and explicit lessons learned

databases such as risk registers or profiles. However, focusing on tacit knowledge is out of the scope of

this study, in order to�prevent biases which may caused by experts’ tacit knowledge some guidelines have

been prepared in the study.��

�


�

��

�

�

��&��+6),��# ��%�"�#��"�#��

/�"'�

($�&��!��&�

/�"'��&��

��!&�

6�!�"�

$��&��&�

+��$"@��"@�

��$��&�"�

/�"'�

+!&!��%�&��

��!&�

/�"'��&��

6�!��/��*�

5�!��!��

/�"'�-&!��"�"�

/�"'�

+�&��&��

5�!&��!��

/�"'�-&!��"�"�

/�"'�2!�! !"�"�

��

-��<!��&�

��

'#��

B4.�

+��$��

.��#��

.�!'��$��"�

�3#��!��&"�

��!&��"��&�

"��!��&�

�3#��$��"��"@�

#��$!�!�

��!&��"��&�

"��!��&�

/��"��&"��

"�!'��$��"�

/�"'�+!&!��%�&��

��!&�

/��"��&"��

��!�"@�&�*��!�"�

��"��!*��"'"�

�� %��&$��!��"��

��!&��"��&�"��!��&��

��!&��$�"�!��

��"'"�

��<�$��"'�

"��&!��"�

��<�$��"'�

"��&!��"�

/�"'�%�&��&��

%��"�

.��$�!��&"�


�

��

�

4. A Proposed Generic Qualitative Project Risk Assessment Framework In this chapter the output of this study is presented with the aim of proposing a systematic method for

assessing project risks qualitatively to help project decision makers in the course of project. Here, the

main concern is on the dynamics of those general guidelines which are developed by PMI.

4.1 Preface

While PMBOK provides a comprehensive foundation and guidelines for managing project risks, there is

still a need for a framework to qualitatively assess project risk in detail. In previous section, the process of

qualitative risk analysis based on PMBOK standard was completely described. As mentioned the main

purpose of this process is to prioritize the identified risks and conditions which affect project objectives

such as time, cost, and quality. Figure 4.1 shows the overview of the focus of the current study as well as

the main inputs and outputs of aforementioned process which is derived from risk management

knowledge area in the given standard.

��$�4��!��/��%�-#��6��%��5�

4.2 A Framework

Assessment of project risks necessitates project managers and other project decision makers to take

suitable decisions on risk management activities; on the other hand, MADM (Multiple Attribute Decision

Making) methods can help decision makers to make preference choices in the course of decision making.

MADM procedures aim at improving decision quality and can be utilized to a variety of people’s options

(30). So in this generic framework, in order to improve the qualitative risk analysis process performance,

different MADM techniques as well as other best practices of previous researches in the field of project

risk analysis have been applied.


�

��

�

To clearly present the proposed qualitative project risk analysis framework, first a procedure is

described in a stepwise manner:

Step 1: Forming a team of decision makers

Step 2: Gathering all possible information about risks

Step 3: Checking the availability, quality, and reliability of the collected information

Step 4: Developing Risk Breakdown Structure (R.B.S) based on internal and external sources of risk

Step 5: Risks screening

Step 6: Developing a Probability-Impact Matrix for both internal & external risks

Step 7: Making sure not to over focus on certain type of risk

Step 8: Updating risk register

Figure 4.2 illustrates a flowchart of the generic framework. The details of each step are presented in the

following of this chapter.

� �


�

��

�

� �

Form the team of decision makers

Collect all the relevant information

about risks

Verify the validity and precision of

risk information

Non-valid or

incredible�

information?�

Recheck or eliminate unqualified risk

information and adjust project scope plan

Develop a RBS in terms of internal

and external sources of risks

Perform risk screenning

Develop a probability – impact matrix

for both external and internal risks

Is there any

sign of biased

ranking?�

Detect the root causes and negotiate

with rankers

Updating risk register

Check the rankings to avoid over

focusing on certain type of project risk

Yes

Yes

�

��$��-��7�#��"�*��%��4��!��/��%�-#��


�

��

�

4.2.1 Forming a team of decision makers

The first step is to constitute decision making team which may consist of the project manager, project

team leaders, team members, key stakeholders such as owners, customers…, and other experts inside or

outside of the project organization that are knowledgeable in the field of risk assessment such as

functional managers. Senior managers, also, by considering the effects of risks on company’s or project

objectives and operational (project & functional) managers by focusing on consequences of risks on

operational level of project such as meeting milestones, resource allocation, activity schedule, and so on

help team assess risks comprehensively.

Assigning individuals or groups to the decision making team can be performed regarding Roles

and Responsibilities part which is predefined in risk management plan. If that part is not provided before

in risk management plan, it should be done during this step. Table 7 which is an excerpt from a real

project (31) is an example of roles and responsibilities section. Moreover, attention should be paid to this

fact that outsiders – decision makers which are placed outside of project organization – may judge risk

management activities including risk analysis better than team members (insiders). The rational for this

fact is that such outsiders may approach and analyze project risks more neutrally and without biased

perspective than insiders (6).

3��8�9�-#��5�"��%��# ��#��

Role Description of Role/Responsibilities

State Executive

Management C Require a formal risk management process for Beacon Project.

• Provide sufficient resources for the proper conduct of risk management.

• Be a vocal/visible advocate for risk management activities.

• Perform required due diligence and project oversight by reviewing top project

risks as identified in Beacon Project Status Reports.

• Support activities to control project risks as the project team escalates them for

action. State Project

Manager C Be a vocal/visible advocate for risk management activities.

• Perform required due diligence and project oversight by reviewing project risks

and ensuring completion of effective risk control activities. Project Team

Members C Report project risks, as they become known.

• Complete risk management activities as assigned.

• Perform steps of the risk planning, identification, analysis and control as defined

in the Risk and Issue Management Process specified in Attachment A of this Plan. Project Team Leads C Review and understand the Risk Management Plan.

• Be vocal/visible advocates for Risk Management activities.

• Compile updates to project risks from Project Team Members.

• Perform requisite steps of the risk planning, identification, analysis and control as

defined in the Risk and Issue Management Process specified in Attachment A of

this Plan.

4.2.2 Gathering all possible information about risks

In this step, a wide range of information concerning project risks should be obtained from previous

process of risk management i.e. risk identification (see chapter 3). Among different inputs to the process

of qualitative risk analysis which are shown in figure 4.1, the list of all identified risk which is

constructed in risk register as an output of risk identification process is used here. Risk register has been

fully described in chapter 3. In addition, other factors such as project type can affect the qualitative risk


�

��

�

analysis process. Common or recurrent projects are likely to have less level of uncertainty than first-time

projects which has never been performed before.

�

��$��0��"��:.�/��#��

As figure 4.3 shows, first time projects often do not have enough past information to help team make

hypothesis on risks (12). Statistical data about risks in past projects as well as lesson learned will be

useful toolkits that prevent project team to fall into repetitive mistakes. This can be performed by

reviewing of past project files, documents, plans, and closure reviews.

Additionally, as project progresses information about new risks and conditions will become

apparent. This forces decision makers to always keep an eye on the course of project through its life-

cycle; since any adjustment in key project documents such as project management plan and project scope

plan will affect risk management plan items, that is, roles & responsibilities for conducting risk

management, risk categories, definition of probability and impact, and stakeholders’ risk tolerances. So,

here, a recommended strategy to project managers is to update their risk databases and also their

estimation during the whole process of analysis when new information about current project performance

comes out.

4.2.3 Checking the availability, quality, and reliability of the collected information

One of the most key elements of credible decision making is a set of reliable data; since risks are based on

data and assumptions, effective decisions about them is quite dependant on quality, validity, and

reliability of data. By appraising the accuracy of data decision makers will verify the level of confidence

in the identified risks (12). Therefore, all data concerning risks must be assessed objectively to specify

whether or not they are accurate for further analysis. For example, the team which analyzes the impact of

economic risk on software development project, needs to evaluate the validity and quality of economic

data it is using.

It is proposed that during sessions among decision makers, some key questions will be answered.

Responding to these questions may clarify the extent to which risk data are qualified, understood,

available, reliable, and integrated. These questions are:

• How well is the risk understood?

• What are data sources? Are they documented or not?

• Are the risk data complete?

• Are the risk data timely and relevant?


�

��

�

• How objective and precise risk data?

A useful tool that can assist team members to verify the quality, reliability, and accuracy of the risk

data is work breakdown structure (WBS). WBS, as mentioned in chapter3, decomposes the scope of the

project and groups and organizes project tasks and activities. Here, it can be asked from participating

members to check whether the identified risk or condition is related or connected to the WBS layers. If

they cannot connect the identified risk to different project components i.e. activities, tasks, schedules,

objectives…, that identified risk will not be a valid or reliable risk to the project.

Beside data, project risks are often constructed upon project assumption. Almost all projects start

with assumptions since they mainly are in lack of complete knowledge about all of circumstances that

will form them. Project assumptions can be representatives of project risks if it becomes apparent that the

perceived assumptions are incorrect as the project progresses and new information about it becomes

available (32). So, another task of team members is to revisit those kinds of assumptions. After

identifying inaccurate or unqualified risk data or assumptions, they should be adjusted or eliminated from

current list for analysis. Finally, personnel who are responsible for updating project scope plan have to be

informed to adjust such a plan immediately.

4.2.4 Developing Risk Breakdown Structure (R.B.S) based on internal and external sources of risk

After finalizing the list of risks which is required to be analyzed and ranked; now it is time to structure the

unorganized gathered risks. Each of us may notice this fact in our experiences that organizing would be a

suitable solution to make sure the extent to which information is produced and understood where there are

vast amount of data. By using unstructured list of risks, decision makers may not easily recognize where

to put their emphasis in the process of assessment.

In order to provide team members to have a top-sight view of project risks as a whole and to give

them the light that in which areas of project they need to focus, a risk breakdown structure (RBS) is

proposed. RBS which is defined by PMBOK as “a hierarchically organized depiction of the identified

project risks by risk category and subcategory that identifies the various areas and causes of potential

risks” can be tailored to any kind of project (6). RBS which is similar to WBS (work breakdown

structure) will assist team members to simply track project risks, to guide and structure the risk

management process including risk analysis (33). It is broken into different levels and each level provides

more details about the upper level from which it is originated. Hillson (33) lists a number of insights into

the risk assessment process that can be arisen by categorizing risk according to RBS not by simply listing

them. These are:

• “Understanding the type of risk exposure on the project

• Exposing the most significant sources of risk to the project

• Revealing root causes of risk, via affinity analysis

• Indicating areas of dependency or correlation between risks

• Focusing risk response development on high-risk areas

• Allowing generic responses to be developed for root causes or dependent groups of risk.”

A question that may arise here is how should we structure risks? Or what is the logic of

classification? Since each project runs under specific condition, it is reasonable for it to have its own

RBS. Nevertheless, a number of researches have been made to categorize risks in a specific type of


�

��

�

project or application area (34) (35) (36) (37). As this paper does not focus on any particular project or

project type, a typical RBS which may be applied in any project will be presented. The concept of this

general RBS has evolved from the generic RBS which is provided by the SIG (The PMI Management

Specific Interest Group) and INCOSE RMWG (The Risk Management Working Group of the

International Council on Systems Engineering) (38) and the notion that each project is affected by its

internal (immediate) and external environment which has been discussed in chapter 3 (see section 3.3.1).

Regarding sources of project risks as an internal or external can bring a more holistic view for

project managers (26) and other decision makers for further analysis in next steps that may facilitate the

task of analysis as well. Figure 4.4 depicts a generic RBS for being used in the process of qualitative risk

analysis. Again, note that the list of risks shown in the layers of this RBS is indicative and absolutely not

exhaustive; but it can be modified to any project type. Moreover, the descriptions of some these risks

which are extracted from (39) have been provided in the table 8. Appendix D provides some lists of

common project risks that can be useful for team members to categorize and structure risks in RBS (40).


�

��

�

�

��$$�-#��5�"��7�#��/6.�


�

� �

�

3��0�/��%�2��#��5�� "�/��%��!�#��# �.��#��3��

Risk Event

Category or Scenario

Description

Unmanaged assumptions Unmanaged assumptions are neither visible nor apparent as recognizable risks.

They are commonly introduced by organizational culture; when they are

unrecognized in project environment, they can bring about incorrect perceptions

and unrealistic optimism.

Technological risk A technological risk may arise from using unfamiliar or new technologies. At the

one end is application of state-of-the-art and familiar technology, where the

technological risk can be quite low. At the other end, a new technology is used that

generates the greatest uncertainty and risk.

Economic climate For example, uncertain inflation rate, changing currency rates, etc. affect the

implementation of a project in terms of cash flow. A forecast of relative valuations

of currencies can be relevant for industries with multinational competitors and

project partners.

Domestic climate Risk events in this category include, attitudes and policies toward trade and

investment, and any recurring governmental crises.

Social risks Risks in this category are related to social values such as preservation of

environment. Some projects have been aborted due to resistance from local

population.

Political risks Political risks are associated with political stability both at home and abroad. A

large investment may require looking ahead several years from the time the

investment is made.

Conflict among individuals Conflicts can affect the success of a project. These conflicts could arise from

cognitive differences and biases, including self-motivated bias.

Large and complex project

risk

Large and complex projects usually call for multiple contracts, contractors,

suppliers, outside agencies, and complex coordination systems and procedures.

Complex coordination among subprojects is itself a potential risk, as a delay in one

area can cause a ripple effect in other areas.

Conceptual difficulty A project may fail if the basic premise on which it was conceived is faulty. For

example, if an investment is planned to remove some of the operational or

maintenance bottlenecks that ignores market requirements and forces, the risk of

such a project not yielding the desired financial benefits is extremely high.

Use of external agencies Appointing an external agency as project manager without creating a large project

organization may not ensure the kind of ownership required for successful

implementation or elimination of defects that the client has observed.

Contract and legal risks A contract is an instrument to transfer the risk from the owner to the contractor.

The contractor only risks it fees, whereas the owner runs the risks, for example, of

ending up with no plant at all. Although there are many contractual modes

available (e.g., multiple split contacting, turnkey, engineering

procurement/construction commissioning), none of these comes without risks.

Contractors Contractor risk failure may originate from the lowest cost syndrome, lack of

ownership, financial soundness, and inadequate experiences, etc. In the face of

intense competition, contractors squeeze their profit margins to the maximum just

to stay in business. Contractors sometimes siphon mobilization advances to other

projects in which they have a greater business interest. If a contractor has

difficulty with cash flow, then the project suffers.


�

��

�

Finally, RBS can be constructed when the project starts, or at an organizational level a universal version

of that can be prepared and tailored to each specific project (41).

4.2.5 Risks screening

After creating RBS and before further analysis, a question may arise for decision makers: Is it necessary

to deeply assess all project risks? Specifically, since risk analysis requires time, money, and resources,

assessment of the risks that are unimportant or less significant to the project performance would be a

trivial and ineffective task; besides, some risks may fall into the tolerance level which is not seen as a

considerable issue for further analysis. So, the aim of this stage is to screen all risks that are acquired from

previous steps. Here, the screening of risks is done based upon the experiences and knowledge of decision

makers or experts; Therefore, two methods, among a number of methods, are suggested i.e. Delphi

method and Nominal group technique. Appendix E lists various methods and techniques which are useful

for risk assessment. Delphi method is structured in three steps as follows (5):

“Step 1: A panel of experts is selected from both inside and outside the organization. The experts do not

interact on a face-to-face basis and may not even know who else sits on the panel.

Step 2: Each expert is asked to make an anonymous prediction on a particular subject. Step 3: Each expert receives a composite feedback of the entire panel’s answers and is asked to make

new predictions based upon the feedback. The process is then repeated as necessary.”

Nominal group, on the other hand, which provides direct and face-to-face contact, is ruled in three steps

(5):

“Step 1: A panel is convened and asked to generate ideas in writing. Step 2: The ideas are listed on a board or flip chart. Each idea is discussed among the panelists. Step 3: Each panelist prioritizes the ideas, which are then ranked mathematically. Steps 2 and 3 may be

repeated as necessary”

It is clear that the subject or ideas in both methods is ranking the project risks. In order to

systematically screen the project risks by Delphi method, a proposed format as depicted in figure 4.5

would be useful; as it puts out an even more coherent way of collecting ranks.

As MADM suggested, the Likert-type scale may be the most appropriate tool for quantification of

qualitative ratings (30). Therefore, here, as an example, a five-point Likert-type scale (1=not at all

important, 2=somewhat important, 3= moderately important, 4= very important, 5= extremely important)

can be proposed to team members to rate project risks. But obviously, different organizations may have

their own priority definitions and scales.


�

��

�

Risk Ranking Form

Project Information

ID: Manager:

Title:

Risk Segment

Round No. * Date:

Risk Name/Description RBS

Code

Rank Comment

*: refers to the number of time in which an analyzer fills in the form.

��$&�/��%�/�#%�#��"�

If Nominal group technique, allowing for face-to-face communication, is applied to the process, the

ranking can be performed by using eigenvector prioritization method which was presented by SAATY

(42). This method is a kind of ratio weighting techniques which provides pair-wise comparisons and

importance ratio between two attributes (in our case project risks) at a time. The steps in eigenvector

prioritization method are as follows (30):

“Step 1- Input Coding

A DM [decision maker] assesses n(n- 1)/2 importance (weight) ratios between attributes. This

information is stored in the upper (or lower) triangle of a (n × n) matrix whose typical element ajk

represents the weight ratio of wj/wk. The remaining elements of the matrix are filled by employing the

reciprocal property of the matrix: ajk = 1/akj and ajj = 1, for all j and k.

Step 2- Computing

Compute the geometric mean of each row of the matrix, and then normalize the resulting numbers.”

Note:�The geometric mean of a data set [a1, a2, ..., an] which is calculated by multiplying all the numbers

and taking the nth root (n= number of numbers) is given by (43):


�

��

�

Let’s give a simple example to make these steps more clear. Assume that there are three project risks,

namely, social (SO), political (PO), and technical (TE) and decision makers are to make pair-wise

judgments among these risks. Decision makers should respond to this kind of question: How many times

is �� risk more important than �� risk? As we can see in table 9, political risk is scored twice more

impressive and important than the social risk in project and in similar way, technical risk is preferred

triple and twice more than social and political risks in that order. After completing final calculation which

is written down in weight column technical, political, and social risks are ranked (in terms of weight

value, largest as first) as first, second, and third respectively.

3��9�-#��5�"��/��%�/��#��#!��;��#�

Risk SO PO TE Geometric Mean Weight

Geometric mean/Total GM

SO 1 1/2 1/3 (1*1/2*1/3) � = 0.5503 0.5503/3.3674= 0.1634

PO 2 1 1/2 (2*1*1/2) � = 1 1/3.3674= 0.2970

TE 3 2 1 (3*2*1) � = 1.8171 1.8171/3.3674= 0.5396

Total: 3.3674 1.0000

4.2.6 Developing a Probability-Impact Matrix for both internal & external risks

The aim of this step is to prioritize project risks based on their ratings which are assigned by assessing the

probability and impact of them. Following from the discussion in chapter 3(section 3.1); the risk for each

event has two key components:

• A likelihood (probability) of occurrence

• Impact of the risk if it occurs

The risk of an event increases, as either its probability or impact increases (see figure 4.6). Nevertheless,

both components require to be well assessed by analyzers in qualitative risk analysis; since a risk with

low probability and high impact or high probability and low impact can also have great impacts on project

performance. Therefore, the task of team members here is to respond to the following questions:

• How much is the probability of the risk occurring?

• What will be the impact or consequence if the risk occurs?


�

��

�

�

�

��$(�/��%��"��#�#��&��

One of the most applicable aids to prioritize risks according to their probability and impact may be

the probability and impact matrix which is discussed in chapter 3(section 3.2.3.2). According to this

matrix, the risk with higher probability and impact is seen more serious than the risk with lower level of

likelihood and impact. In order to ascertain probabilities and relative importance (impact), the structured

and standard checklists can be used by team members. Appendix F provides some samples of these kinds

of checklists. Since estimating probability and impacts is a subjective work, using stipulated rating scales

would be helpful for eliminating some of the subjectivity (40). Rating scales may be developed by project

management units in organization. If it is not made before, the decision making team have to provide it in

such a way that it will be agreed upon by all stakeholders. Moreover, rating scales can be created with

either ordinal or cardinal values. Both values can be set based on interviews by experts in the analysis

team and/or whole organization. Table 10 and 11 provide examples of both ordinal and cardinal rating

scales for probability and impacts respectively. The scales can vary in a project-by-project basis and

primarily based upon organizational preferences.

3��<�0�-#��5�"��/��%��

Probability of risk Mathematical probability

Very Low 0-10%

Low 11-40%

Moderate 41-60%

High 61-90%

Very High 91-100%

�

3��9�-#��5�"��/��%��#��=��#��"��

Consequence Relative Importance(Impacts)

Very Low 0-10

Low 11-40

Moderate 41-60

High 61-90

Very High 91-100


�

��

�

The Ordinal (descriptive) values have their own definitions; table 12 and 13, also, exemplify the typical

definitions for different ordinal rates.

3��9�-#��5�"��2��#��#��.��$<��

Probability Description Definition

High Critical Will occur frequently, has occurred on past projects, and

conditions exist for it to recur

Moderate Significant Will occur sometimes, has happened a minimal number of times

on past projects, and conditions are somewhat likely for it to recur

Low Negligible Will not likely occur, has never occurred on past projects, and

conditions don’t exist for it to recur

�

3��0�-#��5�"��2��#��#��#��=��#��.��$<��

Consequence Description Definition

High Critical

A consequence that will cause loss, cause severe interruptions to

the customer, or severely delay the completion of a major

deliverable

Moderate Significant

A consequence that may cause loss, may cause annoying

interruptions to the customer, or delay the completion of a major

deliverable

Low Negligible

A consequence that may cause minimal loss, cause minimal

interruption to the customer, or cause minimal delay to the

completion of a major deliverable �

Besides, figure 4.7 illustrated a would-be risk matrix which is constructed in terms of descriptive rates.

The matrix is set to 5x5 according to scales of probability and impact which are shown in table 10 and 11.


�

��

�

�

��$8��#��5�"��)� �#��# �'"��+��5�

As discussed before, risk level or score is the product of combining the given risk components.

Here, there are three risk levels – that is, high, medium, and low which are marked by red, yellow, and

white respectively (in black and white version: dark, gray, and white in that order). The objective of this

work is to put emphasis on those risks that would have great impact on the project performance. Red cells

represent those risks that would have significant or serious consequences (including positive and

negative) on project objectives and are required to be seen as of high priority and to be developed by

aggressive response strategies or other priority actions as well. Yellow cells refer to the medium risks

which would have moderate impact on project objectives and may not need any proactive actions from

management. Finally, white cells depicture low risks which would have limited impacts and are needed to

be put on the watchlists and be monitored either. Similarly, this formation can also be applied for cardinal

or numeric ratings. In this case risk level is computed by multiplying mathematical probabilities with

impacts; then the risks with high, medium, and low scores will be categorized in red, yellow, and white

cells correspondingly (see figure 4.8).

�

��$��#��5�"�� #��# �'"��+��5��


�

��

�

The risk scores may be defined and scaled beforehand by project organization (see an example in table

14). If a number of assessors are involved in the analysis, the average of their scoring can also be used to

show the risk level.

3��$�9�/��%�.��/�#��

Range of Score Level(value)

60-100 High

17-59 Medium

0-16 Low

Another way for scoring risk via risk matrix which can be suggested in this step is a method offered

by Datta et al. (26). According to that method, each probability falls between 0 and 1 and impacts(relative

importance) can take a number between 0 to 100 in such a way that total values of impacts equals to 100

(in order to facilitate both the task of calculation and distribution to a large number of risks the figure 100

is chosen). This can be done for both internal and external risks which are developed formerly in step 5.

From mathematical point of view:

Tn= � Ij x Pj (1)

Where: Tn = Total risk on each category (Internal or External)

n = Total number of risks (Internal or External)

j = Index variable regarding risks

I = Impact (weight) assigned to each risk which is a number between 0 to 100

P = probability of relevant risk occurring

Furthermore, in order to reduce the biases which may be caused by assessors, the using of fuzziness has

been proposed; consequently, the mathematical logic will be changed:

Tn= � Aj x Bj (2)

Aj = Ij + (Ij ) x R (3) 5

Bj = Pj + (Pj ) x R (4)

Where: Tn, n, I, P are stated as before

A = New impact (weight) adjusted by fuzziness

B = New Probability adjusted by fuzziness

R = Random numbers

Table 15 illustrates an example of risk matrix regarding this method (without fuzziness) which

involves five assessors, and five internal project risks. The probability and impact values in this matrix are

��=�!��&"�:�;�!&$�:�;�!��!��$��!&"��%!��&��=�!��&"��&��<<��!��!��+��&��%!��&�! ��<<��

��!&� ��&$��&�:�;��


�

��

�

generated by random number generator in Excel spreadsheet. In addition, the average of total risk (Tn)

assessed by all assessors in each category (Internal or External) would be used as an overall project risk

(26) to give general view of both external and internal risks to stakeholders to decide on suitable

mitigation plans and actions that will be taken in risk response planning phase.

3��&�0�-#��5�"��# ��"��"��5�

Assessor

No.

Relative weights

of Internal risks

Probability of occurrence

of Internal risks

Total

Internal Risk

CD MC ME SC QE P(CD) P(MC) P(ME) P(SC) P(QE) Tn

1 25 30 25 75 55 0.1 0.7 0.4 0.1 0.6 74

2 30 25 35 80 60 0.05 0.1 0.7 0.2 0.5 74.5

3 15 45 25 45 75 0.9 0.4 0.5 0.4 0.25 80.75

4 20 30 50 60 35 0.6 0.25 0.5 0.7 0.30 97

5 40 50 40 65 70 0.2 0.5 0.1 0.45 0.4 94.25

Average Total Internal Risks (Overall internal project risk) 84.1

CD, MC, ME, SC, and QE are conceptual difficulty, mode of contract, machine error, size & complexity, and quality error

respectively. Figure 84.1 shows the overall internal project risk is high.

4.2.7 Making sure not to over focus on certain type of risk

Since qualitative risk analysis process is mainly human-driven which deals with decision makers/experts

and their experiences, personal knowledge, estimations, and heuristics, the given process is exposed to

biases. The sources of bias are various in the given process; one may emanate from the expert judgment

techniques (i.e. Delphi method, nominal group technique) which have been used in previous steps. There

are several factors that can be sources of bias in risk analysis; some of them which are listed by Kerzner

(5) are as follows:

• “Insensitivity to the problem or risk

• Motivation

• Overconfidence in the reliability of the analysis

• Overconfidence in one’s ability

• Proximity to project

• Relationship with other experts

• Systematically omitting risk components

• Ambiguous evidence that fits into predispositions”

In addition, heuristics and rules of thumb which are used in the course of project risk management can

lead to faulty judgments or biases (44). There are different kinds of heuristic in risk analysis (44):


�

��

�

• Availability heuristic: assessing the probability of an event or risk in such an easy way that

occurrences can be brought to mind. E.g. judgment based on remembering past events which can

be imprecise estimation.

• Anchoring heuristic: having tendency and insistency to keep close to the initial estimate. E.g. an

assessor, who estimated the likelihood of an event equal to % 15 during the brainstorming

session, estimates the actual likelihood of that event between %13 and %17 during the further

discussion session.

• Representativeness heuristic: risk ranking or assessing (likelihood, impact) are affected by

amount and nature of details vis-à-vis to that risk.

However, there are a variety of solutions to mitigating aforementioned heuristics (44):

For instance, using a comprehensive database of risks could assist project team to abate availability

heuristic. Also, if the amount and nature of past and current project risks or events are structured in a

standard format (e.g. risk severity, likelihood, impacts), decisions regarding risks will less likely be

affected by more details resulting in less representativeness heuristic. Anchoring heuristic can be

mitigated by assessing risks based on objective recorded historical data.

��By the way, the task of team members, here, is to trace the results of risk screening and matrix

development steps, to check whether there is/are a sign(s) of biases in evaluated risks or not. For example,

the representatives of financial department of the project organization in decision making team may score

economical and financial risks more than other risks prejudicially. If any mark of over-focusing or bias is

observed, decision makers can prepare a meeting through which the root causes of that problem will be

examined and risk assessors will be informed about biases. Finally, it should be mentioned that, the bias

analysis is such a broad field which is out of scope of this study.�

4.2.8 Updating risk register

Like other phases in project risk management process, all tasks and activities that have been done

throughout the qualitative risk analysis should be documented for future use in other projects. As

previously mentioned in chapter3, the key database for registering information about risk management,

according to PMBOK, is risk register which is initially developed at the end of risk identification process.

The main information that should be embedded in risk register is extracted from step 4 to 6. Explicitly,

risk categories – internal and external in this framework – or RBS are documented; this can assist project

team to understand common root causes of risk calling for special attention which result in effective risk

responses (6).

Moreover, risk rating and list of prioritized risks are registered for further analysis in the project

risk management process. However project managers focus on high priority risks (high likelihood &

impact) as those risks can have significant impacts on project objectives; they also care about low priority

risks since if those risks are not monitored continuously, they can become big concerns for project

managers in the course of project. So, low priority risks are placed on watchlists for monitoring. Finally,

the risks requiring urgent response in the near-term or delayed response in future are listed as well as the

trends of analysis which can enable project team to respond to root causes to mitigate project risks (6).


�

� �

�

5. Conclusion

According to “A Guide to the Project Management Body of Knowledge” (PMBOK) project risk

management is the process in which project risks are identified, analyzed, ranked, responded with actions,

and monitored and controlled by project managers and project team. Among different phases of this

process, risk assessment (analyzing, ranking) takes an important position as the quality of assessment can

have a great impact on project objectives (5). Risk analysis which is a process of estimating risk level

based on the likelihood of occurrence and consequent of occurrence is divided into two sub-processes,

namely, Qualitative and Quantitative analysis. However, quantitative analysis has been paid more

attention and its use has been gradually increasing in the recent years with the aid of several techniques

and tools, qualitative analysis, on the other hand, has not been given that regard (45).

Moreover, although PMBOK standard, as one of the most comprehensive methodology for managing

projects, provides guidelines, tools, techniques for qualitative analysis, but it develops them in an abstract

term and does not say much about how those tools should be implemented. So, in order to address the

aforementioned need, this paper, mainly based on structure and processes that provided by the given

standard, presents a proposed generic framework for qualitatively analyzing project risks.

The 8-step proposed procedure aims at helping project managers, project team, and other stakeholders

qualify the seriousness of the risk in a systematic approach. In the construction of the presented

framework of this study previous best practices and researches in the field of project risk management and

decision making are exerted. Following from the framework, assigning individuals or groups to the

decision making team is the initial step. In doing so, not only the experts residing in project organization

can be exploited for analysis, but the use of exterior professionals and analyzers (outsiders) would also be

fruitful for the given process and for the reason that outsiders may have more neutral or unbiased

perspective than insiders. Afterward, all possible information about risks should be gathered. This

information constitutes inputs to the process which are mainly derived from risk identification stage.

Moreover, information about past and current projects as well as upcoming activities have to be

considered by assessors since when project progresses, it reveals new risks and situation to stakeholders.

Since effective decision making requires valid and qualified data, another task of analyzers is to check the

validity, quality and reliability of risk data and information. This can be done by revisiting and revising

project assumptions which can be sources of unrealistic and unreliable data when they are false. Another

task would be to ask analyzers whether they can relate the identified risks to different levels of work

breakdown structure (WBS) which shows the scope of project in detail. Then, to be able to understand

which areas of the project may call for special attention, and if there are any concentrations of risk on the

project the use of risk breakdown structure (RBS) is proposed (33). The classification logic of the

proposed generic RBS in this framework is based on the internal and external project risks. Regarding

project risks from internal and external viewpoint can bring a more systematic and structured way of

identifying the appropriate risks (26). Furthermore, as analyzing risk incurs cost by using time, resources,

and money dealing with all risks for further analysis would be an unfruitful action. Hence, all project risks

first are screened by applying different techniques which developed in MADM (Multi Attribute Decision

Making) field of science, namely, Likert-type scale and ratio weighting. In the next step, those screened

risks have to be prioritized to meet the final goal of the qualitative risk analysis process. In so doing, the

probability-impact matrix which is presented in PMBOK standard is applied and the different types of

creation and usage of this matrix is developed. Additionally, the personal experience, knowledge, and


�

��

�

insight of experts can have great either positive or negative effect on the analysis process; the negative

effects are resulted from biases and heuristic. Thus, the main sources and some proposed solutions are

provided. Finally, while keeping records of all the activities performed during the given process is

essential for fulfilling other phases of project risk management, it also can serve as a source of further

knowledge in the future projects.

The generic framework proposed in this paper for qualitative risk analysis which its platform is mainly

deduced from PMBOK methodology has two key advantages i.e. simplicity and flexibility. Specifically, it

does not require any specific knowledge to be run so it can be adopted by project managers, project risk

assessors, and other professionals dealing with risk assessment process in projects. Also, the framework is

not limited to any type of projects; so it can be applied to a variety of projects.

Since the given framework has not been implemented in any real project, the main limitation of this study

is its theoretical validity. Therefore, there is scope to examine the validity of this framework in future

studies by implementing it in a case study.


�

��

�

Bibliography

��#"DEE***�#%��E+��+(E�!��"E2��!��!"#3��F)&��&�G�+!��

��#"DEE***�#%��E+��+(E�!��"E2��!��!"#3@�+!��

��#DEE***�#%��E- ��H"E�!��"E- ��0�+(�!"#3�� F)&��&�G�

+!�� #DEE***�#%��E- ��H"E�!��"E- ��0�+(�!"#3��

��

"��D�)6�@��

��,��#��>�+��#��!��D�6��$��#��%!&!��%�&�� !�"�#$%�� "��D�4��"��

.�!&$!�$"�(&"��&@��

��,��;#��>�?�� &�'�!��'�� ! ��(��I�*�

J��'�D�7!&�I�"��!&$�/��&��$�@��

��'�)�� *��+��,�� -*.�)��/��"��D��+!&!��%�&��

(&"��@��

��2�!� ��#>�@�� -��0��+��1�� 2��

��

��@��"�#��>�@7� ��3�� "��D�8��%"�&�"��0*�"��&@��

��+�%�� >��,�� "��D�8��%"�&�4�"�&�""��""@��

� ��@A�A��>�A��%��4�� &�'�� )��

"��D�4!"��4��'"�@��

��-2�2�@'�6�6-2'/B>��.'+'C��B�-3�(�� &��-��0��

�� (��"��D��&��0K!��@�(&��@��

��,�"�?�� "�#>�� +�6��>��+�@�#��#�� 35��

!��)��"��D�.� �3@��

��.�"��@�+�#��@�>�@��%�/�+�� >�.��+�.��>�+��+�.��#�(��(��

�� "��D�B(��J@��

��!��>�@��#�� &�!�� !��

�� "��D�B��@��

��***�D�B�!��"��/(I��L�@��#DEE***�#��&��%E*�!�0�"0#��&��!"#M%�&��@�+!��

F)&��&�G�+!�� #DEE***�#��&��%E*�!�0�"0#��&��!"#M%�&��

��***�D��+!&!��%�&��-�"��!��!��F)&��&�G�+!��

��#DEE***�#��%!&!��%�&��&��!�E#��&��N*�!'&�""�"��

��6�� >�,�#�6��7�8(3��"��D�.�)��+!&!��%�&��%��$@��


�

��

�

��8��(2�-��+)2��F)&��&�G�+!�� #DEE***�"��%��$�E�$�!��

��0.8��.@��.��#"�8��&"��.��""��F)&��&�G�+!��

��#DEE***�%�"!��#��"��%�!�E/�"��"N�!#��"N ��%��

� ��+!&!��%�&��8��"��F)&��&�G�+!�� #DEE#%�"��&"�&��E�+)�!"#3��

��"�#>�.��#�A�� 7��1��&�� 9� ��2��"��D�

B��@��

��D��#�>�3��!��9��:��1��7-;3(9��'8')3�389&�'��

�� 2�� "��D�,��!&��!��@��

��/��>�@��#�7��1�'�� "��D�8!��O��!&��"@��

��<��=�� 7��1��!��<��;��>��#;�>�/�� 6��@�"��D�(&��%!��&�

.��!��D�8��3��P"�Q��&!�@��!�� @�7��

��?��"��>�D��!�D�7��1��'��"��D�B��@��

��<��7��1��5��3�� '��3�� .2��>�

.,�+�%�� "��D��+(�Q��&!�@�Q�&�� @�7��

��@��#�+��>�D�#�D��#�>��!��#�+��6��*#�� 7��1&� ��7��1�

�� ?��"��D��&!&��!��8�%�"��&��K!��@��

��,�#��>�@��%��9��7��1��!��+��7��1��%��"��D�H&��"��

+!��!&$@��!�'@�+!��!&$@��.08/0��

��3��)/�.��#DEE***��"��'E! ��E��#��E#��"E'%*� ��"E�3#��N!&$N�!��%��

'��-7��-7�9�� *��+��F)&��&�G��

��#DEE***��"��'E! ��E��#��E#��"E'%*� ��"E�3#��N!&$N�!��%��

� ��D��#>�,*�#��#��# �?*�#�>��'��<� ��1��&�'��

@��'�� !� ��! �� "��D�.!��H&��"��!#��"�.��"@��

��4�K/E��(��/�+��F)&��&�G�-#��

��#DEE��"�� !��&�&��E�&��!��"E��N#!��E$��%�&�"E�� N�+)N��N/�"'+!&!�%�N�� #$��

��$��!��+D��.�!��#��F)&��&�G�-#��

��#DEE***��$��!�#%��%E!��"E"�!��#N#��#�#��

��?��#>�2�!� �H"��!�/�"'�4��!'$�*&�.��:/4.;��H&$��"�!&$�J��/�"'"��F)&��&�G�-#��

��#DEE***��"'0$��%E#$�0��"E� "� ��#$��

��2��-@>�A��%��@->�-��@�>?��/�>�+��/�>�E�A��"��/��(��7��1�

��)��1��"��D��!�&��+��&�H&��"��.��*!��&��&��&��(&"��@��


�

��

�

��'��7��1�� ,7��/�� 1��3:A��

3�""��>�:+/>�E�6��@��@�"��D�(&��&!��&!��Q��&!��+!&!��%�&�@��@�7��

��9�� 1��

��"�#>�/@��@�"��D�(&��&!��&!��Q��&!��+!&!��%�&��@�� @�7��

��6��1�� +��>�/>�E�� >2�@�"��D�

(&��&!��&!��Q��&!��+!&!��%�&�@�� @�7��

��?��2�>�E�?��23�H&��"!��/�"'��R��&!��#��F)&��&�G��

��#DEE�#�%�*�!��&��#�&&��$�ES�!�#�&E��E�+(T� /�"'T� +!&!��%�&�T� .(6T� ��T� /�#

��#$��

��-��>�6��+�7��1�'��3��3 �� "��D��!#%!&�O�K!��@��

� ��?�� "�#>�,�"�� B��!��7��1��"��D�Q�""��04!""@��

��2�!� ��# >��*��/�'��# �� B��:��1��"��D�+�6�!*0K��""��&!�@�

� ��

��.--3D>�3��9��'�� :�� I�*�J��'�D�B��@��

��+!��*��$"D�6��%��+�!&��+++��+�� F)&��&�G�

��#DEE***�%!��*��$"��%E�E��%��N%�!&��%��

��5�!��!��!&$�5�!&��!��/�"'�-&!��"�"��F)&��&�G�(&�!��(&"��(&�@�-#��

***��&�!��%E-��"E-��N5�!&��!��/�"'-&!��"�"�#$��

��+� ��>�+��""� �7��1�'��3��&�9� ��2��9��9��"��D��/�@��

��<<��:.�!&��$��&��#�$�!��"�#��;��!��3� � ��F)&��&�G�-#��

� ��#DEE#�!��"�!&��$��$�E�&��"E��0��<<�E��

�


�

��

�

Appendix A: Characteristics of Good Project Management (3)

�

• A finite and defined lifespan

• Defined and measurable business deliverables that contribute towards the achievement of

business objectives

• A defined amount of resources

• Delivery of capabilities from which business benefits and performance improvements can

be leveraged

• An organizational structure, with defined roles and responsibilities

• Focus on management and coordination

• Delivery of outputs within time and cost constraints

• Quality management, focusing on fit-for-purpose outputs based on requirements

• Business cases containing an accurate budget for output delivery

• Risk management focused on costs, quality and timescales for delivery

• Issue management is proactive and focused on ensuring successful delivery

• Project plans that are both product and activity orientated

• Effective engagement with the stakeholder environment, focusing on achieving

stakeholder requirements


�

��

�

Appendix B: The process groups of project management according to

PMBOK (Third edition 2004) (6)

�

�

�

Initiating process group


�

��

�

Planning process group


�

��

�

Executing process group


�

��

�

Monitoring and Controlling process group


�

�

�

Closing process group


�

��

�

Appendix C: Mapping of the Project Management Processes to the Project

Management Process Groups and the Knowledge Areas (6)

�


�

��

�

Appendix D: The General Possible Risks with their Impacts (39)

�


�

��

�


�

�

�


�

��

�

Appendix E: These are some sample of Risk Assessment Methods (39)

�

Method Scope

The Delphi

Technique

Assists to reach consensus of experts on a subject such as project risk while

maintaining anonymity by soliciting ideas about the important project risks

that are collected and circulated to the experts for further comment.

Consensus on the main project risks may be reached in a few rounds of this

process.

Interviewing Identifies risk events by interviews of experienced project managers or

subject-matter experts. The interviewees identify risk events based on

experience and project information.

Experience-

Based

Identification

Identifies risk events based on experience including implicit assumptions.

Brain Storming Identifies risk events using facilitated sessions with stakeholders, project

team members, and infrastructure support staff.

Safety/Review

Audit

Identifies equipment conditions or operating procedures that could lead to a

casualty or result in property damage or environmental impacts.

Checklist Ensures that organizations are complying with standard practices.

What-IF Identifies hazards, hazardous situations, or specific accident events that

could result in undesirable consequences.

Hazard and

Operability Study

(HAZOP)

Identifies system deviations and their causes that can lead to undesirable

consequences and determine recommended actions to reduce the frequency

and/or consequences of the deviations.

Preliminary

Hazard Analysis

(PRHA)

Identifies and prioritizes hazards leading to undesirable consequences early

in the life of a system. It determines recommended actions to reduce the

frequency and/or consequences of the prioritized hazards. This is an

inductive modeling approach.

Probabilistic Risk

Analysis (PRA)

Methodology for quantitative risk assessment developed by the nuclear

engineering community for risk assessment. This comprehensive process

may use a combination of risk assessment methods.

Failure Modes

and Effects

Analysis (FMEA)

Identifies the components (equipment) failure modes and the impacts on the

surrounding components and the system. This is an inductive modeling

approach.

Fault Tree

Analysis (FTA)

Identifies combinations of equipment failures and human errors that can

result in an accident. This is an deductive modeling approach.

Event Tree

Analysis (ETA)

Identifies various sequences of events, both failures and successes that can

lead to an accident. This is an inductive modeling approach.


�

�

�

Appendix F: These are some samples of checklists that can be used in Risk

Identification and Assessment processes (26)

�

External Project Risks

“1. Technological Risks

What are the uncertainties associated with the technology selected for the project?

Can this technology be absorbed with current level of expertise available in the organization?

What should be the level of difficulty in handling this technology?

How are the local factors going to affect the absorption?

What kind of preparation would be required to do this?

What should be the gestation period for the project with this technology?

To what extent is the chosen technology maturing?

What new technologies are being explored in the same area?

What are the levels of understanding of the future users of this technology?

What are the probabilities of chosen technologies being suitable for local conditions?

What is the likelihood of a breakthrough?

How rapidly will the breakthrough’s impact be felt?

When and how will the recent breakthroughs in basic research lead to commercial products?

What might some new applications of currently available technologies be developed?

Have we ascribed a level of confidence to every critical technical objective?

Have decisions that should be left open because of inadequate information on technology been identified

and responsibility assigned for reducing the uncertainty?

2. Political Risks

Who are the international/overseas project partners (equipment supplier/supplier/consultant/contractor)

for this project?

Which countries are involved?

What is the political situation at present in those countries?

What will be the likely political situation during the life of the project? What is the level of political

stability within the country? Which political parties will gain/lose strength in the next two or three

elections?

What significant shift will occur in governmental policies, laws, and regulations pertaining to specific

industries?

What will be the likely political environment during the life of the project? What will be the political

environment’s impact on the project?

What will be the likely incidence of conflict with neighboring countries?

3. Risks Associated With Economic Climate

What are the prospects of the economic health of the country?

What will be the level of inflation over the next five years?

Will GNP increase or decrease over the next five years?

Which industries will grow or decline in the next decade?

What about the economic health of the submarkets?

How will economic events and trends likely affect the project?


�

��

�

What will be the likelihood of government intervention in the economy?

What are the present and past rates of inflation?

What is the balance of payment deficit? What are the major government policies—long term and short

term—regarding the industry?

What are the government policies on taxes and duties?

What are the government policies on other incentives?

4. Risks Associated With Domestic Climate

What is the level of physical violence near the project site?

What is the level of extremist tendencies among the local political parties?

What are the local government’s attitudes toward trade and investment?

What changes in the regulation are forthcoming?

5. Social Risks

What will be impact of the project in the society (employment/rehabilitation)?

Who is going to be affected?

What will be the environmental impact of the project?

What are the current or emerging trends of culture?

Will there be an increase in the political conservatism?

What lifestyle shifts might occur in society?

How will the consumption pattern change?

Immediate Project Risks

1. Large and Complex Project Risks

What is the size of the project?

Is the project cutting across the entire organization?

Which functions, departments, and activities of the organization are going to be affected?

What should be the level of coordination?

Is the delay in one subproject going to affect another?

What should be the requirement of personnel, especially during the construction phase?

What should be the requirement of organizational restructuring as each subproject goes through a

different lifecycle phase?

Are trained personnel, including supervisors and project managers, available to handle such a large

project?

Are the facilities, expertise, resources, and management know-how available to handle the situation?

What will be the number of excess personnel after the project is over?

What will be cost of redeployment of the personnel?

2. Risks Associated With Conceptual Difficulty

Supply—demand projections and trend—what are their levels of accuracy?

How solid are the price-volume projections?

How completely has the customer been identified?

How well are his or her needs and preferences understood?

Has the need for the project been properly established?

What are the current requirements of the customer?

What are the likely future requirements?

What are the current demands of the customer?

What is the likely future demand of the customer?


�

� �

�

What facilities are required to make these products or services?

What facilities need to be created to make these happen?

What inputs are required to make these happen?

What are the channels available for distribution to the customer?

How well is the application known?

How do the products attain the specifications?

How realistic is the timing of introduction?

What would be the effect of slippage?

How solid is the projection of competitive reaction?

How carefully have the potential competitors been identified?

3. Risks of Managing Projects by an External Agency

How is the project going to be managed?

Is the present organizational structure for handling the project sufficient?

Can it be enlarged by drawing people from other areas of the organization?

What are the risks involved in appointing external agencies to manage the project?

What are the probable external agencies to act as project manager?

What is the past performance of the external agency as project manager?

What are its business ethics?

Do they match with the client’s requirement?

What should be the external agency’s responsibility vis-à-vis total stake in the project?

What is its level of commitment and professionalism?

4. Risks Associated With Mode of Contract

Why has this particular mode of contracting been chosen?

What are the probable difficulties that are bound to come with the chosen mode?

What are the preparations required for facing those difficulties?

What is the past experience with this particular mode?

Is the consortium approach going to be there in the project?

Who is going to be the consortium leader?

What will be his or her relationship (authority vis-à-vis responsibility) with other members?

Who will be in command to monitor and control the performance of the consortium members (consortium

leader/client)?

What risks does the consortium leader have if the projects fail to meet deadline?

Who will be responsible for a slippage—the consortium leader or the member?

5. Risks of Failure by Contractors

What is the experience (performance, attitude, business ethics, etc.) in the past with the contractor?

What is the level of experience available with the organization?

What is his or her current level of engagement?

What is the financial status of the contractor?

What is the industrial relations prevailing in this organization?

Who are the owners? What kind of systems and procedures (ISO: 9000/ BS: 5750/ EN: 29000, etc.) are

followed?”

a proposed generic framework for qualitative risk … › smash › get › diva2:225091 › ...a...

Documents