HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 box.us Project Management"

From IS480
Jump to navigation Jump to search
Line 127: Line 127:
 
|-
 
|-
  
! scope="row" |'''10'''
+
! scope="row" |'''8'''
 
|style="text-align: center;"|'''HIGH'''
 
|style="text-align: center;"|'''HIGH'''
 
|style="text-align: left;"|Errors that prevent more than 1 feature from working
 
|style="text-align: left;"|Errors that prevent more than 1 feature from working
Line 153: Line 153:
 
|}
 
|}
 
</center>
 
</center>
 
 
  
 
=<p><div class="NavHead" style="background-color:#2F55A4;-moz-border-radius:4px; text-align: left; padding: 5px; font-size: 70%;"><span style="color: White"> '''Change Management'''  </span></div></p>=
 
=<p><div class="NavHead" style="background-color:#2F55A4;-moz-border-radius:4px; text-align: left; padding: 5px; font-size: 70%;"><span style="color: White"> '''Change Management'''  </span></div></p>=

Revision as of 14:27, 5 November 2012


Teamphotowiki.jpg

Home Stakeholders Project Overview Project Management Documentation Learning Outcomes Useful Links

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.

CONCEPTUALIZATION (07/10/2012 - 27/10/2012)

Conceptualization.jpg


DEVELOPMENT (28/10/2012 - 17/02/2013)

Development.jpg


DEPLOYMENT (18/02/2013 - 31/03/2013)

Deployment Process Boxus.jpg

Our Project Milestone

Project Milestones - Detailed Project Milestones with their dates can be found at: Project Milestones List

Project Schedule - Project Schedule on Google Docs

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.


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
8 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.

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:

  1. Change initiated by external party
  2. Project Manager informed of change
  3. Project Manager makes decision of change and decides if team meeting is needed
  4. Project Manager informs team supervisor and sponsor(only if necessary)
  5. If team meeting is needed, meeting is scheduled, else team would be informed of change once decision made
  6. Change would be analyzed and decision reached by team to make it known.
  7. Change decision is being made known to supervisor
  8. 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:

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:

Risk matrix.gif
Priority Type Risk Consequence Likelihood Impact Level Risk Assessment Level Mitigation Strategy
1

Business

Unfamiliarity with mobile development frameworks required for the project

  • Inability to make decision about best framework to use
  • Slow project progress because of unfamiliarity

Likely

Major

High

  • Conduct research on possible mobile development technologies and consult peers and supervisors for advice on which framework to use, in view of mobile app's scope
  • Development of mobile application in parallel with web application to highlight any possible loopholes and to buffer for any major changes needed early.
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

  • Lay down milestones, deadlines and tasks to do with team before the start of every iteration and review estimates together as a team
  • Project Maanger to actively manage the overrun of schedule through tracking of metrics
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

  • Implement a project dictionary where common terms of use are being recorded down
  • Proactive logging down of common terms of use in the project dictionary
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

  • Analyse client's As-Is Process and verify with client about current As-Is Model
  • Consider longevity of the system during the design of system
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

  • Segregating editing responsibilities - Business Team to edit business related documents while Technical Team to edit technical-related documents
  • Use of Subversion during the committing of code. Lead Developer would be responsible for any code conflicts.
6

Resources

Hardware and software failure during the development of the project.

  • Failure of hardware would cause latest work that is being developed to be lost.
  • Redundancy and repetition of work is necessary in order to keep up to the pace that is being set by the schedule in the event of a software and hardware failure.

Unlikely

Moderate

Moderate

  • Save development codes onto Subversion
  • Business Analyst to do a weekly backup of all documents and source code.
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

  • Set expectations instead of micro-managing how work would be done by individuals
  • Schedule shorter iterations to ensure that targets are met and not piled up.
  • Allocate common coding sessions to allow team to ensure accountability and transparency
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

  • Conduct requirements clarifications before the start of every iteration between team and client to clarify the requirements
  • Using process flow diagrams and storyboards to communicate features with client and team.
  • Discuss about feature design before each development session
  • Recommend and propose technical requirements to client