IS480 Team wiki: 2012T1 6P Project Management

From IS480
Jump to navigation Jump to search
6pcube.png Home   6pProject overviewicon.pngProject Overview   6pProject managementIcon.png Project Management   Project Docs.png Project Documentation   6pMeeting minutesIcon.png Meeting Minutes   6PGralch.png Game Development

Project Management

Project Schedule

6P ProjectPlanTimelineNew1.png


Detailed Project Schedule (pdf)

Project Plan Strategy

We have decided to release our mobile game application 2 weeks earlier into Android Play Store on 21 September 2012. The rationale for doing so is that we want to increase our pool of user testers. From there on, we will be gathering, evaluating the Play Store's comments and make necessary refinement to our game. We have also planned to release a update after every iteration (fortnightly). The update will contains additional stages and previous game levels refinements.

Details on changes in project plan (as of mid term presentation) can be found here.

Planned vs Actual (Mid term presentation)

Screen Shot 2012-11-27 at 9.21.42 PM.png

Delay #1: Initiation and prototyping

Task delayed: Implementation of swinging vine and Gralch aiming controls in functional prototype.
Reason: The task was more complicated than what we had expected. It was a challenge to mimic the swinging action of the vine in Unity3D and we have to seek help and advises from Unity3D forum.

Delay #2: Iteration 3

Task delayed: Flash prototype feedbacks gathering
Reason: The feedback gathering took longer than expected because Larry and Wilson was occupied with internship commitments.

Delay #3: Iteration 4

Task delayed: Launch of App to Google Play Store
Reason: There was some issues with the Google Play payment gateway. Thus, payment could not be made to complete Google Play Store developer registration for several days.

Delay #4: Iteration 5

Task inserted: Game optimization - to reduce APK file size and reduce the number of visible object count in a frame.
Task pushed back: Building of stage 4 was shifted to iteration 6
Reason: Team feels that game game optimization is needed because we have to meet Google Play store requirement of less than 50Mb APK file size. We also need to reduce the visible object count because the game lags a lot on Samsung Galaxy SII.

Plan Project Schedule

Planned vs Actual (Final presentation)

6p planned vs actual.png

There hasn't been any delay or insertion of new task after mid term presentation.

Planned vs Actual (Summary)

* denotes that there are changes.
Conceptual, Pre production and Production phase 1
Screen Shot 2012-11-27 at 9.37.52 PM.png

Production phase 2 and phase 3 Screen Shot 2012-11-27 at 9.38.55 PM.png

Project Risk

Types of Risk Risk Likelihood of Occurrence Impact Mitigation Strategy/Contingency Plan
Project Management Risk

The team may not know what is best for us as this is the first time we are developing a mobile game.



Seek advices from industry professionals and faculty. Plan for more iterations to allow more time for trial and error to ensure that our game is really fun.

We are not able to produce an engaging fun game (based on the majority of user feedback, >80%)



A standard game level template in Unity3D is in place to allow for more internal level design testing before the conduct of user test. More project iterations would be carried out to include additional rounds of refinement and user testing.

Mentor risk - We were assigned mentors following the mid-term presentations, Inzen Studios. Being industry experts, their feedback on our game development approach and game could pose a risk to our project plans.



Work with their feedback and prioritize its importance based on the remaining iterations left for our FYP

Technology Risk

Working with new technology and tools.



Ensure that sufficient time is allocated in the project plan for familiarization and self-learning of new tools.   Before adopting the use of new software/tool, we carry out an evaluation, to analyze, research on the pros and cons of the software/tool.

The integration of all different levels may result in a delay in project schedule



Allocate more time in integrating all the different level design. Members working on setting up different level design have to export the scenes using the Unity3D export package function instead of copying the folders out.

Contingency plan: Re - do all the level design on one person's computer.

Testing Risk

There may not be sufficient feedbacks from Play Store and online sources.



Ensure that sufficient efforts is spent on online marketing (website SEO, Google Adwords campaign) to ensure that the masses know the existence of our app.

As we build our game using Unity3D, we will also post our link to download the app on Unity3D forum and the community will provide us additional sources of feedbacks via the forum.

Contingency plan: Should we do not received more than 20 feedbacks per update release, we will base our gameplay refinement on our user testing.

The lack of Android devices



Plan for earlier launch of app into the Google Play store so that we can get more feedbacks, analyze it and use it to refine our gameplay.

Contingency plan: Borrow android devices from friends for debugging and testing purposes.

Schedule Metrics

Schedule metrics overview
Schedule metrics overview (Mid Term presentation)
Schedule metrics overview (Final presentation)

Individual Efficiency coefficient metric

Goal: To ensure that each team member’s skills are utilized which leads to greater team productivity. This in turns leads to complementing the project planning and task completion rate.

Frequency of measurement: At the end of every iteration/phase

Formula of individual productivity coefficient:
• Individual EC = Actual duration of allocated task/ planned allocated duration of each task to each member.

• Average Individual AEC = Sum of EC of each team member / number of tasks allocated

Average Individual Efficiency Coefficient (AEC) Score Observation Action Plan

AEC < 1

Very efficient and finishes tasks slightly ahead of time.

Start next task earlier or PM to allocate lesser hours for subsequent tasks.

AEC = 1

Task duration planning is accurate.

None required. Team member is efficient in completing his/her task on time.

1 < AEC ≤ 2

Team member is a slightly behind estimated schedule.

Acceptable. An additional 12 hours are given to the member to finish up the task.

2 < AEC

Team member is far too behind schedule or PM has estimated too short duration for the allocated tasks.

Bad. The team member had exceeded the planned duration for more than 35%. The project manager will either assign another teammate to assist in finishing the task or to arrange for an ad-hoc meeting to solve the problem.

Team Efficiency coefficient metric

Goal: To keep track of the overall team performance in each iteration/phase.

Frequencey of measurement: At the end of every iteration/phase

Formula of team productivity coefficient: EC (Team) = Actual duration taken by the team/ Planned duration of an iteration

Team Efficiency Coefficient (EC) Score Observation Action Plan

EC < 1

Slightly ahead of schedule.

The team is efficient. Can start next task earlier.

EC = 1

Task duration planning is accurate.

All tasks are completed on the stipulated date. The team is on track.

1 < EC ≤ 2

Team is slight behind estimated schedule.

Acceptable. The team need to double up and work overtime.

2 < EC

Team is far too behind schedule or PM has estimated too short duration for most of the tasks

Bad. The project manager will have to reshuffle manpower or to readjust the project schedule.

Detailed Schedule metric
Schedule metrics

Bug Metrics

Schedule metrics overview
Bug metrics overview (Mid Term presentation)
Bug metrics overview (Final presentation)

Bug Severity Index

Goal: To keep track bug occurrence in each iteration/phase.

Objective: No bug should be unfixed during the development phase. Bug detected should be resolved the moment it has been detected. By doing so, it will help to improve software quality.

Frequencey of measurement: At the end of every iteration/phase

Bug Severity Index (BSI) Total = 1 x num (low) + 5 x num (high) + 10 x num (critical)

Severity Description

Low Impact (1 points)

Occurs due to typo error or minor code errors with the game play logic.

High Impact (5 points)

The mobile game application runs. However, some functionality is not functioning as expected.

Critical Impact(10 points)

The mobile game application cannot be launched or crashes whenever being launched. We will need to fix all the bugs before continuing with development work.

Action plan

BSI Action

Points =< 5

Fix during development time only.

5 < Points< 10

PM to assign other team mates to help out in debugging.


Halt the current development immediately. Project manager will need to reschedule the project. An emergency meeting with the team will be called by Project Manager to draft out a remedy plan to debug the application or to find a workaround solution.

The whole team will be split into pairs to focus on remedy each bug. Should after 24 hours, the bug still cannot be resolved; the team will have to redesign the game level/artificial logic to suit the team coding capability.

Detailed Bug Metric
Bug Metrics