Guidance on Implementing a New Change Management Process

[Lance Waldrop]

Hi All,

We're in the process of implementing Change Management in Jira, migrating from a legacy system. Our goal is to stay as close to the out-of-the-box solution as possible while meeting our key requirements as efficiently as possible. We’re aiming for simplicity but are open to adjustments if our current approach is too constrained or if there's a better/more modern way.

I’m familiar with configuring all project settings in Jira Service Management and am an org-admin. I'd love to hear from others who have implemented similar setups or have suggestions on how our setup can be improved.

Requirements:

1. Teams & Change Types:

   • Two teams submit change requests: Development and Technology/Operations.

   • Each change request falls into one of three types: Standard, Normal, or Emergency.
   • Each type has specific change reasons (e.g., Standard -> OS/Application Patching, Normal -> Server MACD).
   • Changes are submitted directly in Jira (not via the portal).
2. Team-Specific Change Reasons:
   • Each team should only see relevant change reasons.
   • Example: Development sees Code/Product Bug Fix under Normal, but not Server MACD, which belongs to Technology/Operations.
3. Approval Flow Based on Change Type:
   • Standard changes: Require at least peer approval, but we’re exploring ways to pre-approve certain cases.
   • Normal changes: Require approvals in the following order:
     • Peer Approval (must be first)
     • Security Approval
     • Operations Approval
     • Management Approval
   • Emergency changes: Requires management approval only. 
   • We're used to a strict sequential approval flow (Peer -> Security -> Operations -> Management) and are considering whether to keep this or adjust it.

Looking for Advice On:

• Best practices for implementing team-specific change reasons in Jira Service Management.
• Efficient ways to handle pre-approvals for Standard changes.
• Whether a linear approval flow (Peer -> Security -> Operations -> Management) is still a best practice or if a more flexible approach is recommended.

Would love to hear how others have tackled similar setups! Thanks in advance for your insights.

[Christopher Yen · Accepted solution]

Hi @Lance Waldrop ,

Good to see a post about Change Management / Change Control. 

• Best practices for implementing team-specific change reasons in Jira Service Management.
  • I would suggest exploring the Select List (cascading) field type for Change Reason
• Efficient ways to handle pre-approvals for Standard changes.
  • I'm sure there are better ways but for us we need a Standard Operating Procedure (SOP) documented in Confluence for every standard change and in the SOP I will link to a Change record (Jira Issue) that is a prefilled template for users to clone with just the fields we want them to fill out left empty or with filler text but essentially our standard change catalog is in Confluence
• Whether a linear approval flow (Peer -> Security -> Operations -> Management) is still a best practice or if a more flexible approach is recommended.
  • I think this depends on the company culture, process maturity, and compliance requirements. I'd say just try it out and if there are bottle necks then see where to adjust. 
  • For normal changes we do Peer Approval > CAB Meeting which includes IT and InfoSec and show of hands approval. Many of our teams are on a 2 week release cycle so this works for us
    • One day I'd like to implement a risk point system tied to questions where under a certain number of points only requires peer and change manager approval and higher points go to CAB meetings or trigger security review but again this would only fit a company that prioritizes agility.

[Lance Waldrop]

@Christopher Yen Thanks for your reply!

I would suggest exploring the Select List (cascading) field type for Change Reason

We ended up going with this but slightly different. Since we can't set context on anything but the issue type I saw this leading to duplicate configuration schemes and issue types based on what we wanted our requirement 2 to be. This is what we decided as an example.

Normal

• Development - Code/Product Bug Fix
• TechOps - Server MACD

I'm sure there are better ways but for us we need a Standard Operating Procedure (SOP) documented in Confluence for every standard change and in the SOP I will link to a Change record (Jira Issue) that is a prefilled template for users to clone with just the fields we want them to fill out left empty or with filler text but essentially our standard change catalog is in Confluence

I really like this idea. We're not quite ready for it now but I think it's a cool idea to have some time of check that a confluence document is linked for preapprovals. I'll revisit this at a later time.

I think this depends on the company culture, process maturity, and compliance requirements. I'd say just try it out and if there are bottle necks then see where to adjust. 

For normal changes we do Peer Approval > CAB Meeting which includes IT and InfoSec and show of hands approval. Many of our teams are on a 2 week release cycle so this works for us

One day I'd like to implement a risk point system tied to questions where under a certain number of points only requires peer and change manager approval and higher points go to CAB meetings or trigger security review but again this would only fit a company that prioritizes agility.

We're still growing in our processes and deployments, and there’s quite a bit of crossover since we don’t have a dedicated change enablement owner yet. To keep things flexible, we’re setting up three separate statuses as peer approval placeholders for each change type. For normal changes, there will be an additional status where the rest of the approvers are added. Our previous linear approach was a bit of a blocker, so we’re hoping this strikes a good balance!

Thanks for your help and suggestions!