Difference between revisions of "IS480 Team wiki: 2012T2 box.us Project Management"
Line 123: | Line 123: | ||
! scope="row" | | ! scope="row" | | ||
|style="text-align: center;"| | |style="text-align: center;"| | ||
− | '''Manage Questions'' | + | '''Manage Questions''' |
|style="text-align: left;"| | |style="text-align: left;"| | ||
'''All Users''' | '''All Users''' | ||
Line 154: | Line 154: | ||
'''Volunteer''' | '''Volunteer''' | ||
* View search results (ability to apply for task) | * View search results (ability to apply for task) | ||
+ | |- | ||
+ | |||
+ | !scope="row" colspan="3" style="background-color:#CB2402; color:White; text-align: left;"| | ||
+ | ''' Value-Enhancing FEATURES''' | ||
+ | |||
+ | |- | ||
+ | |||
+ | ! scope="row" | | ||
+ | |style="text-align: center;"| | ||
+ | '''Statistical Reporting''' | ||
+ | |style="text-align: left;"| | ||
+ | '''Empact''' | ||
+ | * View Statistics | ||
+ | * Export Statistics | ||
+ | * View data | ||
+ | |||
+ | |- | ||
+ | |||
+ | ! scope="row" | | ||
+ | |style="text-align: center;"| | ||
+ | '''Manage Records''' | ||
+ | |style="text-align: left;"| | ||
+ | '''Empact''' | ||
+ | * View volunteering records | ||
+ | * Generate records | ||
+ | |||
|- | |- | ||
Revision as of 20:26, 24 October 2012
Home | Stakeholders | Project Overview | Project Management | Documentation | Learning Outcomes | Useful Links |
Contents
Team Charter
Team Box.us is a project team that consists of 6 individuals with varying (and complementing skillsets). The team set out with the following beliefs to achieve at the end of the project:
- Create value for organizations - Value could be business value and also social value to our sponsors.
- Sustainable implementations - Our team believes in having projects that would be sustainable and be able to bring value to the organizations in a long run
- Team Learning - Our team believes in learning during the entire development process so that the experience would be enriching for the organization, the team and the individuals invovled.
Project Scope
Modules | Module Name | Scope details |
---|---|---|
BASIC FEATURES | ||
Manage Account |
All Users
| |
Manage Profile |
All Users
Empact
NPO
Volunteer
| |
CORE FEATURES | ||
Manage Task |
All Users
Empact
NGO
Volunteer
| |
Manage Task Review |
Empact
| |
Manage Questions |
All Users
NPO
Volunteer
| |
Manage Search |
All Users
Empact
NPO
Volunteer
| |
Value-Enhancing FEATURES | ||
Statistical Reporting |
Empact
| |
Manage Records |
Empact
|
Work Breakdown
CONCEPTUALIZATION (07/10/2012 - 27/10/2012)
DEVELOPMENT (28/10/2012 - 17/02/2013)
DEPLOYMENT (18/02/2013 - 31/03/2013)
Schedule & Milestones
UNDER CONSTRUCTION
Project Milestones - Detailed Project Milestones with their dates can be found at: Project Milestones List
Project Schedule - Project Schedule on Google Docs
Schedule Metrics
OBJECTIVE
- To ensure that all project tasks are completed on time and milestones are met.
CALCULATION:
Schedule Ratio = Actual Time / Planned Time |
---|
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 above 1. Keep close monitor on tasks that have a ratio of less than one. |
< 1.2 | Team is behind schedule | Team is behind schedule. Project Manager identifies root cause and allocate more time to complete tasks in the next iteration. |
Bug Metric
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 = (2 X Total No. of Low Severity) + (4 X Total No. of Medium Severity Bug) + (8 X Total No. of High Severity Bug) |
---|
Severity Score | Severity Level | Description |
---|---|---|
2 | LOW | Errors that lies with user interface. Features can still work, but not as what is expected. |
4 | MEDIUM | Errors that prevent an entire feature from working |
10 | HIGH | Errors that prevent more than 1 feature from working |
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. |
Iteration Planning
Sponsor Sourcing
Before everything, we have to find a sponsor. Learning from our past experiences, the team has developed a guideline for sourcing the sponsor. The guidelines are as such:
- The Motivation: What is the need?
- The Idea: In short, what is the idea about?
- The Solution: How would the idea help to solve the need
- The Scope: What is the focus of the project? The differentiating factor? The X-Factor of the project?
- The Implementation: Do we have the technical ability to deal with the project?
At the end of this iteration, the team would have a clear idea of what the scope of the project is about and the high-level steps of what needs to be done to get there.
Agile Development
It's all about agility. Our team aims to mimic as close as possible to real-world software engineering experiences. As such, our team has decided to adopt the Agile Development Process that is flexible and meaningful for the entire team. In our Development phase, we iterate between design, build, test and release for each iteration.
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.
Team Process Change
Team Process changes are modifications, additions, deletions to the existing team processes as stated in the latest versions of project management plan and software configuration management plan. In this case, supervisor. Supervisor would be informed.
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 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 or Business Analyst. Followup actions of changes made to project and team would be tracked by the Deputy Project Manager.
Risk Management
Our team's risk management approach is in constant monitoring and reviewing risk at the start and end of each milestone.
![Risk matrix.gif](/is480/img_auth.php/9/90/Risk_matrix.gif)
No | 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 |
|
4 |
Project |
Change in volunteer matching business process during the development of the system |
Decrease in value of system brought to the business. |
Possible |
Major |
High |
|
5 |
Resources |
Multiple users working on the same files resulting in conflicting versions of documentation |
Loss of information or mismatch in understanding |
Likely |
Minor |
Minor |
|
6 |
Resources |
Hardware and software failure during the development of the project. |
|
Unlikely |
Moderate |
Moderate |
|
7 |
Team |
Different workloads and committment in team due to varying workloads and outside commitments |
Inaccurate allocation and expectation of team and project manager upon each team member, obstructing accurate time estimation and affects schedule allocation. Unhappiness in team due to unfair work allocations throughout the entire project |
Likely |
Major |
High |
|
8 |
Business |
Misunderstanding of technical requirements between client and project team as clients are not technically-inclined |
Re-doing of development work as a result of mismatched expectations between different parties, leading to time wastage |
Likely |
Severe |
High |
|