Risk managementorrussianroulette -presentation_14 Collaborate 2017

Session ID:
Prepared by:
Risk Management or Russian
Roulette
10322
@JanetDahmen
Unloading the smoking gun by monitoring and
mitigating 5 lethal project risks
Janet Dahmen, Brake Parts Inc.

April 2-6, 2017 in Las Vegas, NV USA #C17LV
Presenter Background
Janet Dahmen
Project Manager,
2
 PMP Certified Project Manager, trained on Agile and ITIL Foundations
 25 years managing ERP implementations and custom business solutions
 Implementation experience w Oracle Financial, WMS, CRM, iStore and
Budgeting systems
 Multiple verticals in both Private and Public Sector
 Established PMO offices and Oracle governance support models

Russian Roulette & Risk
Management
Unloading the smoking gun by monitoring and
mitigating 5 lethal project risks

Agenda
• What Is Risk Roulette
• The 5 Deadly Project Risks
• Case Study Analysis
• Another 40 Project Risks to consider & monitor
• Risk Management Templates

Russian Roulette & Risk Management
• The Game of Chance
• A game of chance whose outcome is strongly
influenced by a randomized device
• Common devices used include dice, tops, cards,
roulette wheels
• Russian Roulette
• A game of chance in which a player places a single
round in a revolver, spins the cylinder and pulls the
trigger
• Risk Roulette
• A situation where the controlling of risks is left up
to chance
• Whereby the potential for realized risk is not
controlled

Defining Risk & Risk Management
• Risk:
• Any event or situation that has the potential to impact a
project either Negatively or Positively
• The possibility of something bad or unpleasant happening
• A person or thing that is judged to be a good or bad choice
• A chance that an investment will lose value
• Risk Management:
• The identification, assessment and prioritization of risks
• The process of monitoring for the occurrence of risk
• The process for controlling and mitigating realized risks

Danger Ahead!
5 Deadly Project Risks

The 5 Deadly Risks
1. Inadequate Project Resources
2. Incomplete / Inadequate Requirements
3. Resistance to Change
4. Strength of Project Management Team
5. Missing / Inactive Project Sponsor
8

Risk 1: Inadequate Project Resources
• Assessing Project Resources – Potential Risk Areas
• Appropriate Skill Sets
• Adequate Staffing Levels
• Effective Leadership within the groups
• Project Resource Groups
• Management Team
• Business Team
• Implementation Team
9

Risk 1: Management Group
• Has ability to make decisions
• Has Organizational Influence to Impact Change
• Has Strategic Vision to Steer Project
• Active and Visible Leadership
• Engaged in Team
• Project Sponsor
• Steering Committee
• Risk Escalation Path
• Extremely Political – proceed with caution!
10

Risk 1: Business Team
• Has knowledge of their Departmental Processes
• Has ability (or empowered) to make decisions
• Has ability to envision & lead change w/in Department
• Has ability to lead training within department
• Ability to actively participate throughout project
• 30-40% participation level needed
• Risk Escalation
• Project Sponsor
• Departmental / Middle Management
11

Risk 1: Implementation Team
• Extremely knowledgeable in software & industry
• Strong communication skills (written / verbal)
• Can map business processes and translate into software setup
• Can effectively design solution (standard / custom)
• Able to meet deadlines
• Coverage provided in all business process groups
• Solution Architect able to ensure quality of overall solution
• Risk Escalation Path
• Implementation Team Manager / Engagement Manager
• Project Sponsor
12

Case Study: Inadequate staffing of Business Team
The demands of Day-to-Day Operations vs Project Participation
 Unable to Schedule / Attend requirements meeting
 Unable to make strategic decisions on process design
 Unable to approve requirement documentation
 Unable to Review and Approve Initial Solutions
 Unable to Provide Training
 Unable to Accept final Solution
 Unable to Validate Conversion Data
 Unable to support go live
 Unable to perform day-to-day duties after go live
 Unable to maintain system
13

Risk 2: Inadequate Requirements
• In appropriate Level of Detail
☒Ability to support warehouse processes
Correct Level of Detail
☑Ability to identify picking waves by customer priority, by day
☑Ability to define product quantities for packing
☑Ability to maintain accurate product inventory levels
☑Ability to scan products for receipt, picking & inventory checks
14

Risk 2: Inadequate Requirements
Business Requirement / Description of Need:
Ambiguous Description: Ability to ship orders
Correct Description:
• Tier 1 Customers must have a completed order to shipping
• Tier 2 Customers allow partial shipment with backorders
• Tier 3 Customers allow partial shipment with no backorder
15

Case Study: Inadequate Requirements
You know what happens when you assume…..
• Management Assumed Standard Processes
• Business provided very high-level and incomplete
requirements
• Business Requirements Not Approved in Time
• Solution Design Progressed on Plan
• Reporting Needs Defined too late in design
• Design Decisions Revisited
• Project Delays and cost overruns
16

Risk 3: Resistance to Change
Transformation & Change is Inevitable with ERP’s
How Ready is your Organization for Change?
• Perceived need for change
• The greater the need the more acceptable change will be
• Impact of past changes on employees
• Exhaustion from the amount of prior change
• Numbness due to never ending change
• Shared Vision & Direction
• Common understanding of how organization will be after the change
• Understanding of: “What’s in it for me” (WIIFM)
• Clear and timely communication of what is happening
• Attitude towards Success/Failure
17

Risk 3: Resistance to Change
Resistance to Change is attributed to:
• When the reason for change is unclear
• The Fear of the Unknown
• Perceived Loss of Power / Responsibility
• Fear of Job loss
• Perceived value of change is negligible or negative
• When change threatens to modify work relationships
18

Risk 3: Resistance Introduces Risk
Behavior Root Cause Remediation
Lack of Participation • Fear of Project Association
• Not enabled to participate by
management
• Discuss with individual to
assess root cause
• If attributed to management,
escalate to sponsor
Inability to accept a new
process
Unwilling to sign off on
requirements & final
solution
• Fear of loss of power / responsibility
• Unable to envision how they will be
effective with the new solution
• Reinforce knowledge of final
state
• Escalate to management or
sponsor
Not willing to attend
training
• Fear of Project Association
• Fear of appearing dumb, uninformed,
or not in control in front of others
• Fear of losing job if not effective
• One on One assessment
• Individualized training
program
• Reinforce role in final state
Prevents employees from
participating
• Fear of loss of power
• Unable to envision their leadership
role in new solution
• Reinforce knowledge of final
state
• Escalate to sponsor
19

Case Study: Change Readiness
• Fear of Failure
• Project Sponsor was positioned for Political Appointment
• Wanted to hedge his position
• Did not defuse fear
• Created uncertainty within Steering Committee
• Put Project in Red Status without “cause”
• Refused to Endorse Project Readiness for Go-Live
• Risk Remediation
• Gathered Support w/ Departmental Managers
• Met with Steering Committee independent of Sponsor
• Provided Readiness Assessment Results
• Created a “Shared Responsibility” for decision
20

Risk 4: Lack of Project Sponsor
Sponsor Role:
• Authorizes Project Management Team w/ Responsibility
• Controls Project Budget
• Defines and Regulates the Scope
• Influences Organizational Decisions
• Relationships at Executive Level
• Empowers Management Team & their Priorities
• Can Resolve / Escalate Cross Departmental Roadblocks
• Has ability to remove resistance to business process change
• Holds the Project Team Accountable
21

Risk 4: Project Sponsor Risk Matrix
Risk Mitigation Options
Partially Engaged Sponsor • Seek additional support with other influential business
managers impacted by the project
• Expand Steering Committee membership & role
• Recommend Steering Committee to serve as proxy
Not Politically Aligned /
Not Empowered to Impact
Organizational Change
• Determine who within organization holds the most political
influence and develop relationships
• Foster relationships with impacted departmental managers
• Recommend sub-committees that include immediate
project team and impacted departmental managers
Does Not Control Project
Resources
• Extend invitation to Steering Committee to include project
resource owners (managers)
• Clearly articulate positive impacts from project to foster
support and gain buy-in across departments
Indecisive &/or not able to
make business process
decisions
• Escalate decisions to Steering Committee
• Delegate decisions to departmental managers
22

Case Study: The Powerless Sponsor
• Situation: Call To Change
• Business did not feel empowered to change tenured business
processes that would impact customer experience
• Project Sponsor was from Financial Organization
• Changes needed in Sales & Production Control Departments
• Solution Design on hold pending multiple key decisions
• Solution: Power Shift
• Steering Committee was expanded to include key decision makers
from Sales & Production Control Depts.
• Key Decision Matrix was presented at Steering Committee
• Organizational wide discussion included: Impact analysis, solution
options, process changes, agreement by all parties
23

Risk 5: Project Management Team Effectiveness
24
How Strong is your Leadership Team:
• Experience:
• Ability to see the impact of events & decisions
• Able to draw from experience on appropriate mitigation activities
• Knows how to layout the major steps and maximize team members
experience to expand the plan and include the details
• Able to perform root cause analysis on issues & risks
• Can perform critical path impact analysis on slippages
• Leadership:
• Able to Plan the work and work the plan throughout the project
• Leads by example, with authority and empathy
• Team accepts & respects leadership role

Risk 5: Project Manager Report Card
25
Task Description
Project Governance in place • Governance spelled out in Project Charter
• Processes in place to control scope, issues, risks,
approvals, budget, schedule
• Weekly meetings scheduled with project team
• Bi-Weekly/Monthly meetings scheduled with Sponsor &
Steering Committee
Planning the work
Working the Plan
• Project Schedule reflects all major tasks being worked
• Task dependency identified
• Task assignments and resource loading completed
• Balances priorities and time demands effectively
Leadership • Mutual team respect exists within / across sub teams
• Team follows the direction of PM
• Escalation within team boundaries is appropriate
• Respected by senior leadership team

In Review: The 5 Deadly Risks
1. Inadequate Project Resources
2. Incomplete / Inadequate Requirements
3. Resistance to Change
4. Missing / Inactive Project Sponsor
5. Strength of Project Management Team
26

Organizational Risks
• Project lacks an effective top-management sponsor.
• Project languishes too long in fuzzy front end.
• Layoffs and cutbacks reduce team’s capacity.
• Management or marketing insists on technical decisions that lengthen the schedule.
• Inefficient team structure reduces productivity.
• Management review/decision cycle is slower than expected.
• Budget cuts upset project plans.
• Management makes decisions that reduce the development team’s motivation.
• Non-technical third-party tasks take longer than expected (budget approval, equipment purchase
approval, legal reviews, security clearances, etc.).
• Requirement validation is too poor to support the desired development speed.
• Management places more emphasis on heroics than accurate status reporting, which undercuts its
ability to detect and correct problems.
28

Scheduling Risks
• Schedule, resources, and project definitions have been dictated by the customer or upper
management and are not in balance.
• Schedule is optimistic, "best case," rather than realistic, "expected case."
• Schedule omits necessary tasks.
• Schedule was based on the use of specific team members, but those team members were not
available.
• Effort is greater than estimated: functional requirements, integration points, modules.
• Project plans are abandoned under pressure, resulting in chaotic, inefficient work
• Target date is moved up with no corresponding adjustment to the product scope or available
resources.
• Task prerequisites (e.g., training, hosting contract, completion of other projects) cannot be
completed on time.
• A delay in one task causes cascading delays in dependent tasks.
29

Governance Process Risks
• Amount of paperwork results in slower progress than expected.
• Inaccurate progress tracking results in not knowing the project is behind
• Upstream quality-assurance activities are shortchanged, resulting in time-consuming
rework downstream.
• Inaccurate quality tracking results in not knowing about quality problems that affect the
schedule until late in the project.
• Too little formality (lack of adherence to software policies and standards) results in
miscommunications, quality problems, and rework).
• Too much formality (bureaucratic adherence to software policies and standards) results
in unnecessary, time-consuming overhead).
• Management-level progress reporting takes more team member time than expected.
• Half-hearted risk management fails to detect major project risks.
30

Personnel Risks
• Hiring takes longer than expected.
• Poor relationships between project organization slows down
decision-making and follow through.
• Lack of needed specialization increases defects and rework.
• Personnel need extra time to learn unfamiliar software,
hardware or programming languages, tools or environment.
• The personnel most qualified to work on the project are not
available or not assigned to the project.
• Key personnel are available only part time.
• People’s assignments do not match their strengths.
• Personnel work slower than expected.
31

Team Dynamics Risks
• Team members do not buy into the project
• Low motivation and morale reduce productivity
• Team members do not work together efficiently
• Team members leave before project is complete
• New development personnel are added late in the project and
additional training and communications overhead reduces existing
team members’ effectiveness.
• Conflicts among team members result in poor communication,
poor designs, interface errors and extra rework.
• Problem team members are not removed from the team,
damaging overall team motivation.
• Sabotage by technical personnel results in lost work or poor
quality and requires rework.
32

Risk Register – Part 1
34
Risk Attribute Attribute Description
ID Unique Identifier
Short Description Short (3-4 word description of risk)
Status Current Status: Monitoring, Realized, Mitigated,
Eliminated
Source Person or department responsible for logging risk
Category Budget, Scope, Timeline, Quality, Resource, Integration,
Training, Deployment, Support
Stage The stage of the project the risk was initially identified:
Initiation, Analysis, Design, Build, Test, Deploy, Support
Long Description Detailed description of the risk
Triggering Event What event will trigger this risk being realized
Risk Probability What is the probability of the risk occurring
Cost if Realized What will the cost to the project be if the risk is realized

Risk Register – Part 2
35
Risk Attribute Attribute Description
Monitoring Tools/Process What tools or processes will be used to monitor the realization of
the risk
Monitoring Owner Who is responsible for monitoring for this risk
Result of Realized Risk What will happen to the project if the risk is realized
Escalation Assessment Steering Committee Assessment of Risk and their assessment of
next steps which might be one of the following: Eliminate,
Mitigate, Accept, or Transfer to a third party
Mitigation Strategy & Probability What is the strategy to recover from the risk once it is realized
and what is the probability that the risk can be contained utilizing
the strategy
Mitigation Owner Who is responsible for enacting the strategy
Mitigation Effectiveness
Assessment
Who will analyze the effectiveness of the mitigation strategy
Mitigation Assessment Owner Who will determine if the mitigation strategy was effective
Mitigation Cost What is the cost of Mitigation
Risk Priority High, Medium, Low
Risk Impact Score Calculated score based on project impact, probability and cost
Fallback Plan What is the fall back plan if the risk and mitigation strategy are
not effective

Risk Log

Compressed Risk Register
37

Please Complete Your
Session Evaluation
Evaluate this session in your COLLABORATE app.
Pull up this session and tap "Session Evaluation"
to complete the survey.
Session ID: 10322

Risk managementorrussianroulette -presentation_14 Collaborate 2017

Risk managementorrussianroulette -presentation_14 Collaborate 2017

Recommended

Recommended

More Related Content

Similar to Risk managementorrussianroulette -presentation_14 Collaborate 2017

Similar to Risk managementorrussianroulette -presentation_14 Collaborate 2017 (20)

More from Project Control | PROJ CTRL

More from Project Control | PROJ CTRL (7)

Recently uploaded

Recently uploaded (20)

Risk managementorrussianroulette -presentation_14 Collaborate 2017