IS480 Team wiki: 2012T2 box.us Project Management
HOME | OVERVIEW | PROJECT MANAGEMENT | DOCUMENTATION |
Contents
Team Charter
Schedule & Milestones
Project Milestones
Project Gantt Chart(For Empact)
Project Schedule
- Project Schedule on Google Docs
- Project Schedule Version 3.1
- Project Schedule Version 3
- Project Schedule Version 2
- Project Schedule Version 1
Iteration Reports
The iteration reports covers the bug ratios and schedule ratios for each iteration.
- Iteration 0 Schedule Ratio: Iteration Report
- Iteration 1 Schedule Ratio: Iteration Report
- Iteration 2 Schedule Ratio: Iteration Report
- Iteration 3 Schedule Ratio(Acceptance): Iteration Report @ Acceptance
- Iteration 4 Schedule Ratio: Iteration Report
- Iteration 5 Schedule Ratio: Iteration Report
- Iteration 6 Schedule Ratio: Iteration Report
- Iteration 7 Schedule Ratio: Iteration Report
- Iteration 8 Schedule Ratio: Iteration Report
Metrics
SCHEDULE METRICS OBJECTIVE
- To ensure that all project tasks are completed on time and milestones are met.
CALCULATION:
Schedule Ratio = Actual Duration / Planned Duration |
---|
Schedule Ratio | Description | Response |
---|---|---|
< 0.8 | Team is ahead of schedule | Proceed to embark on the next task if possible |
0.8 - 1.2 | Within healthy schedule range | No actions required for ratio below 1. Keep close monitor on tasks that have a ratio of more than one. Project Manager to review schedule to see which tasks have gone over time. If necessary, review time estimations for tasks in the next iteration. |
> 1.2 | Team is behind schedule | Team is behind schedule. Project Manager identifies root cause of the delay. Project Manager would increase the velocity of the team in the upcoming iteration to complete the tasks on time. |
BUG METRICS
OBJECTIVE
- To minimize the number of bugs that surface during the duration of a sprint and thus ensuring the quality of the application.
- A bug is defined as errors in code that causes system to behave differently from expected.
CALCULATION:
Bug Score = (1 X Total No. of Low Severity) + (2 X Total No. of Medium Severity Bug) + (10 X Total No. of High Severity Bug) |
---|
Severity Score | Severity Level | Description |
---|---|---|
1 | LOW | System is able to function as per normal. Minor issues in expected output or user interface alignment |
2 | MEDIUM | System is able to function but with runtime errors. Some non-critical functionalities may not work as expected |
10 | HIGH | System has some compilation error and unable to run or unusable for a period of time. Core functionalities may be affected |
Bug Score | Action Plan |
---|---|
6 and below | Developers resolve issues within the iteration |
7 - 9 | Schedule debugging in the buffer of the iteration. |
10 and above | Priority goes to resolving bug. Project Manager reallocates task for debugging team to focus on debugging. |
Change Management
There are few sources of change for the project itself. Depending on the initiator of the project change, change control processes would have to be taken into consideration.
TYPES OF CHANGE
Requirement Change
Requirement changes are modifications, additions, deletions of requirements stated in the latest version of requirements documentation. In this case, sponsor and supervisor would be noted. Response from supervisor and sponsor would be sought before decision is sealed.
System Design Change
System changes are modification, additions, deletions to the system architecture and detail system design as stated in the latest versions of system architectural documentations and technical infrastructure documentations. Depending on severity, response from supervisor might be sought before decision is sealed.
Business Process Change
Business Process changes are modifications, additions, deletions to the existing business processes as stated in the latest versions of process analysis documentation.
CHANGE PROCESS
Following the feedback given by our supervisor, we have come up with the revised change process:
- Change initiated by external party
- Project Manager informed of change
- Project Manager makes decision of change and decides if team meeting is needed
- Project Manager informs team supervisor and sponsor(only if necessary)
- If team meeting is needed, meeting is scheduled, else team would be informed of change once decision made
- Change would be analyzed and decision reached by team to make it known.
- Change decision is being made known to supervisor
- Change implemented and decision is made known to team, supervisor and sponsor(if necessary)
DOCUMENTING CHANGE
Changes that are formalized and agreed upon by team, and stakeholders if necessary, would be recorded in the respective documentation by Project Manager/Deputy Project Manager. Followup actions of changes made to project and team would be tracked by the Deputy Project Manager.
Check out our Change Log:
Risk Management
Our team's risk management approach is in constant monitoring and reviewing risk at the start and end of each milestone. Check our our Risk Management Plans for more information:
Priority | Type | Risk | Consequence | Likelihood | Impact Level | Risk Assessment Level | Mitigation Strategy |
---|---|---|---|---|---|---|---|
1 |
Business |
Unfamiliarity with mobile development frameworks required for the project |
|
Likely |
Major |
High |
|
2 |
Team |
Group members making assumptions of technical scope required within the project |
Inaccurate estimates of time required to complete tasks that leads to unreliable project deadlines and milestones |
Possible |
Moderate |
High |
|
3 |
Business |
Difference in understanding of terminologies and terms used in describing the business process (e.g. task, questions, assignments) |
Confusion over terms that may lead to the wrong picture being conveyed between client and team |
Possible |
Minor |
Medium |
|
Deployment
DESCRIPTION
Team Box.us would be responsible for the deployment of the system onto the client's servers and to ensure that the application is able to function smoothly and integrate into their current workflow processes.