Difference between revisions of "IS480 Team wiki: 2014T1 Team Epsilon Risk Management"
(2 intermediate revisions by 2 users not shown) | |||
Line 25: | Line 25: | ||
<!-- Start of sub-header --> | <!-- Start of sub-header --> | ||
{|style="background-color:#FFFFFF; color:#000000 padding: 5px 0 0 0;" width="100%" cellspacing="0" cellpadding="0" valign="top" border="0" | | {|style="background-color:#FFFFFF; color:#000000 padding: 5px 0 0 0;" width="100%" cellspacing="0" cellpadding="0" valign="top" border="0" | | ||
− | | style="padding:0.4em; font-size:150%; background-color:#FFFFFF; border-bottom:4px solid #000000; border-top:4px solid #000000; text-align:center; color:#828282" width="10%" | [[IS480 Team wiki: 2014T1 Team Epsilon Project Management |<font color="#000000" size=2><b>Project Schedule</b></font>]] | + | | style="padding:0.4em; font-size:150%; background-color:#FFFFFF; border-bottom:4px solid #000000; border-top:4px solid #000000; text-align:center; color:#828282" width="10%" | [[IS480 Team wiki: 2014T1 Team Epsilon Project Management |<font color="#000000" size=2><b>Methodology</b></font>]] |
+ | |||
+ | | style="border-bottom:4px solid #000000; border-top:4px solid #000000; background:none;" width="1%" | | ||
+ | | style="padding:0.4em; font-size:150%; background-color:#FFFFFF; border-bottom:4px solid #000000; border-top:4px solid #000000; text-align:center; color:#828282" width="10%" | [[IS480 Team wiki: 2014T1 Team Epsilon Project Schedule |<font color="#000000" size=2><b>Project Schedule</b></font>]] | ||
| style="border-bottom:4px solid #000000; border-top:4px solid #000000; background:none;" width="1%" | | | style="border-bottom:4px solid #000000; border-top:4px solid #000000; background:none;" width="1%" | | ||
Line 32: | Line 35: | ||
| style="border-bottom:4px solid #000000; border-top:4px solid #000000; background:none;" width="1%" | | | style="border-bottom:4px solid #000000; border-top:4px solid #000000; background:none;" width="1%" | | ||
| style="padding:0.4em; font-size:150%; background-color:#E0D1FF; border-bottom:4px solid #000000; border-top:4px solid #000000; text-align:center; color:#828282" width="10%" | [[IS480 Team wiki: 2014T1 Team Epsilon Risk Management |<font color="#000000" size=2><b>Risk Management</b></font>]] | | style="padding:0.4em; font-size:150%; background-color:#E0D1FF; border-bottom:4px solid #000000; border-top:4px solid #000000; text-align:center; color:#828282" width="10%" | [[IS480 Team wiki: 2014T1 Team Epsilon Risk Management |<font color="#000000" size=2><b>Risk Management</b></font>]] | ||
− | |||
− | |||
− | |||
|} | |} | ||
Line 97: | Line 97: | ||
| style="text-align: center;" | B | | style="text-align: center;" | B | ||
| Understand the dependency between different functions/ tasks and identify the critical path of project. Plan the schedule such that there would be minimal disruption to the schedule even if there is a delay in some tasks. | | Understand the dependency between different functions/ tasks and identify the critical path of project. Plan the schedule such that there would be minimal disruption to the schedule even if there is a delay in some tasks. | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| Change or increase in requirements | | Change or increase in requirements | ||
Line 107: | Line 107: | ||
| Work with the sponsor to create a requirement document that both parties agree on. Come to an understanding that any change requests would be subject to the other party’s approval based on his/their judgement of the necessity of the change.<br> | | Work with the sponsor to create a requirement document that both parties agree on. Come to an understanding that any change requests would be subject to the other party’s approval based on his/their judgement of the necessity of the change.<br> | ||
Create a change management metrics to help with the change management decision. Keep track of all change requests. | Create a change management metrics to help with the change management decision. Keep track of all change requests. | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| Sponsor pulls out of project | | Sponsor pulls out of project | ||
Line 142: | Line 142: | ||
| style="text-align: center;" | B | | style="text-align: center;" | B | ||
| Coordinate team members’ schedules and arrange a common timeslot for weekly meetings | | Coordinate team members’ schedules and arrange a common timeslot for weekly meetings | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| Conflicting opinion within the team | | Conflicting opinion within the team | ||
Line 150: | Line 150: | ||
| style="text-align: center;" | B | | style="text-align: center;" | B | ||
| Encourage an open environment so that every member can voice out their concerns and opinions. Handle those as soon as possible. | | Encourage an open environment so that every member can voice out their concerns and opinions. Handle those as soon as possible. | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| Constraint in manpower and member’s ability to commit during crunch time (e.g. before midterms or finals) | | Constraint in manpower and member’s ability to commit during crunch time (e.g. before midterms or finals) | ||
Line 158: | Line 158: | ||
| style="text-align: center;" | A | | style="text-align: center;" | A | ||
| Identify and account for crunch time when planning the project schedule. Team members should monitor their own schedules and raise any scheduling concerns to the project manager as soon as possible. | | Identify and account for crunch time when planning the project schedule. Team members should monitor their own schedules and raise any scheduling concerns to the project manager as soon as possible. | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| colspan="8" style="background:#B2CCFF; text-align: center;" | '''External Risks''' | | colspan="8" style="background:#B2CCFF; text-align: center;" | '''External Risks''' | ||
Line 170: | Line 170: | ||
| Research into iOS update roadmap to better gauge when new versions will be released (Apple often seeds beta versions to developers early) as well as what changes will come with it.<br> | | Research into iOS update roadmap to better gauge when new versions will be released (Apple often seeds beta versions to developers early) as well as what changes will come with it.<br> | ||
Evaluate if there is a need to allocate time to support the new update. If there is, adjust the schedule accordingly, taking into account the overall development progress using the critical path. | Evaluate if there is a need to allocate time to support the new update. If there is, adjust the schedule accordingly, taking into account the overall development progress using the critical path. | ||
− | | style="text-align: center;" | | + | | style="text-align: center;" | Mitigated |
|- | |- | ||
| Delay in procurement of required project resources | | Delay in procurement of required project resources | ||
Line 191: | Line 191: | ||
If the system proves to be too complex, conduct tutorial sessions to educate users about the system. | If the system proves to be too complex, conduct tutorial sessions to educate users about the system. | ||
| style="text-align: center;" | | | style="text-align: center;" | | ||
+ | |- | ||
+ | | Unable to get usage & support from end-users | ||
+ | | Users may potentially resist adopting the system, which means our application will not have an actual end-user | ||
+ | | style="text-align: center;" | Medium | ||
+ | | style="text-align: center;" | High | ||
+ | | style="text-align: center;" | A | ||
+ | | Research on how our system can benefit end-users.<br> | ||
+ | Meet up with end-users and pitch to them why they should use our application.<br> | ||
+ | Pivot and change the business direction of the project, so that the system has actual end-users and can benefit from it.<br> | ||
+ | | style="text-align: center;" | Mitigated | ||
|} | |} |
Latest revision as of 00:04, 21 November 2014
Home | Project Overview | Project Management | Documentation | Team |
Methodology | Project Schedule | Metrics Management | Risk Management |
Risk Assessment
Project Risks
Risk | Consequences | Likelihood | Impact | Level (Derived) | Mitigation Strategy | Status | |
---|---|---|---|---|---|---|---|
Technical Risks | |||||||
Unfamiliarity with technology employed | Slower project progression due to time required for the team to pick up the new language and accompanying technologies | High | High | A | Allocate sufficient time in project schedule to account for time required to learn the new language and technologies | Mitigated | |
Planned technology might be discovered to be incompatible during development | Slower project progression because of the necessity to create workarounds in order for the technology to work | Medium | High | A | Pivot to other more compatible technology if workarounds prove to hinder the project too much | Mitigated | |
Routine bugs discovered during development and UAT | System might become unstable. If the bugs are fatal, they would potentially jeopardize the core functionalities of the system. | High | High | A | Create proper documentation and metrics to keep track of system stability. Conduct routine testing to find and resolve the bugs as soon as possible. |
||
Project Management Risks | |||||||
Delay in task completion due to increased complexity of functional requirements during development | Project schedule might be delayed if the delayed task is a dependency for other tasks | Medium | Medium | B | Understand the dependency between different functions/ tasks and identify the critical path of project. Plan the schedule such that there would be minimal disruption to the schedule even if there is a delay in some tasks. | Mitigated | |
Change or increase in requirements | Project schedule may be delayed to accommodate the changes to the project. Increase in project requirements may lead to scope creep. |
Medium | High | A | Work with the sponsor to create a requirement document that both parties agree on. Come to an understanding that any change requests would be subject to the other party’s approval based on his/their judgement of the necessity of the change. Create a change management metrics to help with the change management decision. Keep track of all change requests. |
Mitigated | |
Sponsor pulls out of project | Project will terminate prematurely | Low | High | B | The team will need to source for another sponsor and project | ||
Team member pulls out of project | Team might be overwhelmed with project scope due to the sudden reduction in manpower | Low | High | B | Reshuffle roles and responsibilities to fill up the gap created by the team member’s exit. Source for another suitable team member if possible and bring him/her up to speed. |
Mitigated | |
Communication breakdown between team and sponsor | Project might be delayed due to pending reply or confirmation from sponsor | Medium | Medium | B | Establish routine meetings with sponsor to provide updates/ demonstrations and to obtain feedbacks. Regularly update sponsor on project progress through email. |
||
Conflicting schedule amongst team members | Unable to meet up for discussions which may lead to team members being on different pages for the project | Medium | Medium | B | Coordinate team members’ schedules and arrange a common timeslot for weekly meetings | Mitigated | |
Conflicting opinion within the team | Lower team morale due to frustrations and stress from the conflict | Medium | Medium | B | Encourage an open environment so that every member can voice out their concerns and opinions. Handle those as soon as possible. | Mitigated | |
Constraint in manpower and member’s ability to commit during crunch time (e.g. before midterms or finals) | Delay in project schedule due to lower availability of resources and manpower | High | Medium | A | Identify and account for crunch time when planning the project schedule. Team members should monitor their own schedules and raise any scheduling concerns to the project manager as soon as possible. | Mitigated | |
External Risks | |||||||
Updates to iOS | Project schedule may be delayed to support the new iOS version release | High | High | A | Research into iOS update roadmap to better gauge when new versions will be released (Apple often seeds beta versions to developers early) as well as what changes will come with it. Evaluate if there is a need to allocate time to support the new update. If there is, adjust the schedule accordingly, taking into account the overall development progress using the critical path. |
Mitigated | |
Delay in procurement of required project resources | Development may be stalled due to resource constraints. In the case of the lack of a deployment server, we will not be able to deploy and conduct UAT. |
High | High | A | Simulate testing environment using our own resources (e.g. server) for preliminary testing | ||
End user’s unfamiliarity with the system | Users may potentially resist adopting the system, which would lead to reduced usage | Medium | Medium | B | Research user’s browsing and usage habits on the different platforms. Conform to web and iOS standards when designing user interfaces. |
||
Unable to get usage & support from end-users | Users may potentially resist adopting the system, which means our application will not have an actual end-user | Medium | High | A | Research on how our system can benefit end-users. Meet up with end-users and pitch to them why they should use our application. |
Mitigated |