Risk Management Plan
From TeamF::CGT
Revision: 3872
Abstract
This documents details the list of Risks that are associated with the Project and methods to mitigate or treat them. This document will be constantly revised and referred to throughout the year.
Introduction
Purpose
This document shall provide a comprehensive overview of the Team Fertility’s processes and procedures. It also lists all the major Risks that are associated with the Governance Toolset.
The aim of this document is to:
- Provide a lightweight, effective Risk management solution for the Risk Wizard project.
- Have a documented way to mitigate risks.
- Have a treatment plan in place to treat risks in the event they occur.
- Define the processes and procedures involved in Risk Management
An effective way to mitigate risks is to have people informed, as such, the intended audience of this document are all the members of Team Fertility.
Scope
This document shall apply to all Team members. As such, it is the responsibility of all those mentioned to familiarise themselves with this document and adhere to the steps outlined throughout regarding Risk Identification, Analysis, Assessment, Mitigation, Monitoring and Treatment. In doing so, the risks affecting the overall quality of this project can be properly monitored and controlled.
Although the responsibility for reducing the likelihood that risks are realized falls on every Team member, it is specifically the responsibility of the Risk Manager (RM) to ensure that proper procedures are in place to guide Risk Management throughout this project’s life cycle. The RM will be assisted by the Project Managers (PM) who will provide regular insights into risks associated with their specific area of this project. This document will further guide the RM and other members of the Team by documenting the necessary actions to manage risks.
Responsibility of the Risk Manager
The Risk Manager for this project is Luke Jones. While the role of the RM has been broadly outlined in the Software Project Management Plan (SPMP), the following is a more detailed description of the responsibilities of the RM.
- Write and maintain the Risk Management Plan (RMP).
- Write and maintain the Risk Reports.
- Frequently monitor and analyse all previously known risks and identify any new risks. This also includes communicating any risk that has been triggered and its relevant treatment plan.
- Develop risk mitigation and risk treatment strategies for each risk that is deemed highly critical according to the established risk exposure rankings, as well as any risks that has been triggered
- Implement risk mitigation strategies and remind other Team members of risk mitigation strategies throughout the course of this project
- Monitor the effectiveness of risk mitigation strategies through observing the development of this project or through feedback from other Team members
- Update Team members on the triggered risks at each Team meeting
Definitions
| Word/Acronym | Definition |
|---|---|
| GUI | Graphical User Interface |
| Mitigation | Preventing a risk from occurring by following a set procedure and/or process. |
| Risk | The potential for unwanted events to occur in processes and procedures throughout the Project. |
| Risk Analysis | Determining the priority level of a risk by calculating the product of its impact value and probability. |
| Risk Exposure | A measure of risk by multiplying its impact value and probability. |
| Risk Monitoring | Processes that are aimed at regularly checking the status of a risk, and re-evaluating a risks RE (Risk Exposure) value. |
| RMP | Risk Management Plan |
| SPMP | Software Project Management Plan |
| SQAP | Software Quality Assurance Plan |
| SRS | Software Requirements Specification |
| Treatment | Preventing a risk from occurring by following a set procedure and/or process. |
| QA | Quality Assurance |
Reference Documents/Materials
The references used to create this document are as follows:
- The Australia and New Zealand Standard on Risk Management, AS/NZS 4360:2004
- 433-340 Team Lotus RMP, 2005
- 433-340 Team Sabre RMP, 2004
- 433-443 Risk Notes
Risk Management Strategy
The Risk Management Strategy will be based the Australian and NZ standard for Risk Management which is a 5-stage cycle (see diagram below) which also have general review and consultation for each stage. It is the responsibility of the Risk Manager to take control of all of these stages and move through the cycle when Risks are triggered or are developing.
A description of the processes and procedures of each stage follows:
Establish Context
The first step of Risk Management is realising what is a Risk in the context of the Project. This involves understanding what are the success criteria for the project and thus have an understanding of events that can cause damage to them.
Identify
Drawing on the success criteria, creativity is required to think of potential areas in processes or procedures where major Risks can arise. The ultimate responsibility for Risk management lies with the RM but for successful Risk management to occur it requires the involvement of the whole team. Involvement of the team will be aided by our online wiki.
The process is as follows:
- A team member feels that there is a Risk in an activity.
- Access the RMP on our wiki site (currently [1]).
- Skip to the Risk Profile section.
- Add a new Risk in that section following the template provided.
- The RM will be automatically be emailed of any changes to the RMP and will promptly investigate the added Risk.
- The RM will decide the seriousness of the Risk and will follow the proper Risk management procedures.
This is a very dynamic process that allows all of the team members to have input into Risk management, has a quick turnaround and is easy to access. The low overhead encourages team members to add and modify Risks and since the RM is automatically sent an email if the page changes, he can decide what the appropriate action is to take.
Analyse
Once a Risk has been identified then a metric will be applied to the Risk based on probability of occurrence and impact. Probability will be calculated by looking at the Risk and comparing it to past data (such as previous year projects) and placing it in the setting of the project. To measure the impact of a Risk it must first be acknoledged that there is no budget for this project, the only asset is the time we have. So impact is measured in time wasted due to the Risk occurring. This value is based on the worst case scenario based on experience in previous projects.
Evaluate
Risks will be ranked on importance and minor Risks may be removed in the evaluation stage. This will be calculated using the Probability of occurence multiplied by the impact on the project. Then ranking from most critical to least critical will apply. This will allow the most critical Risks to get the most attention.
The risk manager should consult the relevant sub-teams when evaluating the risk probability and the risk impact values.
Treatment
Treatment involves having a plan in place to deal with the situation when a Risk has developed but also to have a plan to mitigate the Risk in the first place.
All of these stages are linked to the following two activities:
Monitor and Review
The Risk Manager will assess the current environment of the Project and determine whether a treatment plan needs to be activated or a new risk be defined. All members can advice the RM through email if they believe a Risk may be triggered or exists. The RM will then assess the Risk and take the neccessary action, either mitigation of treatment.
Risk Monitoring Process
Risk will update the status of each risk once a week and sends an email to the team the top 5 risks and short summary of actions that need to be taken.
Any risk that belongs in the High or Critical Risk Exposure Range will be actively managed by the risk manager.
The procedure for managing the risks in “High” Risk Exposure Range:
- The risk manager should send an email to the sub-team leader explaining the status of the risk and the actions that needs to be taken in order to reduce the risk exposure.
- The sub-team leader must respond back with a plan to reduce the risk within three days. This should include implementing mitigation strategy and estimating the cost.
- During the next weekly risk review, the risk manager needs to review the action taken according to the mitigation strategy and update the risk exposure values accordingly. If the mitigation strategy is inadequate, then the risk manager should hold a meeting with the sub-team leader and project manager.
The procedure for managing the risks in “Critical” Risk Exposure Range:
- The risk manager should hold a meeting with the sub-team leader and project manager to come up with a mitigation strategy for the identified risk.
- During the weekly risk review, the risk manager needs to review the action taken according to the mitigation strategy and update the risk exposure values accordingly. If the mitigation strategy is still inadequate, then the risk manager should hold a meeting with the sub-team leader, project manager and supervisor.
Communication and Consultation
During all the stages of Risk Management the Risk Manager will be in contact with various members of the Team depending on which Risks need to be mitigated or treated. Also the Risk Manager will take advice from the Team in determining new Risks or the removal of old ones (such as once a stage is complete, Risks may not be able to occur). Whenever the team has a supervisor/team meeting the Risk Manager will highlight up to three Risks which he feels has the potential for occuring in the immanent future. The Mitigation plan will be reviewed and if necessary the Treatment plan will be applied.
The following section will list out all the current Risks based on the process described in this section.
Risks, Mitigation Plan and Contingency Plan
Each risk will have the following attributes:
- Risk ID: unique number given to a risk
- Risk Description: brief description of the risk
- Risk Category: The area or field of the project where the risk originates from. The areas of the project are as follows
- Team: General activities of the team and team members
- Requirements: The requirement phase of the project
- Design: The design phase of the project
- Implementation: The implementation phase of the project
- Testing: The testing phase of the project
- Documentation: The documents produced by the team
- Process: The standard processes that must be followed by the team
- System: The hardware or software tools used by the team
- Schedule: The schedule and time allocation as defined by the project plan
- Mitigation Plan: The action to be taken to mitigate the risk before it actually occurs.
- Mitigation Plan Cost (MP Cost): The cost of implementing the mitigation plan. It is measured in number of personnel hours required to implement the plan.
- Contingency Plan: The action to be taken to minimise the impact of risk in the event of risk actually occurring.
- Contingency Plan Cost (CP Cost): The cost of implementing the contingency plan. It is measured in number of personnel hours required to implement the plan.
- Risk Probability: the probability of risk occurring
- Risk Impact: the effect of the risk on the project
- Risk Exposure: the criticality of the risk given the probability of it occurring and its impact.
Risk Metrics
Risk Probability
Probability describes the likelihood of a risk occurring. The probability is given a rating between 1 and 10.
The following table defines the metric used for probability:
| Rating | Likelihood of Risk (%) |
|---|---|
| 1 | 1% - 5% |
| 2 | 6% - 15% |
| 3 | 16% - 30% |
| 4 | 31% - 40% |
| 5 | 41% - 50% |
| 6 | 51% - 60% |
| 7 | 61% - 70% |
| 8 | 71% - 80% |
| 9 | 81% - 90% |
| 10 | 91% - 100% |
Risk Impact
Risk Impact is measured in terms of personnel hours that will be required to correct the adverse impact caused by the risk.
The rating for Risk Impact is defined as follows:
| Rating | Number of Personnel Hours Required |
|---|---|
| 1 | 1 - 2 |
| 2 | 3 - 5 |
| 3 | 6 - 9 |
| 4 | 10 - 14 |
| 5 | 15 - 19 |
| 6 | 20 - 24 |
| 7 | 25 - 31 |
| 8 | 32 - 39 |
| 9 | 40 - 49 |
| 10 | 50+ |
Risk Exposure
Risk Exposure is defined as Risk Probability X Risk Impact.
The Risk Exposure will be denoted by a colour in the Risk Log so that information is transferred in an intuitive fashion.
| Risk Exposure Range | Colour |
|---|---|
| 80 - 100 | CRITICAL |
| 60 - 79 | HIGH |
| 40 - 59 | MEDIUM |
| 20 - 39 | LOW |
| 0 - 19 | VERY LOW |
Risk Profiles
The following table details all the risks and their status:
| RISK ID | RISK NAME | RISK DESCRIPTION | RISK CATEGORY | RISK PR | RISK IMP | RISK EXP |
|---|---|---|---|---|---|---|
| 9 | Missing Deadlines | Missing deadlines could happen with any development activity in every phase of software development. There could be various reasons for this, including underestimating the minimum time a task requires, team member unavailability, and hardware failure. | Team | 7 | 8 | 56 |
| 3 | Inability to Find Major Bugs | The software may contain major bugs that may not be detected. The major bugs are the flaws that causes important feature of the software to fail. | Implementation | 7 | 8 | 56 |
| 20 | Inability to Maintain Configuration Management | If the different versions of working classes are not grouped or configured together, different component of the software will not integrate together well and function as a whole system. | Implementation | 7 | 8 | 56 |
| 10 | Lack of Use of Task Tracking | Task tracking is a vital part of successful project management, but if this is not used then there is no auditable way to know what is happening in the project. | Team | 7 | 7 | 49 |
| 18 | Failure to Integrate Different Layers and Modules | Since the architecture is divided into three layers, with different sub-groups working on each layer, there is a possibility that these layers may not integrate seamlessly. There may be misunderstandings about the interfaces, preconditions and post-conditions of methods. Different Classes or Modules within layer may not be integrated well | Implementation | 6 | 8 | 48 |
| 11 | Procedures not being Followed | Team member doesn’t follow the procedures set out in the SQAP and SPMP. | Process | 8 | 6 | 48 |
| 7 | Inconsistency between Design and Implementation | Due to various reasons, a developer is not able to or do not want to follow the design decisions outlined in the SADD and SDD. Instead, he go ahead and implement a different system based on his intuition, without notifying the rest of the team. | Implementation | 6 | 8 | 48 |
| 8 | Inconsistency in Coding Styles | The programmers do not follow common development practices and coding standards, resulting in incomprehensible and hard-to-maintain code. It also increase the probability of bugs. | Implementation | 6 | 7 | 42 |
| 2 | Errors in Design | Errors in design could arise in many different aspect of the design process. The design errors could occur in identification of sub-systems and modules, communication between the modules and integration of different modules. They may arise due to poor understanding of the requirements, poor design methodologies and ineffective communication between the design team members | Design | 5 | 8 | 40 |
| 4 | Inability to Find Minor Bugs | The software may contain minor bugs that may not be detected. The minor bugs are flaws in software that may cause small functions or features to fail. | Implementation | 8 | 5 | 40 |
| 16 | Team unavailability | The team members may be unavailable due to sickness or other commitments. | Team | 4 | 9 | 36 |
| 17 | Lack of experience with .NET | Not all of the members are familiar with the .NET platform or the languages involved. This will greatly slow down the implementation stage as team members need to initially learn to use the technology. | Implementation | 5 | 7 | 35 |
| 6 | Lack of Communication | The lack of communication can within the team in particular, in relation to the team members responsibilities and expectations, the status of the project. The lack of communication can also occur within sub-teams about the task allocations and progress of tasks. The sub-teams also may not communicate effectively. | Team | 5 | 6 | 30 |
| 14 | Misunderstanding requirements | A requirement of the software could be misunderstood during the requirement elicitation and specified incorrectly | 4 | 7 | 28 | |
| 5 | Broad Scope of the Project | The scope of the project may be too broad given the limited resources available to the team. This could arise because software has too many requirements or the scope of requirements is too large that require a lot of resources in designing, implementing and testing. Given our project is quite complex and it needs to be flexible, there is a potential the scope of the project could be too large. | Requirements | 4 | 7 | 28 |
| 13 | Poor management structure | Different management structures will lead to different results, a balance between overhead and process needs to be struck to make best use of all the resources to ensure a quality product. The risk is that the Team’s choice of a decentralised control management structure may not be the most suitable for this project. | Team | 3 | 9 | 27 |
| 1 | Inappropriate Architectural Design | The chosen architecture design may not be most appropriate one. If the architecture does not meet the needs of the system well, it will hinder not only the design process but also the implementation. Any poor choice of architecture could lead to poor sub-system identification, poor modular decomposition and integration. | Design | 2 | 10 | 20 |
| 15 | Client unavailability | he client may not be available for consultation with the team due to his work commitment or sickness. | Team | 2 | 7 | 14 |
| 12 | Team Conflict | Team members may not get along and frictions between member may occur throughout the project. | Team | 1 | 8 | 8 |
Risks
Inappropriate Architectural Design
Risk ID: 1
Risk Name: Inappropriate Architectural Design
Risk Description: The chosen architecture design may not be most appropriate one. If the architecture does not meet the needs of the system well, it will hinder not only the design process but also the implementation. Any poor choice of architecture could lead to poor sub-system identification, poor modular decomposition and integration.
Risk Category: Design
Description of Mitigation Plan: In order to mitigate occurrence of inappropriate architectural design, the design team would ensure that thorough requirement analysis is conducted and environment that the software will operate is understood.
The design team will also need to consider the implementation issues such as ease of development and design characteristics such as scalability. The design team should analyse many different architectures and choose the most appropriate that serves the needs of the software well.
Mitigation Plan Cost: 15-20
Description of Contingency Plan:If this risk occurs, the design leader should hold an emergency meeting with implementation team leader and project manager. If the meeting doesn’t provide any solution, then a meeting with the supervisor must be held.
The design leader must hold a workshop with the design meeting and re-design the architecture.
Cost of Contingency Plan: 50+
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 15/05/2006 | Design has established emergency design workshops to come up with appropriate design architecture. Workshops will run twice a week in order to speed up the design process. | Design architecture close to finalised and will report to the team during the next team meeting. |
Errors in Design
Risk ID: 2
Risk Name: Errors in Design
Risk Description: Errors in design could arise in many different aspect of the design process. The design errors could occur in identification of sub-systems and modules, communication between the modules and integration of different modules. They may arise due to poor understanding of the requirements, poor design methodologies and ineffective communication between the design team members
Risk Category: Design
Description of Mitigation Plan: The design team must conduct through analysis of requirements and must ensure all design team members clearly understand the requirements of the software. Design must research and choose an appropriate and structured design methodology to ensure the design team members have a structured approach to design. The design leader must ensure that all the members understand design concepts and use the architecture of the software effectively to have control over the design of different parts of the system.
Mitigation Plan Cost: 15-20
Description of Contingency Plan: When errors in design occur, the design team member must inform the design team leader. Design team leader must analyse the impact of the errors and identify the affected parts of the design and ensure the errors are corrected.
Cost of Contingency Plan: 50+
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 23/04/2006 | Software Architecture Design | Recommendations for improvement on SADD |
| 31/07/2006 | SDD Internal Review | Recommendations for improvement of SDD |
| 16/09/2006 | SDD Review by Supervisior | Recommendations for improvement on SDD |
Inability to Find Major Bugs
Risk ID: 3
Risk Name: Inability to Find Major Bugs
Risk Description: The software may contain major bugs that may not be detected. The major bugs are the flaws that causes important feature of the software to fail.
Risk Category: Testing
Description of Mitigation Plan: The testing will need to ensure that effective testing strategies are put in place that address the bugs that may arise in particular from building a module and integration of modules. Testing team will need to ensure that effective unit testing, integration testing and system testing are done throughout the testing phases.
Mitigation Plan Cost: 15-20
Description of Contingency Plan: If a major bug can't be found, the testing team leader must hold a meeting with the implementation team and work with them to detect the bug. The testing team may also need to revise its testing strategy.
Cost of Contingency Plan: 30-40
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 29/09/2006 | Started Unit testing | Uncovered bugs |
| 24/09/2006 | Set up Integration testing | Discover any integration issues and bugs |
| 24/09/2006 | Set up Regression testing | Regular testing |
| 05/10/2006 | Set up usability testing | To conduct usability test to uncover major issues |
Inability to Find Minor Bugs
Risk ID: 4
Risk Name: Inability to Find Minor Bugs
Risk Description: The software may contain minor bugs that may not be detected. The minor bugs are flaws in software that may cause small functions or features to fail.
Risk Category: Testing
Description of Mitigation Plan: As with finding major bugs, the team will need to effective testing strategies. The same mitigation plan as “Inability to Find Major Bugs” applies.
Mitigation Plan Cost: 10-14
Description of Contingency Plan: All the minor bugs or any sign of a minor bug will need to be documented in bug-tracking tool. If the level of minor bugs exceed acceptable as decided by the testing team, then the testing team should hold a meeting with the implementation team to investigate any implementation issues that cause the bugs.
Cost of Contingency Plan: 10-14
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 29/08/2006 | Set up unit testing and regression testng | Discovered many small bugs |
Broad Scope of the Project
Risk ID: 5
Risk Name: Broad Scope of the Project
Risk Description: The scope of the project may be too broad given the limited resources available to the team. This could arise because software has too many requirements or the scope of requirements is too large that require a lot of resources in designing, implementing and testing. Given our project is quite complex and it needs to be flexible, there is a potential the scope of the project could be too large.
Risk Category: Requirements
Description of Mitigation Plan: The requirements will need to be cost-end for the resources they require in all phases for the software development. Then the requirements team need to prioritise and select most important requirements so that they don’t require more than the available resources. Implement the software in number of builds so that the scope can be better understood and managed.
Mitigation Plan Cost: 6-9
Description of Contingency Plan: The project manager should hold a meeting with design, implementation and testing leader and the supervisor to look at ways of improving the efficiency of resources in order complete the project. If that it is not possible, then the requirements team leader must negotiate with the client to scale down the scope of the project. This may involve changing design and implementation.
Cost of Contingency Plan: 15-20
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Lack of Communication
Risk ID: 6
Risk Name: Lack of Communication
Risk Description: The lack of communication can within the team in particular, in relation to the team members responsibilities and expectations, the status of the project. The lack of communication can also occur within sub-teams about the task allocations and progress of tasks. The sub-teams also may not communicate effectively.
Risk Category: Team
Description of Mitigation Plan: The project manager must ensure that all team members are aware of their responsibilities as per SPMP and SQAP and must also regularly inform the team members of the progress of the project. Each sub-team leader must ensure that task allocations and responsibilities are effectively communicated and the task tracker is effectively used. Workshops or meetings between sub-team leaders must be regularly conducted so that each sub-team is aware of each together progress.
Mitigation Plan Cost: 6-9
Description of Contingency Plan: If there is evidence of lack of communication between sub-teams, the project manager must ensure that meetings between sub-teams are held. Sub-team leader must also take appropriate action to ensure that any misunderstanding or communication problems are resolved immediately.
Cost of Contingency Plan: 6-9
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Inconsistency between Design and Implementation
Risk ID: 7
Risk Name: Inconsistency between Design and Implementation
Risk Description:
Due to various reasons, a developer is not able to or do not want to follow the design decisions outlined in the SADD and SDD. Instead, he go ahead and implement a different system based on his intuition, without notifying the rest of the team.
Risk Category: Implementation
Description of Mitigation Plan:
The implementation manager must ensure that each team member that has been assign a particular programming task is completely clear about the system architecture, detailed design related to that task, and any dependencies involved.
If the team member disagrees on any of the design, any concern will have to be discussed with the implementation manager and the design manager immediately before diving into implementation.
If the team member does not feel capable of implementing for that particular part of the system, the implementation manager will have to assign the task to someone else in the team.
Constant code inspection needs to be organised to ensure any inconsistency will not propagate and turn into junk code or bugs later on.
Mitigation Plan Cost: 20-24
Description of Contingency Plan:
If any inconsistency of design and implementation is found during code inspection, the inspector must inform the implementation manager immediately.
The implementation manager is then responsible for organising a meeting with the coder and the design manager, to find out where the problem lies. The implementation manager is also responsible for assigning refactoring or reworking tasks to other team members.
Cost of Contingency Plan: 15-19
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 16/09/2006 | Design Manager to review the sdd and the code | Remove any inconsistency |
| 05/10/2006 | Desing Manager updated sdd | SDD became consistent with the implementation |
Inconsistency in Coding Styles
Risk ID: 8
Risk Name: Inconsistency in Coding Styles
Risk Description:
The programmers do not follow common development practices and coding standards, resulting in incomprehensible and hard-to-maintain code. It also increase the probability of bugs.
Risk Category: Implementation
Description of Mitigation Plan:
Before implementation phase begins, the implementation manager is responsible to produce an implementation practices and standards document, which clearly outlines all the essential aspects in implementation. The document has to be clearly understood by all the coders.
Mitigation Plan Cost: 20-24
Description of Contingency Plan:
If any violation of coding styles is found during code inspection, the inspector must inform the implementation manager immediately.
The implementation manager is then responsible for organising a meeting with the coder to stress on the importance of following common coding standards. The implementation manager is also responsible for assigning refactoring tasks to either this team member or other team members.
Cost of Contingency Plan: 10-14
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 7/08/2006 | Asked the implementation manager to set up and conduct code inspection | Ensured the regular inspection of code were done and the code conformed to our coding standards |
Missing Deadlines
Risk ID: 9
Risk Name: Missing Deadlines
Risk Description:
Missing deadlines could happen with any development activity in every phase of software development. There could be various reasons for this, including underestimating the minimum time a task requires, team member unavailability, and hardware failure.
Risk Category: Team
Description of Mitigation Plan:
Before assigning a task, the project manager or a sub-team manager needs to do proper assessment of the complexity of the task, employing software estimation methods where appropriate.
The team members that has been assigned the task needs to take up the responsibility to make sure the task will be finished on time. If he feels the task is not possible to be finished in the allocated time, he needs to raise the question to the manager before accepting the task.
Mitigation Plan Cost: 6-9
Description of Contingency Plan:
If a deadline is already missed or is to be missed inevitably, the manager needs to communicate this information with the project manager, to decide on an appropriate action to be taken.
If the task is on a critical path, the managers should consider devoting more resources to it in order to shorten the time delayed, as their first priority.
If the task is not on a critical path, the managers should consider helping the team members in tackling any problem he encountered, or allocate more time if deemed appropriate.
Cost of Contingency Plan: 10-14
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 25/06/2006 | Sent an email to PM explaining the issue and scheduled a meeting | Meeting to discuss the issue on 27/06/2006. Each sub-team had to produce micro plan and project plan to be updated on a weekly basis |
| 27/06/2006 | Discussed reasons for critical risk exposure for the risks and suggested that project plan needs to be updated and deadlines and microplanning needs to be done within sub-team levels | Updated Project Plan and deadlines are to be discussed in more detail in team meeting |
| 17/07/2006 | Informed the design of the tasks, completion of SDD in particular schema and class diagrams as well as internal review must be completed by 24th July | Sub-team allocated the tasks in order to finsih on time and conducted a longer workshop to review the design. |
| 31/07/2006 | Asked the sub-team, User Application and Toolkit to update the micro plan | Eric produced a great micro plan design and implementation for data layer |
| 31/07/2006 | Asked the PM to update the project plan to reflect the changes in microplan | More accurate project plan and project management |
| 07/08/2006 | Discussed the improvements to the management | Suggested that we send out weekly progress reports, which contains updates from the project plan and task tracker. The PMs or RM can send out the progress reports. We stick the implementation and testing microplans on the wall so team members can see their progress. The tasks in the microplans needs to be more details so everyone can understand the tasks from looking at it. |
| 14/08/2006 | Asked the PMs to produce weekly progress reports, update the project plan and microplans | Updated project plan and ensured the team members stuck to project plan |
| 05/10/2006 | Informed the team of potential slippage in video production, testing of toolkit and unit testing of user app | - |
Lack of Use of Task Tracking
Risk ID: 10
Risk Name: Lack of Use of Task Tracking
Risk Description:
Task tracking is a vital part of successful project management, but if this is not used then there is no auditable way to know what is happening in the project.
Risk Category: Process
Description of Mitigation Plan:
The project managers or sub-team managers will send reminders via email or in team meetings about specific requirements of using task tracking. The managers will also actively monitor the progress of any tasks currently under task tracking.
Mitigation Plan Cost: 15-19
Description of Contingency Plan:
If members persist on not tracking tasks, fines and penalties may be required to convince members of the need. The decision of any penalty will need to be decided in a team meeting, preferably with presence of the supervisor.
Cost of Contingency Plan: 6-9
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 07/08/2006 | Asked the team members in particular sub-team managers to break down the tasks into more details so PM and RM can better track the progress |
Procedures not being Followed
Risk ID: 11
Risk Name: Procedures not being Followed
Risk Description:
Team member doesn’t follow the procedures set out in the SQAP and SPMP.
Risk Category: Process
Description of Mitigation Plan:
The quality assurance manager and project managers need to ensure that all team members understand the required processes by asking them to read SQAP and SPMP, and explaining any questions regarding the processes.
Process audits will be held from time to time in order to verify and make sure that the team is following the required procedures.
Mitigation Plan Cost: 15-19
Description of Contingency Plan:
If members persist on not following procedures that has been set out, the project managers should find out the reason why the team member is not following the procedures and ask them to read the relevant section of SQAP or SPMP. If the team member feels the process is inefficient, the question can be raised in the next team meeting, and the team must consider the reasoning and alter the process by submitting a PIP if deemed necessary.
Cost of Contingency Plan: 10-14
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Team Conflict
Risk ID: 12
Risk Name: Team Conflict
Risk Description:
Team members may not get along and frictions between member may occur throughout the project.
Risk Category: Team
Description of Mitigation Plan:
Team members should communicate constantly on all work and non-work related issues regarding the project. This will enable early identification of any team conflict issues before it gets out of hand. Frequent communication will also work to reduce the likihood of misunderstanding between team members.
The team should encourage openness by more frequent communication via email or small work sessions. The team will also need to organise more social events to boost up team spirit and help team members to gain better understanding of each other.
Mitigation Plan Cost: 15-19
Description of Contingency Plan:
Any team conflict should be directed to the sub-team managers immediately for resolution. If the problem persists, or if the problem is more complicated, then the project managers should be made aware. The project managers, sub-team managers and affected team members should then organise a meeting to resolve the issue.
Cost of Contingency Plan: 6-9
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Poor management structure
Risk ID: 13
Risk Name: Poor management structure
Risk Description: Different management structures will lead to different results, a balance between overhead and process needs to be struck to make best use of all the resources to ensure a quality product. The risk is that the Team’s choice of a decentralised control management structure may not be the most suitable for this project.
Risk Category: Team
Description of Mitigation Plan: If problems develop with the management structure these will be raised at a Team meeting and changes noted in the SPMP.
Mitigation Plan Cost: 2-3
Description of Contingency Plan: If Team management duties has been completely neglected the Risk Manager, Project Managers and the Supervisor will have an emergency meeting to rectify the situation.
Cost of Contingency Plan: 15-20
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Misunderstanding requirements
Risk ID: 14
Risk Name: Misunderstanding requirements
Risk Description: A requirement of the software could be misunderstood during the requirement elicitation and specified incorrectly
Risk Category: Requirements
Description of Mitigation Plan: Each requirement will be analysed extensively, through internal reviews as well as during the design. The proof of concepts will be used to ensure that specified requirement is correct. All the specified requirements for the current implementation will be reviewed and understood by the client before the implementation. Software will be implemented in multiple builds to allow for frequent feedback from client.
Mitigation Plan Cost: 4-8
Description of Contingency Plan: If a requirement has been misunderstood before the SRS sign-off, then the requirements team will discuss possible changes with the client. If the requirement is found to be misunderstood after the implementation of each build, the requirements and design teams and the client will need to discuss possible changes in the next implementation to correct the misunderstanding. If it is discovered after the final release, nothing can be done about it.
Cost of Contingency Plan: 30-40
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Client unavailability
Risk ID: 15
Risk Name: Client unavailability
Risk Description: The client may not be available for consultation with the team due to his work commitment or sickness.
Risk Category: Requirements
Description of Mitigation Plan: Ensure that both Richard and Mark (employees of Risk Wizard) understands the requirements of the software and they can be contacted if assistance from the client is needed. This will require constant contact with the client through client meetings and email.
Mitigation Plan Cost: 1-3
Description of Contingency Plan: Contact either Mark or Richard of Risk Wizard if one or the other is unavailable. Contact the client through email or web-cam.
Cost of Contingency Plan: 3-4
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
Team unavailability
Risk ID: 16
Risk Name: Team unavailability
Risk Description: The team members may be unavailable due to sickness or other commitments.
Risk Category: Team
Description of Mitigation Plan: Team members should inform the PM of their availability in advance if possible and the PM will allocate the tasks to other members. The PM and subteam leaders should plan include slack in the project plan to take team unavailability into account. Have more than one team members work on a major task so team doesn’t rely on one member, thus delay the project.
Mitigation Plan Cost: 2-4
Description of Contingency Plan: The PM to reallocate the task to another team member if possible. Otherwise request the team member to provide more working hours once they become available.
Cost of Contingency Plan: 10-15
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 29/05/2006 | Risk Manager role has been moved to Shankar due to unavailability of Luke. | Shankar to take on responsibility to update the RMP and manage risks. |
| 02/07/2006 | Asked Tim to re-allocate the tasks to team members | Tasks were re-allocated and more team memembers started working on design. |
| 10/07/2006 | Luke is back and other team memembers are available to work | More human resources available |
Lack of experience with .NET
Risk ID: 17
Risk Name: Lack of experience with .NET
Risk Description: Not all of the members are familiar with the .NET platform or the languages involved. This will greatly slow down the implementation stage as team members need to initially learn to use the technology.
Risk Category: Implementation
Description of Mitigation Plan: Workshops and training tutorials may be required to educate members about the platform. These can be conducted by team members who are more knowledgeable about the platform. Team members can also conduct research into the technology to accelerate their learning.
Mitigation Plan Cost: 10-15
Description of Contingency Plan: If implementation has commenced and there are members who are still unfamiliar with the platform then rapid education is required. This will be in the form of intense study which will be based on books written on the subject. If possible, the team member should shadow more knowledgeable people to develop their skills.
Cost of Contingency Plan: 20-30
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 25/06/2006 | Sent an email to Eric to organise tutorials and workshop for team to learn .NET | Organised DVDs to be distributed |
| 02/07/2006 | Sent an email to Eric to find out the progress of learning | Team members have been reading the tutorials and more familiar with C# and ASP.NET |
| 10/07/2006 | Encouraged the team-members to learn C# and ASP.NET | No lab sessons were conducted as team members found self-learning more preferred option |
Failure to Integrate Different Layers and Modules
Risk ID: 18
Risk Name: Failure to Integrate Different Layers and Modules
Risk Description: Since the architecture is divided into three layers, with different sub-groups working on each layer, there is a possibility that these layers may not integrate seamlessly. There may be misunderstandings about the interfaces, preconditions and post-conditions of methods.
Risk Category: Implementation
Description of Mitigation Plan: Each sub-team must work together and define the interfaces of the methods and pre and post conditions of each method call.
Mitigation Plan Cost: 5
Description of Contingency Plan:
Cost of Contingency Plan: 15-19 If integration problems arise, then sub-teams must hold a meeting and ensure that interfaces of the methods and pre and post conditions of each method is properly defined. This may require re-factoring some of the code.
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 07/08/2006 | Asked the implementation to look into integration issues. Suggested a meeting be with all the sub-team implemenation leaders to talk about integration and to ensure everyone understand the interface | |
| 24/09/2006 | Set up Integration Testing Process | Conducting Integration testing on Toolkit and User Application |
Hardware Failure
Risk ID: 19
Risk Name: Hardware Failure
Risk Description: Hardware, in particular servers, computers and team members's personal computers and lap top may fail. This could result in loss of valuable information relating to project.
Risk Category: Team
Description of Mitigation Plan: Any team member working on their personal computer, must commit their work to the repository on a regular basis. All team must save and back up their work on a regular basis.
All the team work including wiki and repository must be backed up on a regulary basis.
Mitigation Plan Cost: 5
Description of Contingency Plan: If information is lost due to hardware failure, restore the work from back-up.
Cost of Contingency Plan: 15-19
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|
| 07/08/2006 | Eric lap-top failed | Restored the work on to his lap top from the repository |
| 12/10/2006 | Checked with Eric to see if back up of repository is being done | Ensure effective back up |
Inability to Maintain Configuration Management
Risk ID: 20
Risk Name: Inability to Maintain Configuration Management
Risk Description: If the different versions of working classes are not grouped or configured together, different component of the software will not integrate together well and function as a whole system.
Risk Category: Implementation
Description of Mitigation Plan: All the classes must be put under version control and must be configured into different versions so that software will integrate well.
Mitigation Plan Cost: 5
Description of Contingency Plan: If configuration breaks down, the version control must be assessed and configuration management process must be corrected
Cost of Contingency Plan: 15-19
History:
| DATE | ACTION TAKEN | OUTCOME |
|---|---|---|