pmp cross-cutting skills have been updated in the pmp exam ... · iilcert5...

IIL-‐CERT5

Project Risk Management The Project Management Cer:ficate Program

1 ©2014 Interna:onal Ins:tute for Learning, Inc.

PMP cross-cutting skills have been updated in the PMP Exam Content Outline – June 2015 (PDF of the Examination Content Outline - June 2015 can be found under the Resources Tab).

Learn about why the PMP exam is changing in 2016.

Download the new Exam Content Outline to study cross-cutting skills here:http://www.brainshark.com/pmiorg/2015PMPExamChange

IIL-‐CERT5



©2014 Interna:onal Ins:tute for Learning, Inc.

Participant’s Notes:

IIL-‐CERT5


3


Participant’s Notes: Review these learning objec:ves carefully.

The learning content contained within this module is based on these learning objec:ves.

At the end of this module or the end of the course, you should be able to answer quiz or test ques:ons related to these learning objec:ves.

If you are par:cipa:ng in this course for cer:fica:on, you will be bePer prepared to pass a cer:fica:on exam by recalling these learning objec:ves.

IIL-‐CERT5


4


Participant’s Notes: Risk is oRen thought of as something nega:ve, something that should be avoided. Depending on whether one is a risk seeker or opposed to risk, opinions will oRen lead to very different results. Within project management, risk is looked at both ways – as a poten:al problem or a poten:al opportunity. Regardless, risk always involves something that will occur in the future.

Risk is inherent in all projects and will only cause challenges if ignored. Managing risk is important throughout the project life cycle. It is an itera:ve process that is tailored to specific events in order to protect or enhance project objec:ves.

IIL-‐CERT5


5


Participant’s Notes: Project risk management includes the processes of conduc:ng risk management planning, iden:fica:on, analysis, response planning , and controlling risk on a project.

PMBOK® Guide– FiRh Edi:on, Glossary

IIL-‐CERT5


6


Participant’s Notes: The PMBOK ® Guide – FiRh Edi:on describes the key benefit of this process as ensuring that “risk management is commensurate with the risks and project importance.”

PMBOK ® Guide -‐ FiRh Edi:on, p. 313

IIL-‐CERT5


7


Participant’s Notes: The PMBOK® Guide – FiRh Edi:on defines the following for this first Project Risk Management process:

Inputs

•  Project management plan •  Project charter

•  Stakeholder register

•  Enterprise environmental factors •  Organiza:onal process assets

Tools & Techniques

•  Analy:cal techniques

•  Expert judgment •  Mee:ngs

Outputs

•  Risk management plan

IIL-‐CERT5


8


Participant’s Notes: Although the current state of the Project Management Plan serves as an input to this process, the Risk Management Plan will become an integral part of the Project Management Plan. This is part of the “progressive elabora:on” of the Project Management Plan.

The Stakeholder register contains documenta:on of stakeholder analysis such as their level of power, level of concern, appe:te and tolerance for risk and other data that will help you manage their expecta:ons.

IIL-‐CERT5


9

Analy:cal Techniques are a combina:on of stakeholder risk aetude analysis and an evalua:on of strategic risk exposure for the organiza:on. Stakeholders aetudes toward risk may be analyzed in the following terms:

•  Risk Appe)te. The degree of uncertainty an en:ty is willing to take on in an:cipa:on of a reward.

•  Risk Tolerance. The degree, amount, or volume of risk that an organiza:on or individual will withstand

•  Risk Threshold. Refers to measures along the level of uncertainty or the level of impact at which a stakeholder may have a specific interest. Below that risk threshold, the organiza:on will accept the risk. Above that risk threshold, the organiza:on will not tolerate the risk.

PMBOK® Guide -‐ FiRh Edi:on Glossary

Strategic Risk Exposure is the analysis of the impact to the organiza:on if risks should come to frui:on. Typically, once a project team has evaluated the risks and devised their response plans the organiza:on will need to assess any residual or con:ngency risks and quan:fy them. A con:ngency reserve should be created to cover these residual risks.

Project teams hold planning mee:ngs to develop the risk management plan. APendees should include the project manager, the project team leaders, anyone in the organiza:on with responsibility to manage the risk planning and execu:on ac:vi:es, key stakeholders, and others as needed. They use the organiza:onal process assets such as risk management templates and other inputs as appropriate.

Successful planning outcomes are derived from leveraging everyone’s input. Some of the best informa:on available to the project team comes from historical informa:on, whether in the form of lessons learned, or the experience of those who have par:cipated on similar projects.

IIL-‐CERT5




Participant’s Notes: The risk management plan describes the process that will be used to accomplish risk iden:fica:on, qualita:ve and quan:ta:ve analysis, response planning, and monitoring and control throughout the life cycle of the project.

The plan includes:

•  Methodology •  Roles and responsibili:es

•  Budge:ng

•  Timing •  Risk categories

•  Defini:ons of risk probability and impact •  Probability and impact matrix

•  Revised stakeholders’ tolerances

•  Repor:ng formats •  Tracking

Stackpole, Snyder Cyndi, A Project Manager’s Book of Forms, Second Edi:on, p. 102, John Wiley and Sons.

The first element of a risk management plan is the methodology used. This defines the approaches, tools, and data sources that may be used to perform risk management on a par:cular project. These could change depending on the project stage, amount of informa:on available, and flexibility remaining in the

IIL-‐CERT5


11


Participant’s Notes: The PMBOK® Guide – FiRh Edi:on describes the key benefit of this process as “the documenta:on of risks to an:cipate events.”

PMBOK® Guide FiRh Edi:on, p. 319

IIL-‐CERT5


12

The PMBOK® Guide – FiRh Edi:on defines the following for this second Project Risk Management process: Inputs

•  Risk management plan •  Cost management plan •  Schedule management plan •  Quality management plan •  Human resource management plan •  Scope baseline •  Ac:vity cost es:mates •  Ac:vity dura:on es:mates •  Stakeholder register •  Project documents •  Procurement documents •  Enterprise environmental factors •  Organiza:onal process assets

Tools & Techniques

•  Documenta:on reviews •  Informa:on gathering techniques •  Checklist analysis •  Assump:ons analysis •  Diagramming techniques •  SWOT analysis •  Expert judgment

Outputs

•  Risk register IIL-‐CERT5




Participant’s Notes: The stakeholder register is a good place to begin evalua:ng who might be helpful in iden:fying risks. The stakeholders themselves may be a source of risk that needs to be planned for.

As you are reading through the the project management plan and project documents, par:cularly contracts, you might no:ce terms that may make the execu:on of the project more difficult to comply with. An example of this would be a contract that requires the project team to guarantee access to a par:cular piece of property, that is land-‐locked by property rights owned by others, in order to build a structure for the client.

Assump:ons made during es:ma:ng (refer to Time and Cost Management modules in this course) are usually sources of risks.

The WBS (from the Scope Management module) is a good place to look to iden:fy risks.

IIL-‐CERT5


14


Participant’s Notes: Use a risk breakdown structure (RBS) to structure categories and sub-‐categories for risks on a project. Tools or templates such as this can be reused from project to project and can assist with the efficiency, effec:veness and quality of risk iden:fica:on.

IIL-‐CERT5


15


Participant’s Notes: Brainstorming is probably the most frequently used informa:on-‐gathering technique. The goal is to obtain a comprehensive list of risks that can be addressed later in the qualita:ve and quan:ta:ve analysis process. Some of the many benefits to brainstorming include a comprehensive risk list of risks, and synergy that allows the team a bePer understanding of the risks and ins:lls a culture of risk-‐awareness that improves team effec:veness.

In order to get a range of possible risks, it is important to choose the “right mix” of par:cipants. They should include key people from different disciplines, key project people, and someone independent of the project. In order to have a successful brainstorming session, careful thought and prepara:on is a must. A trusted facilitator should encourage everyone to contribute. All ideas are posted and there is no discussion about the ideas.

IIL-‐CERT5


16


Participant’s Notes: The Delphi technique is used by experts to reach consensus on a subject such as project risk. Because the bias is reduced and no one individual will have the ability to exert undue influence, the Delphi technique is oRen used for cri:cal decision-‐making for risk management.

There are also some disadvantages. Group members cannot interact. In some cases this is good, since it iden:fies problems that may not have been considered.

IIL-‐CERT5


17


Participant’s Notes: A scan of the internal and external environment is an important part of the strategic risk planning process. Factors internal to the organiza:on usually can be classified as strengths (S) or weaknesses (W), and those external to the firm can be classified as opportuni:es (O) or threats (T).

IIL-‐CERT5


18


Participant’s Notes: The risk register records is started in this process. In each subsequent risk process it is elaborated or updated. It will eventually contain informa:on on the probability, impact, response, trigger event and responsible party for risk events.

IIL-‐CERT5


19


Participant’s Notes: This example of a risk register can be used to build a risk breakdown structure. The risk type is the top level, the risk area is the second level, the descrip:on of uncertainty is the third level.

This register is “progressively elaborated.” As you obtain more details, your register will include more informa:on.

IIL-‐CERT5


20


Participant’s Notes: The PMBOK ®Guide – FiRh Edi:on describes the key benefit of this process as enabling the project manager “to reduce uncertainty and to focus on high-‐priority risks.”

PMBOK ®Guide -‐ FiRh Edi:on, p. 319

IIL-‐CERT5


21


Participant’s Notes: The PMBOK® Guide – FiRh Edi:on defines the following for this third Project Risk Management process:

Inputs

•  Risk management plan •  Scope baseline

•  Risk register

•  Enterprise environmental factors •  Organiza:onal process assets

Tools & Techniques

•  Risk probability and impact assessment

•  Probability and impact matrix

•  Risk data quality assessment •  Risk categoriza:on

•  Risk urgency assessment

•  Expert judgment Outputs

•  Project documents updates

IIL-‐CERT5


22

During qualita:ve analysis the probability, impact and exposure are arrived at through subjec:ve measures. These subjec:ve assessments of probability and impact are entered into the risk register and ranked according to their exposure (P X I = Exposure) in order to ensure that responses are prepared for those with the highest probability of occurring and the most severe impact if they do occur.

Many :mes, team member will state a risk, such as, “Lack of execu:ve support.” If another stakeholder looks at a risk described in this manner…two ques:ons will immediately come to mind:

1.  How likely is this to happen or why should I believe that this will happen, and

2.  If it does happen, why should I be concerned.

In this example, “Lack of execu:ve support” is the risk event, however, the statement is missing the root cause and the impact statement. A bePer way to write this statement or to express it is:

“Because our project sponsor is leaving the company (the root cause), we may not have execu:ve support (the event), which may mean that we may not complete the project on :me (the impact statement or consequence.)

There are two ways to present this in the risk register, one way is to have one column en:tled “Risk Statement” and write one complete statement. Another way to put this in the risk register is to break it into three columns to individually iden:fy the root cause, the risk event, and the impact/consequence.

IIL-‐CERT5




Participant’s Notes: Risk impact or consequences may be described in qualita:ve terms such as high, medium, and low or a numerical ra:ng scale, e.g., 1-‐5. Risk probability is the likelihood that risk will occur. Probability can also be ranked by high, medium, low or may also be expressed on a numerical ra:ng scale.

Risk consequences or impacts are the effect on project objec:ves if the risk event occurs. These two dimensions of risk are applied to specific risk events, not the overall project. Analysis of risks using probability and consequences helps iden:fy those risks that should be managed aggressively.

IIL-‐CERT5


24


Participant’s Notes: This type of scale might be a predefined organiza:onal process asset, or something the team determines for the risk management plan, if the firm has not documented such concepts or standards.

IIL-‐CERT5


25

The intent of both rela:ve and numeric approaches to probability and impact is to ul:mately assign a ra:ng of the risk to guide how aggressively the project team should pursue an appropriate response. For numeric scales, the risk score is equal to P X I, and these products produce rela:ve numerical scores that help rank the risks. Separa:ng these risks into rela:ve bands using the popular traffic light analogy, allows you to group risks into categories for high, moderate or low aPen:on.

The organiza:on’s tolerance of risk will determine what they consider high (red), moderate (yellow), or low (green) risk ra:ngs. The higher the risk ra:ng, the more aggressive the amount of aPen:on. For example:

•  Red risks may be required to be reduced or avoided •  Yellow risks may be mi:gated or accepted with explicit con:ngency plans, to mi:gate damage, should

they occur •  Green risks may be accepted, but only require minimal budget and schedule con:ngencies.

These divisions are not hard lines, but in general, a risk neutral orienta:on will have a balanced approach to how many cells are in each band, as in the table on this slide. A risk-‐seeking orienta:on would have less red and more green, since it would be acceptable to move forward with more/higher risks outstanding.

Let’s compare these perspec:ves to a risk-‐averse orienta:on on the next slide.

IIL-‐CERT5




Participant’s Notes: The majority of your risks will go on the watch list. You will be leR with a list of risks that require you to ac:vely respond, those risks that require further analysis and those risks that you should merely monitor (the watch list).

IIL-‐CERT5


27


Participant’s Notes: The PMBOK ®Guide – FiRh Edi:on describes the key benefit of this process as producing “quan:ta:ve risk informa:on to support decision making and reduce uncertainty.”


IIL-‐CERT5


28


Participant’s Notes: The PMBOK® Guide – FiRh Edi:on defines the following for this fourth Project Risk Management process:

Inputs

•  Risk management plan •  Cost management plan

•  Schedule management plan

•  Risk register •  Enterprise environmental factors

•  Organiza:onal process assets Tools & Techniques

•  Data gathering and representa:on techniques

•  Quan:ta:ve risk analysis and modeling techniques

•  Expert judgment Outputs


IIL-‐CERT5


29


Participant’s Notes: The cost and schedule management plans iden:fy the procedures and methods used to manage cost and schedule on the program. Informa:on such as es:ma:ng techniques, the confidence level for es:mates, the range of es:mates along with the basis of es:mates indicate the degree of overall risk to the schedule and budget. Addi:onally the cost and schedule management plans describe how con:ngency reserve will be es:mated and applied on the project.

This informa:on will be used to determine the likelihood of mee:ng cost and schedule targets.

IIL-‐CERT5


30


Participant’s Notes: Risk quan:fica:on follows risk qualifica:on when needed. Quan:ta:ve risk analysis isn’t required on every project. Part of tailoring the project is determining the tools that should be used to insure they reflect the level of risk support required for the project. It should also be noted that the tools used are only as good as the veracity or existence of credible data.

Interviewing stakeholders and subject maPer experts is the star:ng point for gathering the informa:on needed for quan:fying risk.

To improve the outcome of quan:ta:ve analysis, follow the recommenda:ons on the slide.

IIL-‐CERT5


31



IIL-‐CERT5


32

Normal Distribu)ons: ORen referred to as a “bell curve,” this is a symmetrical curve with the “mean” (average) in the middle. The area beneath the curve represents 100% of the observa:ons of a sample. This area under the curve is divided into standard devia:ons (represented by “sigma.”) the area covered by 1 standard devia:on on both sides of the mean represents 68% of the data points in the sample. 2 standard devia:ons on both sides of the mean represents 95% of the data points and 3 standard devia:ons on both sides of the mean represents 99% of the data points. This final observa:on is referred to as “six sigma” or 99.9985% of the area under the curve.

Beta Distribu)ons: This distribu:on curve is used to model random varia:on and can take on various shapes. The PERT formula (O+4(ML) +P/6) represents a simplified equa:on for a beta distribu:on that is used in project management for es:ma:ng purposes.

Uniform Distribu)ons: This distribu:on is used when the probability of occurrence is unchanged from the minimum value to the maximum value. Said another way, when the probability remains unchanged.

Triangular Distribu)ons: This distribu:on is typically used when the most likely outcomes are known. The most likely outcomes are centered in the middle and decline on either side of the middle. Also used when observa:ons are very limited.

IIL-‐CERT5




Participant’s Notes: Sensi:vity analysis is a simple tool that inves:gates how es:mated performance varies based on changes in the key assump:ons on which a quan:ta:ve es:mate was based. Experimental design could consider alterna:ves by modeling each alterna:ve, keeping all other variables constant. This process can help the project team discover which risk events have the greatest impact on the project objec:ves.

This is called a tornado diagram. You can see the risks ranked based on the degree of impact that they could have on the project.

IIL-‐CERT5


34


Participant’s Notes: Decision trees provide a visual structure to help the project team display op:ons and further explore the possible outcomes of choosing those op:ons. Decision trees help to form a balanced picture of the risks and rewards associated with each possible course of ac:on.

IIL-‐CERT5


35


Participant’s Notes: Decision trees are used when a decision cannot be viewed as a single isolated occurrence, but rather as a sequence of several interrelated decisions.

Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edi:on, by Harold Kerzner, Ph.D., pp. 882-‐883

IIL-‐CERT5


36


Participant’s Notes: Decision trees are used when a decision cannot be viewed as a single isolated occurrence, but rather as a sequence of several interrelated decisions.

Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edi:on, by Harold Kerzner, Ph.D., p. 882

IIL-‐CERT5


37


Participant’s Notes: Besides the financial impacts, what other business considera:ons might you discuss as an organiza:on?

IIL-‐CERT5


38


Participant’s Notes: In Monte Carlo simula:on, each task, with risk characteris:cs that vary from a normal distribu:on, is assigned a probability distribu:on that describes that task’s risk profile. The ques:on is defined such as “do you want to know the total project cost or the project dura:on?” Finally you tell the simula:on program…how many versions (itera:ons)of the schedule you want to produce. ARer the simula:on is run, each outcome is analyzed for its probability and result.

“Simula:on refers to any analy:cal method meant to imitate a real-‐life system, especially when other analyses are too mathema:cally complex or too difficult to reproduce.” (Crystal ball 2000, www.decisioneering.com). Without the aid of simula:on, data will generally reveal a single outcome, generally the most likely or average scenario.

IIL-‐CERT5


39


Participant’s Notes: Monte Carlo simula:on received its name when the process was used in casinos in Monte Carlo, Monaco to determine probabili:es and outcomes of various gambling scenarios.

Please note that the Mean Cost has as likely a chance of occurring as not (50% probability that the project will come in at or under that cost).

•  What are the implica)ons of this curve?

•  Where on this curve does your organiza)on usually budget projects?

•  If you were the project manager, at what amount would you like to see the budget set?

IIL-‐CERT5


40


Participant’s Notes: Depending on the results of the Monte Carlo simula:on the team may determine the amount of con:ngency needed to meet to protect the delivery date commitment or the budget commitment.

IIL-‐CERT5


41


Participant’s Notes: The PMBOK ® Guide – FiRh Edi:on describes the key benefit of this process as “addressing risk s by their priority .”

PMBOK ® Guide -‐ FiRh Edi:on, p. 342

This includes:

•  Developing and documen:ng an organized approach to risk response planning

•  Determining the responses for individual risk events

•  Planning for adequate resources •  Iden:fying the owner and :me frame for

implementa:on

IIL-‐CERT5


42


Participant’s Notes: PMBOK® Guide – FiRh Edi:on defines the following for this fiRh Project Risk Management process:

Inputs

•  Risk management plan •  Risk register

Tools & Techniques

•  Strategies for nega:ve risks or threats •  Strategies for posi:ve risks or opportuni:es

•  Con:ngent response strategies •  Expert judgment

Outputs

•  Project management plan updates


IIL-‐CERT5


43


Participant’s Notes: Risk Register: In addi:on, aPributes of the risk can assist in the determina:on of the proper response ac:on.

IIL-‐CERT5


44



IIL-‐CERT5


45


Participant’s Notes: There is cost associated with each risk response strategy, and these costs become line items in the project budget. These are known risks, with known recovery costs. Risk events that are unan:cipated are funded with con:ngency reserves, which are usually a percentage of the total project budget set aside for these known unknowns. The con:ngency reserve amount needed is based on the probabilis:c analysis of the project and the amount of buffer needed to reduce the overall project risk level to a level acceptable to the organiza:on.

The project plans must be updated to reflect con:ngency funds and reserves.

IIL-‐CERT5


46


Participant’s Notes: The risk register is a summary document (most likely a table in a spreadsheet containing strategy, responsibility, target date, triggers, status, etc.) that travels from risk iden:fica:on through risk monitoring and control.

The risk response plan is a more detailed supplement to the risk register that explains the specific response in more detail. Risk response plans may not be necessary for each risk on lower risk projects. On more complex, higher risk projects, you may need addi:onal detail especially for high probability and high impact risks.

ARer risk responses have been iden:fied you may s:ll have residual risk.

Residual risk is the risk that remains aRer risk responses have been implemented.

Secondary risks are risks that arise as a direct result of implemen:ng a risk response.

The PMBOK® Guide – FiRh Edi:on, Glossary

IIL-‐CERT5


47


Participant’s Notes: When you decide which risk response strategy to use, ask the following ques:ons:

•  Can the strategy be implemented and s:ll meet client needs?

•  What is the an:cipated effec:veness of the risk strategy?

•  Is the strategy affordable in terms of cost and other resources?

•  Is :me available to develop and implement the strategy?

IIL-‐CERT5


48


Participant’s Notes: The PMBOK ®Guide – FiRh Edi:on describes the key benefit of this process as “improving efficiency of the risk approach throughout the project.”


Monitoring risk events must occur throughout the project life cycle. Predetermined triggers or warning signs will be an obvious indicator that risk has or is about to occur, but regularly scheduled risk monitoring ac:on should also occur.

Controlling risk is ac:ng on the result of the risk monitoring process. We may have to choose an alterna:ve strategy for risk response, implement a con:ngency plan, take correc:ve ac:on, or maybe even re-‐plan the project.

IIL-‐CERT5


49


Participant’s Notes: The PMBOK® Guide – FiRh Edi:on defines the following for this sixth Project Risk Management process:

Inputs

•  Project management plan •  Risk register

•  Work performance data

•  Work performance reports Tools & Techniques

•  Risk reassessment

•  Risk audits •  Variance and trend analysis

•  Technical performance measurement •  Reserve analysis

•  Mee:ngs Outputs

•  Work performance informa:on

•  Change requests

•  Project management plan updates •  Project documents updates

•  Organiza:onal process assets updates

IIL-‐CERT5


50


Participant’s Notes: Stakeholders are interested in how risks and the response plans for risks may affect the schedule and cost of the project. Progress reports, status reports and forecast reports draw on the ac:vi:es taking place on the project to evaluate the need for correc:ve or preven:ve ac:ons.

IIL-‐CERT5


51


Participant’s Notes: The frequency of risk reassessment depends on how the project progresses rela:ve to its objec:ves.

IIL-‐CERT5


52


Participant’s Notes: In this diagram, you see how EVMS helps you forecast the outcome of the troubled project based on extrapola:ng the current data. If nega:ve trends are discovered early and supported with good data, the project manager may have some chance of reversing them. In this diagram, which, if any, shows a nega:ve trend, cost or schedule performance?

IIL-‐CERT5


53


Participant’s Notes: A tool that can be used for monitoring and controlling technical or performance risk is technical performance measurement (TPM). TPM has many similari:es in concept with EVMS, but uses different data. Early indica:ons of technical performance slippage may predict con:nued difficul:es and ul:mately a shorzall in performance if correc:ve ac:ons are not taken early.

IIL-‐CERT5


54


Participant’s Notes: TPM requires that you develop your baseline technical plan by driving overall objec:ves down to the detailed levels where the work is done. If technical specifica:ons are a part of the statement of work, performance will be measured to those specifica:ons. Linking the technical accomplishments to milestones produces a :me-‐phased technical plan. TPM focuses on the possibility of missing technical targets, which may predict technical risk and client acceptance issues at comple:on.

IIL-‐CERT5


55


Participant’s Notes: In summary, risk response plans must be appropriate to the level of risk that exists within the project. Monitoring and control ac:vi:es must be tailored to fit the degree of risk and may include addi:onal risk iden:fica:on and analysis. Periodic risk reassessments, variance and trend analysis, risk audits, and technical performance measurement should be performed during project execu:on and may result in addi:onal planning.

IIL-‐CERT5


56


Participant’s Notes: A scope change is very similar to a change in contractual terms. It changes the agreement between client and performing organiza:on. It is important that all documents be updated to reflect the new agreement. Different stakeholders rely on these various documents for informa:on on how to perform project work.

IIL-‐CERT5


57

RESPONSIBILITY STANDARDS One of risks we, as project managers, need to be on the look out for is unethical or illegal behavior from our team members or other stakeholders. There are several responsibility standards that cover how to address unethical behavior. We uphold this Code and hold each other accountable to it.

As a project manager we have a responsibility to behave ethically, and require that our colleagues do the same. We report unethical or illegal conduct to appropriate management and, if necessary, to those affected by the conduct. If we are in a situa:on where we see unethical or illegal behavior we need to report it appropriately, including to the person or persons who are affected by the behavior. We bring viola)ons of this Code to the aTen)on of the appropriate body for resolu)on.

Certain industries have boards where you would report viola:ons. For example if you see a Professional Engineer or a CPA behaving inappropriately you would report that to the licensing body for that profession. We only file ethics complaints when they are substan)ated by facts.

As important as it is to report viola:ons, we should only do that if we have facts, not gossip or rumors. We pursue disciplinary ac)on against an individual who retaliates against a person raising ethics concerns.

In the event that we see someone being treated poorly because they were a whistle-‐blower or reported an ethics viola:on, we need to pursue disciplinary ac:on against the party ini:a:ng the mistreatment.

IIL-‐CERT5





IIL-‐CERT5


60

pmp cross-cutting skills have been updated in the pmp exam ... · iilcert5...

Documents