Kanban - Change Management

1,836 views
1,399 views

Published on

Using kanban board to help manage change requests through a bureaucratic process

1 Comment
1 Like
Statistics
Notes
  • 'If an Ops person identify a migration change, he will process it...' - so the person is always a 'he'? And the PM, that's also always a 'he'? Seems a bit outdated.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,836
On SlideShare
0
From Embeds
0
Number of Embeds
56
Actions
Shares
0
Downloads
16
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Kanban - Change Management

  1. 1. Managing migration work flow within an ever changing environment
  2. 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. 3. Proposed solution Team collaboration between the operations team and the PM group using a visual representation Kanaban Board
  4. 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. 5. RM Change Change Build Build and Deploymen ImplementReady Review Assessment Approval Test t Approval Change Management work flow Kanban Board
  6. 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. 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. 8. RM Change Change Build Build and Deploymen ImplementReady Review Assessment Approval Test t Approval PM Submit RM and create a cardserver1 per server A card will initially have the serverserver2 name in the title The body of the card will includeserver3 the PM, Change Owner, Change Coordinator, Due date/time. * If not all information is available leave the namesserver4 blank
  9. 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. 10. RM Change Change Build Build and Deploymen ImplementReady Review Assessment Approval Test t Approval Ops team identify a change process andserver1 update board and cardserver2server3 PM identify a change process and update boardserver4 and card
  11. 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. 12. RM Change Change Build Build and Deploymen ImplementReady 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. 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. 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. 15. RM Change Change Build Build and Deploymen ImplementReady 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. 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. 17. RM Change Change Build Build and Deploymen ImplementReady 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
  18. 18. Questions?QUESTIONS?

×