Risk Analysis Checklist and Templates for Managers

Internal Risks Checklist-PD.docx
Organizational Risk Analysis Checklist-PD.docx
Organizational Risk Identification Checklist-PD.docx
Organizational Risk Planning Summary-PD.docx
Portfolio Contingency Plan Template-PD.docx
Portfolio Risk Management Plan Template-PD.docx
Portfolio Risk Summary Template-PD.docx
Process Analysis Checklist-PD.docx
Process Development Plan Template-PD.docx
External Risks Checklist-PD.docx

Risk Management for Project Driven Organizations
By Andy Jordan, PMP
Internal Risk Checklist
When an organization undertakes a major initiative there is potential for many different factors to influence the project. This checklist identifies
categories of risk that exist internal to the organization that may impact the ability of the organization to successfully deliver the project. During the
business casing and project review and selection work the sponsor and senior team members should review this checklist and confirm that they have
considered the implications of risks occurring within each of these categories. This document can then become a feeder to the more detailed risk
management documentation that will be developed if and when the project is approved.
This document should be used in conjunction with the external risk checklist, and it should be noted that the risks identified here should remain strategic
in nature. The purpose of this document is to help identify the risk exposure that the organization will face if it proceeds with this initiative, and while the
temptation with internal risks is to identify all of the risks that exist, this is not an exercise in risk identification, simply a support tool to the project review
and selection process.
Risk Category Description Risk Exposure
($000s)
Risk References Last Review
Date
Last Reviewed
By
Compliance Compliance risk is the risk to the organization from the
need to comply with laws, regulatory frameworks, etc.
Examples of the negative implications of a failure to
comply are obvious, censure, exclusion from a
professional body, perhaps even legal action. The
positive elements are less obvious, but they are still
there – being one of a few organizations able to claim
that they have been given the highest level of industry
recognition by the governing body for example.
Financial Financial risks are the risks associated with investment
decisions that the organization makes. Every proposed
project involves a degree of financial risk – whether it is
approved or rejected. Financial risks are often assumed
as a result of some of the other risk categories, but
managing these risks should be key to the decisions
made around projects – does the expected return
justify the investment that is being made?

By Andy Jordan, PMP
J. Ross Publishing WAV® material 2 of 3 2013
($000s)
Date
Last Reviewed
By
Operational Operational risks are those that stem from the day to
day execution of what the organization does. This is a
very broad category and may show itself through
quality, customer service, productivity, employee
satisfaction, or any number of other factors. For most
organizations operational risks need to be broken down
to a lower level to be properly understood and
managed, the operations category is simply too broad.
Strategic Strategic risks result from the directional decisions that
the organization makes – the goals and objectives that
it sets and the strategies and plans that it puts in place
to achieve those goals and objectives. This is the most
fundamental type of risk for the organization and will
drive all of the others.
Technological We looked at technological risks as an external
environmental factor, but there is also significant
internal risk from technology. Decisions about which
technologies to use can drive significant risks into the
organization. If we choose to embrace new technology
then we may face steeper learning curves, more
teething problems, etc. If we instead decide to use
older platforms then we may be faced with an earlier
forced upgrade, lower performance and reduced
feature sets.

By Andy Jordan, PMP
Guidelines
The risk category and description columns are based on my book Risk Management for Project Driven Organizations and are intended to help to identify
potential internal sources of risk. An individual project may not have risks in every category, and the descriptions are not intended to be exhaustive,
rather they are prompts for discussion as to possible risks that your project may face.
By far the most important column in this template is risk exposure. This field is intended to be an estimate of the potential financial impact of the risks in
each category should they trigger. At this pre-approval stage they are only high level planning estimates, and the figure in each category is calculated by
adding the potential exposure (risk amount multiplied by % chance to trigger) for each of the risks identified in the risk references column. Effort impact
is converted to financial cost for the purposes of planning. Management costs are not considered here as response strategies have not been determined.
The risk references column is intended to identify the risk ID for any risks that you have identified within that category and may well include a hyperlink to
the risk document where more details are available. The last review date and last reviewed by fields are simply audit fields to ensure that the analysis is
current and complete.
Because these risks are internal to the organization they will ultimately generate most of the risks that are actively managed by the project, but care
should be taken to avoid excessive depth and management strategies at this point, that analysis will be completed during project planning.

By Andy Jordan, PMP
Organizational Risk Analysis Checklist
Item Completed?
Am I an appropriate resource to conduct this work? Choose an item.
Qualitative Analysis
Is the risk understood as described in the risk summary? Choose an item.
Have all likely triggers been identified? Choose an item.
Has likely impact of triggering been analyzed (cost and schedule)? Choose an item.
Has a value for schedule and budget impact been developed? Choose an item.
Has a value for likelihood to trigger been developed? Choose an item.
Quantitative Analysis – (only complete this section if quantitative risk undertaken)
Have comparable risks been identified and validated? Choose an item.
Do comparable values align with qualitative analysis? Choose an item.
If no, is variance explainable and acceptable Choose an item.
Prioritization
Can risk be effectively managed? Choose an item.
Can risk be efficiently managed? Choose an item.
Has risk history been considered (N/A for first time analysis only)? Choose an item.
Management Approach
Has risk management approach been determined? Choose an item.
Approval
Has analysis been reviewed and approved? Choose an item.
Has risk summary been updated? Choose an item.
Guidelines
This checklist is deliberately kept as simple as possible to avoid unnecessary overhead. Although the
template is set up with Yes / No options it can be considered as a personal memory prompt for risk
analysis resources rather than a formal document that needs to be completed. For the same reason
portfolio and / or resource identification fields are not necessary.
The goal for successful completion of the checklist is to answer ‘Yes’ to every question, a ‘No’ should be
a flag that further work may be required. The assumption is that this checklist will be reviewed /
completed by each individual involved in risk analysis as they proceed through the steps outlined in the
Process Elements section of Chapter 9.
Notes on each field:
 Appropriate Resource – this is a sensible ‘sanity check’ for each person who has been asked to
take part in organizational risk analysis. Risk analysis resources are often experts, but there
should still be a confirmation step that the right expert has been matched with the right risk.
 Is Risk Understood – analysis cannot be successful unless the risk as documented in the risk
summary is fully understood. The risk analyst should discuss any areas of uncertainty with the
person who prepared the risk summary prior to beginning their analysis.

By Andy Jordan, PMP
 Likely Triggers – in order to analyze the impact of the risk the analysis needs to understand the
likely triggers for the risk. The description of the risk should make most of these obvious, but
the risk analyst should confirm that all reasonable trigger events have been considered.
 Impact Analysis – the most fundamental element of this work – has the full potential impact of
the risk triggering been identified and considered. It can be easy to overlook more complex
impacts after the more obvious items have been considered but in a complex environment like a
portfolio or program it cannot be assumed that the immediate direct impacts are the only ones
(or even the most severe impacts).
 Value of Impact – all analysis needs to be distilled down to a schedule (hours / days / weeks)
and / or cost value so that the risk can be compared against other risks and so that appropriate
reserves can be included. These values will also feed the organizational risk profile as well as
contributing to the decision around the appropriate management strategy.
 Likelihood to trigger – for the same reasons as described for ‘value of impact’ above the risk
analysis should generate a likelihood to trigger, generally in the form of a percentage.
 Comparable risks – quantifiable analysis relies on identifying similar risks from previous and / or
current initiatives to use for comparison purposes with the risk currently being analyzed. We
need to ensure that the risks used for comparison purposes are appropriate – they are
comparable and there are not special circumstances that will invalidate comparison.
 Do Values Align – quantitative analysis involves comparison with historic data and we need to
check the alignment of our qualitative analysis with the historic ‘actuals’ data to see whether
the numbers align. If the values are broadly comparable (as defined by the organization) then
the quantitative analysis supports the qualitative work, if not then the next question needs to be
addressed.
 Is Variance Explainable and Acceptable – if the quantitative and qualitative analyses are
inconsistent with one another then the risk analyst needs to be satisfied that there is a reason
for the variance and that the degree of variance is acceptable given the explanation. A variance
is not automatically a problem, it may simply represent the absence of directly comparable
historic risks and the need to apply some adjustments, but this should still be consciously
confirmed as part of the checklist.
 Can Risk be Effectively Managed – once the core analysis has been completed the focus shifts
to prioritization and management. This begins with understanding whether there is anything
that the organization can do to manage the risk. This may not be complete elimination, but we
should confirm that attempts to manage the risk are capable of delivering tangible
improvements.
 Can Risk be Efficiently Managed – we also need to ensure that risk management is appropriate
– that the cost of managing (financial and schedule) is justified by the potential improvement
that can be delivered. There may be circumstances where risk management is approved
regardless of whether it is cost effective simply because of the potential impact of a risk
triggering, but this is still an important consideration.

By Andy Jordan, PMP
 Risk History – this category does not apply to the first time analysis of a new risk, but will apply
in all other circumstances. The history of the risk – the response to past management, the trend
of the risk (see Chapter 9), etc will affect decisions about prioritization and management and
need to be considered as variables to the decision.
 Management Approach – based on the prioritization exercise this is the final step in the
analysis, confirmation that the preferred management approach has been determined.
 Reviewed and Approved – because of the importance of the analysis it is necessary for the work
to be reviewed and approved (see Chapter 9) and this step merely confirms that this has
occurred.
 Risk Summary Updated – the final step in the analysis checklist is to ensure that the risk
summary is updated with the results of the risk analysis.

By Andy Jordan, PMP
Organizational Risk Identification Checklist
Item Completed?
Am I an appropriate resource to conduct this work? Choose an item.
Has existing risk list been reviewed (if appropriate)? Choose an item.
Is risk candidate new and not an extension / version of an existing risk? Choose an item.
Is risk candidate at the organizational / portfolio / program (as appropriate) level? Choose an item.
Does risk candidate have the ability to impact the portfolio / program? Choose an item.
Is risk candidate sufficiently documented for discussion? Choose an item.
Guidelines
This checklist is deliberately kept as simple as possible to avoid unnecessary overhead. Although the
template is set up with Yes / No options it can be considered as a personal memory prompt for risk
identification resources rather than a formal document that needs to be completed. For the same
reason portfolio and / or resource identification fields are not necessary.
The goal for successful completion of the checklist is to answer ‘Yes’ to every question, a ‘No’ should be
a flag that further work may be required. The assumption is that this checklist will be reviewed /
completed by each individual involved in risk identification prior to the group review process (Chapter 8)
 Appropriate Resource – this is a sensible ‘sanity check’ for each person who has been asked to
take part in organizational risk identification work. The specific criteria will be determined by
each organization and should be clearly communicated, but see discussion in Chapter 8.
 Existing Risk List – in most cases risk identification will be supplemental to the list of existing
risks and it is important to review that list in order to avoid duplication.
 Is Candidate New – we need to avoid duplication of risks and if the situation that is being
considered is really an additional impact from an existing risk then it should not be created as a
new risk. That will create duplication of effort and potentially reduce the effectiveness of risk
management.
 Is Candidate at Portfolio Level – we need to ensure that the candidate being considered is at
the portfolio / program level rather than a project level risk that should be managed as part of a
single initiative.
 Is There Ability to Impact – right at the start of the book we defined risk as having to create
impact, if the situation being considered will not have impact (positive or negative) then it
should not be considered as a risk.
 Sufficiently Documented – following the individual analysis there will be a group review and
while it may be premature to complete a risk summary at this point (although your organization
may decide that is appropriate), the risk candidate should be documented to explain why the
person reviewing it believes that it is a portfolio or program level risk.

By Andy Jordan, PMP
Organizational Risk Planning Summary
This document consolidates information from the External Risk Checklist and Internal Risk Checklist
templates to provide a summary of the expected risk exposure for a proposed initiative and adds
additional information designed to assist in decision making. This summary is used as part of project
review and selection to help ensure that the organization understands the potential risk exposure that it
faces prior to approving the project. As such it forms part of the overall business case that approval is
based upon by the project selection board or equivalent.
Risk Exposure by Category
Risk Category Risk Exposure ($000s)
External Risks:
Competitive
Economic
Geographic
Investor
Political
Regulatory
Reputational
Societal
Technological
External Sub Total:
Internal Risks:
Compliance
Financial
Operational
Strategic
Technological
Internal Sub Total:
Total Exposure:

By Andy Jordan, PMP
Constraints Hierarchy
The constraints hierarchy identifies the priority of the constraints in the event that compromises need to
be made. Item number 6 in the hierarchy is the first of the constraints that would be compromised in
order to preserve the remaining 5, number 5 would be sacrificed if needed to preserve the top 4, etc.
The number 1 constraint is the one which will be preserved at all cost.
This is important in risk planning because it helps the organization to understand the implications of the
risk exposure. If risk is the number 1 constraint then significant funds will need to be put into managing
the risk exposure and into providing contingency and management reserves to minimize impact. If risk
is the 6th
constraint then the organization is more risk tolerant on this initiative and will be prepared to
accept higher risks with less active management.
Order (Most important to least) Constraint
1
2
3
4
5
6
The six constraints are Cost ($), Effort, Quality, Risk, Schedule and Scope.
Reserves
Reserves identify the amount of funding that will be put aside for Contingency and Management
reserves. The organization should expect to include these funds in the total project budget for this
initiative.
Contingency reserve is specifically to address the impact of the risks identified in the risk exposure total
above. If the contingency reserve fund is lower than the total exposure then the organization needs to
reduce the exposure through risk management or risk a shortfall that will impact other initiatives and /
or operations.
Management reserve is to address risks that have not yet been identified and requires a subjective
assessment. Generally speaking, the greater the number of unknowns around the project and the
higher the number of internal and external risk categories that have risks identified, the higher the
management reserve should be. Again if the management reserve is insufficient this will impact other
initiatives and / or operations.

By Andy Jordan, PMP
Reserve Type Amount ($000s)
Contingency
Management
Guidelines
This document is shown in Word format for ease of formatting of the text, it can however easily be
copied into Excel if you wish to use calculations.
The risk exposure information can be copied straight from the two checklists related to this summary
and requires no further explanation.
The constraints hierarchy is an important part of this summary. Essentially each of the six constraints
needs to be entered into the hierarchy in reducing priority order with the understanding that this order
will be followed in the event that the project has problems. From a risk management standpoint this
helps us understand how important risk is relative to the other constraints – in a new drug development
project we would expect to see risk right at the top, in a mobile app development project risk will be
lower down with schedule and scope likely near the top.
The reserves are important because they reflect real funding that should be added to the project costs
to form the total budget. The contingency reserve should bear a close relationship with the total risk
exposure, but this is not quite the same as in project risk management. When we calculate the
contingency reserve during a project it is the sum of the potential impact of each risk multiplied by the
likelihood of the risk occurring. At this planning stage we have not yet considered how risk management
can reduce our exposure so it is acceptable to have a lower number (contingency should never be higher
than total exposure), but there are some important considerations:
 The greater the amount of risk exposure that is in the external risk category, the higher the
contingency reserve should be. This is because external risks are generally less capable of being
managed to a lower exposure and / or likelihood to occur.
 The higher risk is in the contingency hierarchy the higher the contingency reserve should be,
especially if risk is higher than cost. This is because risk is determined as one of the last things
that the project will sacrifice, and if risk is considered to be more important than cost it makes
no sense not to ensure that there is sufficient contingency reserve.

By Andy Jordan, PMP
Management reserve is a more subjective value and is based on the expectation of unknown risks.
Some organizations will apply an arbitrary percentage of the contingency reserve to this category, but in
truth is should consider:
 The greater the number of external and internal risk categories that have been identified the
higher the management reserve should be. This is because the risks are clearly wide ranging
which increases the likelihood that some may be missed.
 The presence of one or two very large risks with relatively small chances to trigger should result
in an increased management reserve. Contingency reserves are based on average exposure
across the portfolio of risks and outliers can skew the numbers requiring management reserve
to make up any shortfall.
 A high risk exposure in internal risks should lead to increased management reserve. High
internal risks implies that the project has a large number of elements that are not well
understood / well controlled by the organization which may result in missed risks.

By Andy Jordan, PMP
Portfolio Contingency Plan - Template
Portfolio Name Risk ID #
Risk Owner Date Last Updated Click here to enter a date.
Trigger Events:







Damage Limitation:
1.
2.
3.
4.
5.
6.
7.
Recovery:
1.
2.
3.
4.
5.
6.
7.
Plan Approved? Choose an item. Approved By
Is recovery approved without impact assessment and further approval? Choose an item.
Contingency Implementation
Date Triggered Click here to enter a date. Confirmed By
Damage Limitation Notes:
Date Impact Assessment
Completed
Click here to enter a date. By
Link to Impact Assessment
Recovery Approved? Choose an item. Approved By
Recovery Notes:

By Andy Jordan, PMP
Guidelines
This document summarizes the contingency plan for a risk. Every actively managed risk requires a contingency plan
and it is vital that the document is completed thoroughly and maintained as the risk evolves and develops. When and
if the risk triggers there will be a need for decisive action and this document needs to be clear and complete enough
to allow for those steps to be taken without a requirement for further analysis.
The contingency plan is broken into two distinct sections, the first is completed as one of the first activities within risk
management (see Chapter 10), and the second is completed when the contingency is implemented.
 Portfolio Name – this field may not always be relevant at the portfolio level, but should always exist for
programs to help identify the initiative that the risk relates to. You can also apply this template to projects if
they are complex enough to justify this amount of formality.
 Risk ID # – this is simply an identifier that allows you to uniquely code each risk. Try to use a different coding
system to that used for program and / or project level risks to avoid confusion.
 Risk Owner – the single person responsible for managing the risk. This should always be a single person – if
multiple people are involved then that will be addressed in the risk summary. If your systems support it
consider making this a link to e-mail, instant messaging, etc to allow for contact directly from the plan.
 Date Last Updated – the contingency plan won’t change as frequently as the risk summary, but it should be
reviewed frequently and updated as material changes on the risk occur. At the very least a contingency plan
that hasn’t been updated for several months should be reviewed to ensure that it is still relevant and
complete. This field includes a date selector – click on the down arrow to bring up the current month and
navigation options.
 Trigger Events – the event or events that define whether or not a risk has triggered. Every trigger must be
specific and measurable, leaving no room for interpretation as to whether it has occurred or not. Where
multiple triggers exist this field should also define the combination of triggers that must occur for the risk to
be considered triggered (all, one of, the first plus two others, etc).
 Damage Limitation – the sequence of actions to be taken when the risk triggers in order to minimize the
impact that the risk has. This list should be executed in sequence, and unless otherwise stated should occur
as start to start dependencies (i.e. start task 2 as soon as possible after task 1 has started). Except in very
rare circumstances the damage limitation activities will automatically occur once the risk has triggered and
must be clearly defined so that it is obvious to anyone unfamiliar with the risk what has to occur. It may be
necessary to reference external documents for further information, and if individual people are referenced
the role should be used to avoid potential delays from an absence.
 Recovery – the sequence of actions to be taken to recover the situation after the damage limitation has
occurred. The notes for ‘Damage Limitation’ also apply here, but note that further analysis and approval may
be required before recovery can be implemented (see ‘Recovery Without Impact Assessment Approved’
below).

By Andy Jordan, PMP
 Plan Approved – the contingency plan should be reviewed and approved (see Chapter 10) and this confirms
that the approval has been given and in the next field provides the name of the person who provided that
review and approval. If your contingency plan frequently has to be reviewed and updated during a portfolio
you may also want to add a date field for the date of the last review. This field includes a drop down menu
that currently supports options for Yes and No. You can modify these values – if your organization supports
the concept of a conditional approval for example. To modify the values select the ‘Developer’ ribbon in
Word and then ‘Design Mode’. Select the drop down which will now have a different frame around it and
then click on ‘Properties’ for a pop up box and instructions for modifying and adding to the list.
 Approved By – see note for ‘Plan Approved’ above.
 Recovery Without Impact Assessment Approved – in many cases it will be necessary to conduct an impact
assessment or similar analysis when a risk triggers before approving steps to be taken to recover the
portfolio, program, project or work package to as close to the pre-trigger situation as possible. This is
because the work involved in recovery may not be the best use of resources (see Chapter 11), however in
some situations, typically where the risk impact is potentially catastrophic, the recovery needs to be
implemented as soon as possible after damage limitation and so this field approves that action to occur
without an impact assessment. This field includes a drop down that can be modified if you need more than
Yes and No options. See the notes under ‘Plan Approved’ above for instructions on how to modify the list.
 Date Triggered – this is the first field of the second half of the contingency plan and is the first field
completed when the risk has triggered. This represents the date that the risk triggered. This field includes a
date selector – click on the down arrow to bring up the current month and navigation options.
 Confirmed By – triggering a risk is a significant step and the risk owner should seek confirmation that their
analysis is correct and that the risk has triggered. If the trigger events have been well defined this step is
simply a safeguard and should not be considered mandatory.
 Damage Limitation Notes – this field allows for any notes and observations from the implementation of the
damage limitation steps. At a minimum it should include dates / times of actions taken to provide a summary
of actions, but may also require a more detailed summary (or a link to such a summary elsewhere in the
organization).

By Andy Jordan, PMP
 Date Impact Assessment Completed – if an impact assessment is required (most situations) then the date of
completion should be entered here. This field includes a date selector – click on the down arrow to bring up
the current month and navigation options.
 By – the person completing the impact assessment.
 Link to Impact Assessment - the impact assessment may modify or replace the steps identified earlier in the
‘Recovery’ portion of the contingency plan and so the impact assessment must be linked to the contingency
plan.
 Recovery Approved – the impact assessment should be reviewed and approved by the portfolio / program /
project manager as appropriate and this confirms that the approval has been given and in the next field
provides the name of the person who provided that review and approval. This is a vital step as it may commit
the organization to significant additional work. This field includes a drop down that can be modified if you
need more than Yes and No options. See the notes under ‘Plan Approved’ above for instructions on how to
modify the list.
 Approved By – see note for ‘Recovery Approved’ above.
 Recovery Notes – this field allows for any notes and observations from the implementation of the recovery.
At a minimum it should include dates / times of actions taken to provide a summary of actions, but may also
require a more detailed summary (or a link to such a summary elsewhere in the organization).

By Andy Jordan, PMP
Portfolio Risk Management Plan – Template
ID Description Programs / Projects Owner Severity Status Link to risk summary
Choose an item. Choose an item.
Guidelines
Don’t try and do too much with the risk management plan. It is just a summary document that provides an overview of the portfolio risks and allows access to more detail. Consider building
this template within your PPM tool or within a corporate collaboration tool that allows for features to color code items based on different criteria, automatic updating of data based on
changes to the underlying risk summary, the ability to contact the owner directly from the template, etc. Depending on the functionality of your tool you may be able to create this as an
automated report that requires no manual intervention to maintain (all of the data is populated from risk summaries). This template can also be used for programs with minimal change.
Notes on each column:
 ID – this is simply an identifier that allows you to uniquely code each risk. Try to use a different coding system to that used for program and / or project level risks to avoid confusion.
 Description – this should briefly summarize the risk so that readers have a basic understanding, but should avoid being a detailed entry. Remember that the vast majority of readers will
be familiar with the risks so they only need a brief summary and the full risk summary document is only a click away.
 Programs / Project – this should list all of the programs and projects associated with this risk. Feel free to categorize if appropriate – “all IT” for example. Make sure that you clearly
define what determines the association – provision of resources, potential for symptoms to occur there, potential for impact, etc.

By Andy Jordan, PMP
Portfolio Risk Management Plan – Template
Notes on each column:
 Owner – the single person responsible for managing the risk. This should always be a single person – if multiple people are involved then that will be addressed in the risk summary. If
your systems support it consider making this a link to e-mail, instant messaging, etc to allow for contact directly from the plan.
 Severity – a drop down menu makes selection easier and avoids the potential for confusion of terms and supports dependent formatting (color coding based on criteria for example). This
field includes a drop down menu that currently supports options for Yes and No. You can modify these values – if your organization supports the concept of a conditional approval for
example. To modify the values select the ‘Developer’ ribbon in Word and then ‘Design Mode’. Select the drop down which will now have a different frame around it and then click on
‘Properties’ for a pop up box and instructions for modifying and adding to the list. Make sure that you define what constitutes each of the categories that you establish to avoid
differences in interpretation. The drop down options here must be aligned with the options for the same field on the Risk Summary Template.
 Status – see notes for severity.
 Link to risk summary – a link to access the more detailed risk summary for additional information on the risk. You may be able to eliminate this column and use the ID or description fields
as a link.

By Andy Jordan, PMP
Portfolio Risk Summary - Template
Portfolio Name Risk ID #
Risk Owner Last Review Date Click here to enter a date.
Current Status Choose an item.
Current Severity Choose an item.
Link to Contingency Plan
Risk Description:
Risk Analysis
Potential Schedule Impact Potential Financial Impact
List of Impacted Programs and / or Projects
Analysis Approved? Choose an item. Approved By
Risk Analysis Notes:
Risk Management
Risk Management
Approach
Choose an item. Risk Management Method Choose an item.
Risk Management Notes:
Risk Closure:
Closure Cause Choose an item. Date Closed Click here to enter a date.
Risk Closure Notes

By Andy Jordan, PMP
Guidelines
This document is the master document for a single risk. Don’t try to save a few minutes by only completing it in a
rudimentary fashion – someone reviewing the document years after the project is completed in an attempt to help
them to manage a similar risk should be able to understand the document. If your suite of tools supports the
creation of a template like this that allows only the most recent comments to show initially then this can assist with
formatting and readability, but there is no reason why a simple word template with carefully separated notes
(referencing the date that each comment was created) can’t be successful.
This template assumes a negative risk (threat), but it can be adapted easily for a positive risk (opportunity) with
simple changes to one or two fields – the risk management methods dropdown for example. Most of the fields will
remain unchanged for positive risks and it is good practice to encourage the tracking of these positive risks to avoid
the potential for missed opportunities which have very real impact on goals and objectives.
 Portfolio Name – this field may not always be relevant at the portfolio level, but should always exist for
programs to help identify the initiative that the risk relates to. You can also apply this template to projects
if they are complex enough to justify this amount of formality.
 Risk ID # – this is simply an identifier that allows you to uniquely code each risk. Try to use a different
coding system to that used for program and / or project level risks to avoid confusion.
 Risk Owner – the single person responsible for managing the risk. This should always be a single person – if
multiple people are involved then that will be addressed in the risk summary. If your systems support it
consider making this a link to e-mail, instant messaging, etc to allow for contact directly from the plan.
 Last Review Date – the date that the risk was last reviewed. This isn’t necessarily the date that the
document was last updated as a review can occur without any changes made (although you may want to
introduce a best practice of noting in the notes fields that no changes are required. This is particularly easy
to do if your tool / template allows for filtering of notes / comments. This field includes a date selector –
click on the down arrow to bring up the current month and navigation options.
 Risk Severity – a drop down menu makes selection easier and avoids the potential for confusion of terms
and supports dependent formatting (color coding based on criteria for example). This field includes a drop
down menu that currently supports options for Yes and No. You can modify these values – if your
organization supports the concept of a conditional approval for example. To modify the values select the
‘Developer’ ribbon in Word and then ‘Design Mode’. Select the drop down which will now have a different
frame around it and then click on ‘Properties’ for a pop up box and instructions for modifying and adding to
the list. Make sure that you define what constitutes each of the categories that you establish to avoid
differences in interpretation.
 Risk Status – see notes for severity, this again has a customizable drop down.
 Link to Contingency Plan – a link to launch the detailed contingency plan associated with the risk.
 Risk Description – the detailed explanation of what the risk is, why it is important and how it is likely to
impact the portfolio. This should be as detailed as necessary to provide all of the required information.

By Andy Jordan, PMP
 Potential Schedule Impact – the impact (usually in days or weeks) that is expected to occur if the risk
triggers, based on the analysis of the risk.
 Potential Financial Impact – the impact (usually in $000s) that is expected to occur if the risk triggers,
based on the analysis of the risk.
 List of Impacted Programs and / or Projects – the full list of programs and / or projects that are impacted
by the risk, either in terms of management activities, by the potential to be impacted if the risk triggers, or
both. In complex portfolios, or on particularly complex risks, you may wish to split this field to list both the
initiative and the nature of the impact for that initiative.
 Analysis Approved – the risk analysis should be reviewed and approved (see Chapter 9) and this confirms
that the approval has been given and in the next field provides the name of the person who provided that
review and approval. If your risk analysis work frequently has to be reviewed and updated during a
portfolio you may also want to add a date field for the date of the last review. This field includes a drop
down that can be modified if you need to modify the options. See the notes under ‘Risk Severity’ above for
instructions on how to modify the list.
 Approved By – see note for Analysis Approved above.
 Risk Analysis Notes – whenever the analysis is reviewed and updated this field should be updated. This will
not be as active as some other notes fields, but may still require reviewing and updating in the event of a
significant change on the risk or other portfolio elements.
 Risk Management Approach – this will reflect whether the risk is being managed passively or actively
based on the results of the analysis. This field includes a drop down that can be modified if you need to
modify the options. See the notes under ‘Analysis Approved’ above for instructions on how to modify the
list.
 Risk Management Method – this will reflect the method that will be used to manage the risk. This should
be consistent with the Risk Management Approach field – e.g. passive risk management should not be used
in conjunction with mitigation. See Chapter 9 for more details. This field includes a drop down that can be
modified if you need to modify the options. See the notes under ‘Risk Severity’ above for instructions on
how to modify the list.
 Risk Management Notes – this will be the ‘running commentary’ on the way that the risk is being
managed. Any changes to the way that the risk is managed, no matter how small, should be captured here,
as should any changes to the way that the risk is responding to that management (positive or negative).
You may also want to have a brief comment here whenever the risk is reviewed, even if it is only ‘no
change’ with the date. However, care should be taken to ensure that the update doesn’t become
automatic and that the risk owner is still conducting a thorough review on a regular basis.

By Andy Jordan, PMP
 Closure Cause – if the risk is no longer being managed then the reason should be captured (the elimination
of the threat or the triggering of the risk) along with the date that the risk was closed. Note that a decision
to stop actively managing the risk is not the same as closure and should be recorded in the Risk
Management Approach and Risk Management Method fields. This field includes a drop down that can be
modified if you need to modify the options. See the notes under ‘Risk Severity’ above for instructions on
how to modify the list, but note that you should be careful in creating more options for closing a risk –
generally elimination or triggering are the only possible reasons.
 Date Closed – see notes on Closure Cause above. This field includes a date selector – click on the down
arrow to bring up the current month and navigation options.
 Risk Closure Notes – an explanation of why the risk was closed – details of why the threat is no longer
considered real or details of the trigger events.

By Andy Jordan, PMP
Process Analysis Checklist
This checklist assumes that you will be developing a process analysis matrix similar to that shown in
Table 20.1
Item Completed?
Has business case been reviewed? Choose an item.
Scope
Have all project execution areas within the organization been identified? Choose an item.
Does scope need to be reduced to subset of execution areas? Choose an item.
If yes, has scope been clearly defined (for this phase)? Choose an item.
Does scope align with business case? Choose an item.
If no has variance been approved? Choose an item.
Existing processes
Does organization have a standard organizational risk management approach? Choose an item.
If yes, enter version number / date
Does organization have a standard project risk management approach? Choose an item.
If yes, enter version number / date
Have all existing active risk management processes been identified? Choose an item.
Have all documented processes been obtained? Choose an item.
Have all support documents (templates, guidelines, etc) been obtained? Choose an item.
Have examples of managed risks been obtained for each available approach? Choose an item.
Risk outcomes / organizational view
Have processes with available risk outcome / success metrics been identified? Choose an item.
Have metrics been obtained where available? Choose an item.
Is executive / leadership view of risk effectiveness and challenges understood? Choose an item.
Documentation
Has matrix been completed? Choose an item.
Is matrix thorough enough to be understood? Choose an item.
Guidelines
This checklist is intended to partner the matrix shown in Table 20.1 and a change to one may well
require a change to the other. This template framework can also be used to capture information on a
specific departmental risk process as you drill down into more detail on the way that risk management is
applied in different areas of your organization. You will need to adjust some of the specific checks, but a
consistent ‘next level down’ checklist will help to ensure that the work undertaken on understanding the
current state for each row of the matrix can be compared with other rows.
 Business Case Review – this is an initial ‘sanity check’ to ensure that the business case has been
reviewed prior to any other work being undertaken. The business case should provide the
foundation for at least the next few questions as well as contributing to other checks.

By Andy Jordan, PMP
 All Execution Areas Identified – even if the project will have restricted scope initially any area of
the organization can provide inputs to the processes that you develop, reveal best practices to
leverage, etc. Additionally, if the process analysis identifies significant gaps and / or
shortcomings the scope may need to be reviewed once the analysis is complete.
 Scope Reduction – unless the project, or this phase of the project, is going to address every
project execution area within the organization then the scope will only be a subset of those
process areas and this question confirms that.
 Scope Definition – the scope obviously needs to be clearly understood and unless every project
execution area is to be included then this must be specifically defined.
 Scope Alignment with Business Case – the project was approved based on the business case
which will have contained some high level scope for the project. We need to ensure that the
scope as now defined aligns with the scope contained in the business case, and if not address
the next checklist item.
 Variance Approval – if the business case and the current scope are not aligned then the
variance needs to be approved before the work can proceed. This approval should be given by
the same person or group who approved the project initially.
 Existing Standard Organizational Risk Process – if the organization already has some form of
standard organization wide risk management approach then that should be captured here and
the version number / last modified date captured. Note that this should reflect any approach
that has been identified as an organization wide and will not necessarily reflect compliance,
reach, etc.
 Existing Standard Project Risk Process – if the organization already has some form of standard
project risk management approach then that should be captured here and the version number /
last modified date captured. Note that this should reflect any approach that has been identified
as ‘standard’ and will not necessarily reflect compliance, reach, etc. You may need to duplicate
these two rows if there are different standards for different areas of the organization.
 All Active Processes Identified – it is important to identify all of the risk management processes
that are currently in use so that the broadest possible understanding of the way that risk
management occurs is obtained. This should not be limited to just the areas of the organization
that are in scope for this project / phase, but should seek a full picture within the organization.
You may wish to add an additional check, or rephrase this one, to consider approaches that are
not active. This requires an understanding of your organization to avoid including obsolete
processes that may result in an inaccurate picture while at the same time ensuring that we don’t
ignore useful process foundations where the only problem is that they are being ignored.
 Documented Processes Obtained – this ties back to the previous check and requires us to
obtain the process documents that exist for each of those processes. Some processes may have
no documentation at all, merely being executed on an ad hoc basis, while others will be well
documented with detailed process flows, descriptions and change control. Most scenarios will
represent something in between and you should expect inconsistencies between what is
available for each process.

By Andy Jordan, PMP
 Support Documents Obtained – this expands on the previous check to ensure that additional
documentation associated with the processes have been obtained. These are likely to vary even
more substantially from process to process and may include training documents, templates,
checklists, examples, etc.
 Risk Examples Obtained – building on the previous two checks, this item is designed to ensure
that we obtain examples of how processes are actually applied to real risks. This will help to
identify variances in process execution as well as providing a more accurate picture as to how
risk management is really happening. Care should be taken here to obtain a cross section of
examples, not just one or two, and certainly not only the examples that are volunteered by
existing process owners (which are unlikely to show any problems that may exist).
 Available Metrics Identified – the next few checks can be the most difficult. Where possible we
want to identify the success or otherwise of existing processes in as objective a way as possible.
This requires us to identify where such metrics exist so that the data can be sought out. This
may be in the form of historic risk data from a project database (we are generally more
concerned with summary data that shows benefits of management, trigger rates, accuracy of
contingency and management reserves, etc) or may be less formally captured in project plans.
In many cases there may not be reliable data available.
 Metrics Obtained – where reliable metrics are available we should ensure that summary data is
obtained so that the success or otherwise of existing risk management approaches can be
reviewed. There should be a low expectation around the amount of reliable data that can
actually be obtained.
 Leadership view – this is an area that is almost completely subjective, but it is important to help
you understand the environment into which you are going to be implementing your processes.
Because your project has already been approved by this point there is clearly some recognition
that opportunities for improvement exist, but this may not be a universally held view. You need
to understand which areas of the organization believe that problems exist, which areas believe
that existing processes are adequate, and where those views differ from the reality that you
have discovered through the analysis. You are not seeking here to re-educate leaders within the
organization, rather you are gaining a better understanding of upcoming implementation
challenges.
 Matrix Completed – as a check towards ensuring that the analysis has been completed you
need to ensure that the matrix that you have used is complete – at least some value (even if it is
only “not available”) in every cell.
 Matrix Understandable – with a matrix format there can be a tendency to minimize the content
provided to match the relatively small cell size for each area. You need to ensure that someone
who reviews the matrix without already having a detailed understanding of the issues can
interpret the matrix successfully. The use of abbreviations can be helpful, but in that situation a
glossary / acronym dictionary needs to be provided.

By Andy Jordan, PMP
Process Development Plan Template
This template provides a step by step guide to developing the processes around organizational risk
management, although with minimal adjustment it will be applicable to other organizational processes.
This template is designed to be completed throughout the process development effort and is laid out in
sequence to mirror the activities described in Chapter 21.
Step 1 – Process framework
The process framework is the highest level of process structure that will be developed. It is the
equivalent to the Risk Identification → Risk Analysis → Risk Management → Contingency and Impact
Assessment → Adjust and Refine framework that formed the basis of the processes outlined in Chapters
8 to 12.
Step # Step Name Step Definition
1
2
3
4
5
 Step Name – this will be the name of the highest level process area and should clearly establish
the work that is being undertaken. It should represent a logical segregation of the work to be
carried out as part of organizational risk management – risk identification, risk analysis, etc.
 Step Definition – While the steps should be simple and straightforward they should still contain
a brief definition. This will likely only reinforce the name for the majority of readers but it will
help to prevent any misunderstanding. The definition should only be brief – the later sections of
the template provide opportunity for greater detail.
Step 2 – Process structure framework
The process structure defines the style, templates, etc for the process. Chapter 21 provides details on
the variables to consider when deciding on the structure, and it is important to ensure that the structure
is defined and captured – that’s the only way to ensure that the processes will be developed
consistently and correctly. It is therefore vital to ensure that this section is always accurate and up to
date.
Process Item Location

By Andy Jordan, PMP
 Process Item– this will refer to the specific items that come together to define your framework.
Examples will be the process document template, checklist template, guidelines, etc. You
should avoid being too specific – the key is to provide a standard look and feel without reducing
the flexibility that your process development team has. There is no explanation or definition
column in this table because the names should be self-evident. If you have ten different types
of checklist that require explanation then you are too detailed!
 Location – This is simply the network location where the template / guideline / manual / etc can
be found so that it is readily accessible to all team members. The framework is of no use if it
cannot be accessed by the project team and this helps to ensure that it is easy to find all of the
information that is needed. If you are linking to a folder rather than a specific document (which
will make maintenance easier as you don’t have to update the link every time that an element
changes) then you need to ensure that there is only one document in that folder. I generally
create a sub-folder called ‘previous versions’ or similar and move all outdated versions into that
leaving only the current version in the main folder.
Step 3 – Process detail completion checklist
In Step 1 we defined the high level framework, and in Step 2 we established the way that the detailed
process elements and supporting documents would be developed. Here in Step 3 we confirm that the
work to bring those elements together has been undertaken successfully. This section of the template is
a checklist that needs to be completed for each of the entries from Step 1. Here I have included
additional columns to indicate completion of each of those steps but if your project has more steps then
you may decide to break the checklist out into separate lists for each process phase.
The majority of Chapter 21 is spent on explaining each of these items in more detail and you may wish
to adjust this checklist to better reflect the specific aspects of your particular implementation. You may
also need to generate supplemental checklists that are only applicable to one or two sections of the
process – that may be particularly true if you are enhancing an existing risk management approach.

By Andy Jordan, PMP
Completed for (from process framework above)
Item Step 1 Step 2 Step 3 Step 4 Step 5
Has all work been completed in accordance with process
structure framework?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
If No, have exceptions been approved? Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have all process tasks / elements for this step been
defined?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Do all elements have a specific owner (responsibility and
accountability)?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Has guidance been provided in identifying owners where
needed?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have all inputs been identified and defined? Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Has distinction been made between required inputs and
optional support inputs?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have all outputs been identified and defined? Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have all tools and templates been identified and defined Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have exception scenarios been identified? Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have exception processes been defined for those
scenarios?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Have supporting documents and processes been
defined?
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.
Choose an
item.

By Andy Jordan, PMP
 Work completed in accordance with process structure– the whole point of establishing a process structure for the initiative is to create
consistency across all process elements and between the risk management approach and other organizational and / or significant
processes that are undertaken. It is therefore important to try and ensure that all work is conducted in accordance with that structure
framework.
 Have exceptions been approved – the choice not to use the defined process structure framework should only be taken in the most
exceptional of circumstances and that decision must always be approved. You will determine the level at which that approval should
occur but I would strongly recommend that it be at the sponsor / governance level rather than the project manager – this is a significant
variance.
 Process elements defined – these next checks really reflect completion of the core of process development activities. Here we are
ensuring that every item has been defined – every box and connection in the process flow, every step in the process explanation, etc.
None of the subsequent checklist items can be completed until this one is complete because they all require activity to be undertaken for
each process element.
 Elements have owner – see Chapter 21 for more details on how the owner should be defined, but each process element should have
both responsibility (the person doing the work) and accountability (the person who ensures that the work gets done) clearly established
in terms of skills, experience, etc.
 Guidance provided on ownership – some elements may require more specific guidance for practitioners on how to establish a unique
owner for each task within the process. Again chapter 21 goes into more detail but this check is important to ensure that the process
development team provides enough guidance to make it simple and straightforward to identify the owner for each element.
 All inputs identified – process steps cannot succeed unless they are provided with the right ‘raw material’ to process. In parallel with the
development on processes the required inputs to each step must be identified, ensuring that everything that is required by the process is
available and that everything that is identified as an input is introduced at the right point in the process.
 Distinction between required and support inputs – Chapter 21 explains the distinction between mandatory inputs that are consumed or
transformed by the process and the optional support elements that are beneficial but have an element of discretion around their use. As
part of the process development work it needs to be made clear which category each type of input falls into, and this check should also
ensure that all inputs are legitimate for the process itself. It can be tempting to include optional support inputs that are only likely to be
available and / or helpful in a small minority of cases and in most scenarios those should not be listed as distinct inputs.

By Andy Jordan, PMP
 Outputs identified and defined – the outputs of the process provide practitioners with a ‘roadmap’ for successful execution – as the
outputs are generated so the confidence that the process is being executed correctly increases. It is therefore vital to ensure that process
development clearly identifies all of the outputs at the correct point in the process – if the process doesn’t include it then it simply won’t
be produced when the process is executed. Similarly, the output has to be defined well enough to ensure that it is clear the level of
complexity and detail that is required and the purpose of the output. The tools and templates (see below) can assist, but the process
definition of these outputs should provide the business focused context.
 Tools and templates identified and defined – it is only natural that when the process is executed practitioners will use the tools and
templates that support each process element as their main guide to successful completion. While education and leadership needs to
ensure that the process doesn’t simply become an exercise in form filling, it is important to ensure that the tools and templates that are
provided are comprehensive enough to ensure that the process is executed comprehensively without being too rigid and preventing
practitioners from applying their judgment.
 Exception scenarios identified – processes are designed to provide a standard approach to the majority of situations. It is impossible to
develop a process that will serve every single scenario, but if the process definition work doesn’t define the exception situations then
practitioners will, and that can rapidly result in everything becoming an exception. This is an area that may well need to be revisited
during the pilot phase, and potentially after a full rollout, but process development should aim to identify as many of the expected
exceptions as possible.
 Exception processes developed – there is no benefit in identifying the scenarios that do not fit the standard process unless exception
processes are also developed for those scenarios. To many practitioners the idea of an exception will also mean an area where there are
no processes in place. It is important that the defined process creates an alternate process path for each of those scenarios, minimizing
the variance and returning to standard processes as quickly as possible. The definition of exception processes will also need to include
inputs, outputs, tools and templates, etc.
 Supporting documents and processes – while not directly associated with the process itself, this element is one of the most critical to
success. This area should cover training materials, manuals, examples of completed templates, etc as well as ‘link’ processes that connect
organizational risk management with other processes within the organization. This should also cover the processes for delivering
training, ensuring that manuals are available and maintained, etc. The details can vary considerably for this section and it is worth
considering developing a specific list of items for each step in the process as well as for the overall approach.

By Andy Jordan, PMP
Step 4 – Process Finalization Checklist
The final step in process development is to ensure that all of the different elements of the overall
organizational risk management approach come together as a cohesive set of steps that achieve
expectations and are capable of integrating with other organizational processes. This section can only
be addressed once all of the work in Step 3 is complete and you may well want to combine the
completion of the checklist with the formal review of the processes by the whole team that is described
at the end of Chapter 21.
Item Completed?
Is progression through the process as smooth as possible? Choose an item.
Are inputs complete, relevant and introduced at the right time? Choose an item.
Are outputs complete, relevant and introduced at the right time? Choose an item.
Are all tools and templates complete and appropriate? Choose an item.
Are all owners accurate and appropriate? Choose an item.
Are exceptions accurate, complete, and clearly defined? Choose an item.
Are support materials consistent, complete and appropriate? Choose an item.
Does process integrate with existing organizational processes? Choose an item.
 Progression as smooth as possible – the different process elements that come together to form
the overall end to end process will have been developed by a number of different individuals,
and while the elements will have been consolidated under the different steps that you identified
at the start of this plan template there will inevitably some variation. In this check you are
focused on ensuring that there is a cohesive, consistent process from start to finish. You will
focus particularly on the ‘hand offs’ between the different steps, but you are also ensuring that
the process structure has been interpreted consistently so that practitioners have the same user
experience for every process element.
 Inputs – the inputs should be considered in combination with the next check (outputs) as the
two are inextricably linked. You are focused here on ensuring that:
o Every input that is required is included – if it’s not in the process then it won’t be used
during process execution.
o Every input that is included is relevant and adds value. Additionally you need to ensure
that you are correctly distinguishing between mandatory and support inputs and that
only rarely used information sources aren’t identified as part of standard process inputs.
o Inputs are introduced at the right point in the process. They should only be associated
with process elements where they are required and of course if the inputs are
generated by an earlier process element then you need to ensure that they are
identified as an output from that step – it wouldn’t be the first time that an input was
required before the process step that produced it or without any process element ever
producing the output.

By Andy Jordan, PMP
 Outputs – these must be considered alongside the inputs discussed above and the elements
that we are concerned with align with those elements:
o Every output that is required is included – if it’s not identified in the process
documentation then it won’t be produced during process execution.
o Every output that is produced is relevant and adds value. If the output is never used
further downstream in the process then it may not be required (it may still be needed to
assist with management or with other organizational processes).
o Outputs are produced at the right point in the process. This is effectively the mirror
image of the last sub point under inputs – outputs must be produced before they can
become inputs to downstream process elements.
 Tools and templates – this is an area where significant care is necessary. Tools and templates
are a common area of variance between different groups within your project team, even if there
are clear template standards identified in the process structure. The most frequent difference is
in varying levels of depth and expectations and this issue needs to be addressed to ensure that
all artifacts are consistent and appropriate. The tools and templates also have to align with the
process elements, inputs and outputs – if you have a template associated with a process
element but no output that uses that template then what exactly is the template for? You may
also have differences in terms that need addressing, which may also indicate that you haven’t
produced a (comprehensive) process glossary.
 Owners – the majority of the work on owners will have been undertaken by the groups
responsible for each step within the process. However, you need to look at the overall process
flow and look for illogical ownership flows. You may have situations where ownership switches
back and forth between a couple of different owners and that may indicate an opportunity to
revisit the owners to see if they can be rationalized to avoid the back and forth. This will be
particularly true for owners who are accountable – it is more acceptable to have additional
changes in responsibility to ensure that the best possible person is completing the work.
 Exceptions – this is an area that may need to be revisited during the pilot and deployment work,
and that should be expected. However, as the process is being finalized you need to ensure that
any exceptions that have been identified are legitimate, that the boundary conditions have been
set (the groups that it applies to, the scenarios that can trigger the exception, etc) and that the
exception process is clearly defined and designed to bring the approach make in line with the
standard as quickly as possible without compromising quality. This check should also confirm
that there are no areas of the process where exceptions have been missed.

By Andy Jordan, PMP
 Support materials – these will need to be finalized towards the end of the process work as they
are the items that will help people to understand all of the other areas of the process. As such
this check is largely concerned with ensuring consistency in versions, completeness of coverage
and suitability for purpose – do they help practitioners to understand the processes, their
purpose, how to execute them, etc.
 Integration with other processes – your project team will have been focused on the processes
that they have been developing and will have had a largely internal focus – ensuring that they
are building the best possible organizational risk management process. This final check ensures
that all of that work can be leveraged as effectively and efficiently as possible by ensuring that
all of the connections with other organizational processes are well defined and that the
transition is smooth. This will require consideration of the same issues around inputs, outputs
and process elements that we considered above for this process as well as ensuring that all of
the connections have been defined. Commonly process development teams do a good job of
identifying the processes that they rely on (upstream), but are less good at ensuring that the
processes that rely on risk management (downstream) are complete, comprehensive and
accurate.

By Andy Jordan, PMP
External Risk Checklist
When an organization undertakes a major initiative there is potential for many different factors to influence the project. This checklist identifies categories of
risk that exist external to the organization that may impact the ability of the organization to successfully deliver the project. During the business casing and
project review and selection work the sponsor and senior team members should review this checklist and confirm that they have considered the implications of
risks occurring within each of these categories. This document can then become a feeder to the more detailed risk management documentation that will be
developed if and when the project is approved.
This document should be used in conjunction with the internal risk checklist.
($000s)
Date
Last Reviewed By
Competitive The competitive environment in which the company
operates is an obvious area for external factors to
impact. An innovative feature from a competitor, an
aggressive pricing strategy or a new entrant into the
market all have the potential to affect the
organization’s risk environment. On the flip side a
competitor’s failed product or late delivery can have an
equally dramatic impact.
Economic The economic situation can have a profound impact on
an organization’s risk environment – the impact on
sales and revenue, the ability to maintain investment
and staffing levels, the speed with which they can
return to previous levels, etc.

By Andy Jordan, PMP
($000s)
Date
Last Reviewed By
Geographic An organization’s location(s) contribute to their risk
environment, with impacts varying from proximity to
resources, communication links and markets to the
number of competitors for resources. There can be an
assumption that these factors are fairly stable, but
that’s not the case at all – earthquakes, tsunamis,
hurricanes, etc fall into this category as well and the
potential for exposure contributes to the risk
environment.
Investor Financial risks are generally seen as internal to an
organization, and obviously the company needs to take
responsibility for its financial performance. However,
there is a closely connected, but distinct, external risk –
the concept of investor risk. This may be from one or
more major shareholders, from a major external private
company investor, or from a mass uprising from smaller
shareholders.
Political The political climate that an organization finds itself in
can have a tremendous impact, a change from a right
wing to a left wing government (or vice versa) can result
in changes to everything from taxation to workers’
rights and subsidies to export restrictions. Additionally,
in areas of political instability the impacts may be even
more dramatic.

By Andy Jordan, PMP
($000s)
Date
Last Reviewed By
Regulatory All industries are subjected to a degree of regulation,
but for many the regulatory demands can introduce
tremendous risk, especially if those demands change.
Import / export regulations, reporting requirements,
safety measures, etc can all change the risk
environment significantly. These aren’t restricted to
the private sector either; public sector organizations
can sometimes be just as heavily regulated with
restrictions that do not necessarily follow logic.
Regulatory risk directly connects to the internal risks
around compliance which is concerned with ensuring
that the regulatory requirements that exist now are
met.
Reputational How the company is perceived has a major effect on
the risk environment that it exists within. This category
can cover everything from perceived quality of products
and service to reputation as a corporate citizen. In the
current reality of instant and global communications
and the ability for any individual to have a voice
through blogs, Twitter and the like this is something
that can have even greater impact than in the past.
Some would argue that this is not an external risk as the
organization’s actions drive their reputation, but this is
only partially true – not everything that is said about an
organization is accurate!

By Andy Jordan, PMP
($000s)
Date
Last Reviewed By
Societal One of the most obvious examples of societal risks
today is the retiring baby boomers and the skills
shortage that will result for many organizations. Other
high profile elements of this category are the
expectations for a more varied and flexible working
environment for Generation Y workers, and the
increased expectations for flexible working hours and
environments. These are all macro level, but societal
risks can have significant impacts at the micro level too
– unique circumstances that impact one office,
community, etc.
Technological We have all seen the speed of technological
advancement in recent years and these changes can
drive significant risk into the organization. This
category covers a huge area from the rapid rate of
change in software versions that shortens the period
from launch to obsolescence to the evolution of new
platforms and capabilities on those platforms. This is
one environmental factor that is often
underappreciated as a risk category simply because the
majority of risks are seen as positive (opportunities).

By Andy Jordan, PMP
Guidelines
The risk category and description columns are based on my book Risk Management for Project Driven Organizations and are intended to help to identify
potential external sources of risk. An individual project may not have risks in every category, and the descriptions are not intended to be exhaustive, rather they
are prompts for discussion as to possible risks that your project may face.
By far the most important column in this template is risk exposure. This field is intended to be an estimate of the potential financial impact of the risks in each
category should they trigger. At this pre-approval stage they are only high level planning estimates, and the figure in each category is calculated by adding the
potential exposure (risk amount multiplied by % chance to trigger) for each of the risks identified in the risk references column. Effort impact is converted to
financial cost for the purposes of planning. Management costs are not considered here as response strategies have not been determined.
The risk references column is intended to identify the risk ID for any risks that you have identified within that category and may well include a hyperlink to the
risk document where more details are available. The last review date and last reviewed by fields are simply audit fields to ensure that the analysis is current and
complete.
Unlike the risks identified in the internal risk checklist, many of the risks here may require an ‘accept’ type management approach because there is little that can
be done to control many of the risks identified in this category. In some ways that makes it more important than ever to understand the risk exposure in this
category as that exposure will exist throughout the initiative.

Risk Analysis Checklist and Templates for Managers

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Risk Analysis Checklist and Templates for Managers

Similar to Risk Analysis Checklist and Templates for Managers (20)

More from Tahir Abbas

More from Tahir Abbas (9)

Recently uploaded

Recently uploaded (20)

Risk Analysis Checklist and Templates for Managers