The address of this document is: http://www.perceptek.com.au/kteam/docs/rmmm.html
|
|
Risk Mitigation, Monitoring, and Management |
The MultiMahjong ProjectTeam |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
1. Joanna Araminta 2. Victor Leung 3. Joel Brakey 4. Michael Hart 5. Dean Cortinovis 6. Long Tang |
(Project Manager and Risk Manager) |
This document describes the risks that may be encountered in designing and managing the MultiMahjong Project, and the process that Team will follow to avoid them.
Joanna Araminta (jiar)
$Revision: 1.11 $
$Date: 1999/10/25 00:42:16 $
1.1 Overview
of Major Risks
1.2
Responsibilities
2.1
Description of risks
2.1.1
Lack of training on Java
2.1.2
Unrealistic delivery deadlines where slippage may occur
2.1.3
Staff inexperienced with the Software Development Process
2.1.4
Staff knowledge on networking concept may be low
2.1.5
Lack of experience in Project Planning
2.1.6
Size estimate may be significantly low
2.1.7
Lack of availability of tools on University's Computing System
2.1.8
Lack of availability of tools on MAC
2.1.9
Quality of product documentation and coding that must be produced may be
low
2.1.10
Requirements demand a good knowledge on Artificial Intelligence
2.1.11
Software may not be easily tested
2.1.12
Log messages on modifications done on coding and documentation may not be
well
controlled
2.1.13
Unavailability of team members
2.1.14
There may be conflicts between team members
2.1.15
Reviews may not be conducted regularly
2.1.16
Customer may change the Project's requirements
2.1.17
System may be down
2.1.18
Lack of experience working with a customer
3.1
Lack of training on Java
3.2
Unrealistic delivery deadlines where slippage may occur
3.3
Staff inexperienced with the Software Development Process
3.4
Staff knowledge on networking concept may be low
3.5
Lack of experience in Project Planning
3.6
Size estimate may be significantly low
3.7
Lack of availability of tools on University's Computing System
3.8
Lack of availability of tools on MAC
3.9
Quality of product documentation and coding that must be produced may be low
3.10
Requirements demand a good knowledge on Artificial Intelligence
3.11
Software may not be easily tested
3.12
Log messages on modifications done on coding and documentation may not
be well
controlled
3.13
Unavailability of team members
3.14
There may be conflicts between team members
3.15
Reviews may not be conducted regularly
3.16
Customer may change the Project's requirements
3.17
System may be down
3.18
Lack of experience working with a customer
4.1
Lack of training on Java
4.2
Staff knowledge on networking concept may be low
4.3
Staff inexperienced with the Software Development Process
4.4
Unrealistic delivery deadlines where slippages may occur
4.5
The size estimate of the 433-341 Project may be significantly low
4.6
Client may not be as enthusiastic about the Project as the team is
4.7
Size estimate may be significantly low
This document describes the risks that Team may encounter while designing and managing the MultiMahjong Project, and the strategies and actions that K-Team will conduct to mitigate these risks.
This document will be mainly used by the Project Manager, as part of the overall Project Plan, in monitoring the project. Risk monitoring consists of three objectives:
The MultiMahjong Project is a complex project, in the sense that it is intensely difficult, if not impossible, for the individual developer to comprehend all the subtleties of its design. It is also a new project, where there is no existing system.
A complex project such as this involves a lot of different type of risks. These risks will be described in the Project Risk Table as described in Section 2.
The client for this project is:
Steve Goschnick, Managing
Director
Solid Software Pty Ltd
Level 3, Bouverie Street,
Carlton VIC, 3053
Ph: 03 9344 9322, 03 9344 0154
E-Mail: gosh@solidsoftware.com.au,
gosh@cs.mu.oz.au
Our team for the project is called Team and consists of:
|
Joanna Araminta (jiar) |
Ph: 9889 4423 |
The supervisor for the project is:
|
Anthony Senyard (anthls) |
Ph (W): 9344 1940 |
A Risk Manager will be appointed by the Project Manager to monitor all possible risks associated with the Project, which are listed in the Project Risk Table (see RMMM Section 2)
Once a risk has occurred, the Risk Manager should follow the mitigation strategy as planned (see RMMM section 3). The Risk Manager should also inform the other team members of the consequences of the problems associated with the risk. The Risk Manager should continue to monitor other risks while trying to minimize the consequences of the occurred one.
The Risk Manager for Team is:
|
Joanna Araminta (jiar) |
Ph (H): 9889 4423 |
|
No. |
Risks |
Category |
Probability |
Impact |
RMMM |
|
1 |
Lack of training on Java |
DE |
90% |
2 |
|
|
2 |
Unrealistic delivery deadlines where slippage may occur |
BU |
85% |
1 |
|
|
3 |
Staff inexperienced with the Software Development Process |
ST |
80% |
1 |
|
|
4 |
Staff knowledge on networking concept may be low |
TE |
80% |
2 |
|
|
5 |
Lack of experience in Project Planning |
PR |
75% |
2 |
|
|
6 |
Size estimate may be significantly low |
PS |
70% |
2 |
|
|
7 |
Lack of availability of tools on University's Computing System |
TE |
60% |
2 |
|
|
8 |
Lack of availability of tools on MAC |
TE |
60% |
3 |
|
|
9 |
Quality of product documentation and coding that must be produced may be low |
BU |
60% |
3 |
|
|
10 |
Requirements demand a good knowledge on Artificial Intelligence |
TE |
60% |
4 |
|
|
11 |
Software may not be easily tested |
PR |
50% |
2 |
|
|
12 |
Log messages on modifications done on coding and documentation may not be well controlled |
PR |
50% |
2 |
|
|
13 |
Unavailability of team members |
BU |
50% |
2 |
|
|
14 |
There may be conflicts between team members |
BU |
40% |
3 |
|
|
15 |
Reviews may not be conducted regularly |
PR |
15% |
3 |
|
|
16 |
Customer may change the project's requirements |
PS |
10% |
1 |
|
|
17 |
System may be down |
TE |
10% |
3 |
|
|
18 |
Lack of experience working with a customer |
CU |
5% |
4 |
Table 1 - Project Risk Table
It is anticipated that the program is to be implemented using Java 2 (SQAP section 9.2). While the development team is quite familiar with C++, which is also an object oriented programming language, the team has a very little direct experience with Java. This can be quite a risk as there could be major slippages that occur because of this risk.
The Project Plan (SQAP section 3.2) includes a set of deadlines established in the initial stages of the project. While every effort should be made to ensure that we conform to these deadlines, we acknowledge that, during the course of the Project, the Project Plan may have to be modified to account for any unforeseen delays. As such, it is necessary to define procedures for handling these changes.
Any delays in the Project Plan will be classified as either a minor or major slippage.
A minor slippage occurs when:
A major slippage occurs when:
This is K-Team's first Software Development Project, so every process is still very new to the team, even though the team had been taught what it's all about. Some slippage may occur because of this, as the team will have to do a lot of research for any uncertainties found during the Project's life cycle.
This project is to be written in a client server manner. The development team has a limited knowledge on how to write a client server application. This can cause some slippage, probably major ones, during the Project's life cycle.
The development team has never been involved in developing a piece of software. Thus the team has very little experience with Project Planning and the tools used in planning a Project. The team might also find difficulties in estimating the amount of time needed to complete each processes, in order to produce a satisfiable piece of software.
Since this is the first time for the development team to work with a big project such as the MultiMahjong Project, the team's estimation on lines of code (LOC) may be inaccurate. Even if the estimation may be quite accurate, the degree of confidence that the development team will have in the estimated size will be fairly low.
The programming language, which the development team has to use in order to build the software, is Java 2 (SQAP section 9.2). This is the latest version of Java that includes the new SWING library, which the development team will use to build the user interface of the software. This version will not be available on the University's Computing System until Semester 2, which starts at the end of July. This could cause some slippage in the Project's life cycle if the development team needs to implement some prototypes of the system at an earlier stage of the Project's life cycle than expected. The development team will need to store and compile these prototypes in the University's Computing System so that all team members have access to them.
The programming language, which the development team has to use in order to build the software, is Java 2 (SQAP section 9.2). Java 2 version at the moment is only available for Windows and UNIX platform. Unfortunately, not every member of K-Team is using Windows or UNIX. There are two members of K-Team who are using MacOS, and the latest Java version for Mac at the moment is Java 1.1.8, which doesn't include Swing. However, this may not be a big risk as Swing plug-in is available.
The development team has never produced any software documentation and coding in a professionally manner. The team is also unfamiliar with the standards of what good quality documentation and coding is supposed to be. Thus the degree of confidence in writing good quality documents needed in a Software Development Process, and coding is fairly low.
It is anticipated that the behaviour of the Artificial Intelligence featured in the program would be of vital importance. The development team has almost no experience with Artificial Intelligence programming. This could affect the quality of the final product.
With the unfamiliarity of the implementation language and working on a bigger scale projects, testing the final product may not be as easy as it seems. It is very hard to make sure that every possible situation where the software may ended up at, have been tested. There are probably errors such that the development team may not know why it happened.
Considering also the time given to do the Project, it may not be possible to carry all the tests that the development team will describe in the Test Plans (see TP section 2 - section 5).
The development team has never been working in a team project using CVS as the version control of all documents involved in the Project. Thus the log messages on modifications done on documentation and coding may not be done carefully.
The development team members have different timetables and most of them also have part time jobs. This makes it a bit hard to locate meeting times that suit everyone.
The team members of the development team have never been working together as a team. Because of this, there may be some conflicts that will happen among team members.
Since the development team is very new to the Software Development process, the team may not realize the importance of reviews. Therefore, reviews within the Project's life cycle may not be conducted regularly. Reviews may not have to be done weekly, however one or more reviews are always required when a document is finished to ensure the quality of the document.
Most customers don't really know what they want as the requirements for the software, thus they may want to change the Project's requirements at unacceptable times. This could be early or very late in the Project's life cycle. If this happen, it will affect the whole Project Planning, which may cause major slippage.
Machines are not prefect either. The whole computer system may be down at unpredictable times. Depending on the length of time where the system may be down, it can affect the Project Plan and can case some major slippage.
The development team has never develop a software for a customer. Thus the development team may be lack of customer interaction skills. This could cause some misunderstanding between the development team and the customer, since both the customers and the development team may not know what is expected. Also, the development team may not successfully create a good relationship with the client, thus a regular communication between the client and the development team could never be achieved.
In mitigating the lack of training on Java, the research team must develop a research plan, which should show milestones when they will conduct the learning and research of the new language. Among the possible solutions to this problem are:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take these actions:
In mitigating the slippage that may occur:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take these actions:
In mitigating this risk, the development team must have considered these plans:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take these actions:
In mitigating this risk, the development team must have a research plan, which shows all the milestones when the team does some research on the issue. Among the possible solutions to this problem are:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
The Project Manager manages the Project Plan. In mitigating the risk associated with the Project Plan, the Project Manager must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, the Project manager is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
Not every member of the development team is using PC to do the Project, some use Mac. We all know that not all software tools that are available for PC are also available for Mac. Therefore, in mitigating this risk, those members who are using Mac to do the project must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, the team members who are affected, are required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the Project Manager must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, the Project Manager is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the Project Manager must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, the Project Manager is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
In mitigating this risk, the development team must:
In monitoring the activities of the project, the following issues will be monitored:
Risk management takes into account when the risk has occurred. When this happens, K-Team is required to take the following actions:
This is the very first time K-Team is working with Java. Thus the knowledge on the language is very limited. K-Team was aware that this is one of the most critical risks that the team will face in completing the Project, thus K-Team has prepared the Mitigation, Monitoring and Management Plan (see section 3.1) that the team will follow in order to avoid the risk from happening and how the team will manage the risk if it does occur. This plan has been thought of and discussed during team meetings carefully.
K-Team has been following the contingency plan as described above in section 3.1. K-Team started doing some research on Java 2 as early as April. Prototyping could not be done as early as the team planned since Java 2 wasn't installed in the University's Computing System until the Semester break, which is around June-July.
While prototyping, the Risk Manager started to monitor the team's activity to find out whether this particular risk has occurred or not. To do this, the Risk Manager followed the monitoring plan of the risk, which was planned earlier (see section 3.1).
When the risk does occur, Risk Management plan takes into account. K-Team's Risk Management Plan for the 'lack of training on Java' risk was for the team to acquire help from Java masters (i.e.. the Client) or University lecturers. K-Team followed the management plan by arranging Java workshops with the Client, sometimes in June.
K-Team found that it wasn't enough to manage the risk just by seeking help from the Client or University lecturers about the language. Therefore, K-Team decided to assigned three dedicated team members (Victor Leung, Dean Cortinovis and Long Tang) to be the technical researchers (Java Masters), while the rest of the team focused on other things such as the Software Development Process and documentation. The technical researchers would then keep the rest of the team updated about the language during general team meetings.
Overall this risk has been managed very well and carefully by the K-Team.
This is the first time K-Team is working on developing a Client/Server application. Thus, K-Team realised that this would be one of the main risks that K-Team may encounter while completing the Project. The Mitigation, Monitoring and Management Plan for this risk are described in section 3.4.
K-Team followed the Mitigation Plan in order to avoid the risk from happening. K-Team did the research on Java networking as early as possible. K-Team realised that this risk has occurred when the team failed to create the Server prototype on the due date.
Risk Management plan takes into account when the risk has occurred. K-Team decided to assigned a team member to focus on the Server, while the other team members will focus on the other part of the coding and documentation, in order to avoid further slippages. This approved to be working quite well, even though some more minor slippages occur along the way cause by other risks encountered.
This is K-Team's very first Software project, thus the whole Software Development Process that K-Team has to follow are still new to the team. K-Team realised very early in the Project's life cycle that this could be one of the risks that K-Team may encounter while completing the Project. Therefore, K-Team was prepared with the Mitigation, Monitoring and Management Plan for this risk (see section 3.3).
While avoiding this risk, K-Team followed the Mitigation plan as described in section 3.3. The Project Manager ensured that every member of the team knows what are involve in the Software Development Process. The Project Manager also seeks guidelines of what a good Software Development Process is from the team's Supervisor during meetings with the Supervisor.
At the start of the Project, K-Team failed to follow all the process described in the team's Software Quality Assurance Plan (SQAP), since K-Team wasn't really aware of what each process is for.
K-Team realised that this risk has occurred just before the Semester 1 break. The Project Manager then arranged a SQAP internal review meeting as soon as possible, to ensure that every team member has read and understand the document. Ever since the internal review each team member always reminded each other when K-Team hasn't been following the process described the SQAP.
Project Planning was another main issue that K-Team has never worked with before. Thus at the start of the Project's life cycle, Project Planning wasn't very successful. K-Team kept being confronted by unrealistic deadlines that caused slippages.
K-Team was quite aware of this risk, and has planned the risk's Mitigation, Monitoring and Management Plan (see section 3.2).
In avoiding the risk from occurring, K-Team ensured that all the milestones in the Project Plan are well discussed in the team meeting and that the Project Manager should discuss the Project Plan with the Supervisor on each Supervisor's meeting.
K-Team had some major slippages that occurred while completing the Project. While managing the risk, K-Team followed the Management plan, as described in section 3.2. The Project Manager ensured that the Project Plan is being re-schedule to account for any unforeseen delays, and that, when necessary, re-allocation of tasks is done.
In Semester 1, five out of six members of K-Team had to do 433-341 Software Engineering Process and Practice. K-Team wasn't aware that the Project given for the subject would be quite big, especially for a 30% worth of Project. The Project was on GNU_Make, and it was set out similar to the MultiMahjong Project. There were three deadlines:
Project Plan and SRS 23
April 1999
Design and Test Plan 7 May 1999
Code and Test Report 21 May 1999
GNU_Make is a huge program, and the Project goal was to fix a subtle defect in the GNU_Make package. This required the Project's team to at least understand some of the coding, and this required a lot of time. Thus it became one of K-Team's critical risks.
This risk is not described in the K-Team's Project Risk Table, as K-Team wasn't aware of the presence of the risk. Thus, K-Team doesn't have any Risk Mitigation, Monitoring and Management plan for the risk.
In monitoring this risk, K-Team ensured that the deadlines of both projects are met, and that both projects were up-to-date.
Since the vast majority of K-Team was involved in the GNU_Make Project, while managing this risk, K-Team had to divide the Team into two. K-Team ensured that one team focused on one Project at the time, to ensure that major slippages would not occur on both projects.
K-Team is very enthusiastic about the Project from the very start the project was assigned to K-Team. K-Team thought that the Client would be too, however this doesn't seem to be the case.
K-Team tries the best to maintain a good communication with the Client. However, the Client seems to make promises to K-Team, but never been satisfied. For example, the Client promised that the team will be given the graphics of the Mahjong tiles as soon as possible. This is quite critical since the team needs this graphics in order to complete the GUI. This still hasn't been done until now, and that K-Team has to provide the graphics in order to complete the project. K-Team wasn't prepared for this and thus it created some slippages along the project's life cycle.
K-Team wasn't aware of this risk at all, thus K-Team doesn't have the Mitigation, Monitoring and Management plan for this risk.
In monitoring the risk, K-Team tries to ensure that the Client delivers all the promised goods by the due dates that are usually arranged during the team meetings with the Client.
While managing this risk, the Project Manager
would discuss about the matter with the Supervisor, while the Client Liaison
Officer would try to keep hassling the Client for all the things that the
Client has promised to provide to the Team. Where possible, K-Team would
decide to get all the promised things themselves (such as graphics), instead
of waiting and waiting. This risk management has been proven to be
working very well, since if the team just keeps on waiting for the Client's
promised things, K-Team would not be able to be at the stage where the
Project is at the moment. K-Team would not even be able to get half of
the final product done.
Since this is the very first time K-Team developed a full software, K-Team didn't really know the scope of the project. K-Team was quite aware of this risk, and decided that this could be a critical risk, since if it does happen and the team doesn't have any Risk Management plan, it may cause major slippages. Thus K-Team came up with the Mitigation, Monitoring and Management plan, as described in section 3.6.
In order to avoid this risk from happening, K-Team decided to start prototyping at the very early stage of the Project's life cycle, as planned. After doing a lot of research on Java and did some prototyping, just to get the feel of how Java works, K-Team realised that the team would not be able to meet all the requirements that the Client specified.
While managing this risk, the Project Manager ensure that this issue is discussed with the Supervisor during the Project Manager meeting with the Supervisor, and also that the Client is informed if the situation. The next step that K-Team did was to rewrote the team's Software Requirements Specifications (SRS) before the sign-off. K-Team managed to cut down some of the Project's requirements, such as getting rid of the applet, and K-Team decided to change the layout of the SRS so that it now shows the requirements being divided into three levels. Level 1 is for all the essential requirements, level 2 consists of all the highly desirable requirements and level 3 for all the desirable requirements (see SRS section 4).
The Client agreed with the changes and that K-Team would only need to satisfy all the level 1 requirements.