HeaderSIS.jpg

IS480 Team wiki: 2016T1 Stark Project Management Change Management

From IS480
Jump to navigation Jump to search
Team Stark Logo.png


Team Stark Home.png   HOME

 

Team Stark About Us.png   ABOUT US

 

Team Stark Project Overview.png   PROJECT OVERVIEW

 

Team Stark Project Management.png   PROJECT MANAGEMENT

 

Team Stark Documentation.png   DOCUMENTATION

 


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