A Proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK, Study Guides, Projects, Research of Risk Analysis

Download A Proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK and more Study Guides, Projects, Research Risk Analysis in PDF only on Docsity!
  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.  A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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)      A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
 
 
    
 
 
   !"

 
 #!"$$#%&
  
 
&'"!%&#""#" 
 (&!
&"!&$!##
&!%&#""#"
&#  
  )
*+!&!%&,&*$-!"!&$""" 
."/
"'
"010
""&
&%&  
 )
*/
"'+!&!%&  
/
"'+!&!%&""*2
!!%  
 !

!&$(%#!+!
3  
+4),!&$
"'%!&!%& 
5!
!
/
"'-&!"
"!"!4!' 3  
 -#"6&
!%*'5!
!
/
"'-&!"
" 

"0
%7./
&"  
-&3!%#6&
/4.  
/
"'/!&'
&%  
 /
"'%#&&" 
!&3!%#)$
&! !

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

!&$(%#!+!
3    
  8! 0/
"'+!&!%&!&&
&#""%#&&"  8!  0/
"'($&

!
&#""%#&&"  8! 05!
!
/
"'-&!"
"#""%#&&"  8! 05!&
!
 /
"'-&!"
"#""%#&&"  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    A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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: A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   
   ! "# 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 P3M3 2 - Portfolio, Programme and Project Management Maturity Model9explains 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   • 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    • 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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   • 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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) A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   • 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    
 .  /%!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): A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    
   /%+#"#  
 *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: ; A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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$04#! /%-#  " ## Inputs Tools & Techniques Outputs 1. Organizational process assets 2. Project scope statement 3. Risk management plan 4. Risk register 5. Project management plan 1. Data gathering and representation techniques 2. Quantitative risk analysis and modeling techniques 1. Risk register (updates) 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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 1. Risk management plan 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 1. Risk register (updates) 2. Project management plan (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: A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   • 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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    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 toprevent biases which may caused by experts’ tacit knowledge some guidelines have been prepared in the study.  A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   
 & +6),# %"#"# /
"' ($&

!
& /
"'& !& 6!" $
&

& +$"@"@ 
$
&" /
"' +!&!%& !& /
"'& 6!/
* 5!
!
 /
"'-&!"
" /
"' +&

& 5!&
!
 /
"'-&!"
" /
"'2!! !""  -
<!
&   '# B4. +$ .# .!'$" 3#!
&" !&"
& "
!
& 3#$""@ #$!! !&"
& "
!
& /
"
&" "!'$" /
"'+!&!%& !& /
"
&" !"@&*!" 
"!*
"'"  %
&$
!" !&"
&"
!
& !&$"! 
"'" 


<$
"' "&!
" 


<$
"' "&!
" /
"'%&

& %
" .$!
&" A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
     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!/%-# A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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). 389-#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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    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? A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    
$ $-#5" 7#/6. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    30/%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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    
$ (/% " ##& 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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    
$ 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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    • 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). A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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. A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   '
7
1   ,7/   
1 3:A 


    3"">: + / >E6@
@"D(&&!
&!Q&!+!&!%&@ @7  9   

     
 
1
 


      
 
   "#>/ @ @"D(&&!
&!Q&!+!&!%&@ @7  6 


1
   

  +>/ >E >2  @"D (&&!
&!Q&!+!&!%&@ @7   ?2  >E?2 3 H&
"!/
"'R
&!#F)&
&G  #DEE#
%*!&#&&$ES!#&E E+(T /
"'T +!&!%&T .(6T T /# #$  ->6+ 7
1'

3

3  
"D!#%!&OK!@   ? "#>,"    B! 
 7
1  "DQ""04!""@  2!  # >*/ '#    B: 1"D+6!*0K
""
&!@   .--3D>3  9 '
:
 
 I*J'DB
@  +!*$"D6%
+!&++++  F)&
&G #DEE***%!*$"%EE%
N%!&% 5!
!
!&$5!&
!
/
"'-&!"
"F)&
&G(&!(&"
(&@-#
  ***
&!%E-
"E-
N5!&
!
/
"'-&!"
"#$ + >+ "" 7
1'

3

&9 
2 9 9 "D/@   <<
:.!&$&#$
!
"#;! 3    
 
  F)&
&G-#
 #DEE#!"!&$$E&
"E
0<<E  A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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 A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    Appendix B: The process groups of project management according to PMBOK (Third edition 2004) (6)    Initiating process group A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    Monitoring and Controlling process group A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   Closing process group A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   Appendix C: Mapping of the Project Management Processes to the Project Management Process Groups and the Knowledge Areas (6)  A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
   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? A proposed Generic Framework for Qualitative Risk Analysis Based on PMBOK
    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?”