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