Template "Project Risk Analysis" - CI/PMO

Risk Analysis Project

Cover Sheet

Project Title: PPM Activity ID: Please enter ID here CI Project Manager: Barbara Milbourn (CI/PJM2)
SmartWAN UD Project Manager: Simon Bell (CI/OSR1.2-NA)
Quality Manager: Ryan Wilson (CI/QMM-NA)
Moderator: Please enter name here

Actions are tracked: In this document

https://rb-wam.bosch.com/tracker/secure/Dashboard.jspa

Participants of latest meeting/update of risk analysis:

Name Attendance Response
Simon Bell OSR1.2
Jim Sandgathe OSR1.2
Jan Holzmann OSN2
Klaus Kirdorf OSN2
Ralf Rothenhoefer OSN2
Jens Milbrandt OSX1

The required signatures for the risk analysis (PjM and PjQM) are covered with signatures of the respective QG.

Document History:
Version Date Description of Changes Author
1.0 04.06.19 First draft of risks Simon Bell CI/OSR1.2
1.1 07.16.19 completed rating and measures Simon Bell CI/OSR1.2
1.2 07.22.19 Additional risks added Simon Bell CI/OSR1.2

Risk assessment has to be updated regularly throughout the entire project cycle.
Recommended at least monthly for Category A & B projects, quarterly for Category C & D projects.
Risk Register PPM Activity ID: Please enter ID here

SmartWAN
Risk Register (All risk)

Nb Entry Date Risk category Risk/Opportunity Effects Root Cause Risk Assessment Actions Responsible Deadline Status Remarks / Notes
of initial risk as per definition Concrete, understandable description corresponds with assessed Impact [I] leading to or generating this risk P I RZ Initial Risk preventive and counter measures or Risk action owner Due date for of action
under 'How To' RZ response actions to enhance likelihood Risk Action
strategy
CR = Customer Functions not working as expected due to design. Scalability not Solution does not fit, restart of investigation, customer impact if Ensure all functions are tested in a Jim Sandgathe (CI/OSR1.2-
1 04.06.19 New technology 3 4 12 12 Avoid Continuous Open
Satisfaction reached moved to production PoC NA)
1) Agree in advance on resource
Delay on study, not all processes followed, requirements not Augustin Solis-Winkler /
2 04.06.19 RR = Resource Bosch project resources unavailable Parallel projects, economic situation 2 4 8 8 Mitigate agreement Continuous In progress 16.07.19 - resource agreements being sent
properly accounted for Barbara Milbourn
2) Backfill resources from teams
Explain to spend and control board
importance of project. Highlight to
3 04.06.19 BtR = Budget Necessary Budget for project not available Resources not given to successfully complete study Economic situation 4 5 20 20 Mitigate Simon Bell / Martin Koehn 8/15/2019 In progress
upper management benefits/risks to
project
1) Resources spent signing new contract Pursue contract extension, create
Agustin Solis-Winkler /
4 04.06.19 BtR = Budget Current WAN contracts in the regions cannot be extended 2) Contract would be signed for service we want to migrate away Economic / outside vendor 3 4 12 12 Avoid timeline of current contract deadlines. Continuous Open
Barbara Milbourn
from Close monitoring of schedule,
Make sure selected vendor provides
1) Bound to one vendor for solution/problems SD-WAN technology is not an open required support, test functionality in Simon Bell / Augustin Solis-
5 04.06.19 BR = Business SD-WAN is not an open standard, multivendor strategy doesn't fit 5 3 13 13 Accept 6/1/2020 Open
2) Price negotiation / competition standard PoC, Steering committee Winkler
discussion/agreement
Sign support extension with vendor
(VAP)
End of Sale for Network Optimization Solution may lead to performance Network performance affected, devices running without support, Sign memorandum of understanding 16.07.19 - VAP contract pending signature, MoU
6 04.06.19 QR = Quality EoS 3 4 12 12 Avoid Simon Bell 9/1/2019 In progress
problems if SD-WAN solution is not yet available incorrect device sizing agreement with vendor (MoU) being developed, project approval in progress
Gain agreement and resources to
properly execute project
O365 design 3 may be delayed if Smart-WAN infrastructure is not Monitor timelines, synchronize with Agustin Solis-Winkler /
7 04.06.19 BR = Business delay to O365 rollout, poor performance for customer Project delay 3 3 9 9 Mitigate Continuous Open
aligned with O365 roadmap O365 timeline, escalate on deviations Barbara Milbourn
Opportunity: Increase network productivity by leveraging Internet Jim Sandgathe (CI/OSR1.2-
8 04.06.19 BR = Business Improved user experience, increased network resilience technology change 3 3 9 9 Pursue Continuous Open
circuits NA)
Opportunity: Lower operating costs by leveraging low-cost internet Jim Sandgathe (CI/OSR1.2-
9 04.06.19 BR = Business Cost savings, shorter time to deliver circuits technology change 3 3 9 9 Pursue Continuous Open
circuits NA)
delay on study, costs not known, decision delay managed vs. Process takes longer than planned, Close monitoring of RFP team and
10 04.06.19 ScR = Schedule RFP process consumes more time than planned 3 4 12 12 Mitigate OSL1 / Agustin / Barb Continuous Open
own operated complexity purchasing, create detailed checklist
Requirements tracking, engage with
Solution does not fit, restart of investigation, customer impact if Capacity, not all customers known,
11 04.06.19 QR = Quality Not all customer requirements realized in decision process 4 3 12 12 Mitigate customer facing teams, review in OS in coordination with AC 12/1/2019 Open
moved to production not all requirements known
steering committee
Consulting with IDS/ISI, solution Jim Sandgathe (CI/OSR1.2-
12 04.06.19 SrR = Security Security requirements cannot be fulfilled solution does not fit, restart of investigation security requirements 2 4 8 8 Mitigate 3/1/2020 Open
testing NA)
High number of projects on hold or
NOS replacement late, leading to unsupported components. Obtain approval of budget from the 16.07.19 To be presented to the SBC on 30.07.
13 15.07.19 BtR = Budget Low priority of SmartWAN or cancelation of the study canceled as a result of the current 4 5 20 20 Mitigate Simon Bell / Martin Koehn 8/15/2019 In progress
O365 introduction delayed SBC Justification presentation created.
economic situation
proper documentation of requirements
Not all requirements gathered and tested, solution does not fulfill Agustin Solis-Winkler /
14 15.07.19 RR = Resource Bosch internal resources not enough or not given (non project) capacity due to multiple projects 3 3 9 9 Mitigate gathering, escalation towards steering Continuous Open
needs Barbara Milbourn
committee
follow security best practices, validate Jim Sandgathe (CI/OSR1.2-
15 15.07.19 SrR = Security Unknown security vulnerability data loss, service interruption, network compromise technology vulnerability 2 5 10 10 Mitigate Continuous Open
solution with IDS/ISI, develop DR plan NA)
Complete change in operational processes, interfaces, Agustin Solis-Winkler /
16 17.07.19 RR = Resource Outages in WAN/longer troubleshooting times technology change 3 5 15 15 Transfer Risk to be transferred to rollout 8/1/2020 Open
troubleshooting etc. Barbara Milbourn
Agustin Solis-Winkler /
17 17.07.19 BR = Business Organization cannot adjust to the new working model Impact on effective operations, customer satisfaction technology change 3 2 6 6 Transfer Risk to be transferred to rollout 8/1/2020 Open
Barbara Milbourn
Contractual agreements, purchasing
longer times to resolution, capacity spent troubleshooting, service vendor support is not sufficient or Jim Sandgathe (CI/OSR1.2-
18 17.17.19 QR = Quality Software / hardware quality issues 3 5 15 15 Avoid validation, valid requirements in vendor Continuous Open
chaining issues, software validation takes a long time inadequate NA)
selection
Incompatible network overlay technologies at different network
PR = Further areas resulting in segmentation issues Agustin Solis-Winkler /
19 17.17.19 Future vendor strategy unknown resulting in wrong fit for Bosch technologies cannot be foreseen 3 4 12 12 Transfer Risk to be transferred to rollout 8/1/2020 Open
product risks Future vendor changes regarding licensing, support etc. Barbara Milbourn
Influence on vendor for future requirements, support etc.
Devices are undersized for location resulting in poor
CPOC testing insufficient, Data not Ensure all functions are tested in a Jim Sandgathe (CI/OSR1.2-
20 22.17.19 QR = Quality Sizing concept is inaccurate performance, devices are oversized for location resulting in 2 4 8 8 Avoid 12/1/2019 Open
valid for all site classes PoC NA)
paying too much for hardware

CI/PMO; V5.2, with IT PEP V9.0 printed on 7/24/2019 C:\Users\MBI1MTP\Desktop\Risk_Assesment_EN_v5.2.xlsm 2/5

Project Risk Management Dashboard
SmartWAN

Risk Diagram Risk Status Distribution Risk-Action Due-Date Distribution

17
8
5 1 2 2

4 4 5
Impact

3 2 1

2 1
4 2
1 1
0 0 0
1 2 3 4 5
Probability Open In progress Completed Low risk > 60 days > 30 days in 30 days Overdue

Risk Response Strategy Distribution Risk Category Distribution Risk-Mitigation Effectiveness

Further Product Risk 1
Pursue 2 1
Security Risk 2

Accept 1 Safety Risk 0

Legal Risk 0
Transfer 3 Scope Risk 0
Schedule Risk 1
Avoid 5
Resource Risk 3

Mitigate 10 Quality Risk 5

0 0
Customer Satisfaction 1
Reduced Increased No change
Budget Risk 3

CI/PMO; V5.2, with IT PEP V9.0 printed on 7/24/2019 C:\Users\MBI1MTP\Desktop\Risk_Assesment_EN_v5.2.xlsm 3/5

Information on how to use this template
Scope of risk analysis Risks are generally categorized in two categories: Product Risk and Project Risk.

Cycle, participants and versions The risk analysis has to be updated regularly throughout the entire project lifecycle.
Mandatory participants are PjM (CI and UD),Product-Owner (in agile projects)and PjQM. In case of a study, PjQM is an optional participant.
It is best practise to define standards for Impact [I] and Probability [P] in each project.
Procedure In updating the risk analysis, existing risks will be reassessed and new risks will be identified and documented.
The initial Risk-Assessment [RZ] after documenting a Risk for the first
time can be manually maintained under "Initial RZ".
Existing values of Probability [P] & Impact [I] can be overwritten with new rating values based on reassessment of the risk.
In the event that a new risk is added or any rating (Probability [P] or Impact ([]) is changed, a new version of the risk assessment template must be created. The latest version of the
risk assessment must be used for the respective QG.
Versioning of the risk assessment template can be done with the versioning function of SharePoint or manually by renaming the version of the risk assessment template and storing
them in the project folder. It is a good practice to regularly baseline the risk assessment worksheet for tracebility purposes!
Definition of actions For every risk a risk action has to be defined in the risk register. For each action a risk action owner must be named and a deadline has to be defined. It is common to have multiple
action items for a single risk. In this case, each risk action must have a risk action owner and deadline clearly defined.
If possible, a risk trigger should be defined as a indicator of the imminent occurance of an identified risk.
New action(s) have to be defined if existing risk actions are insufficient to fully eliminate the impact of the risk.
Risk actions must be as close to the resolution of the risk impact as possible, temporary workaround solutions are not considered final risk containment actions! Fallback plans
should be defined for critical risk.
No action has to be defined for risk-response 'Action', but a comment describing why the risk has been accepted is necessary under column 'Remarks'.
It is possible to 'Accept' risks under a certain threshold (e.g. 5) without defining actions if this is accepted by the Project Sponsors. These risks have to be marked with status 'Low
Risk'.
Tracking of risks and actions If actions are tracked in a separate tool (e.g. Track & Release) a link to the respective tracking tool has to be maintained on the 'Summary'-Tab.
For action measuement tracking in this template, an appropriate Risk Status of: 'Open', 'In Progress', 'Completed', 'Low Risk' must be maintained.
Effectiveness of risk actions has to be reviewed regularly throughout the project lifecycle. New actions must be defined if existing risk actions are insufficient to fully eliminate the
impact of the risk.
With the successful implementation of risk actions, the risk Probability [P] rating can be reduced accordingly.
The risk Impact [I] rating howevercannot be reduced unless evidence exists that the root cause of the risk has been migitated and hence impact of the risk is lower than originally
identified (or the financial impact is reduced through an insurance).

Documentation To ensure the traceability of the risk analysis (requirement of C/AU),

- Basic data and the documents change-history (on 'Summary'-tab) and
- the column "Entry date of risk"
have to be maintained.
Information on makros To ensure the consistency of the template it is absolutely necessary thatnew lines are inserted exclusively using the button 'New line'.

Additional Information on risk It is a good practise to also considerpositive risk during the risk identification process. Positive risks are opportunities to the project that can be exploited.
categories
Risk Response Strategy 'Pursue' should be used to identify opportunities (positive risk). Positive risk should still be categorized (BR, CR, SR, ...) and asessed for their probability and
impact.

Risk category
Risks that have an impact on the customers business processes.
1 BR = Business
Example: Potential divestiture in 5 years time. An example for an opportunity would be to open up a new market that was not initially targeted with the project.
Risks that have an impact on project budget or project costing.
2 BtR = Budget
Example: Insufficient budget. As an opportunity it would mean to deliver the project at a reduced budget.
Risks that have an impact on customer-satisfaction towards project.
3 CR = Customer Satisfaction
Example: High stakeholder expectation on deliverables. A possibility to increase the user-experience would be an example for an opportunity.
Risks that have an impact on the quality of the projects deliverables.
4 QR = Quality
Example: High error rate, critical test failure, or an improvement to decrease these factors (as opportunity).
Risks that have an impact on resource-fulfillment.
5 RR = Resource
Example: Unstaffed demand for critical roles, high dependencies of single critical role, the possibility to collaborate on a work-package with another project to reduce workload.
Risks that have an impact on the project schedule.
6 ScR = Schedule
Example: High critical path, complex dependencies between work packages, an opportunity to use a co-working space for the project-team to expedite delivery of work-packages.

Risks that have an impact on the scope of deliverables.

7 SR = Scope
Example: Potential scope creep, insufficiently defined scope, unexpected changes, or an additional use-case that can be implemented without increasing budget/schedule/resources.

Risks that have impact on legal aspects.

8 LR = Legality
Example: Antitrust exposure, complex legislative requirement of local authority
Risks that might impact the well-being of others.
9 SfR = Safety
Example: If an App used for safeguards in a physical product loses its connection to the device, safeguards might not work and the operator might come to harm.
Risks that have impact on IT- and data-security.
10 SrR = Security
Example: Complex SAP authorization matrix, PSO/DSO audit, ISP audit unclose items.

11 PR = Further product risks Only for product risk assessment.

Risk assessment:
Probability of occurrence [P] 5 = very high
4 = high
3 = medium
2 = low
1 = unlikely
Impact / Significance of effects [I] 5 = very severe
4 = severe
3 = medium
2 = low
1 = none
Risk - Risk figure [RZ] The risk figure supports the prioritization of risks and is the result of the product of Probability and Impact:
Risk = Probibility [P] * Impact [I]

Risk response strategy

1 Mitigate Mitigate the risk exposure to minimum by defining contingency action plan, fallback plan
2 Avoid Avoid the risk exposure by amending project schedule plan, project scope
3 Transfer Transfer the risk exposure to a third party (eg: outsource, insurance)
4 Accept Accept the risk as it is (eg: customer accept the risk with no action necessary require to be define)

CI/QMM; V4.2, with IT PEP V7.0;

© Robert Bosch GmbH 2010. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights. 4
5 Pursue Enhance the likelihood of an opportunity to be achieved by exploiting, enhancing or sharing its root-cause.

CI/QMM; V4.2, with IT PEP V7.0;

© Robert Bosch GmbH 2010. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights. 5
Document History
Template "Project Risk Analysis"

Version Release Date [Author] Description of Changes Author

4.3 with IT PEP V8.01 PMO taking over of the template from CI/QMM Reichel (CI/PMO-CS1)
Threshold 12 is not pre-defined anymore
more detailled information about the use of this template du to findings in audits
4.3 with IT PEP V8.01 Reichel (CI/PMO-CS1)
List for risk category
seperation of the worksheet template history and information about the usage of the templage
- Addition of 'basic data' in first sheet, E9
4.3 with IT PEP V9 - Dependency threshold - Definition of measure removed, 1st sheet, E7 Lang D. (CI/PMO)
- spelling mistakes amended
4.3 with IT PEP V9 Info template usage, row 5: Participants added Lang D. (CI/PMO)
4.3 with IT PEP V9 Threshold removed Lang D. (CI/PMO)
4.4 with IT PEP V9 TICOS removed Fixed-Term Tartler J. (CI/PMO)
1. Inclusion of graphical dashboard (Risk diagram, risk response, risk status, risk category, risk due date)
2. Inclusion of risk response strategy
3. Inclusion of low-risk type and watchlist tab
4.5 11/5/2014 4. Rename of wording 'W' & 'T' to 'P' & 'I' Ho (CI/PMO-CS1)
5. Addition of risk category description
6. Additon of filter buttons for Risk Register & Watchlist display
7. Removal of sorting buttons
4.6 2/10/2015 Revision of macros to adopt template to Office 2013 use Ho (CI/PMO-CS1)
5.0 2/3/2017 Update of participants attendance Ho (CI/PMO-CS1)
5.1 6/7/2017 Added remark for review-frequency and risk response "Pursue". Boenke (CI/PMO)
Bosch Corporate Design applied and print layout customised.
5.2a 8/21/2018 Schaible Holger (CI/ITE)
Macros "Display Active Risk" and "Display Watchlist" repaired
Updated Info-Texts (How to use):
- Clarified Scope to also include Product-Risk
- Added Product-Owner as mandatory participant in Risk-Review for agile projects (as per IT PEP v9.5)
5.2 10/1/2018 Boenke (CI/PMO)
- Additional minor changes to further clarify existing texts.
Safety Risk has been added as an additional Risk-Category.
A column to document the initial Risk-Assessment and a diagram to view effectiveness of mitigation-actions has been added.
5.2.1 10/5/2018 Fixed missing formula for first 11 risk-entries. Boenke (CI/PMO)
5.2.2 10/31/2018 Fixed issue with formatting of column "Initial Risk". Boenke (CI/PMO)

CI/QMM; V4.2, with IT PEP V7.0;

© Robert Bosch GmbH 2010. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights. 5