Risk Assessment and Mitigation¶
Highlighted changes:
- Each risk now has a responsible risk owner
- Improved description as to how we came up with the risks and improved formatting
- More details are in the updates report
Introduction¶
Risk management is an important part of any project, we must prepare for what could happen during the course of the project in order to be able to quickly recover and stay on track. The risks which are shown below take into account the scale of the project and aim to cover only risks which are realistic within this context.
To determine risks we brainstormed various scenarios - such as a teammate being ill for more than a few weeks. From these scenarios, we collected possible risks, and worked out the likelihood of them occurring. To determine the risk we discussed how it would impact the project, focussing on how many knock-on effects the issue would cause.
The risks are presented in a tabular format, with the following columns:
- Risk ID - this allows for traceability across the project
- Description - describes what the risk is for
- Likelihood - each risk has an estimated likelihood on a scale
- High =good chance this risk will occur, about 75% chance
- Medium =equal chance of risk occurring or not, about 50% chance
- Low =not likely to occur, about 25% chance, however some risks may be lower
- Impact - this describes the impact the risk would have to progress in the project
- Severity - shows the severity of the impact on the project on a scale
- High =a major setback which could affect the whole project
- Medium =could add up to a week of extra work and may threaten a deadline
- Low =may mean a few extra hours of work, but nothing major
- Mitigation - describes how how we will aim to avoid such a risk and deal with it
- Owner - describes the owner of the problem, where the owner is the person most likely to be responsible for the issue.
The overall table is split into sections which group together similar risk such as software risks. Each section is then ordered by severity, highest first. Equal severity is ordered by likelihood.
This table will be regularly consulted in an attempt to monitor the risks and try to ensure they do not occur and catch them early if they are occurring.
Due to the size of the team we feel that these risks are appropriate and accurate.
Table of risks¶
Software risks¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 1 | Our game may be slow or unresponsi ve. | Medium | No one will want to play the game. | High | Improve efficiency of the game wherever possible and regularly check performance | Coding Team |
| 2 | Software library doesn’t work or lacks a feature e.g. has a bug that stops the game from working, or is missing a feature required for the game to work. | Medium | We would struggle to implement the feature we want to add. We would also use up lots of time trying to solve the issue. | Medium | Test the elements of the library you plan to use beforehand . Also, make sure the library has an active community surrounding it and that bugs are fixed quickly. If it was early stages we could get a new library but this would require us to rewrite our code to work with the new library. | Software Library Owner |
| 3 | Code is hard to understand and seems too complex. | Low | Could cause bugs and makes bug fixing harder. Slows down the productivi ty of the group. | Medium | Use meaningful variable names and plenty of comments, both in code and in commit messages. Make sure code is reviewed by the majority of members before it gets merged into the repository . | Coding Team |
| 4 | Conflicts in git. Different members changing the same code. | High | May need to move code around and even rewrite. | Low | Make sure people work on separate elements by assigning them to different tasks and if not then make use of Gits tools. | Coding Team |
| 5 | Our own software doesn’t work as intended. | High | Will need to bug fix. Loss of time and potentiall y productivi ty if that function or feature is the bottleneck of the game. | Low | This is a normal part of software developmen t. We all make mistakes. However, before code is approved by the group we will use unit testing that will test key functions of the game as we develop them meaning that should a function break we will know about it before it’s merged. | Coding Team/Desig n Team/Proje ct Manager |
Hardware risks¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 6 | Personal computer breaks long term or is lost. | Low | Could lose work and be unable to work. | Low | Ensure work is saved online to google drive
service and that code is stored on github. Department PC’s should be accessible most days and have all the tools we need. |
Final User |
| 7 | Personal computer crashes while working. | Medium | Potentiall y will have lose work, meaning you lose time doing it again. | Low | Save regularly, google docs[2] will do this for us. Regularly commit code to personal branches so that it stored elsewhere other than your PC . | Final User |
Risks with people¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 8 | A team member leaves the module or even the course. | Low | They may have only access to their work, also the rest of the team will have more to do. | High | As above store online but also try to keep each other motivated to avoid this. | Project Team |
| 9 | A team member is ill/away for a week or two. | High | They might have been skilled in a certain area that no other member can do well.If they have the only access to work may get behind from it. | Medium | Hard to avoid, but we should store work online where everyone can access. If we work in pairs to complete tasks then there will be less of a chance of having one person who knows the most about one area. |
Project Team |
| 10 | Arguments within the team. | Medium | Disrupts the work of the team and prevents us moving forwards. Also, unpleasant for the team as a whole. | Medium | Try to avoid conflict but if necessary have proper debates perhaps using a mediator, do not keep issues hidden. | Project Manager |
| 11 | Lack of communicat ion. | Medium | Tasks may be done twice or not done at all. | Medium | Keep strong communicat ion using the tools we plan to use. | Project Manager |
| 12 | A team member does not do their work. | Medium | Could disrupt other members work and could make the other team members annoyed. | Low | Don’t give members too much work or work they cannot do, ensure that the team communicat es well and regularly meets up to discuss how the work is going. | Project Team/Manag er |
Risks with tools¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 13 | Google drive servers stop working. | Low | Could lose/lose access to work that is stored there. | Medium | Store work locally , and on other services. | |
| 14 | Central git repository [1] is lost in some way. | Low | Temporaril y lose access to it. | Low | Keep up to date local copies so can be easily restored. We could host our own local copy should github go down. | Git/Coding Team |
| 15 | Website hosting fails. | Low | Users lose access to the website. | Medium | The website files are stored on github and every team member has a local copy of the repository on their computer so we could bring the site back up on a different server. The site is also protected by cloud-flar e[3] who will provide a cached version of the site if our host were to go down. | Website Hosting Owner |
Requirements risks¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 16 | Not including a requiremen t which is required by the customer. | Low | We let the customer down and have failed them. | High | Make sure key requiremen ts are elicited from the customer so they get what they want. | Requiremen ts Team |
| 17 | A requiremen t could change/ be added. | High | May need to rewrite code or add extra code to account for it. Extra time will be needed. | Medium | Our software architectu re must be flexible and able to be changed easily. | Requiremen ts Team |
| 18 | Stating a requiremen t that we cannot actually achieve. | High | Let down the customer and also waste time. | Medium | Be sensible when deciding requiremen ts, be sure you can achieve them. | Requiremen ts Team/Codin g Team |
| 19 | Ambiguity in requireme nts. | Medium | May end up making something which is not what was originally intended. | Medium | Ensure requiremen ts are clear and check any ambiguitie s with the customer. | Requiremen ts Team |
| 20 | Choosing requiremen ts that the customer doesn’t really want. | Medium | Waste time which could be spent on requiremen ts they did want. | Low | Ensure you know which requiremen ts the customer really wants and which can be ignored. | Requiremen ts Team |
Estimation risks¶
| ID | Description | Likelihood | Impact | Severity | Mitigation | Owner |
| 21 | Expect the team or a team member can do more than they actually can. | Medium | Work is not done or is done to an insufficie nt standard. | Medium | Give tasks that people can do and if they can’t then help them. When working on difficult tasks work in pairs to complete the task meaning individual team members don’t feel as overwhelme d by the task | Project Manager |
| 22 | We may underestim ate how long it will take to do some work. | Medium | Work ends up taking longer than expected or not done to the standard it could be done. This could cause other areas of the project to suffer | Medium | Set realistic timings to do work and be realistic on how long a task will take. Account for unforeseen delays in our plan adding time where we can catch up. | Project Manager |
| 23 | Be too pessimisti c about what we can achieve. | Medium | We end up with a product which is not as good as it could have possibly been. | Low | Push our limits but also stay realistic and within the requiremen ts. If we have extra time then we can use it to enhance the product. | Project Manager |
| 24 | Distribute tasks incorrectl y. | Low | Team over/under worked. | Low | Distribute tasks appropriat ely and tell others if feel over/under worked. | Project Manager |
Bibliography¶
[1] GitHub [online] Available https://github.com [Accessed 01/11/2016]
[2] Google Drive [online] Available https://www.google.com/drive/ [Accessed 01/11/2016]
[3] Cloud Flare [online] Available https://www.cloudflare.com/ [Accessed 01/11/2016]