HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2015T1 4Sight Risk Management"

From IS480
Jump to navigation Jump to search
 
Line 166: Line 166:
 
|-
 
|-
 
|External Risk
 
|External Risk
|Future developers might not be familiar with the technologies that the team have used.  
+
|If the client decides to expand the project in the future to include additional features, incoming developers might not be familiar with the codes written and the technologies that the team have used.  
|Unable to do a proper handover. Maintenance of application might be an issue in the future.  
+
|1. The new team might have to spend a lot more time trying to comprehend the codes and devise ways to build new functionalities on top of existing ones. <br/> 2. The new team might consider building again from scratch due to the challenges they face in the above mentioned point.
 
| align=center | Medium
 
| align=center | Medium
 
| align=center | High
 
| align=center | High
| Team to prepare proper documentation for sponsor. This includes commenting of codes and deployment guide.
+
| 1. Well commented codes to ensure code readibility. <br/> 2. Modularize the application by functionalities so that there is minimal dependency considerations when scaling it. Modularized functions are coded to be reusable by any new feature set.
 
| align=center | Mitigated
 
| align=center | Mitigated
 
|-
 
|-
  
 
|}
 
|}

Latest revision as of 20:03, 29 November 2015

4Sight team logo.png
4Sight Home.png HOME   4Sight Team.png ABOUT US   4Sight Project overview.png PROJECT OVERVIEW   4Sight Project management.png PROJECT MANAGEMENT   4Sight Documentation.png DOCUMENTATION  
Project Schedule Software Development Methodologies Schedule Metrics Task Metrics Bug Metrics Risk Management Change Management
Risk scale.jpg
  • Risks categorise as high require urgent attention. They are high in impact level and high in probability of occurrence. Crafting of the mitigation plans have to be well analyzed and developed
  • Risks categorise as medium require moderate attention. They have a medium impact level and occur on an occasional basis
  • Risks categorise as low require the least attention. They have a low impact level and occasionally or rarely occur
  • Risks categorise as none require no attention

Activated Risks

  • These risks have occurred. Team has taken the necessary actions to mitigate the risks.
Risk Type Risk Statement Consequence Likelihood Impact Mitigation Strategy
Project Management Risk Unable to get actual users to conduct testing due to busy schedule Unable to get genuine feedback from actual users and hence affecting usability of system High High Coordinate in advance with Clearvision stakeholders so that they have ample time to gather relevant users for our User Testing, such as involving nurses and optometrists from other Clearvision clinics.
Technical Risk Team member is unfamiliar with the new technologies/languages used such as: django framework, python, angularJS and C3.JS. 1. Disruption to progress

2. Unduly stress to team member
High High 1. Team members to pick up skill as soon as possible, preferably before coding task.

2. Lead Developer to coach team member where possible.

3. Conduct group learning and sharing
Technical Risk 2 way SMS might not work for all mobile device platforms (iPhone, Android etc.). Current provider, infobip might not work for iPhone. Team has to source for other providers that provide 2 way SMS service suitable for all mobile device platforms. This might cause a delay in project schedule Medium High Lead Developer to work closely with provider and check if 2 way SMS service is possible for iPhone. Meanwhile team has to look for alternative providers and ensure that it works well with all mobile device platforms.
Client Management Risk As the team is doing early deployment, there might be more change requests along the way since users will be using the application on a day-to-day basis. These changes might not be easily picked up in our demo done every sprints as well as the user testing we have conducted because it does not cover all possible scenarios. Incur higher development cost with increase change requests Medium High 1. Any proposed change request is to go through the change management process.

2. Inform Supervisor of any major change request.
Project Management Risk Risk of scope creep as project progresses Project schedule delays Medium High 1. Any proposed change request is to go through the change management process

2. Regular app demos to sponsors in order to reduce change in scope
Operational Risk Team member unable to work due to unforeseen circumstances. Eg: Sick, urgent family matter 1. Project schedule delays

2. Quality of work may be compromised
Medium High 1. Delegate work of affected team member to the rest of the team, if needed.

2. Review plans and make necessary changes where possible.

3. Schedule task assigned to affected member to buffer period, if needed.
Project Management Risk Team is unsure of the time estimates required for each task of a user story Inaccuracy in time estimates, resulting in inaccurate planning of project schedule Medium Medium Members to do their own estimate for tasks assigned to them based on a benchmark, set to improve estimation. Team then comes together for a discussion to finalized time estimate for each task.

Potential Risks

  • These risks have not occurred. Our team has taken the necessary actions to mitigate the risks.
Risk Type Risk Statement Consequence Likelihood Impact Mitigation Strategy Status
Project Management Risk Team might not be able to gather requirements on time due to doctors' busy schedule. Delay in Project Schedule Medium High Team can first work on the existing requirements obtained and start doing the mockup for sponsor approval. PM to arrange meeting a week in advance and to inform sponsor of agenda and requests beforehand. PM to work closely with sponsor. Mitigated
External Risk If the client decides to expand the project in the future to include additional features, incoming developers might not be familiar with the codes written and the technologies that the team have used. 1. The new team might have to spend a lot more time trying to comprehend the codes and devise ways to build new functionalities on top of existing ones.
2. The new team might consider building again from scratch due to the challenges they face in the above mentioned point.
Medium High 1. Well commented codes to ensure code readibility.
2. Modularize the application by functionalities so that there is minimal dependency considerations when scaling it. Modularized functions are coded to be reusable by any new feature set.
Mitigated