Risk Management
Likelihood & Impact Table
Impact Metric Table
| Impact
|
Description
|
| Low
|
Would not have impact on Project Progress
|
| Medium
|
May or may not have an impact on Project Progress
|
| High
|
Will have an impact on Project Progress
|
Likelihood Metric Table
| Likelihood
|
Description
|
| Seldom
|
Unlikely to happen within the timespan of a month
|
| Likely
|
May happen 1-2 times bi-weekly
|
| Highly Likely
|
Happen more than once in a week
|
Metric Value vs Action Plan
| Metric Value
|
Description
|
|
|
Risk should be handled by a single member
|
|
|
Risk should be handled by 2 members of the team
Mitigation plan to be activated
|
|
|
Risk should be handled by 2-3 members of the team
Mitigation plan to be activated
If mitigation actions are unsuccessful, schedule for meeting within 48 hours
|
|
|
Risk should be handled by 4-5 members of the team
Mitigation plan to be activated and followed closely
If mitigation actions are unsuccessful, schedule meeting within the next 24 hours
Alternative mitigation plan to be carried out immediately
|
|
|
All members of the team should be involved in handling the risk
Mitigation plan to be activated and followed closely
If mitigation actions are unsuccessful, schedule meeting within the next 4 hours
Alternative mitigation plan to be carried out immediately
|
Collective Risk Assessment
| No
|
Risk Category
|
Risk Description & Consequence(s)
|
Likelihood
|
Impact
|
Metric Value
|
Mitigation Strategy
|
Implemented
|
| 1
|
Changes in Technologies
|
The rate at which mobile platforms upgrade their OS to keep up with technological advancements may be faster than the rate at which developers can keep up with versioning issues.
The application may crash on mobile devices which are running on incompatible OS versions.
|
Highly Likely
|
High
|
|
The team will mitigate this risk by performing extensive research at the start of the project, and periodically at each phase of the project where requirements need to be reviewed. This will be especially impactful for developers.
The Project Manager will also review the project schedule to encompass longer durations where required.
The team will work closely with the Usability Analyst to test the application extensively on different platforms and OS versions.
Developers are to work closely with Business and Usability Analysts to find alternative solutions or a work-around support to solve compatibility issues.
|
Research was and still is being performed as the project progresses. Even though development for Android has been completed, the team updates itself regularly to ensure that OS updates do not affect application abilities.
Also, when we were performing research 2 weeks into this iteration where iOS development had already begun, Apple revealed plans to eliminate all devices running on iOS 6. Since our initial plan was to code in iOS 6 such that the app will be available to devices running on both iOS 7 and iOS 6, the schedule was reviewed to extend this iteration to port the codes from iOS 6 over to iOS 7.
|
| 2
|
Reliance on External Systems for Application Roll-out
|
Chosen mobile platform involves Apple
The submitted application requires layers of approval by Apple before it can be successfully deployed onto the App Store. The application also faces possibilities of rejection.
|
Likely
|
High
|
|
iOS deployment guidelines to be read thoroughly way before deployment period.
Put in effort to provide the specific documentation Apple requires.
|
iOS Guidelines were read through before deployment.
Efforts were focused on documenting the specifics Apple required for their various stages of review.
|
| 3
|
Chosen Technology does not meet User Requirements
|
Unlike teams embarking on sponsored projects, ours is a self-proposed idea. This may lead us to be more inclined to believe that the importance of technical functionalities outweigh user needs.
The team risks producing a product that does not concentrate on user requirements.
|
Likely
|
High
|
|
Requirements gathering will be performed on both user segment groups (i.e. Event Organisers and Participants).
Market research data must be of a healthy sample size of at least 100. Information collected will be used to review project requirements at each phase of development.
User Tests will also be conducted at respective development phases.
|
With the help of our mentor, the team met up with experienced industry players to further understand what the current market is able to offer, the needs of event organisers and how participants play a part in the entire ecology. The team also held a focus group with student organizers to validate if application functionalities were relevant, needed and useful to the management of student-led events.
|
