IS480 Team wiki: 2016T1 Stark Project Management Change Management
Revision as of 20:51, 27 October 2016 by Cylee.2013 (talk | contribs)
Change Management
Steps for Change Management
1. Receive change request
2. Analyze feasibility of change request
3. Evaluate the level of impact on project if change request is implemented
4. Decide the level of priority for the change request
5. Accept or reject the change request
Priority of Change Request | Outcome |
---|---|
Reject | Change is rejected. Inform requester (Eg: mentor, supervisor, others) . |
Low | Add to Tertiary / Good to Have function. |
Medium | Discuss with mentor / supervisor to rescope the project by replacing current functions to accept change. |
High | Hold internal meeting to discuss functional requirement. Immediately update in project schedule. PM to reschedule tasks. |
Change Log
Iteration | Date | Description | Reason | Feasibility | Priority | Outcome | Status |
---|---|---|---|---|---|---|---|
2 | 22 May | Move "Verify account via SMS" to Good-To-Have Feature | This is not the core functionalities hence moved to "Good-to-have" features to make more time for the core requirements to be fulfilled | Fits into schedule without any expected delay as a consequence. | Low | Accepted | Completed |
3 | 7 June | Move "Export to other platform (social media, e-commerce platform" to Good-To-Have feature | This is not the core functionalities hence moved to "Good-to-have" features to make more time for the core requirements to be fulfilled | Fits into schedule without any expected delay as a consequence. | Low | Accepted | Completed |
6 | 8 July | Reshuffle "Manage Data (Admin)" Module to from iteration 6 to iteration 9 | Schedule was planned mostly for functional aspect. However, general presentation (Front-end) for users side is not present and user side application should be of higher priority. | PM see that user side application should be of higher priority. Reshuffling of module will still fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
7 | 25 July | Scheduled UT1 from 25 July to 1 August. | Delay in deployment. Reschedule deployment from 24 July to 31 July | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
7 | 25 July | Shift "3-way chat" function in "Dispute System Module" and "Manage Dispute (Admin) Module" to Secondary Features. Schedule on iteration 9. | "3-way chat" is not the core feature of MaiMai. Decide to focus on all core features before acceptance | Fits into schedule without any expected delay as a consequence. | Low | Accepted | Completed |
8 | 1 Aug | Added "Manage Dispute (Admin)" Module to iteration 8 (buffer iteration) | Underestimated function's difficulty. Developer working on it requires much more help and hence requires more time. | Iteration 8 was meant to be a buffer iteration to catch up with all delays. Fits into schedule without any expected delay as a consequence. | Low | Accepted | Completed |
9 | 18 Aug | Release delayed from 15 Aug to 19 Aug | Found a few crucial bugs and development for dispute function met with problems as the business process to handle disputes was not well defined and planned, hence making us find a lot of loop holes while developing it. | May have lesser time to reach to the market and other features may have lesser to be completed. However, developers have agreed that the later few functions in the iterations should still complete on time as the difficulty isn't that high thus will not have any expected delay. The team agrees that will still be able to push for the target 5 transactions per member as according to one of the object of our "Go to market" plan. | High | Accepted | Completed |
9 | 20 Aug | Suggest to allow users to earn badges as achievements | Group suggested to allow users to earn badges when they reach certain achievements and badges will appear on the profile page of the users to gain additional assurance for other users who are transacting with them. | It is not one of our core feature to focus on. In addition, due to time constraint, it will not be implement as of now. | Low | Rejected | N.A |
9 | 20 Aug | Move "3-way chat" to "Good-To-Have" feature. Shift to iteration 12 | Group had a discussion and realise that for the dispute process to work the 3 way chat is not essential. In additional, there is not enough time, thus the group decide to shift to "Good-To-Have" feature. | Fits into schedule without any expected delay as a consequence. | Low | Accepted | Completed |
10 | 30 Aug | Added Plain text (Location check-in) to "Good-To-Have" feature | Considering the suggestions from acceptance, we recognise that structuring the agreements aspect in our transaction process will allow us to process disputes in a much quicker time. as such, the team has decided to allocate time to implement as many structured agreements as possible. | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
11 | 19 Sep | Shift UT3 from 14 Oct to 24 Oct | Taking into accounts all the new "Good-To-Have" features, UT3 will focus on testing these features. | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
12 | 8 Oct | Shift iBanking from iteration 12 to iteration 13 | Need to replan the business process as there is no way for savings account to be automated | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
12 | 8 Oct | Added "Web Push Notification" into "Good-To-Have" feature in iteration 13 | To integrate the user's experience with the notification function in MaiMai | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
12 | 17 Oct | Altered "Location Check-In" to "Agreement fields (Location, Date and Time)" | Check-In process requires much more planning and considerations. As there is limited time, the team has decided to focus on providing as much structured agreements as possible to show future plan of using such structured agreements as a mean to automate the dispute management process. | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |
12 | 21 Oct | Shifted UT3 from 24 Oct to 31 Oct | With additional features being modified and added into scope, UT3 will focus on all additional features. | Fits into schedule without any expected delay as a consequence. | High | Accepted | Completed |