1. ITPD ISSUE MANAGEMENT PROCESS SEPTEMBER 5, 2008
Risk Process
ITPD
ISSUE MANAGEMENT PROCESS
SEPTEMBER 5, 2008
March 10, 2015

2. Review of Project Control Processes
Agenda
Review of Project Control Processes
Risk Management

3. Opportunity & Risk Management
All projects contain uncertainty: you must manage uncertainty to maximize positive outcomes (“opportunities” or “positive risks”) and to minimize negative outcomes (“risks”)
“If ( Event) happens, then (Consequence).”
Opportunities & Risks: to be managed in the risk register/log.
Risks + opportunities will be monitored by Risk Level: a combination of the Probability that the risk occurs and the Impact of that occurrence.

4. Opportunity & Risk Management
Probability
Definitely: The risk/opportunity has either already occurred or you are pretty sure (+90%) that it will
Probably: The risk/opportunity will most likely occur – probability is 51% to 90%
Possibly: It is possible that the risk/opportunity will occur, but not likely. Probability is 10% to 50%
No-Way: It is almost certain that the risk/opportunity won’t happen. Probability is less than 0% to 10%.

5. Opportunity & Risk Management
Impact
1 = No Impact: There will be no impact on project budget, schedule, quality, benefits or resources
2 = Low:
Overall project budget will not be impacted (that is, overrun can be absorbed elsewhere)
Impact on schedule will be only of non-critical tasks
No noticeable degradation in quality
Benefits will not be impacted
No additional resources will be required
Overall chances of project success not significantly impacted
3 = Medium:
May impact overall project budget by up to 10%
Dates on critical tasks are impacted, but can be recovered by 'tweaking' the plan
Noticeable, but acceptable degradation in quality
Benefit numbers and timing are impacted, but change is acceptable
Chance of project success is reduced, but still at an acceptable level
4 = High:
Project budget impact of greater than 10%
Slippage of key dates - major re-planning exercise required
Unacceptable degradation in quality of work
Benefits are significantly impacted
Risk of failure on the project is unacceptably high
Extreme: Project will fail. Major re-work required.

6. Opportunity & Risk Management

7. Opportunity & Risk Management
Risk responses must be:
Appropriate to the severity, probability and impact of the risk
Cost effective in meeting the challenge
Timely to be successful
Realistic within the project context
Agreed upon by all parties involved
Owned by a responsible person.
Note: Unknown risks cannot be managed although project managers may address them by applying a general contingency based on experiences with similar projects.
Risk acceptable responses:
Avoidance – Change the project plan to eliminate the risk or condition to protect the project objectives from the risk impact.
Transference – Shift the consequence + ownership of a risk to a third party. Simply gives another party responsibility for the risk’s management; it does not eliminate the risk.
Mitigation – seeks to reduce the probability and/or impact of an adverse risk event to an acceptable threshold. Early action to reduce the probability of occurrence or impact is more effective than trying to repair the consequences after it has occurred.
Acceptance – indicates that the project team has decided not to change the project plan to deal with a risk or is unable to identify any other suitable response strategy. May include developing a contingency plan to execute, should a risk occur.

8. Opportunity & Risk Management
The project will use the following risk ratings to assess action required:

9. Risk Management - Process

10. Risk Management – Process Steps
Ref ID
Process Step
Description
Input/Output
Time Horizon
Owner 1
Identify the Risk
A risk is an element that may cause uncertain danger to the AIS project. When a risk is discovered, a team member must contact his/her lead with all the pertinent information regarding the risk
Input: Risk discovery
Output: Detailed information about the Risk
As necessary
Project Team 2
Log the Risk
The lead must meet with the Project Manager to approve the risk and log it into the Risk log
Input: Detailed information about the Risk
Output: Risk Management entry
Project Manager 3
Communicate detail to Assignee with Risk Number
If the Risk is to be assigned to a team other than the original team reporting the risk, Project Manager must communicate the Risk information to the Assigned Team Lead
Input: Risk logged
Output: Reassignment of Risk to different team 4
Qualify the Risk
The Project Manager must review the Risk and detail all the relevant problems that can occur from the Risk. They must identify all the teams impacted if the Risk were to occur, and all potential loss
Output: Updated Risk 5
Track As Task, Action Item, or Issue and Update Risk Mitigation
During Risk Qualification, the Project Manager may identify a Risk as being a Task, Issue, Opportunity/Gap in addition to or instead of being a Risk. If this occurs, a Task, Action Item, or Issue will be logged in Document Repository Tool, and the Risk Mitigation must contain the Task, Action Item, or Issue information.
Input: Updated Risk
Output: Task, Action Item, and/or Issue resulting from Risk 6
Manage the Risk
The “Assigned to Team” listed on the Risk will evaluate the Risk for a response. This will involve proactively working with impacted teams and reporting out appropriate tasks at least once per month. Risks will be reviewed periodically with the project management team.
Input: Updated Risk
Output: Possible escalation of Risk
At least once/ month depending on risk level.

11. Risk Management – Process Steps
Ref ID
Process Step
Description
Input/Output
Time Horizon
Owner 7
Risk Disposition
If the Risk does not require any more escalation, the Project Manager will evaluate the continuing disposition of the Risk. If they feel it is still a Risk that requires a Mitigation Plan, they will choose to Mitigate the Risk. If the Risk Mitigation requires additional monies be spent, they will choose to Track the Risk as a Change Request. If the Risk should be tracked as an Issue, they will choose to Track the Risk as an Issue.
Input: Updated Risk
Output: Decision on course of action (Create Mitigation Plan, Create Change Request, Create Issue)
As necessary
Project Manager 8
Propose Mitigation Plan
The Project Team will update the Risk in Document Repository Tool with a detailed plan to mitigate the risk. If the Project Manager does not approve of the mitigation, the Project Team must work with the Project Manager to create an acceptable mitigation plan
Input: Updated Risk
Output: Detailed Mitigation Plan
Immediately upon identification
Project Team 9
Update Risk and Log in appropriate other log.
If the Risk is actually an Issue, Task, or Gap, then the Project Team must log in appropriate log in SharePoint, update the Risk with the relevant information, and follow the Other Process.
Output: Logged Item and Updated Risk, Task, Issue, or Gap. 10
Execute Mitigation Action Items
Once the Mitigation Plan is accepted, the Project Team must carry out the Action Items listed in their detailed Mitigation Plan.
Input: Detailed Mitigation Plan
Output: Action taken as directed by Mitigation Plan for Risk 11
Alter Project Plan
If Project Management Team determines to avoid or transfer the risk, then they must follow change control to remove the problematic piece of scope from the project plan to accommodate.
Input: Change Control Process
Output: Updated Project Plan for removed scope 12
Update Risk Register to close risk
If the risk is really another item (task, issue, gap, etc) or if the risk has been rendered not a risk by avoiding the scope in the project plan or transferring to a third party, then close the risk in the risk register.
Input: Altered project plan or altered task list, issue list, or gap list.
Output: Updated Project Plan, SOW with third party.

12. Q&A
9/18/2018

13. For additional information on this process, please contact…
Contact Information
For additional information on this process, please contact…
Contact Name
Phone