Risk Management PlanVersion 3.1

Team Browser

Mamadou S Diallo

Tamara Jennings

Alexander Posipanko

Matt Sauchelli

Jordy Then

David Vera

Perrillen Zuniga

CSC 354

Dr. Tan

Risk Management Plan October 19, 2018

2

Risk Management Plan October 19, 2018

Table of ContentsTable of Contents…………………………………………………………………………………………………………………………………… i

REVISION HISTORY…………………………………………………………………………………………………………………………………. ii

1.0 INTRODUCTION………………………………………………………………………………………………………………………………… 1

1.1 Purpose of Document………………………………………………………………………………………………………………… 1

1.2 High Level Product Overview…………………………………………………………………………………………………….. 1

1.3 Explanatory Material: Acronyms & References……………………………………………………….…………………. 1

2.0 RISK MANAGEMENT PROCEDURE…………………………………………………………………………………………………….. 2

2.1 Process………………………………………………………………………………………………………………………………………. 2

2.2 Risk Identification………………………………………………………………………………………………………………………. 2

2.3 Risk Analysis………………………………………………………………………………………………………………………………. 2

2.3.1 Qualitative Risk Analysis…………………………………………………………………………………………………… 2

2.3.2 Quantitative Risk Analysis…………………………………………………………………………………………………. 3

2.4 Risk Response Planning………………………………………………………………………………………………………………. 3

2.5 Risk Monitoring, Controlling, and Reporting………………………………………………………………………………. 4

2.6 Summary of Risks………………………………………………………………………………………………………………………. 4

2.6.1 Technical………………..………………………………………………………………………………………………………... 4

2.6.2 Personnel……………..………………………………………………………………………………………………………..… 4

2.6.3 Schedule………………………………………….……………………………………………………………………………….. 4

2.6.4 Cost……………………………….…………………………………………………………………………………………………. 5

2.6.5 Supportability………………………………………………………………….……………………………………………….. 5

2.6.6 Breakdown of Specification…………………………………………….……………………………………………….. 5

2.7 Impact of Risks on Schedule Deliveries………………………………………………………………………………………. 5

3.0 RISK LOG…………………………………………………………………………………………………………………………………………. 6

4.0 RISK MANAGEMENT PLAN APPROVAL…………………………………………………………………………………………….. 10

i

Risk Management Plan October 19, 2018

REVISION HISTORYThe up-to-date revision history is listed in Table 1. As changes to this document are made, the table will be edited to reflect them.

Version Date Description Editor

1.0 9/19/18 Wrote Section 3.0, Section 2.0 Matt Sauchelli

1.1 9/23/18 Edited Section 2.0, Section 3.0 Matt Sauchelli

2.0 9/29/18 Edited Risk Log (3.0)

Updated Table of Contents

Perrillen Zuniga

2.1 9/30/18 Edited Introduction (1.0) David Vera

Wrote Risk Management Plan Approval (4.0) Mamadou Diallo

2.2 10/1/2018 Edited Risk Management Procedure (2.0) Tamara Jennings

2.3 10/2/208 Edited Risk Management Procedure

(2.0)

Alexander Posipanko

2.4 10/3/2018 Edited Risk #6, 8, 13, 16 (3.0) Jordy Then

2.5 10/4/2018 Edited Risk Management Plan Approval (4.0)

Wrote Cost (2.6.3)

Mamadou Diallo

Edited Introduction (1.0) David Vera

Edited Risk #1, 4, 10 (3.0)

Wrote Supportability (2.6.5)

Perrillen Zuniga

Wrote Schedule Risks (2.6.3) Jordy Then

Edited Technical Risks (2.6.1)

Added Assignee Column to Risk Log (3.0)

Tamara Jennings

2.6 10/5/2018 Added Breakdown of Specification (2.6.6) Tamara Jennings

3.0 10/18/18 Edited Process (2.1)

Edited Risk Identification (2.2)

Edited Impact of Risks on Schedule Deliveries

Alexander Posipanko

ii

Risk Management Plan October 19, 2018

(2.7)

Edited Summary of Risks (2.6)

Edited Personnel (2.6.2)

Edited Risk Management Plan Approval (4.0)

Added Risk #15 (3.0)

Mamadou Diallo

Updated the table for Risk Log (3.0)

Edited Risk Analysis (2.3)

Edited Risk Response Planning (2.4)

Edited Risk Log (3.0)

Edited Personnel Risk (2.6.2)

Edited Schedule Risks (2.6.3)

Edited Impact of Risks on Schedule Deliveries (2.7)

Jordy Then

Edited Risk Analysis (2.3)

Edited Qualitative Risk Analysis (2.3.1)

Edited Risk Response Planning (2.4)

Edited Risk Log (3.0)

Perrillen Zuniga

Edited Quantitative Risk Analysis (2.3.2) David Vera

3.1 10/19/18 Revised Risk Analysis (2.3)

Edited Risk Log (3.0) risk #13

David Vera

Edited Revision History

Edited Page Numbers

Tamara Jennings

Table 1: Revision History

iii

Risk Management Plan October 19, 2018

1.0 INTRODUCTIONA risk is the possibility that something bad or unpleasant may occur and have a negative effect on the project’s objectives. Risk management is the process of identifying, assessing, and controlling threats. These threats could stem from a wide variety of sources such as information security, data related risks or even financial uncertainty.

1.1 Purpose of DocumentThe purpose of the Risk Management Plan is to foresee and prepare for potential risks whilst providing a process to mitigate and prevent them. This document will outline risks that relate to the LTC-TMS project.

1.2 High Level Product OverviewThe purpose of this project is to create a functional long-term care management system that incorporates information from external sensors to measure step count, heart rate, and room temperature. The LTC-TMS will be available to patients and their families to view their information and tasks. It will also be available to CNAs, allowing them to add and make changes to a patient’s record. The system will also be used by the management personnel of the facility to keep track of staff information and facility schedules. Additionally, hardware will be installed in rooms as well as worn by patients to collect sensory information. This information will be transmitted wirelessly to a database, so facility staff can view it in the task management system on both a desktop browser and a mobile application.

1.3 Explanatory Material: Acronyms & ReferencesThe acronyms and terms listed in Table 2 are used throughout this document.

Acronym Full Name

Client A long-term care facility that uses the system

CNA Certified Nurse Assistant

CNO Chief Nursing Officer

Facility Long-term care facility using the system

KU Kutztown University of Pennsylvania

LTC-TMS Long Term Care-Task Management System

MCU Ming Chuan University of Taiwan

Patient A person receiving treatment at a long-term care facility

iv

Risk Management Plan October 19, 2018

Table 2: Acronyms & References

v

Risk Management Plan October 19, 2018

2.0 RISK MANAGEMENT PROCEDUREThe risk management procedure outlines strategies for the identification, analysis, and mitigation of risks associated with the development of the project. Additionally, a number of risk types are identified in this section.

2.1 ProcessThe project manager will work with the risk manager, who is in charge with overseeing the possible risks in the project, to ensure risks are actively identified, analyzed, monitored, and mitigated throughout the course of the project. The steps to do so are outlined in the following sections.

2.2 Risk IdentificationRisk identification is the process of finding risks that could adversely affect the completion of the project. All members of the project team will be responsible for identifying and reporting risks as they are encountered. Once the risks are identified, they will be added to the Risk Log in section 3.0. Each week, a portion of the team meeting will be devoted to reviewing risks as the project progresses.

2.3 Risk Analysis All identified risks will be prioritized based on their probability of occurring and the impact it would have on the project. There are two ways to analyze the risks- qualitative risk analysis and the quantitative risk analysis. Qualitative risk analysis will give an approximation of the probability of a risk occurring, while quantitative risk analysis will use a numerical-based scale of probability.

The purpose of each analysis is to help categorized each risk then give the probability of each risk to help scale what the team needs to focus on when they begins to design and build their project. Each risk will also impact different requirements of the project. Each requirement will be categorized to help the team visualize the impact the risks have on the project. For example, if a risk impacts a primary requirement, handling that risk will be a priority to the team.

There will be three types of requirements: primary, secondary and tertiary. Primary requirements are the basic functionalities and resources need to get the project working, such as a login screen for the browser part of the project. Secondary requirements are the functionalities that not required for the project to work, but they will help keep the project working efficiently. Tertiary requirement are the little details such as cosmetics of the program that can be easily removed or changed if the team or client does not want them included in the project anymore.

2.3.1 Qualitative Risk Analysis The probability and potential impact of each risk identified in Risk Log in section 3.0 will be evaluated and classified according to the following categories.

Severity

● Critical (C): This refers to a risk that could lead to project failure (inability to deliver the project as described).

● Serious (S): This refers to a risk that could have a major impact on project cost and delivery timeline. Secondary requirements may not be completed in time.

vi

Risk Management Plan October 19, 2018

● Moderate (Mo): This refers to a risk that could have a moderate effect on the project cost/schedule. Secondary requirements would still be achieved.

● Minor (Mi): This refers to a risk that could have only a small impact on the project cost/schedule. Project requirements, both primary and secondary, would still be met.

● Negligible (N): This refers to a risk that would have no impact on the overall success of the project. All requirements would still be met, with little to no impact on the schedule and budget.

Probability● Very High: Greater than 85% probability of occurrence● High: Greater than 70% probability of occurrence● Medium: Greater than or equal to 45% probability of occurrence● Low: Less than 45% probability of occurrence

Impact

● High: A risk that has the potential to have a significant impact on project schedule, cost, or requirements

● Medium: A risk that has the potential to have a moderate impact on project schedule, cost, or requirements

● Low: A risk that has a small potential of impacting project schedule, cost, or requirements

2.3.2 Quantitative Risk AnalysisAnalysis of risks that have been ranked according to the qualitative risk analysis process and their potential impact on project tasks will be estimated. The main goal is to reduce the amount of money or time wasted due to a risk. Even though the project is not made for monetary gain, there is still money being used to purchase the hardware and it would be best to limit those monetary risks. Time consumption is another focus in analyzing quantitative risks. Decisions will be made to determine whether the inclusion of a feature may or may not take up more time than originally planned. That is why a numerical rating system will be applied to each risk based on the analysis. Each risk will be assigned a number between one and ten, with one being the lowest priority and ten being the highest of priority and should be handled as soon as possible.

2.4 Risk Response PlanningEach risk will be analyzed by the project team, which will identify methods for reducing the impact or probability of occurring. Then, each risk will be assigned to a member of the project team for monitoring. This process will ensure that the risk will not be neglected over the course of the project. For each major risk, the following process will be used to address it:

● Avoid: eliminate the portion of the project that would be affected by the risk● Mitigate: designing a plan for reducing the probability or potential impact of the risk. This will

take time to design and implement, causing a delay in completing the project● Accept: choosing to accept the risk and the impact that may result from it. This will result in

working around the risk instead of trying to eliminate it from the project.

vii

Risk Management Plan October 19, 2018

● Transfer: outsource the responsibility for handling the risk either in the form of insurance, or by contracting an outside firm. This will increase the budget and the time needed to finish the project since the risk is being monitored by a party other than the project team.

2.5 Risk Monitoring, Controlling, and ReportingEach risk will be assigned to an individual team member. It is the responsibility of the team member to monitor the risk and take appropriate action as necessary and report it to his/her team lead, the project manager, and the risk manager. The status of each risk will be evaluated every two weeks throughout the course of the project.

2.6 Summary of RisksEach of the subsequent sections details a category of major risk and an initial plan for mitigation. Each risk is categorized as either technical, personnel, or schedule risks. Technical risks involve risks associated with the underlying technology that is to be used by the system. Personnel risks are related to risk involving important members of the project team. Schedule risks are risks regarding timing and how that affects development. Cost risks relate to the impact that the cost resources could have on the project. Supportability risks involve risks regarding maintenance of the project. Risks related to breakdown of specification deal with a lack of clear requirements.

2.6.1 TechnicalThe potential technical risks identified by the team can be reduced by having different methods of handling each of the components - database, app, and website. In order to achieve maximum functionality and peak performance while staying on schedule and in budget, compromises may be necessary. This could mean that some technical features may be sacrificed for the good of the whole project.

2.6.2 PersonnelPersonnel risks are a moderate component of the project due to the varying experience levels with different systems being used for the project among the team members. Each team member has a different level of experience, so additional research and learning may be necessary to be able to work on the project. The most significant personnel risk is communication with the MCU team; the difference in time zones limits the amount of time that the MCU team is able to be contacted. It is also more difficult to solely communicate online, so misunderstandings may be more common or go unchecked for a longer time. To handle this, weekly meetings are organized between the KU and MCU teams. Personnel risk also deals with issues of team member being absent from involvement of the project such as team meetings and group discussions with MCU. To lessen the impact of this risk, more than one person is assigned to major portions of the project and notes are taken at all meetings.

2.6.3 ScheduleSchedule risks are risks regarding time issues. Since this project is going to be developed over the span of two semesters, there are many national and international holidays that MCU and KU will observe. MCU has national holidays such as Mid-Autumn Festival, National Day, Chinese New Year, Tomb Sweeping Day, and Labor Day. KU honors American national holidays such as Martin Luther King Jr. Day, Presidents' Day, Memorial Day, Labor Day, Columbus Day, Veterans Day, and Thanksgiving. This is a risk

viii

Risk Management Plan October 19, 2018

due to the fact that development will most likely be halted during these days of celebration or remembrance. Schedule risks also include the break between semesters. Regarding this project specifically, the winter break will cause a decrease in productivity and development to this project. With an anticipated completion date in May of 2019, the KU team will need to thoroughly plan and design the project in the Fall semester so that implementation and testing can be completed in the Spring semester.

2.6.4 Cost Without a real client, the team has no choice but to apply for grant to pay for the required resources. If the project team is unable to obtain a grant, the project cannot proceed.

2.6.5 SupportabilitySupportability risks are risks that can lead to the system not being able to run by itself after deployment. This could be due to software issues, such as a compilation failure, or personnel issues, such as the client not having someone to fix issues as they arise. At this time, it is unknown whether KU and MCU students will be responsible to making updates and fixes to the system when it is released to the client or if the client will hire a support specialist.

2.6.6 Breakdown of SpecificationAs development begins, requirements may change due to unforeseen circumstances. Additional time must be spent clarifying specifications to ensure that the project can move forward. When there is a breakdown of specification, the project may be on hold or regress, threatening schedule and budget constraints.

2.7 Impact of Risks on Schedule DeliveriesThe development of the system is split into two phases. Phase one is the planning phase, taking place between August 2018 and December 2018. The second phase is the development phase, which will occur between January 2019 and May 2019. The system is expected to be ready for delivery at the end of the second phase. The risk category that is most likely to affect project delivery is the technical risk category. There are multiple technical components that have to work together in order to ensure the full functionality of the system that is described in the Software Project Plan. As more technical risks arise, the team will have to work diligently to ensure that there is little to no impact on the final delivery date.

ix

Risk Management Plan October 19, 2018

3.0 RISK LOG

This Risk Log contained in Table 3 will be maintained by Risk Manager and will be reviewed during each team meeting. Each risk detailed in this table is assigned an identification number, organized by type, and assessed based on the severity, impact, and probability.

ID Description Type Severity Impact Probability Mitigation Assignee

01 Software incompatibility (for example: program languages and database are not meshing together following an update, or a decision to change programming language or change database)

Technical Critical Medium Medium Mitigation: Do research beforehand during planning phase and actually try out the relevant software/technology before using it in the actual project

Perie Zuniga

02 The lack of communication between teams due to various of reasons such as, misunderstanding or misconstruction, could occur.

Personnel High High Low Mitigate: Team leads give weekly updates on their team’s progress.

Tamara Jennings

03 The scope of the work is poorly specified that results in the addition of more features

Technical Medium High Medium Accept: Allow for user feedback for insurance that it is what the client wants and envisions

Perie Zuniga

04 The project team currently has no

Technical Critical High Medium Mitigate: Designate team members to

Mamadou

x

Risk Management Plan October 19, 2018

real client to test the hardware/ application.

find an alternate set of end users to test the system.

Diallo

ID Description Type Severity Impact Probability Mitigation Assignee

05 A team member could be unable to work due to being sick or unavailable due to personal problems such as doctor appointments, car accidents, etc.

Personnel Moderate Medium Medium Mitigation: Have an extra person who knows what needs to be done at the current stage of the project to cover on the behalf of the unavailable team member

Jordy Then

06 The User Interface between multi- platform applications can be inconsistent, with one platform having different features than the other when both should have similar features and usability.

Technical Minor Medium Medium Mitigation: The app and browser teams must collaborate with each other to ensure a consistent interface experience on all platforms.

David Vera

07 Increase of Software Bugs with future feature implementation

Technical Moderate or Severe

Medium/High

Medium /High

Mitigation: Instilling a protocol for testing and approval of new features and an option to receive feedback from the end-user.

Mitigation: Having a list of verified

Jordy Then

xi

Risk Management Plan October 19, 2018

devices (i.e. testing the app functionality on specific devices like an iPhone 7 and Samsung Galaxy Tablet and verifying that there are no major issues) before deploying updates.

ID Description Type Severity Impact Probability Mitigation Assignee

08 Firebase has a change of management, where Google does not support Firebase anymore

Technical Critical Critical Low Transfer: Develop and test a plan to migrate the data from Firebase and into another NoSQL database. See if it is even viable to do so.

Perie Zuniga

09 Total hardware failure (when the hardware stop working).

Technical Critical Critical Low Mitigation: Find a good hardware in case a component suddenly stop working.

Mamadou Diallo

10 If the user hardware is being overused, can lead to the potential of the hardware being destroyed.

Technical Critical Critical Medium Mitigation: Design the components to withstand more than daily use to prevent hardware from suffering user inflicted damage.

Alex Posipanko

11 The lack of funding for the hardware

Financial Critical Critical Medium Transfer: Look for a secondary funding source for the

Jordy Then

xii

Risk Management Plan October 19, 2018

system such as sponsorships or grants.

12 Inconsistency when building a multiplatform app can be the result of separate teams working on separate application development

Technical High High Medium Mitigation: Constantly compare set-based codes and share visualizations between the separate development teams to detect the inconsistency amongst platforms.

David Vera

ID Description Type Severity Impact Probability Mitigation Assignee

13 Web Hosting Sites experiences an outage or the company that is hosting the site becomes out of service

Technical Critical High Low Transfer: Have a secondary web hosting site to back up our website

Tamara Jennings

14 Project testing halted due to being put on a waitlist to get the permission to test on real clients on public facilities.

Technical Critical High Medium Mitigation: Have team members inquire facilities for authorization to perform testing, within the early stages of implementation to avoid waiting later on.

Jordy Then

15 Bad weather could Schedule Minor Medium Medium Mitigation: Doing a Mamadou

xiii

Risk Management Plan October 19, 2018

prevent team meetings.

virtual meeting by using the Google Hangouts for video conference and the google drive for documents exchange.

Diallo

Table 3: Risk Log

xiv

Risk Management Plan October 19, 2018

4.0 RISK MANAGEMENT PLAN APPROVALA Risk Log will be maintained by the project manager and will be reviewed as a standing agenda item for project team meetings.

Any Changes to the project “Long Term Care Task Manager System” must be coordinated with and approved by the undersigned or their designated representatives.

Full Name & Title Date Signature

Justin Frye, Project Manager & KU Hardware/Database/ Project Management Team Lead

Peter Shively, KU Application Team Lead

Tamara Jennings, KU Browser Team Lead

Ting-Feng Lin, MCU Application Team Co-Leader

Felix Kong, MCU Browser Team Co-Leader

Freya Chen, MCU Hardware/Database/Project Management Team Co-Leader

Lucas Strickland, Database Administrator

Matt Sauchelli, Risk Manager

xv

Risk Management Plan October 19, 2018

Client

xvi