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:
Teams & Change Types:
- 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.
- 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.