Tools For Risk
Management
Week 6
Lecturer: Barney Baldwin
Announcements
• Individual project due April 3
• Feedback has been provided in Canvas
• If you have questions, set up some time with me in the next week.
• Beacon students will meet early next week.
• Quiz 2 is next week
• Today we will
• Launch the group project
• Cover Change Capability
2
Group Project
(review GroupProject doc)
Group Project (25% of the final grade)
• See the “Group Project” and “AgileMethodology” documents
• Need to form groups of 4-6 students before next week.
• Notify associate and me with the group member names and UNIs
• One student in team must be third semester! This individual will
take the “product owner “role.
4
Recap: Organizational
Context
Recap: Organizational context
• We reviewed what organizational traits will lead to success (or
failure!) in implementing risk tools (and ERM process
improvements in general)
• Hire the best talent (including vendors)
• Define Clear Objectives
• Develop a culture of continuous change
• Invest in building and maintaining competitive differentiators
• Organize for success
• Segregation of duties
• Accountability and clear roles
• In short, reduce organizational risk (including HR, vendor, talent, etc.)
• And increase organizational delivery capability
6
Sidebar: Vendor risk for risk tools
• Discussion: Bringing in a new vendor for a risk tool
• Will this always increase vendor risk?
• If so, how to mitigate it?
7
Vendor Risk and Risk Tools
• Vendor risk, like any operational risk, can be quantified as
Impact * Probability of any incident
• Mitigants to reduce Impact
• Increased ”Mobility” of processes to another vendor, i.e. it is relatively easy to move
• Failback to a manual process or in-house systems for critical processes
• Mitigants to reduce probability
• Use established vendors
• Robust Vendor management (accountability, mature VM processes, etc.)
• Bringing in an additional vendor will usually (but not always)
increase vendor risk, and eliminating a vendor will probably
decrease it
8
Recap: Process Context
Risk Processes and Risk Tools
• T4RM process Taxonomy of ERM activities
• Identify, Measure, Aggregate, Present, Control
• Tools are mostly leveraged for Measure, Identify
Aggregate, Presentation
• These processes are supported by most tools
Control Measure
• Measurement includes using models to compute
risk
• Backtesting is used to validate models against historical
data
Present Aggregate
• Stress testing is used to assess risk in forward-looking,
hypothetical scenarios
10
System Decomposition – Issues with too many systems
• People – training, different skills needed to support different systems
• Process – divergent methods, high operational risk
• Technology – cost and complexity of redundant systems
• Data – manipulation is costly, prone to data errors
• Change – Complex environment with multiple system
Issues arise at system boundaries, high costs for overlapping systems
11
System Consolidation – Issues with too few systems
• People – vendor risk with dependency on single system
• Process – supported may not be sufficiently flexible (one size fits all)
• Technology – becomes out-of-date quickly, tech risk
• Data – may not support needed processes
• Change – may impact multiple business areas, testing is challenging
Monolithic systems age quickly as business and tech evolves, vendor risk is
very high
12
What is the Solution?
• In general, fewer systems is better and less complex
• Data and process consistency
• Cost – fewer vendors and staff to support multiple systems
• Adopt a small number of best-of-breed solutions.
• SIMPLIFY the business processes and the tools
• Shut down systems and processes that are not adding
sufficient business value
• Maintain high change capability, nimbleness
• KEEP THE DATA CONSISTENT across systems to the extent
possible.
13
Change Capability
Change Capability
• Change Capability represents the Cost and Time to implement changes
• High Capability – low cost/time to implement changes
• Low Capability – changes are costly
• Most overlooked, but in the long term the most critical, factor for business success
• Increased by:
• Process simplification and automation
• Standardization of technology
• Culture of continuous improvement
• Robust change management
• Decreased by:
• Introducing complexity, manual steps
• Ill-suited technology
• Ad-hoc changes in response to business issues
• Neglect, poor governance
15
Change Capability, ROI, and the Value/Cost curve
• Change Capability is the ability to
efficiently implement changes to business
processes
• Return on Investment (ROI) in the context
of a systems change is:
Increase
value / cost Change
Value
of the change, over a time period Capability
• Quantifying value can be challenging for
technology and risk projects Change 1
• Appropriate management of tools will Change 2
maximize Return on Investment – which
is the derivative of the value/cost curve
Cost
16
How to Improve Change Capability
• Measure complexity, and account for complexity in change projects
• Adopt standards for technology and clear processes for adoption of new
technology
• Establish robust change management practices
• Version control is absolutely essential!!!
• Automate all repetitive tasks for delivery
• Continuous Integration / Continuous Delivery (CI/CD)
• DevOps is the practice of automating development/change
• All steps between code change and production release are automated
• Simplify and standardize enterprise data
• Adopt Agile practices where possible
17
Agile and Waterfall
Methodologies
Traditional “Waterfall” Project Methodology
• “Waterfall” methodologies were developed to manage large projects
(months to years)
• Each step is completed before the next step begins
• Plan->Design->Build->Test->Release->Support
• Each step usually involves a
different team
• Handoff between teams requires
documentation
Source: Trust Radius [link]
19
What is Agile?
• In the ‘90s, technology projects were very
bureaucratic and heavyweight
• Agile was developed as an alternative
• 17 software developers met in the spring
of 2000 and early 2001
• Produced Agile Manifesto and Agile
Principles
• Less predictable, less documentation than
traditional methods
• Suitable for smaller projects, fewer teams involved
• “Learn as you go” approach
Source: Rachaelle Lynn, planview.com [link] 20
Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
21
Agile Principles
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter
timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
22
Agile Scrum
• Scrum is a type of Agile Methodology
• Used for organizing our team project
• Work is based on Sprints
• Planning – 1 day
• Execution – 1-3 weeks (depending on organization and project)
• Retrospective – ½ day
• Team has three roles
• Scrum Master
• Product Owner
• Developers
23
Discussion – Project Methodologies
• Consider a large project implementation involving
multiple teams and many months of work:
• What are the benefits of a strict waterfall (plan, design, code, test,
implement) approach?
• What are the potential drawbacks?
(Consider People, process, technology and data contexts)
24
Comparing Agile and Waterfall
• Most initiatives involve some elements of both Agile and Waterfall
• There are many variations of both Agile and Waterfall methodologies.
• Waterfall is appropriate for large
projects with many teams
and/or dependencies
• E.g. regulatory initiatives
• Agile is best for most data,
analytics, and risk projects
Source: Trust Radius [link]
25
Agile Methodology
for Group Project
(review AgileMethodology doc)
Next Week…
Next Module (Week 7)
• Quiz 2: Presentations and readings from weeks 4, 5, and 6
• Refer to Syllabus
• We will focus on the steps needed to implement an enterprise risk tool.
• Read:
• WZhan, X., Ling, Z., Xu, Z., Guo, L., & Zhuang, S. (2024). Driving efficiency and risk
management in finance through AI and RPA. Unique Endeavor in Business & Social
Scienceshen Low-Code/No-Code Development Works - and When It Doesn't.
28
