Difference between revisions of "IS480 Team wiki: 2018T1 analyteaka riskmanagement"
Line 209: | Line 209: | ||
|style="text-align: center;"| High - 0.8 | |style="text-align: center;"| High - 0.8 | ||
|style="text-align: center;"| To structure the database with bare minimum personal data inside the database. This is to ensure in the event of PDPA regulation change we will have bare minimum requirement change. Even though, we are likely not going to get affected by the regulation during the few months of development, we have to ensure the application will last without need the need to change. | |style="text-align: center;"| To structure the database with bare minimum personal data inside the database. This is to ensure in the event of PDPA regulation change we will have bare minimum requirement change. Even though, we are likely not going to get affected by the regulation during the few months of development, we have to ensure the application will last without need the need to change. | ||
− | |style="text-align: center;"| | + | |style="text-align: center;"| Active management |
|- | |- | ||
Revision as of 17:48, 6 September 2018
The risk impact assessment requires the team members to consider the impact of each risk across the various project objective areas. Based on this potential impact, the risk is assigned to one of the 5 identified scales below.
Project Objective | Relative/Numerical Scales | ||||
---|---|---|---|---|---|
Very Low / 0.05 | Low / 0.10 | Moderate / 0.20 | High / 0.40 | Very High / 0.80 | |
Time | Insignificant time increase | < 5%-time increase | 5% – 10%-time increase | 10% - 20%-time increase | >20% time increase |
Scope | Insignificant scope decrease | Minor scoping areas affected | Major scoping areas affected | Scope reduction unacceptable to sponsor | Project end item is effectively useless |
Quality | Insignificant quality degradation | Only very demanding applications are affected | Quality reduction requires sponsor approval | Quality reduction unacceptable to sponsor | Project end item is effectively useless |
By taking into consideration the estimated probability of occurrence as well as the potential impact from the risk impact assessment, a quantitative impact measure is obtained. Based on the team and clients risk threshold and appetite, the measures will be grouped and the appropriate action to be taken will be identified.
Impact / Probability |
Very Low | Low | Moderate | High | Very High |
---|---|---|---|---|---|
0.05 | 0.10 | 0.20 | 0.40 | 0.80 | |
0.90 | 0.05 | 0.09 | 0.18 | 0.36 | 0.72 |
0.70 | 0.04 | 0.07 | 0.14 | 0.28 | 0.56 |
0.50 | 0.03 | 0.05 | 0.10 | 0.20 | 0.40 |
0.30 | 0.02 | 0.03 | 0.06 | 0.12 | 0.24 |
0.10 | 0.01 | 0.01 | 0.02 | 0.04 | 0.08 |
Risk responses involve a combination of the following activities: Avoiding, Mitigating and Accepting. Prior to the start of each phase of the project, all risks will be considered and preventive measures will be put in place as part of mitigation. Additional action will be taken in accordance to the descriptive bands that are detailed below.
Green (Conditional Management) – Green regions will involve continuing with the project as per normal. Acceptance will be the main response in this band, active steps will only be taken when indicators of the risk arising begin to present themselves.
Orange (Passive Management, Mitigating) – Yellow regions will involve continuing with the project with passive risk management. Mitigation will be the main response in this band. During each end of iteration review, we will take note of whether the risk is still a possible threat and given the circumstances at each checkpoint, we will decide whether to invoke contingency measures and subsequently, risk management measures.
Red (Active Management, Avoiding and Mitigating) – Red regions will involve continuing with the project with active risk management. Avoidance will be the main response in this band. Contingency measures will be set in place and during each end of iteration review, we will take note of whether the risk is still a possible threat and given the circumstances at each checkpoint, we will decide whether to directly invoke risk management measures
S/N | Risk Type | Risk Detail | Risk Mitigation | Likelihood | Impact | Strategy |
---|---|---|---|---|---|---|
1 | Technical Risk | Majority of our team is not proficient in python, google app engine, flask and machine learning. | Spent time going through bootcamp training for python and machine learning to build on our foundation. We will also take various modules such as visual analytics, AA, EWS and networking to build on our competency. | Very High - 0.9 | Very high - Potential delay in the schedule due to production delay. | Active Management |
2 | Resource Management Risk | Most of the team are not well-versed in analytics, which is the core feature of our system. As well as limited knowledge on consumer behavior and digital marketing. | Spent time going through bootcamp training for analytics and consult professors on analytics. Also take courses related to digital marketing and consumer behavior. | High - 0.8 | High - Could affect our production timeline and analytics result. | Active Management |
3 | Human Risk | Potential schedule clash due to the different in class timetable. Additionally, FYP with internship concurrently means we could only work on our project at night and during the weekends. | Project manager to better plan the schedule. Ensuring that everyone will have a common free slot for work (e.g 1 day block slot every week) | Medium - 0.5 | Moderate - Schedule need to be re-adjusted if there’s a delay in the execution of task. | Passive Management |
4 | Client Management Risk | Client unable to provide csv containing sensitive data (NRIC, name) due to privacy compliances | Discuss with clients and capture what we need during bootstrap stage (e.g determine age, gender and race) and hash the values such that we can still analyze it without having access or storing the raw csv file. | Medium - 0.3 | Moderate - Would require a work around to analysis the data | Passive Management |
5 | Technical Risk | PDPA changes might affect the way our application is design and structured. | Very high - Potential delay in the schedule due to production delay. | High - 0.8 | To structure the database with bare minimum personal data inside the database. This is to ensure in the event of PDPA regulation change we will have bare minimum requirement change. Even though, we are likely not going to get affected by the regulation during the few months of development, we have to ensure the application will last without need the need to change. | Active management |