IS480 Team wiki: 2017T1 CodeBenders Risk
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.
Yellow (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 Category | Risk Type | Risk Management | Likelihood | Impact | Strategy |
---|---|---|---|---|---|---|
1 | Technical Risk | Application Execution Risk | Risk: The operation of the application has a strong dependency on data connection/Wi-Fi and Phone Signal. Action: We design and develop the application such that it uses minimal data transmission and can transmit on lower end data bands. |
0.9 | Low | Passive Management |
2 | Technical Risk | Development Risk | Risk: Since we are developing an application that is cross platform, we may run into development issues where the compilation or running of the application is possible on 1 platform but not the other. Action: We have team members with both Android, Windows and Apple based devices so we can shift development and testing between devices to make sure that the development is completed while maintaining quality. |
0.3 | Moderate | Passive Management |
3 | Technical Risk | Development Risk | Risk: This is the first time that team members are using the the tooling suggested by clients (Microsoft Visual Studio and Microsoft Xamarin) that is to be used to develop the application, hence there may be unfamiliarity with the UI. Action: The team will engage in sufficient education on the tooling as well as undertake mini development projects before proceeding on to work on the development of the application so that work can be completed as efficiently as possible. |
0.7 | High | Active Management |
4 | Technical Risk | Application Execution Risk | Risk: Team members have little to no experience with working on mobile development projects as well as with development in the language, C#. Hence the understanding of how to go about development as well as creating the framework and architecture may be ambiguous. Action: The team will engage in sufficient education on the tooling as well as undertake mini development projects before proceeding on to work on the development of the application so that work can be completed as efficiently as possible. |
0.7 | High | Active Management |
5 | Client Risk | Stakeholder Risk | Risk: Potential lack of use because employees are not comfortable with using technology and figuring out how the application works. Action: We will conduct adequate research into scenarios and personas, multiple rounds of prototyping with sufficient client feedback prior to starting the development on the UI. Additionally, run through a tutorial during the first launch to highlight the importance of the features and use of the application. |
0.5 | Very High | Active Management |
6 | Client Risk | Stakeholder Risk | Risk: Failure by employees to download and regularly update the application. Action: Taking this into consideration, we will set up the application such that auto updating is carried out in the background once connected to a network. |
0.7 | High | Active Management |
7 | Client Risk | Stakeholder Risk | Risk: Misuse of the application by uses (ie activation for non-emergency situations). Action: During the initial use tutorial, we emphasise that this application is to be used for emergencies only. Beyond this, we will advise the client to issue advisory emails to ensure behaviour that is compliant. |
0.5 | Moderate | Passive Management |
8 | Client Risk & SMU-Related Risk |
Organisational Risk & University Risk |
Risk: Unexpected school/company related events causing delays in supervisor/sponsor meetings. Action: On a monthly basis, we will fix down meeting dates with sponsors, with additional contingency dates for higher priority meetings. |
0.5 | Low | Conditional Management |
9 | SMU-Related Risk | University Risk | Risk: Insufficient time to complete due to school and course workload. Action: Ensure equitable work distribution and peer to peer work tracking so that members are aware if there are any incomplete tasks that would hold up the schedule. Additionally, add in sufficient buffer time to cope with unexpected changes. |
0.3 | Moderate | Passive Management |
10 | SMU-Related Risk | Team Risk | Risk: Conflicting schedules between team members reducing the amount of time available for meeting. Action: During term planning and bidding exercises, we will collaborate and communicate with regards to class and CCA time planning to maximise the availability of time to meet. |
0.5 | Moderate | Passive Management |
11 | SMU-Related Risk | Team Risk | Risk: Team members fall sick to the point where contribution to project is affected (ie hospitalization). Action: Always ensure that the wellbeing of the team members is preserved by encouraging healthy diet, exercise and work life balance. Additionally, conduct peer sharing sessions so that everyone is aware of what is being done by each other such that taking over will be easy in such situations. |
0.1 | High | Conditional Management |
12 | SMU-Related Risk | Team Risk | Risk: Personal Laptop Devices breaking down during the term. Action: We adopted the usage of Git to do version control and ensure access of files on all member’s computers. Additionally, everyone is to perform backups of data onto personal storage at frequent intervals and use their personal electronic devices wisely. |
0.1 | High | Conditional Management |
13 | Project Management Risk | Scheduling | Risk: Due to the existing uncertainty with project scoping as well as the lack of prior experience with mobile development, estimation of the time required to complete tasks can be quite ambiguous and thus, there may be situations where too little or too much time is allocated to various project tasks. Action: After receiving the details of the application requirements from the client, we conduct internet research as well as consult people whom we know (friends, family, schoolmates) who have experience in app development with similar functionality to aid in our estimations. furthermore, during the documentation and planning stages, the granularity of breakdown of the development tasks will increase allowing us to get a more accurate picture of how long the task will take. |
0.9 | Very High | Active Management |