HeaderSIS.jpg

IS480 Team wiki: 2013T2 GENShYFT Project Management risk

From IS480
Jump to navigation Jump to search

GENShYFT IS480 1314 Logo.jpg


Home   Project Overview   Project Management   Documentation   The Team


X-Factor   Risk   Schedule   Metric   Minutes


Risk Management Plan


The team uses the following approach to manage project risk.
GENShYFT is480 1314 risk.jpg


Risk Assessment


IS480 Genshyft 1314 Risk-Table.png
Level "A" risks need the maximum attention.
Level "B" risks needs reasonable amount of attention and planning.
Level "C" risks requires least amount of attention.

Project Risks

Risk & Mitigation Plan (From Acceptance)

This Risk Table Structure was inspired by ThunderBolt <br

Types of Risk Risk Description Likelihood Impact Level Mitigation
Project Management Risk

Delay in completion of task. These task can cause possible bottlenecks due to dependency requirements. This may affect the delivery of the product.

High

Medium

A

Includes buffer in every iterations in order to deal with such situation. Do a clearly defined critical path to ensure a clear understanding on the critical path. More time and effort should be given core components that affects the success rate of other components. Understand which task can be brought forward in the event other task cannot be completed without prior pre-requisite component.

Client may potentially have different ideas and suggestion along the way. This may translate into a scope creep , especially if the client were to venture into areas not discussed previously.

Medium

High

A

Change management Plan. Review each change request case by case.Discuss and interact with the client on the feasibility and priority of change. If a change is necessary, re-confirm priority of function with client again. A Change request may be rejected if the team is lacking resources such as time or man-power.

Technical Risk

Team is unfamiliar with the current technologies used such AngularJS and NodeJS. All of the core components requires the use of AngularJS to interact with Json. The client requires the deployment to be strictly on Google App Engine(GAE). It is unable to be run locally without the usage of NodeJs to create a simluated version of GAE locally.

High

High

A

Study these technologies off-hand to be more prepare when development portion began. Technologies must be well understood for implementation, hence the developers should explore the client's existing codes in order to utilize and re-usable codes. This also allows the developer to understand the current logic that was implemented.


High volumes of data is stored by the client. Potentially these data may not be sufficiently clean and suitable for analysis. Most data derived from database management systems is geared towards speedy performance and transaction and not for Business Analytics.

Medium

Medium

B

Create new database structure specifically for business analytic. This is to ensure that the current database can still be used for fast performance while the new database structure free for study. Additional time will be given to extract, load and transform data to the most appropriate forms.

The project is a continuation of several groups over the past year. Taking over the project from previous team may lead to complex integration. The coding style and flow of the logic is differs between different groups. The team has to work with multiple style and format, which may confuse or lower the chance of understanding the logic of the current algorithm.

Medium

Medium

B

During the exploration phase, the team can write comments base on what he/she has discover about a particular code. This helps those who have yet read that part to better follow the logic. Interaction with past FYP team gives us a better understanding on the existing system that requires upgrading.

Difficulty in integrating multiple systems together like GAE, database server and application since the team is not allowed to change it directly as client has placed restrictions in accessing his web servers. Team needs to pass the codes to the client so that he can test and check that it integrates seamlessly.

Low

High

B

Time will be taken to understand the limitation of the technologies used




Risk & Mitigation Plan (From Mid-Term)

This Risk Table Structure was inspired by ThunderBolt

Types of Risk Risk Description Likelihood Impact Level Mitigation
Project Management Risk

Team members might underestimate school commitments and conflicting priorities. This might affect the completion of deliverables and even the quality.

Medium

Medium

B

Team members will meet up and discuss to clarify if there are other commitments they need to adhere to. PM will revise the schedule by including sufficient buffer days during such "busy" periods.


Team might not be able to complete all the agreed upon features by final presentation.

Low

High

B

Team will liaise with client and make client understand clearly why there might be a potential drop in functions i.e. due to lack of time according to schedule

Technical Risk

During the official tournaments, a critical bug may be found like users might not be able to join a group tournament on SingPath.

Medium

High

A

Before the tournaments, the team will hold a mock tournament within SMU to source out critical bugs and solve them. This would be our 2nd UT.