Change Management Configuration Guidance

[Tylor Seastrum]

I am building out a change management process for my company's IT Department for the first time. This is also my first time being a Jira admin as well as touching Change Management. I am searching for guidance from those who have been in the IT industry longer than me as well as those who have a good understanding of Change Management to build this process.

My workflow if as follows:

I have it currently designed for three separate approval steps:

• Standard (Pre-approval)
  • Only require Peer review approval
• Normal Change
  • Requires Peer approval and then Manager Approval
• Major/Emergency Change
  • if a change request follows this path they will need Peer Approval, Manager Approval, and CAB Approval

I am trying to make this dependent on some custom field radio buttons. I would like help creating a plan to build this form out and more specifically which fields and how those fields may work together to get the best outcome. 

I am curious how other companies run there change management process and how I would be able to adapt and use those ideas to better my companies process.

The two driver radio button custom fields that at the moment might be the deciding factor are as follows:

Change type:

• Standard
• Normal
• Emergency 

(The above would pick the approval path)

Member Impact:

• Small Group
• Department
• Multiple Department
• Full Credit Union
  
  
  

(These last radio buttons are intended to add more specifics for the user to dial in exactly what there change management might fall under)


I would appreciate any advise or feedback about how to structure these radio buttons so that no matter the change i.e. Routine Patch Update, System Update, System Rollback, Changing a system, and everything in between that can happen within the realm of the IT department. 

[Lisa Forstberg · Accepted solution]

Hi @Tylor Seastrum ,

This is a large topic and I am not really sure exactly what you're question is :-D but I try to share a bit of my experience as I have just recently finished deploying Incident, service request, problem and change enablement processes in a car company.

I teamed up with a ITIL expert who took charge over training the operations and development teams and posed requirements on the tool for me to fullfil. It is a real treat for a Jira admin to collaborate closely with ITIL experts.

My experience is that different companies have different ambition levels with their change enablement process. How much of the change enablement process should be automated f ex

It is always good to start with the purpose and goal of the change enablement process in the company. 

My current client have a clear purpose: protect the production environment through controlling (or at least documenting) what gets released to production when.  As many deployments to production cause incidents it is of key importance for the operations team to have access to intel about what was released when. That will shave a lot of time off the resolution time for Incidents.

Also my client have an ambition to automate the creation of changes from the build pipeline. Depending on the maturity of the development teams build pipeline and routines this is definitely possible. Trying out in small scale first is always good.

Speaking of starting small, the change features in Jira is abundant. Depending on the size and ambition of your change enablement process you may want to scale down and hide some of the proposed fields etc. Keeping forms clean and clutter free will help both reporters and agents.

As you already pointed out Changes are of different types. You can use forms to make the input form dynamic - if "Normal" and "Multiple departments" then present more fields etc. You can work with conditions in the workflow transitions to allow for different routes through the workflow depending on type of change.

Best of luck

/Lisa