ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

Kanban - Change Management

•Download as PPTX, PDF•
•
T
Tal Aviv

The document proposes using a Kanban board to help manage the migration workflow between operations and project management teams. The board would use cards to visually represent each migration change moving through stages of ready, review, assessment, approval, build and test, deployment approval, and implementation. Cards would include details of the change and responsible parties. All teams would have visibility into what stage each change is at. If changes aren't progressing, project managers could intervene to resolve delays. The board aims to improve collaboration and provide transparency throughout the migration process.

1 of 18
Downloaded 23 times
Managing migration work flow within an ever changing environment
Problem  The HWI group manage numerous changes at any given time  The number of migration changes is expected to increase with the VM migration project and KMT migration.  Migration changes do not always make it in time to implementation stage  PM’s do not have clear visibility to what stage their migration changes are at.
Proposed solution ï‚— Team collaboration between the operations team and the PM group using a visual representation Kanaban Board
What is a Kanban Board? ï‚— Kanaban board is a visual representation of the work stream. ï‚— Each stage in the work flow is represented by a column. ï‚— Each work unit is represented by a card ï‚— The cards follow the work stream by moving from left to right.
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Change Management work flow Kanban Board
Kanban Card  Each card will have the following properties:  Title: Change number  Body:  PM  Change Owner  Change Coordinator  Due Date – The due date is the time that the change need to be in implementation and not necessarily the start of the change request.
Process – Card creation  PM will provide the vendor the list of servers or RM’s for migration.  The PM will create a card for each server and put it in RM Ready queue.
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval PM Submit RM and create a card server1 per server A card will initially have the server server2 name in the title The body of the card will include server3 the PM, Change Owner, Change Coordinator, Due date/time. * If not all information is available leave the names server4 blank
Process – Identify and initial placement  If an Ops person identify a migration change, he will process it ,move the card on the board and fill out the missing information.  Most likely this card will move directly to change assessment  If a PM learns that a change was created he will move the card to change review and update the missing information
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Ops team identify a change process and server1 update board and card server2 server3 PM identify a change process and update board server4 and card
Process – Changes moving  As changes are progressed through the system, the ops or PM’s will update the board.  Anyone can have access to the board  Anyone that see a change in SM can move the card to the proper phase.
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Change Progress by server1 ops or PM server2 server3 Change Progress by server4 Ops or PM At any stage all groups have a visual representation of what stage are all the changes at. Anyone can update the board
Process –CAB Representation 13  A PM that see one of his changes in deployment approval will know that it is going to appear on the CAB or eCAB.  The PM will be responsible to attend the CAB or to confirm that the change owner will attend the CAB.
Process – Identify issues  The PM is responsible to review the board on a daily basis.  If a PM see that a change has not moved or is stuck in any of the approval stages he can compare the data to SM and focus on resolving the delay. Visual representation for all
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Why is this still at Deployment approval server1 server2 Why is this still in Build server3 Approval? server4 Changes that are not moving will be visible and will require PM intervention
Process - closure ï‚— A card that reach implementation will stay there until removed from the board by the PM (i.e. work was completed) or be moved back to build and test for rescheduling.
RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Something was wrong, need rescheduling server1 server2 server3 Ready to go server4 Changes that are ready to go will be in implementation. PM will either remove from the board or move back for rescheduling
Questions? QUESTIONS?

More Related Content

Kanban - Change Management

  • 1. Managing migration work flow within an ever changing environment
  • 2. Problem ï‚— The HWI group manage numerous changes at any given time ï‚— The number of migration changes is expected to increase with the VM migration project and KMT migration. ï‚— Migration changes do not always make it in time to implementation stage ï‚— PM’s do not have clear visibility to what stage their migration changes are at.
  • 3. Proposed solution ï‚— Team collaboration between the operations team and the PM group using a visual representation Kanaban Board
  • 4. What is a Kanban Board? ï‚— Kanaban board is a visual representation of the work stream. ï‚— Each stage in the work flow is represented by a column. ï‚— Each work unit is represented by a card ï‚— The cards follow the work stream by moving from left to right.
  • 5. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Change Management work flow Kanban Board
  • 6. Kanban Card ï‚— Each card will have the following properties: ï‚¡ Title: Change number ï‚¡ Body:  PM  Change Owner  Change Coordinator  Due Date – The due date is the time that the change need to be in implementation and not necessarily the start of the change request.
  • 7. Process – Card creation ï‚— PM will provide the vendor the list of servers or RM’s for migration. ï‚— The PM will create a card for each server and put it in RM Ready queue.
  • 8. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval PM Submit RM and create a card server1 per server A card will initially have the server server2 name in the title The body of the card will include server3 the PM, Change Owner, Change Coordinator, Due date/time. * If not all information is available leave the names server4 blank
  • 9. Process – Identify and initial placement ï‚— If an Ops person identify a migration change, he will process it ,move the card on the board and fill out the missing information. ï‚¡ Most likely this card will move directly to change assessment ï‚— If a PM learns that a change was created he will move the card to change review and update the missing information
  • 10. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Ops team identify a change process and server1 update board and card server2 server3 PM identify a change process and update board server4 and card
  • 11. Process – Changes moving ï‚— As changes are progressed through the system, the ops or PM’s will update the board. ï‚— Anyone can have access to the board ï‚— Anyone that see a change in SM can move the card to the proper phase.
  • 12. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Change Progress by server1 ops or PM server2 server3 Change Progress by server4 Ops or PM At any stage all groups have a visual representation of what stage are all the changes at. Anyone can update the board
  • 13. Process –CAB Representation 13 ï‚— A PM that see one of his changes in deployment approval will know that it is going to appear on the CAB or eCAB. ï‚— The PM will be responsible to attend the CAB or to confirm that the change owner will attend the CAB.
  • 14. Process – Identify issues ï‚— The PM is responsible to review the board on a daily basis. ï‚— If a PM see that a change has not moved or is stuck in any of the approval stages he can compare the data to SM and focus on resolving the delay. Visual representation for all
  • 15. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Why is this still at Deployment approval server1 server2 Why is this still in Build server3 Approval? server4 Changes that are not moving will be visible and will require PM intervention
  • 16. Process - closure ï‚— A card that reach implementation will stay there until removed from the board by the PM (i.e. work was completed) or be moved back to build and test for rescheduling.
  • 17. RM Change Change Build Build and Deploymen Implement Ready Review Assessment Approval Test t Approval Something was wrong, need rescheduling server1 server2 server3 Ready to go server4 Changes that are ready to go will be in implementation. PM will either remove from the board or move back for rescheduling