IS480 Team wiki: 2015T2 Team Hei Midterm Wiki
Jump to navigation
Jump to search
Project Progress Summary
Project Highlights
- Took 4 weeks to be fully familiarized with ASP.NET MVC Framework and SQL Server
- Took 2 weeks to be fully familiarized with the Highcharts Library
- Develop part of the application using Java as the team was worried that the clients might not be able to provide team with a .Net server before Acceptance
- After Acceptance, took 1 week to convert the Java codes to C#
- Took 2 weeks to Redesign and restructure the UI after the Acceptance
- Completed 3 User Testing thus far:
- User Testing 1: Testers reflected that the project, if fully actualized would be useful. But the current system lacks functionality and the UX leaves more to be desired
- User Testing 2: Testers felt that the system has potential. However, felt that the Dashboard could be more intuitive and better thought-out
- User Testing 3: Testers felt that the system would be useful in helping users glean useful insights. On the whole, received extremely positive feedbacks for User Testing 3 (from a team of 16x IDA developers)
- Demonstrating the system to the Ministry of Manpower on 6th March 2015
Project Management
Project Status
Project Schedule (Plan Vs Actual)
Planned Project Timeline
Actual Project Timeline
Project Metrics
Project Risks
Previously in the acceptance, our team surfaced our 5 most probable project risks: (1) client management risk, (2) project management risk, (3) technical risk, (4) resource risk and (5) human risk. However, at this juncture (Midterms), our team only flags out client management as a risk, and have identified that the remaining 4 risks no longer pose as high risks to our team.
Risk Type | Risk Event | Likelihood | Impact | Mitigation | Learning Points & Remarks |
---|---|---|---|---|---|
Client Management Risk | There may be major changes in our client requirements that requires drastic changes to our schedule | Medium | High | Our team will meet our client regularly to ensure that we are always on top of our client’s requirements to lower the risk and impact of future changes to requirements | Client Management Risk - We felt that this continues to be a risk because the Client requirements would continue to change regardless of the stage of project / phase we are in. The only consolation is that the changes would be less major and less frequent as the project draws closer to the end. However this means that changes should still be anticipated, and hence the team’s mitigation strategy is to continue meeting the clients regularly to ensure that we are always on top of our client’s requirements, and consistently demonstrate to the clients our developed product to ascertain that our interpretation of the requirements are aligned. |
Project Management Risk | Team is unsure of the time required to complete each task/functionality | Low | Medium | Constantly review and re-estimate project schedule and the time required to complete each task/functionality | Project Management Risk – At the start of the project, it was determined to be a risk because most of the functions in the project requires new technology, and the Scrum Master was still not as proficient in the estimation of the tasks due to the lack of experience. But this is no longer the case now. However, we felt that this no longer poses as a risk because as we are already at the midpoint of the project and the scrum master has as a result of that developed an uncanny ability to accurately estimate the hours required for each function after iterations of estimation. |
Technical Risk | Team is not proficient in the technology used such as: ASP.NET MVC, D3JS | Medium | Medium | Team to research on technology and designate proficient team members to share knowledge | Technical Risk – At the start of the project, this was determined to be a risk because the project required many new technologies, and the team have never dabbled in the required technologies before. Hence, there was a possibility that the development might not go as well as we planned. However, this is no longer a risk because the developers have already built up on their proficiency in the technologies required after the many iterations of development. |
Resource Risk | Unexpected technology issues (laptop/repository crashes) | Low | High | Ensure that the latest documentation and codes are backed up in the repository and in other cloud storage as backup copy | Resource Risk - At the start of the project, this was a risk because the team was using tools (visual studio) and repositories (Stash) and hence were not confident about the stability of the tools and whether it would give up on us. Moreover, one of the developer was developing on an old laptop that would shut off on its own every now and then. However, having been through many iterations, the team have developed a certain level of confidence within the tools. Also, the member with the old laptop have just replaced it. Hence, the risk of resource related problem occurring is greatly reduced. |
Human Risk | Team member is not available due to illness or unforeseen circumstances | Low | Medium | Each member to have dual roles so that the backup member is able to take over the role if such circumstances arise | Human Risk – At the start of the project, there were no redundancies in the skillsets of the members. The team had no suitable replacement for certain tasks if the member in charge of that were to fall sick given the gap in our skills. However, the team has now significantly built on up redundancies given that each member had also been working in their secondary role in the past few iterations. Hence, even if certain members were to be unavailable, the team would still be able to function properly. |
All in all, the team would continue to closely monitor the project to circumvent any Client Management problems that might occur while also stay on the lookup for any other possible problems that the team did not anticipate.
Technical Complexity
Quality of Product
Intermediate Deliverables
Stage | Date |
---|---|
Project Management | Project Timeline |
Project Scope | |
Risk & Mitigation | |
Project Overview | Description |
Market Research | |
Design & Prototype | |
Testing | User Testing |
Documentation | Meeting Minutes |
Testing
For more information of our User Test, click to learn more:
Reflection
Team Reflection
Sponsor Comment