Skip to main content

Change Management Process

The change management process to be folllowed is mentioned below:

Step 1- Recording a change​

  • The change requested by the university can be recorded as issues by anyone who encouters the change request in Change Management project.
  • The issue will be assigned to the resepective module owner.
  • Its mandatory to label the issue with module as well the university name.

Note: Error and bugs will be directly reported in specific board.

Step 2- Change Analysis​

  • Module owner shall analyse the change and categorise changes into following:

    • Must Have (M)-Feature requests that are non negotiable product needs and are mandatory.
    • Should Have (S)- Important feature requests that are not madatory but should ideally be a part of workflow.
    • Could Have (C)- Nice to have feature requests that are not mandatory to the workflow but would do no harm if included. The issues which are marked as could have do not have immediate impact, thus can be discussed in later CAB meetings.
    • Won't Have (W)- Feature requests that won't be incorporated in the workflow.

  • The MSCW lists of change requests can be seen on the MSCW board.

Step 3 - Change Approval​

  • Changes with no financial implication shall be approved by the Executive Change Approval Board (ECAB) comprising of the following team members:

    • Project Lead
    • R&D Lead
    • Product / Module Owner
    • Project Learning Officer
    • UI/UX Lead

  • CAB meeting will happen every Friday at 5:00 p.m.

Note: Changes which may involve financial or administrative approvals shall be submitted to Principal Investigator, Project Samarth and shall be approved as per the guidelines defined by the sponsor.

Step 4- Adding due date and time estimate​

  • The module owner along with his/her team will add due date and time estimate (time taken to complete the task in question) in the concerned issue.
  • The discussion points will be mentioned in the issue and sub tasks/issues will be made accordingly and assigned to respective team member.

Step 5- Moving issue to the product board​

  • Once the issue has been categorised as Must Have (M) and Should Have(S), the issue will be moved to respective module's board.

Note: Only the rollout monitoring board will be visible to a university.

Do's and Dont's​

Do's​

  1. Module owner shall categorise the change requests into MSCW before the CAB meeting.
  2. Module owner/Change management team will add all the points discussed as comments in the issue.
  3. In case, any change requires repo update, module owner will assign it to concerned person and move it to module specific project.
  4. Work should start in any issue only after approval from change management board.
  5. Use the 5 why method to analyse the issue and reach the issue. Mention the root cause analysis steps in the comments.

Dont's​

  1. Close an issue without discussion.
  2. Create an issue without labels.
  3. Create new labels without discussing with change management team.