HeaderSIS.jpg

IS480 Team wiki: 2017T1 CodeBenders Risk

From IS480
Jump to navigation Jump to search


Codeblender logo.jpg
Home CodeBlenders.png

HOME

Users CodeBlenders.png

ABOUT US

ProjectOverview CodeBlenders.png

PROJECT OVERVIEW

Calendar CodeBlenders.png

PROJECT MANAGEMENT

File CodeBlenders.png

DOCUMENTATION

 


CodeBendersriskimpactassess.png


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
CodeBendersmatrix.png


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

Codebenderspotentialrisks.png
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