Change Management

Summary

Flowset templates can be used as a starting point for a workflow implementation.  Simply find the template that best matches your process requirements and then clone it.  See Workflow Templates for details of using Flowset Templates.

Effectively managing change requests is crucial to minimizing disruptions, ensuring quality and consistency, and mitigating risks. It ensures that changes are implemented in line with requirements, preventing scope creep and budget overruns, while also aligning with the organization's strategic objectives.

This template implements a change management process including

• Change request definition and details capture
• Various levels of reviews
• Change Implementation and rework (where necessary)
• Ability to bypass formal Change Management when appropriate
• Ability to reject Change Requests

Template Design

The Change Management template consists of a number of activities.  These activities represent a set of tasks that need to be performed before moving on to the next activity.  Data supplied in these activities is used to control which activity you can transition to when the current activity is completed.  The template also provides the ability to return to a previous activity if, for example, more information is needed to be able to complete a review.

The image above shows the Change Management workflow template.  The activities (in green) show the main steps in the process.  These are

1. Provide Change Definition
2. Change Management Review
3. CAB Review
4. Implement Change
5. Post Implementation Review
6. Identify Rework Needed
7. Bypass Formal Change Management
8. Change Request Rejected

The lines (flows) between activities represent transitions from one activity to the next.  The availability of these transitions will be controlled by the workflow based on task data supplied during the activities.

Process Persisted Fields

Activities will normally gather information to allow their tasks to be completed.  This information is typically local information known only to the activity being performed.  Once you transition on to the next activity, it will gather it's own information to allow it to compete.  There are times, however, where some information gathered in an activity may be needed in subsequent activities.  For example, many of the activities might behave differently depending on whether the change has been categorized as 'Major' or 'Minor'.

Process Persisted Fields can be accessed from any activity and prevent the need to keep asking the same questions in different activities.  The process persisted fields defined in this workflow template are

Detailed Design

The sections below describe details of the tasks involved in each of these top level activities.  See Activity Task Modeling for details of how to define task flows for an activity.

Provide Change Definition

This activity will ensure that the Change Reason and Change Type have been recorded and that the ticket description contains sufficient details to be submitted to the Change Management Review activity.

The image above shows the task flow for this activity.  The task flow initially decides (1) whether we need to provide the change specification (this will be when we first perform this activity) or clarification details (if we return to the activity for clarification).

When providing the specification, we are prompted to supply the Change Reason and the Change Type (2).  This information is stored in Process Persisted Fields and will be available to subsequent activities.  If the Change Reason is identified as 'Other', then we'll be asked to give more details about what 'Other' means (3).  Ultimately we will be shown Guidance information (4) about how to proceed on to the next activity.

If clarification was needed, then the agent will be asked to provide this information (5) before moving on to the next activity.

Change Management Review

This activity reviews the information provided and will either

1. Seek clarification from the 'Provide Change Definition' activity
2. Provide Clarification requested by the 'CAB Review' activity
3. Reject the change request
4. Classify the change type to either allow the change management process to be bypassed or to decide on the type of Change Approval Board review needed to approve this change

The image above shows the task flow for the Change Management Review activity.  The tasks performed can be summarized as follows

1. Clarification for CAB
   The CAB has returned back to this 'Change Management Review' activity to seek clarification.  These tasks will guide the agent to provide the extra details needed.
2. Request clarification
   The agent does not have enough information to accept or reject this change request.  The ticket will be passed back to 'Provide Change Definition' along with details of the information that is missing.
3. Reject change request
   This change request has been rejected.  The agent will provide details of why it was rejected in the ticket comment.
4. Change type
   The agent is give the opportunity to check the Change Type and reclassify it as Major or Minor.
5. Minor changes
   For minor changes, the agent can decide whether the change management process can be bypassed completely (for example for very trivial changes) and if this is the case, capture the reason that the change management process was bypassed.
6. Major changed
   For major changes, we capture further details about whether there will be any downtime and which systems are likely to be affected.
7. CAB Type needed
   Finally we identify the Change Approval Board review type that will be needed for this change.  If we choose to Bypass the CAB, then we get the agent to justify this decision.

CAB Review

This activity is the final level of approval that is needed before the implementation of the change can commence.  The previous activities should have gathered all the details of the change and performed an initial review.  This activity is primarily responsible for the final decision to proceed or stop.  The CAB Review will either

1. Approve the change and pass on to the 'Implement Change' activity
2. Approve a retrospective change (the change has already been implemented) and the workflow will finish.
3. Ask for more information from the 'Change Management Review' activity
4. Reject the change

The image above shows the task flow for the CAB Review activity.  The first part (1) provides guidance and a set of checklists of considerations that should be addressed during the CAB Review.  These include

• Has sufficient detail been provided
• Have the risks been assessed
• Is the proposed change compliant with any relevant standards

Based on the answers given to these questions, the task flow will be routed as appropriate (2).

Implement Change

This activity is responsible for tracking the implementation of the change after it has been approved.  This activity may run 

1. When the change request has been approved and the change is initially implemented
2. After an implementation review when some level of rework has been identified to improve the implementation

The above image shows the task flow for the 'Implement Change' activity.  The tasks performed can be summarized as follows

1. Rework implementation
   This activity is running as a rework request after the initial implementation.  The agent can decide whether to accept the suggested rework or reject it.  If the rework is accepted then it will go through the normal recording of the implementation progress (see 3 below).
2. Abandon change
   If for some reason, the work on this change implementation has to be abandoned then this part of the activity flow allows the agent to mark it as abandoned and capture reasons for it being abandoned.
3. Record progress of implementation
   The main part of this activity task flow is the recording of the dates when the implementation was started, testing started, testing completed and the implementation deployed.  These need to be recorded in order.

Post Implementation Review

This activity performs a review of the implemented change to identify whether the change request has been implemented correctly according to the specification.

The image above shows the task flow for this activity.  The Review task (1) simply asks the agent to specify whether the implemented change satisfies the change request.  If not then 'Rework' is requested (the Change Type is set to Rework in the Rework (2) stop shape), otherwise the process is completed (3).

Identify Rework Needed

When the Post Implementation Review identifies that rework is needed to complete the implementation of the change request, this activity asks the agent to include in a ticket comment details of the rework that is needed.

The image above shows the task flow for this activity.  The Rework task asks the agent to provide details of the rework needed prior to transitioning back to the 'Implement Change' activity (but this time with the Change Type set to Rework).

Bypass Formal Change Management

When the 'Change Management Review' activity identifies that the Minor change defined is so trivial that it needs no formal change management applied to it, then the process transitions to this activity.  In this activity, the agent is asked to add any further information that might be pertinent to the bypass of formal change management before finally finishing the workflow.

The image above shows the task flow for this activity.  The Bypass task asks the agent to provide any further information relevant to bypassing the change management process before the workflow is finished.

Change Request Rejected

The change request has been rejected by the 'Change Management Review' or the 'CAB Review' or the implementation has been abandoned.  This activity asks the agent to provide any further details about the rejection of this change request before finally finishing the workflow.

The image above shows the task flow for this activity.  The Reject Reasoning task asks the agent to provide any further relevant details about why the change request was rejected or abandoned before the workflow is finished.

Customization

The template provides a specific implementation of a change management process.  Having created a workflow from this template, you are then free to customize it to better suit your needs.  Customization might consist of

1. Adding new activities to cover parts of your change management process not covered by the template
2. Delete activities that are not needed in your change management process
3. Modify the existing activities to gather more information or change the conditions to identify which task fields are mandatory to complete the task.
4. Add task fields that are based on Zendesk Ticket fields.  This will enable selected task data to be recorded on the Zendesk Ticket and could be used for reporting purposes.
5. Assign groups to the various 'Review' activities so that these reviews are performed by the appropriate people in your organization (e.g. assign CAB Review to your Change Approval group)
6. Modify or extend the stages of the 'Implement Change' activity to better suit your needs.
7. Expand on the 'Provide Change Definition' activity to capture any extra information specific to you organization.
8. Modify Process Persisted Field definitions to capture Change Types or Change Reasons to better suit your needs.