IS480 Team wiki: 2012T2 Viaxeiros Project Management

From IS480
Revision as of 01:27, 11 April 2013 by Lin.siew.2010 (talk | contribs) ()
Jump to navigation Jump to search
Viaxerios Logov1.png
Welcome to Viaxeiros FYP Wiki Page
Navigation 4.png

Project At A Glance

Schedule Bugs

Current Iteration:
(26 MAR '13 - 08 APR '13)

Schedule Metric : N/A

Total tasks:
Tasks in progress:
Tasks Completed:

Current Bug Points: 09
Level 1 bugs: 0
Level 2 bugs: 2
Level 3 bugs: 0


Agile Unified Process

Adapted from the Rational Unified Process (RUP), Agile Unified Process (AUP) provides a simplified framework catering primarily for companies with an agile environment. Documentations are prepared to be "barely just good enough" to enable the flexibility required in an agile process.The process is broken down into 4 phases : Inception, Elaboration, Construction and Transition.

Our team models this framework heavily in our project management. Due to the agile environment our client currently has, it is necessary that our team is able to manage the fast pace working style our client has and match this project similar to their way.


In AUP, iterations tend to be small and many. In our team, each iterations spans for 3 weeks.

Change Request Log

Due to the agile process, changes to the requirements of the projects are rapid and regular. In this case, it is necessary to track and manage changes of the sponsors. Our team implements a change request log that tracks the changes sponsors wants to have. As a team, we will decide the importance of this change and hence change our schedule accordingly.

Change Request Log


As part of the request of the sponsor, the native application has to be deployed to Google PlayStore. However, the first deployment will take a much longer time than that of subsequent deployment as multiple testing. This concept is similar to the AUP.


MileStone - Final2 Scale800.png


Schedules are done and managed in Google Docs:

Schedule Breakdown


Schedule Metric [Current Iteration's Metric]

Each members are allocated with a few functions to complete. The schedule will then follow this metric:


This metric will be tied to an action plan as follows:

Schedule Metric AC.png

The following are the links for the previous iterations:

Bug Metric

Click here to view our bug tracking metrics.

To manage the quality of the work, a bug metric will be used with the following formula:

Viaxeiros Bug Metric.png

The bug metric will then follow this action plan:

Bug Metric AC.png

Work Stress Metric

Click here to view our work stress metric.

In order to make sure each members are able to cope with their current workload, each members have to fill in their stress percentage based on the following table:

Workload table.jpg This table will be gauged by the following action plan: Work Stress Metric.png

Risk Analysis

In order to manage the probable risk involved in the project, our group takes into account 2 variables: Impact and Likelihood. Based on the criteria mentioned below, the risk rate for each risk is accessed and a mitigation cum action plan is created.

Risk Metric AC.png


High - Chances of the occurrence happening is almost regular (very high)

Moderate - Chances of the occurrence happening is irregular (sometimes)

Low - Chances of the occurrence happening is seldom (very little)


High - The occurrence has a very great detrimental effect on project

Moderate - The occurrence has a significant effect on the project

Low - The occurrence has a limited effect on the project

S/N Risk Description Consequences Impact Likelihood Risk Rate Mitigation Strategy / Contingency Plan Status
1 Technical Risk
1.1 Team is unfamiliar with the technology used
  1. There might be a delay in project schedule
  2. longer time needed to create functions
High High A
  1. Team members are to start researching and trying the technology in advance before the iteration
  2. Share research documents and knowledge among members
Risk Strategy in place - Implemented
1.2 Conflict / issues during configuration and setup
  1. Delay in the project schedule
Moderate Moderate B
  1. All setup for the project should be done early
Risk Strategy in place - Implemented
1.3 Unfamiliar codes / API given by the company
  1. Longer time needed to implement functions
High High A
  1. Request for a detailed documentation of the API used from the company
  2. Ask the company directly and clarify the usage of the API
Risk Strategy in place - Implemented

Set up a private googledoc collaboration for API documentation between Qiito Developers and Viaxeiros

2 Development Risk
2.1 Critical bug found during development
  1. Development of project will be stalled
High Moderate A
  1. Coders should consult the entire group about it to discuss for solutions
Risk Strategy in place - Implemented
3 Client / Sponsor Risk
3.1 Additional requirements requested during implementation of codes
  1. Might not be able to finish requirements on time
  2. substandard work produced
High Moderate A
  1. Team members should discuss and decide if they can commit to the additional workload on time. If not, firmly reject the additional requirements/ol>
Risk Strategy in place - Implemented
3.2 Clients are uncertain what they want in the application
  1. Redundant functions done
  2. Delay and changes in schedule
Moderate High A
  1. Design a few prototypes for the company to view. Perhaps this might help the company to see what they want
Risk Strategy in place - Implemented
3.3 Frequent changes in requirements
  1. Frequent changes in schedule
High High A
  1. Team members should discuss and decide if they can commit to the changes needed on time. If not, firmly reject the changing requirements
  2. The schedule for the team has to be very flexible to take into account the frequent changes in requirements from the client.
Risk Strategy in place - Implemented
4 Team Risk
4.1 Team members may not be free during the critical period
  1. Delay in the project schedule
High Moderate A
  1. Push more work to be done before the the period where members are not free.
  2. Make sure the work intended for the missing member is fully covered.
  3. alter the schedule to fit the manpower available
Risk Strategy in place - Implemented
4.2 Team members may have conflicts with each other during the project
  1. Delay in the project schedule
  2. Quality of work will deteriorate
Moderate Moderate B
  1. Project manager has to step in to be the mediator. Discuss the issue and work to solve the problems before continuing on the work
Not Implemented Yet
5 Project Management Risk
5.1 Over-estimate the days needed to build function
  1. Delay in the project schedule
Moderate High A
  1. Project manager to take note of the schedule and plan the future schedules more carefully
  2. Provide a longer time period for the next iteration to complete the functions.
Risk Strategy in place - Implemented