IS480 Team wiki: 2012T1 Team Gratitude Risk Management

From IS480
Jump to navigation Jump to search

Gra home.jpgHome   Gra po.jpgProject Description     Gra documentation.jpgProject Documentation   Gra management.jpgProject Management   T&S.jpgAbout Us

Risk Management

Key Assumptions

When developing the risk management plan and risk register, it is assumed that:

  • All identified risks can be categorized into the five categories stated in the risk management plan.
  • There are no risks that will not occur and have a probability rating of 0.
  • There are no risks that will certainly occur and have a probability rating of 1.
  • Risks will only impact four factors; cost, time, scope and quality of the deliverables.

Risk Management Plan

Risk Identification

The project team will review all project documentations and information that has been gathered from the stakeholders and conduct an evaluation against similar past projects. Through the evaluation, potential risks that may affect the project are identified. Information gathering techniques such as brainstorming, interviewing and SWOT analysis will also be used to further identify risks. As potential risks may change over time in accordance to the project environment, additional stakeholder meetings may be organized periodically to keep the risk management plan up-to-date.

Roles and Responsibilities

The project manager will oversee the risk management plan. He will also be responsible for managing most of the risks related to project management. On the other hand, the rest of the project team will be responsible for managing risks that are related to their project roles. Tasks are delegated in such a way so as to instill a sense of responsibility and accountability among all team members and to ensure that risks are identified early so that response strategies can be executed in a timely manner.

Time Buffers

The project team will review each tasks listed in the work breakdown structure (WBS) and identify tasks with severe risks to it. A 10% time buffers will also be added to each of the risk-related activities.

Risk Categories

The risks identified in the project will be categorized into five main categories namely business requirement risk, external risk, technical risk, organizational risk and project management risk. The following table shows how different types of risk are being categorized into the various risk categories.

Risk Categories Description
Business Requirement Risk Risk that is related to the business requirements of the system.
External Risk Risk that is related to external stakeholders.
Technical Risk Risk that is related to the technological aspect of the project.
Project Management Risk Risk that is related to the management of the project related to issues such as costs and schedule.
Organizational Risk Risk that is related to the organization support provided by the key stakeholders.

Risk Probability and Impact

Every identified risk will be assessed and assigned with a probability and impact rating using the following matrices. They will then be ranked according to the overall score, which is computed by multiplying both probability and impact ratings.

Probability Ratings
Probability Level Description
Lesser than 0.21 Risk that is highly unlikely to occur.
0.21 – 0.40 Risk that is unlikely to occur.
0.41 – 0.60 Risk that is likely to occur.
0.61 – 0.80 Risk that is highly likely to occur.
More than 0.80 Risk that will almost certainly occur.

Impact Ratings
Impact Level Time Scope Quality
1 Insignificant time increase Insignificant area of scope impacted Insignificant degree of quality impacted
2 < 5% time increase Minor area of scope impacted Minor degree of quality impacted
3 5-10% of time increase Moderate area of scope impacted Moderate degree of quality impacted
4 10-20% of time increase Significant area of scope impacted Significant degree of quality impacted
5 > 20% of time increase Project end product is useless Project end product is useless


There should be at least one weekly project meeting initiated with the project team. During the meeting, team members are to inform and discuss any new potential risks they may have encountered or envisioned during project execution. The project team must decide the actions to be taken to counter these risks. All new potential risks and its response strategies should be documented in the risk register for future risk evaluations. The WBS should be reviewed periodically to ensure that the progress of the project is not affected by any new potential risks.

Risk Documentation

A risk register, which documents the risk response strategies, is made accessible to all team members through a shared folder on Tortoise Subversion. Team members are to access the risk register when an identified risk event occurs and take response strategies according to the document. They are to inform the team about the event and update the risk register accordingly. However, if an unidentified risk event has occurred, the team must be informed immediately and a project meeting must be initiated to decide on the response strategies that should be taken. The risk register should be updated after the project meeting.

Risk Glossary

Terms Definition
Contingency Plan An alternative plan that will be implemented if a possible foreseen risk event actually occurs.
Rank The ranking of risks according to their overall score.
Risk An uncertainty that can have a negative or positive effect on meeting project objectives.
Risk Acceptance A type of risk response strategy that accepts the consequences of a risk should it occurs.
Risk Avoidance A type of risk response strategy that eliminates a specific threat by eliminating its cause.
Risk Identification A process to identify the type of risks that is likely to affect a project.
Risk Mitigation A type of risk response strategy that reduces the likelihood of occurrence and impact on the project.
Risk Owner An individual who is accountable for the execution of the risk response strategy or contingency plan.
Risk Register A document that documents the potential risk events, risk management processes and other information related to the project.
Stakeholders An individual or a group of people who is involved in or will be impacted by the project.
Time Buffers Amounts of time used to compensate for unplanned delays in the project schedule.
Trigger An indicator or symptoms of actual risk events.

Risk Register

No Risk Description Category Root Cause Probability Impact Score Rank Response Strategy Type Potential Responses Contingency Plan Trigger Risk Owner

Difficulty in integration and deployment of project components

As current project components are not developed and integrated onto a server real time during development phase, data migration will have to be performed at certain points of the phase. During the data migration process, there might be some difficulties in integration and deployment of these components to school deployment server or ECSS server.

Technical Risk

Project components were not developed according to the school deployment server's or external hosted server's minimum requirements.

0.60 5 3 1 Risk Mitigation

Perform data migration after the development of each project phase to integrate project components onto server and implement testing to identify and resolve any errors.

Fix the errors immediately and if there is a delay in project schedule, review and update project schedule, budget and forecast and highlight the delay in project schedule to stakeholders.

Any errors that occurs during data migration of project components onto server.

Pan Fei
2 Change in system requirements

Users would like to make changes to the system requirements that was stated and finalised under project charter after sign off.

Business Requirements Risk

Users are unsure of what they want or unable to describe what they need during requirements gathering.

0.60 4 2.4 2 Risk Mitigation Reiterate system requirements that were discussed and stated under project charter before stakeholders sign off. Execute change control management strategy. Any stakeholders requesting to change system requirements. Ivan Sim
3 Severity of information system bugs Team underestimated the severity of bugs during the development of information system. Project could not progress as module with bug is the predecessor for subsequent tasks. Might cause delay in the progress of project. Technical Risk There is inadequate system testing and team members were unaware of the bugs. 0.60 4 2.4 2 Risk Mitigation Team members to conduct code review and system testing after each project phase were completed. They are to fix any bugs before the development of subsequent phases. Fix any bugs immediately and if there is a delay in project schedule, review and update project schedule, budget and forecast and highlight the delay in project schedule to stakeholders. A module of the information system is unable to function as expected. Ren Ruiyun
4 Information system is not user-friendly Completed online information system does not meet the requirements of the users in terms of usability and design. Business Requirements Risk User interface was not designed according to specified user's requirement or was poorly designed. 0.40 4 1.6 4 Risk Mitigation

Research and gather ideas from library books or online resources for the development of user-friendly interface. Thereafter, create user interface prototypes and seek users' feedback before developing information system.

Conduct User Testing and make improvements according to users’ feedbacks. Users' feedback that information system's user interface was not user-friendly. Lin Yin
5 Misunderstanding with project sponsor Team is working with a new project sponsor and does not have enough information about the organisation and its steering committee. Team might have trouble handling project sponsor. Project Management Risk Team is working with new project sponsor for the very first time. 0.40 4 1.6 4 Risk Mitigation

Be sensitive of new project sponsor when managing them. Team will have to take time and effort to understand them and their requirements.

Invite project sponsor out for a meal and clear any existing misunderstanding.

Team worries that there might be difficulty working with the new project sponsor. Ivan Sim
6 Insufficient system requirements information Insufficient system requirements information were gathered from stakeholders during meeting. Team might end up delivering information system with missing features or features that are not required. Business Requirements Risk

Team did not research on similar types of information system beforehand and prepare sufficient questions that were relevant or required by the project. Users do not know what they really want or had difficulties in describing what is needed.

0.30 5 1.5 6 Risk Mitigation Prepare more research and relevant questions before meeting. Organise additional meetings with stakeholders to ensure that more system requirements information were gathered. There were unclear user requirements when analysing system requirements. Ivan Sim
7 Late completion of assigned tasks Team members are unable to complete assigned task as scheduled causing delay in subsequent tasks. Project Management Risk Team members may have other commitments and are involved in academic workloads and extra-curricular activities during school terms. 0.50 3 1.5 6 Risk Acceptance N/A Assign other team members to help with uncompleted tasks, review and update project schedule, forecast and highlight the delay in project schedule to stakeholders. Failure to meet any one of the project deliverable milestones. Daniel Tan
8 Conflicts among team members Team members are unable to reach a consensus on workload distribution or methods used to develop information system. Organizational Risk Team members felt that work allocation is unfair. They also have different opinions on the method of executions. 0.30 3 0.9 9 Risk Mitigation Ensure that all team members are aware of each other’s' tasks and clear any disagreements regarding work allocation before project starts. Team members' opinions should be listened and the team must come to a consensus on the method of execution before the start of project. Organise team meeting to clear unhappiness or doubts among team members. Arguments among team members. Daniel Tan
9 Missing project documents Latest version of project documentations or source code files were not properly stored or documented by team members. Project Management Risk

Project documentations or source code files were not shared among the team members. Team members do not realise the importance of documentations or updating of edited files.

0.30 3 0.9 9 Risk Mitigation

Team will use TortoiseSVN for easy management and storage of all documentations and source code files. If members have edited any files, files must be updated to TortoiseSVN at the end of each day. Besides that, team members are also required to back up all their work on an external hard disk weekly.

Recreate documentations or source code files. Team member is unable to find latest version of project documentations or source code files that were created previously. Ivan Sim
10 Inadequate knowledge or unfamiliarity with technologies

Inadequate knowledge or unfamiliarity with technologies used for project development. Team members might not be able to perform as expected from them.

Organizational Risk

System requirements specified by the project sponsor require the use of new technologies in order for certain functional requirements to work.

0.30 3 0.9 9 Risk Avoidance Perform in-depth analysis to find replacement alternatives which team members are more familiar with. N/A Team member brings up issue on inadequate knowledge or unfamiliarity with technologies. Pan Fei
11 Lack of development resources

Team does not have sufficient development resources such as MS SQL Server and Adobe Photoshop for the development of the information system.

Organizational Risk Team does not have the required development resources or funds to purchase them. 0.30 3 0.9 9 Risk Acceptance N/A Team to use open source software. Team members are unable to complete assigned tasks due to development resource issues. Ivan Sim
12 Medical conditions Team members falling sick or have short term illness. Organizational Risk Team members have overworked or did not lead a healthy lifestyle. 0.40 2 0.8 13 Risk Acceptance N/A Distribute the work of the sick member evenly among the rest of the team members. Team member reporting sick. Daniel Tan
13 Unable to turn up for project meetings Team members are unable to provide each other with status updates on the progress of their assigned tasks. Project Management Risk

Team members may have other commitments and are involved in academic workloads and extra-curricular activities during school terms.

0.30 1 0.3 15 Risk Mitigation

Devise a meeting plan to accommodate every member’s schedule and commitments and set aside certain timeslots for project meetings.

Meeting to carry on and team member who is unable to turn up for meeting is to provide status updates to the team before the meeting.

Failure to turn up for project meetings by any team members. Daniel Tan

Risk Tracking

Risk No# Outcome
1 Eliminated
2 Eliminated
3 Mitigated
4 Mitigated
5 Eliminated
6 Eliminated
7 Mitigated
8 Eliminated
9 Eliminated
10 Eliminated
11 Eliminated
12 Eliminated
13 Eliminated