Risk Management Plan
| Document | Risk Management Plan Draft |
| Author: | Sampsa Tervo |
| Version: | 0.1 |
| Date: | 14.2.2023 |
List the risks, assess their severity and probability, and try to consider measures on how the most serious / probable risks could be prevented in advance. In addition, it would be good to have a plan of how to act if the risk materializes. Attach the following section here:
| RISK ID | Description | Severity | Probability | Responsible | Action in case the risk escalates |
|---|---|---|---|---|---|
| RISK001 | Electric grid goes down | S2 | P5 | Person it happens to | Wait for the electric grid to resume |
| RISK002 | Testing not adequate | S2 | P4 | Sampsa Tervo | Take the system offline and fix any faults in it |
| RISK003 | User interface breaks | S1 | P4 | Justus Hänninen | Take the system offline and fix the UI |
| RISK004 | Backend errors | S1 | P4 | Justus Hänninen | Take the system offline and make sure that the errors stop occurring |
| RISK005 | Injections to system from front-end | S1 | P4 | Reima Parviainen | See what the injections are about and prevent them from happening again |
| RISK006 | Customer gets defunded | S1 | P5 | - | End the project |
| RISK007 | Trolls fill up database | S2 | P4 | Justus Hänninen | Clear the database of any unwanted data |
| RISK008 | Internet connections go down | S2 | P4 | Everyone | No action, continue work locally if possible |
| RISK009 | Bad quality of code | S1 | P5 | Developers | Take the system offline and fix any faulty code |
| RISK010 | Inaccurate time estimations | S2 | P3 | Iina Pirinen | Re-evaluate the timing of things and continue work |
| RISK011 | Sabotage | S2 | P5 | Reima Parviainen | Fix any damage done to the system and make sure it can't happen again |
| RISK012 | Product owner goes on sick leave | S4 | P3 | Everyone | Continue work on things that were agreed on |
| RISK013 | JAMK servers go down | S3 | P4 | Everyone | Continue work locally |
| RISK014 | Project team members leave | S3 | P4 | Everyone | Make sure that everyone is up to date on what anyone is doing so that someone else can take on their responsibilities |
| RISK015 | Norovirus attacks the team | S4 | P5 | Everyone | Inform anyone that needs to know and get well soon! |
| RISK016 | CSC gets breached | S3 | P4 | Aarne Salmi | Make sure that nothing gets stolen |
| RISK017 | Developer's hard drive breaks | S4 | P5 | Person it happens to | Inform everyone about the work that was lost |
| RISK018 | Competing teams steal source code | S5 | P5 | Everyone | Tell them that it's not cool to do that |
| RISK019 | End user email leaks | S3 | P5 | Justus Hänninen | Inform them about it |
| RISK020 | System gets DDoS'd | S4 | P5 | Aarne Salmi | Wait for the system to resume working correctly |
| RISK021 | Miscommunication within the team | S5 | P4 | Everyone | Update every team member with the correct information |
| RISK022 | Requirements don't meet the users needs | S2 | P5 | Everyone | Get back to work on the project and make sure to get it right the next time |
Severity descriptions
The severity class should be defined according the project
| Severity class | Description |
|---|---|
| S1 | Force Major, Total show stopper |
| S2 | |
| S3 | Medium effect, have to take action |
| S4 | |
| S5 | No immediate affect, to be observed |
| Probability class | Description |
|---|---|
| P1 | Almost inevitable |
| P2 | |
| P3 | Could very well happen |
| P4 | |
| P5 | Almost impossible |