HeaderSIS.jpg

IS480 Team wiki: 2013T2 Excelente Risk Management

From IS480
Jump to navigation Jump to search

option

Home About Us Project Overview Project Management Project Documentation


Project Schedule Metrics Risk Management


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.