The Soft Side of Risk must get much of Project Managers' attention in this day and age: The Technology-Intensive Universe

1. PROJECT RISKSQualitative & Quantitative Assessment PROJECT RISKS

2. Over 30 Years of Experience in Banking . . .
Mohammad Fheili currently serves in the capacity of an Executive
at JTB Bank in Lebanon.
 He has successfully delivered over 1,500 hours of training to
professional bankers.
 He served as an Economist at Association of Banks in Lebanon
(ABL), and as a Senior Manager at BankMed and Fransabank.
 He worked as an Advisor to the Union of Arab Banks.
 Mohammad also served as Basel II Project Implementation
Advisor to CAB and HBTF Banks in Jordan.
 Mohammad received his college education (undergraduate &
graduate) at Louisiana State University (LSU), and has been
teaching Economics and Finance for over 25 continuous years
at reputable universities in the USA (LSU) and Lebanon (LAU).
 Finally, Mohammad published over 25 articles, of those many
are in refereed Journals (e.g., Journal of Money Laundering &
Control; Journal of Operational Risk; Journal of Law &
Economics; etc.) and Industry Bulletins.”
mifheili@gmail.com
+(961) 3 337175

4. If You’re Convinced that we have been evolving in that fashion,
then the extreme majority of anticipated and undertaken projects
is about “AUTOMATION”, or IT in General.
Increasing Demands for Certain Skills. The
Absence of Such Technical Skills reflects
Negatively on the Success of the Majority of
Undertaken Projects, and introduces an
element of Risk in Planned Projects..

5. Data
Technology
RelationshipsProcess
Connected Eco‐System
Revenue Pressures
brought on by regulatory
compliance, Low interest
Rates, Increased Customer
Demands and new
competitive threats
require new Business
Models that are both
Strategic and Integrated in
Approach.
In a connected ecosystem,
human interactive virtual
environments allow FSIs
to foster collaboration in a
cross functional,
integrated approach to
regulatory readiness.
FSIs must enhance customer
engagement by creating
compelling multi‐channel
experiences and developing
innovative business models
that capitalize on the
emergence of a networked
society.
Financial Service
Institutions risk losing
ground on competition
unless they can restore
market and customer
trust, manage
regulatory changes
effectively, lower
expenses and introduce
new revenue streams.Organizational
Agility: Readiness
To Cope

6. SIMPLE! Bricks & Mortals
People
Come
First
Data
Come First

7. IMPORTANT NOTICE: We've moved!
Please update your favorites
In an effort to standardize our domain and website names, the
fujitsucanada.com domain has moved. Please use our new address at
https://sempai.fai.fujitsu.com.

8. Projects & Inherent Risks

9. My Version of a
“Brain Teaser”.
Let’s Think
Together about
the A,B,C of a
Project

10. “Nice Music” If The
Project Succeed.
“Noise” If The
Project Fails

11. • A New Organization (e.g., Real Estate Development, Software
Development, Whole Sale Training, Mass Recruitment, Etc.)
• An Extension To An Existing Organization: New Product, New
Production Plant, New Production Technique, New Software,
etc.
• Automation of An Existing Process
• Redesign of an Existing Process
• Design of a New Process
• Compliance
• Reporting
• Etc.
Possible Projects

12. Potential Problems
• Top management not recognizing this activity as a project
• Too many projects going on at one time
• Impossible schedule commitments
• No functional input into the planning phase
• No one person responsible for the total project
• Poor control of design changes
• Problems with team members.
• Poor control of customer changes
• Poor understanding of the project manager's job
• Wrong person assigned as project manager
• No integrated planning and control
• Organization's resources are overcommitted
• Unrealistic planning and scheduling
• No project cost accounting ability
• Conflicting project priorities
• Poorly organized project office

13. Knowledge Gap
• Who Knows what? Acknowledge the
“Knowledge GAP” between the Various
Stakeholders, and Team Members about
the Project.
• Collect, Validate, Analyze, and Share
Relevant Data and Information about the
Project to Close the GAP.
To Address These Problems, . . . .

14. Understand The Project Environment,
And Potential Sources of Risk
• A Sail From “Lebanon” To
“Cyprus” is a Project.
• Understanding The
Environment Begins Before
Sailing
• Identifying Risks Associated
With This Project Starts Before
Sailing
• Collecting Data about Weather
During the Trip Begins Before
Sailing.
• Planning Responses To These
Identified Risks Begin Before
Sailing.
• Etc.
R.I.S.K.
After All A boat in the harbor is safe. . . . But that’s not
what Boats were made for.

15. VS.

16. Flying From “Beirut” To “Paris” Is a Project. Descent Below Safe
Altitude is an Incident.
Minimum Safe Altitude (MSA)
IncidentAccident

17. Project RISKManagement
Highly Unrealistic to Expect Project Details to be
that straight forward, and progress that
smoothly… Too Good To Be True!
Realistically, Project
Management is more like Rock
Climbing:
 Possible But Difficult
 Requires attention to Details
to Secure Completion.
 There are Risks Associated
with it which need to be
identified at the start to
safe‐guard against them
(i.e., Gear up).
 Variations will be
encountered BUT okay as
long as they are within an
acceptable range.

18. Types of
Project Risk
Let’s Dive In…

19. Types Of Project Risk
• Executive Support Wavering, inconsistent or weak executive commitment is often a project's
biggest risk. This can be difficult (but not impossible) to document. Ask for specific
commitments. Where you are denied you can document it as a risk.
• Scope The quality of your estimates, dependencies and scope management. If an estimate is just
a guess, that's a risk. Be sensitive to the comfort level of estimates. If your team is unsure about
a particular estimate, you can document this as a risk.
• Change Management A continuous flow of complex change requests can escalate the complexity
of your project and throw it off course. Change requests may lead to a perception that a project
has failed because they continually add budget and time to the project. If requirements are
missing items that are expected to come later, that's a risk.
• Stakeholders with a negative attitude towards a project may intentionally throw up roadblocks
every step of the way. If you anticipate conflict or a lack of cooperation between stakeholders,
document it as a risk.
• Resources & Team Resource issues such as turnover and learning curves are common project
risks. There's always a risk that your key experts will leave. If your team are inexperienced or
need to acquire new skills, that's another risk.

20. • Design The feasibility and flexibility of architecture and design are key to your project's
success. Low quality design is a risk. You might want to highlight the design of complex or
experimental components as separate risks.
• Technical The risk that components of your technology stack will be low quality. There are dozens
of quality factors for technical components (e.g. stability, availability, scalability, usability, security,
extensibility). It's a good idea to identify specific risks in components. For example, the risk that a
component will have a security flaw.
• Integration Whatever you're delivering needs to integrate with the processes, systems,
Organization, Culture and Knowledge of the environment. Integration Risks are Common. If you
need to integrate your project into a business process there's a risk that the process will be
disrupted. This may represent a significant business impact.
• Communication Invalid stakeholder expectations is a fundamental project risk. If the stakeholders
think you're building an orange but you're building an apple — your project will fail. If stakeholders
become disengaged (e.g. ignore project communications), that's a risk.
• Requirements Garbage in, garbage out. If requirements aren't feasible or are detached from
business realities, your project may fail. Look at the feasibility, quality and completeness of
requirements to identify risks. Look at whether requirements are possible to integrate with
organizations, processes and systems.
Types Of Project Risk

21. • Decision Quality Slow, low quality or ambiguous decisions are common risks.
• Feasibility Risk identification is a critical time to consider the feasibility of the project. Ask the
key members of your team to do their own sanity checks. List any doubts about feasibility as
risks.
• Procurement The procurement process is ripe with risks. For example, there's a risk that you
won't find an acceptable proposal to an RFP. There's also a risk that your vendors won't deliver
to the terms of their contracts.
• Quality and risk management are intertwined. You'll expect to have defects in your project.
However, there's a risk that quality won't meet basic levels. Significant rework may trigger
project failure. Identify quality related risks for process inputs and outputs. Identify quality risks
for infrastructure, work packages, components and products.
• Authority Project teams often lack authority to complete project work. In many cases, teams
are expected to influence to achieve project objectives. This reflects business realities. For
example, your project may cross organizational boundaries. It's rare that a project team doesn't
depend upon influence. It's a useful exercise to think of risks in terms of a lack of authority. If
you need to influence to secure infrastructure. cooperation or inputs — there's always a chance
the answer will be no.
Types Of Project Risk

22. • Approvals & Red Tape If you anticipate that red tape (e.g. financial approvals) will slow
down your project — add this as a risk.
• Organizational change (e.g. restructuring, mergers, acquisitions) will throw your project off
track. Think about the minimum stability that your products require to launch. List
potential organizational changes as risks.
• External forces such as laws, regulations and markets. If your project touches compliance‐
sensitive processes regulatory change is a risk.
• Project Management If your organization asks you to Restructure your project management
methodology (drop processes and documentation) you can document this as a risk.
• Secondary Risks Secondary risks are often overlooked aspect of risk. Secondary risks are
the result of risk mitigation and transfers. Let's say you transfer a risk to a vendor with
a fixed price contract. The contract itself represents a counterparty risk. You've replaced a
series of project execution risks with a series of procurement risks.
• User Acceptance There's always a chance that users will reject your product. You can build
a product that matches requirements (on time and to budget). However, if users reject the
product the project will be considered a failure.
• Commercial If you're building a commercial product for market (new product
development), there's always a chance the product will be a commercial failure. This
should be documented as a project risk.
Types Of Project Risk

23. • Risk management affects all aspects of your project – your budget, your schedule,
your scope, the agreed level of quality, your communications and stakeholder
engagement, the success when the project’s output is implemented, and so on.
• Risks can be positive (i.e. opportunities), as well as negative (generally referred to
as risks).
• Risk management is about behaviors that prove that risk management is a top
priority for you and the team, such as “being constantly aware of what might
happen,” agreeing on strategies for all risks, and undertaking actions to prevent
negative risks from becoming issues (i.e. occurred events) whilst maximizing the
opportunities of positive risks.
• Risk management needs to be conducted from the start of the project, constantly
discussed and monitored, and involve all members of the project team.
• How you choose to handle risks depends on your most influential project
stakeholders’ 'appetite for risk'.
• Each identified risk needs to be assessed, a strategy for dealing with it agreed upon
by all appropriate parties, and tracked until closure.
• Project risk management is not “the project manager tracking risks in a Risks
Register and sharing it occasionally when or if people ask to see it” – it is much
more than that.
Project Risk Acknowledgment

24. Project Risk Management
Boils Down To This ….

25. PRIMARY SECONDARY
PEOPLE
Employee Fraud / Malice (Criminal)
PROCESSES
Payment / settlement / delivery risk
SYSTEMS
Technology investment risk
EXTERNAL
Legal / Regulatory Risk / Public Liability
Unauthorized activity / Employee misdeed (Willful)
Employment Law
Workforce disruption
Loss or lack of key personnel
Documentation or contract risk
Valuation / Pricing
Internal / External reporting and compliance
Project risk / Change management
Selling Risks
System development and implementation
Systems failures
Systems security breach
Systems capacity
Criminal Activities
Out‐sourcing / Supplier Risk
In‐sourcing Risks
Disaster and Infrastructural utilities Failures
Political and Government Risks
People are the Source of Many Risks
and the Solutions to the
Management of all Risks!
There are no right answers here
only “acceptable” ones, and what is
acceptable is very much driven by:
• People’s risk attitudes and
• The Organization’s culture.!
The Focus on IT System
Risks is Over-Rated
Sources Of Project Risk
Data Collection Does NOT Stop when
Project Starts

26. Organizations Have
Turned Desperate To
Search for and Identify
Risks (Intentional &
Unintentional) to
Immunize their
Projects from Deadly
Shocks . . .
Non‐Identifiable Risk
Non‐Identifiable Risk
An Organization’s Risk Population
Identified &
Identifiable
Risks
• Expected Losses
are Normally
Controlled or met
Using Gross
Income,
• While Unexpected
Losses Require
Capital.
Sources Of Project Risk
Data Collection Does NOT Stop when
Project Starts

27. Collect
them
all!
Data
Data
Data
Data
Data
Data
Data
Data
Data
A Data warehouse is a good
idea, but a warehouse only
works when Staff bother to
make deliveries into it –
and that’s where
Compliance Officers need
some sharp Inter‐Personal
skills, to convince others to
share their data. Without
the Right/Complete/Timely
Data, Compliance Decisions
are Ambiguous, Ignorant, or
Uncertain!
Any Piece of Information
May Have An Implication On
The Success Of The Project
Risk Management Must Be Data‐Rich
Data Collection Does NOT Stop when
Project Starts

28. Data Warehouse
Risk Management Must Be Data‐Rich
Data Collection Does NOT Stop when
Project Starts

29. Good Understanding over
Potential Outcomes.
Full Awareness on
Probability of Occurrence
Completely “Blank” over the
Nature & Scope of the
Outcomes.
Fully Aware of Probability of
Occurrence
Completely “Blank” over the
Nature & Scope of the
Outcomes.
Fully Unaware of Probability
of Occurrence
Good Understanding over
Potential Outcomes.
Fully Unaware of Probability
of Occurrence
RiskUncertainty
AmbiguityIgnorance
The Purpose behind Project
Risk Identification is to:
• Provide Evidence on
Probability of Occurrence
• Push Towards Increased
Understanding of Potential
Outcomes.
There is a BIG difference
between Ambiguity,
Ignorance, Uncertainty and
RISK.
Increasing Our Understanding of
Potential Outcomes
Increasing Evidence on Probability of
occurrence
Risk Management Must Be Data‐Rich
Data Collection Does NOT Stop when
Project Starts

30. Increasing Our Understanding of
Potential Outcomes
Increasing Evidence on Probability of
occurrence
RiskManagement Ambiguity
Uncertainty
Data‐Rich, Information‐Driven
Decision‐Making Process: Deciding
What Data to Collect is by itself a
Project
Ignorance
Companies are expected to
collect the needed data to
move closer to Risk
Management and Away from
Ambiguity, Ignorance, and
Uncertainty.
Risk Management Must Be Data‐Rich
Data Collection Does NOT Stop when
Project Starts

31. Low
High
LowHigh
Accept
Mitigate
Transfer
Avoid
Frequency of Occurrence of Mistakes in Serving the Client
Severity of Losses Resulting From These Mistakes
High‐Frequency / High‐
Impact Client Account (Or
Transaction) Behavior
Low‐Frequency / High‐
Impact Client Account
(Or Transaction)
Behavior
High‐Frequency / Low‐
Impact Client Account (Or
Transaction) Behavior
Low‐Frequency / Low‐
Impact Client Account
(Or Transaction)
Behavior
Operational Risk (Frequency/Impact)
Characterization of Money Laundering
ML‐Incidents Population of the Bank
It’s likely that any change in the
Organization will have some impact
on its Operational Risk Profile:
Processes Automation tends to
replace people with systems.
In terms of operational losses, the
result may be a transition from
High‐Frequency, Low‐Impact losses
TO Low‐Frequency, High‐Impact
losses. The event type will change
as well.
Risk‐Culture Awareness
maybe a superior solution
to Automation
Controls are turning Time
Consuming
Data Collection Does NOT Stop when
Project Starts
Risk Management Must Be Data‐Rich

32. Insufficient training
CAUSES EVENTS CONSEQUENCES
Lack of management
supervision
Inadequate
auditing procedures
Inadequate security
measures
Poor HR
policies
Poor systems
design
Inadequate
segregation of duties
External
Fraud
Employment Practices
& Workplace Safety
Clients, Products
& Business Practices
Damage to
Physical Assets
Business Disruption
& System Failures
Execution, Delivery &
Process Management
Internal
Fraud
Regulatory, Compliance
& Taxation Penalties
Restitution
Loss of Recourse
Reputation
Business Interruption
EFFECTS
Monetary
Losses
OTHER
IMPACTS
Forgone
Income
•
•
•
Write-down
Loss or Damage
to Assets
Legal Liability
You Manage This!
CAUSES
Relevant Data Means Better Handling
Prevention is Key

33. Loss Prevention Loss Loss Control
Relevant Data Means Better Handling
Prevention is Key

34. Risk
Of Control
and
Correction
Cost

35. I Like!

36. 1 2
34
Your Assignment (i.e,
Project) is:
• Pick One Animal to take
care of,
• for One day,
• Inside a 25m2 room;
and
• Alone?
You May Ask Any
Question To Help You
Prepare Adequately For
This Assignment.