IS480 Team wiki: 2012T2 box.us Project Management
|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.
As seen, the team would be involved in 3 main areas of the project: Conceptualizing, Development and Deployment.
- CONCEPTUALIZATION - In this phase, the team is in-charge of refining the client's existing proposed idea through analysis of the current business process and needs of the different stakeholders. Through this process, the client would be able to identify key business benefits that the system would bring. This phase would end when the client and the team has come up with a baseline list of functionalities that can be agreed upon.
- DEVELOPMENT - In this phase, the team is in-charge of designing and coming up with the system, including the system architecture, and the actual web application and phone application. The team is to work closely with the client to come up with the final solution. This phase would end with the User Acceptance Testing by the client, which would also mark the beginning of the next phase.
- DEPLOYMENT - In this phase, the team is to ensure that the solution (web application and the mobile application) would be successfully transited to the client. It may include the deployment of the solution onto the necessary platforms and to ensure that the solution meets the requirements spelled out in the requirements specification.
Our schedule is reviewed per iteration basis, and to set the time needed for each iteration. Baseline dates are provided but are reviewed again at the start of every iteration. Project Manager is the editor of the project schedule, and team members are expected to review, know and deliver based on the project schedule.
Our project is based on the Agile Methodology. We first plan out the features that we want to see completed and the target date that we need to meet to finish the features. We then decide what are the tasks that needs to be done to hit each milestone, further break them down into each iteration to determine what are the tasks that needs to be done, until we have granular tasks that each individual can undertake.
Although we are developing on two platforms (web and mobile app), we would be running both developments in parallel, so as to identify blindspots in terms of development that could arise due to our lack of experience in development on iOS platforms.
- Project Initiation Completed - 07/10/2012
- Requirements Gathering Completed - 21/10/2012
- Acceptance Reached - 05/11/2012
- Manage Account
- Manage Profile
- Prototype Completed - 24/11/2012
- Manage Questions
- Post Tasks Completed - 02/12/2012
- Manage Tasks
- Matching Mechanism is being tackled here
- Notifications Completed - 16/12/2012
- Manage Messages
- System Admin Completed - 30/12/2012
- Manage System
- Search Completed - 13/01/2013
- Manage Search
- Volunteer Activity Records Completed- 20/01/2013
- Manage Records
- User Feedback - 27/01/2013
- Feedback Improvements Completed - 10/2/2013
- User Acceptance Test - 17/2/2013
- Post Mid Term Feedback Completed - 17/3/2013
- Handover Completed - 31/3/2013
- Poster Day Completed
The following diagram shows a bird's eye view of what are the key tasks that needs to be done within the entire project:
CONCEPTUALIZATION (07/10/2012 - 27/10/2012)
DEVELOPMENT (28/10/2012 - 27/01/2012)
To ensure schedule robustness and quality management, we are using 2 metrics. For schedule metrics, we would collect the metrics data at the end of every iteration. For quality management, we would collect the bug metric at the end of every iteration also. Primary responsibility lies with the Lead Developer for collecting bug metric data and Project Manager for collecting schedule metrics data.
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.
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. Our iterations are planned as such:
Iteration 0 : Project Initiation
This is a time for our team to learn as much as possible in the following areas:
- Project Plan - How are we going to get to the end?
- Technical Walkthrough - What are the tools, knowledge, help and expertise that are available?
- Business Value - What value do we bring?
- Justifications - What would help to solidify our reasons for the project?
- Team Bonding! - All work, no play, and you would hate your FYP. This is a time for the team to go through the initiation and storming phase, where we be honest about our doubts and fears and limitations and also strengths and confidence in the project.
At the end of this phase, the team would have established its project plan, roles and responsibilities and the baseline project schedule. The project manager would then send an update email to the supervisor, to the client and update the wiki.
MILESTONE 2: SYSTEM CONCEPTION COMPLETED
Iteration 1 : Gather Requirements
The focus of iteration 1 is to commence on requirements gathering. The requirements gathering phase is the most important phase because it is where we establish the baseline from which all communications would stem from and also it is the first time that all the different parties get to synergize and work with one another. During this phase, the team seeks to answer the following questions:
- What is the scope of the project?
- Who are the target audience?
- What are the use cases?
- What are the functionalities that needs to be done?
- What are the non-functional requirements that we need to adhere to?
- How does the client want the user interface to look like?
- How are we going to handover the project?
At the end of this phase, the team would have established its use case scenarios, user storyboards and functionality list. This would all be placed into a requirements document. The project manager would then arrange for a meeting with client to clarify the use case scenarios, the user storyboards and the functionality requirements. The supervisor would be updated on the outcome of the meeting.
Should there be any major changes to the requirements, rectifications would be made. Depending on the scope of the project, the team might increase the no. of iterations of requirement studies needed.
Iteration 2 : System Design
MILESTONE 3: PROTOTYPE COMPLETED
MILESTONE 4 : POST TASKS COMPLETED
MILESTONE 5: NOTIFICATIONS COMPLETED
MILESTONE 6: SYSTEM ADMIN COMPLETED
MILESTONE 7: SEARCH COMPLETED
MILESTONE 8: VOLUNTEER ACTIVITY RECORDS COMPLETED
MILESTONE 9: USER FEEDBACK COMPLETED
MILESTONE 10: FEEDBACK IMPROVEMENT COMPLETED
MILESTONE 11: POST MID-TERM FEEDBACK COMPLETED
MILESTONE 12: HANDOVER COMPELETED
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.
SOURCES OF CHANGE
External changes are changes in requirements that are raised by a party that is outside the project team. They can be triggered by course supervisor, client, any other project stakeholders or external circumstances. Such changes are usually made known to the team via any team member, the project manager or indirectly via external sources. In this case, team, supervisor and sponsor would be informed. Respond from supervisor would be sought before decision is sealed.
Internal change are self-contained changes raised within the project team. It is usually raised by team members and would cover areas concerning team processes and source code management issues. The nature of such changes would usually mean potential changes in the team’s processes. In this case, only supervisor would be informed.
TYPES OF 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.
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)
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.
Our team's risk management plan is centered around early detection.