IS480 Team wiki: 2013T2 OneRevolution ProjectManagement Metrics
|Home||About Us||Project Overview||Project Management||Project Documentation|
The schedule metrics is very useful for the project manager as she was able to keep track of the schedule progress and through this tracking she would be able to know if the team has confidence to complete this project in time. If there is always a delay seen in the metrics, it would show that the project manager had not planned enough time for each iteration and this would cause the team to be unable to complete all the functions if the delay continues and buffer time being used up. Hence the project manager should revise the schedule. Thus, this schedule metrics is very important to the team and the project manager.
The manhour metrics served similar purpose as the schedule metrics. It allows the project manager to track the man hours used by the team and ensure that the team is able to commit into the project and not being overly committed into the project too. There will be a total planned hours that the teams promises to commit at the beginning of each iteration. The team will then discuss about the hours needed for each task and completes his/her tasks. At the end of each iteration, the project manager will collate the actual hours and take the planned man hours / actual man hours * 100%. If the man hours efficiency hits 100%, it would mean that the team is very efficient and our team is trying to hit the 100% gauge. The project manager will then plot the man hour efficiency on the metrics . Thus this man hour metrics is very important to the team and project manager as it ensures that the time used for the tasks are on track and sufficient.
Version 1 of detailed bug metrics here!
Version 2 of detailed bug metrics here!
The bug metrics is very important to the team as it helps to keep track of the number of bugs happened in that iteration. It also helps to make sure that sufficient time is allocated to solve the bugs. For example, the peak in iteration 5 causes the team to be extended by one day to solve the critical bugs. If the allocation of extension is not done, it might affect the development of the next functions that the team intends to work on. The priority of the bug is important as this gives the developer a idea which bugs are more important and needs to be debug first.
Version 1 for Detailed Change Log!
Version 2 for Detailed Change Log!
In order to track the changes made in our project, our team use a change log to track for technical changes. And to justify if this change should be made, there are two main factors our team is concerned about.
The priority level is to measure the project value of the change. There are 3 priority levels. The lower the number, the more important it is.
1.Will bring significant value to the project
2.Will add value to our project
3.not add much value to project.
The impact to determine the amt of delay it may affect on the project schedule. There are 3 impact levels. The lower the number, the more impact it has on the project.
1.Strong, high possibility delay schedule.
2.Moderate, might delay schedule.
3.Low, will not delay schedule.
Below is the the decision table that our team will follow to decide if to implement the change.
Below are just some examples of our technical changes, for more technical changes please refer to our change log
|S/N||Change Description||Who Requested||Priority Level||Impact Level||Implement or Not implement||Hours needed||Affected Iteration||Status|
|1||For Product Management, allow users to choose multiple products for each scenario and a product for each lane. In the past, user is only allowed to choose a product per scenario which will be inconvenient for users in future as in reality, there are more than a product being transported in a scenario.||Team||1||1||Implement||12||8||Closed|
|2||For Consolidation of Markers, allow user to have an option to combine the markers to the existing marker (the location of the consolidated marker will be the location of the existing marker)||Team||1||2||Implement||5||8||Closed|
|3||For Ocean and Land Detection, when a marker drops into the sea, it should be auto-moved to the land.||Supervisor||2||2||Implement||6||8||Closed|
|4||Change to add in Search Bar for Scenario Management to allow users to be able to search desired scenarios by the scenario name.||Team||2||2||Implement||4||8||Closed|
|5||For the choosing of product for a lane, initially users are supposed to choose from scenario form and he/she is unable to change the product chosen for the scenario, now instead of choosing from the scenario form at the start, he/she is able to choose the product directly from lane)||Team||2||2||Implement||4||9||Closed|