S/N
|
Risk Description
|
Consequences
|
Impact
|
Likelihood
|
Risk Rate
|
Mitigation Strategy / Contingency Plan
|
Status
|
1
|
Technical Risk
|
1.1
|
Team is unfamiliar with the technology used
|
- There might be a delay in project schedule
- longer time needed to create functions
|
High |
High |
A
|
- Team members are to start researching and trying the technology in advance before the iteration
- Share research documents and knowledge among members
|
Risk Strategy in place - Implemented
|
1.2
|
Conflict / issues during configuration and setup
|
- Delay in the project schedule
|
Moderate |
Moderate |
B
|
- All setup for the project should be done early
|
Risk Strategy in place - Implemented
|
1.3
|
Unfamiliar codes / API given by the company
|
- Longer time needed to implement functions
|
High |
High |
A
|
- Request for a detailed documentation of the API used from the company
- Ask the company directly and clarify the usage of the API
|
Not Implemented
|
2
|
Development Risk
|
2.1
|
Critical bug found during development
|
- Development of project will be stalled
|
High |
Moderate |
A
|
- Coders should consult the entire group about it to discuss for solutions
|
Not Implemented Yet
|
3
|
Client / Sponsor Risk
|
3.1
|
Additional requirements requested during implementation of codes
|
- Might not be able to finish requirements on time
- substandard work produced
|
High |
Moderate |
A
|
- Team members should discuss and decide if they can commit to the additional workload on time. If not, firmly reject the additional requirements/ol>
|
Risk Strategy in place - Implemented
|
3.2
|
Clients are uncertain what they want in the application
|
- Redundant functions done
- Delay and changes in schedule
|
Moderate |
High |
A
|
- Design a few prototypes for the company to view. Perhaps this might help the company to see what they want
|
Risk Strategy in place - Implemented
|
3.3
|
Frequent changes in requirements
|
- Frequent changes in schedule
|
High |
High |
A
|
- Team members should discuss and decide if they can commit to the changes needed on time. If not, firmly reject the changing requirements
- The schedule for the team has to be very flexible to take into account the frequent changes in requirements from the client.
|
Risk Strategy in place - Implemented
|
4
|
Team Risk
|
4.1
|
Team members may not be free during the critical period
|
- Delay in the project schedule
|
High |
Moderate |
A
|
- Push more work to be done before the the period where members are not free.
- Make sure the work intended for the missing member is fully covered.
- alter the schedule to fit the manpower available
|
Not Implemented Yet
|
4.2
|
Team members may have conflicts with each other during the project
|
- Delay in the project schedule
- Quality of work will deteriorate
|
Moderate |
Moderate |
B
|
- Project manager has to step in to be the mediator. Discuss the issue and work to solve the problems before continuing on the work
|
Not Implemented Yet
|
5
|
Project Management Risk
|
5.1
|
Over-estimate the days needed to build function
|
- Delay in the project schedule
|
Moderate |
High |
A
|
- Project manager to take note of the schedule and plan the future schedules more carefully
- Provide a longer time period for the next iteration to complete the functions.
|
Not Implemented Yet
|