The Change Management Framework for a Sustainable Jira

Key Takeaways

• Don’t chase a new tool. Most Jira messes can be solved inside your current environment, starting from a basic Kanban template.
• Leadership and the team need different conversations. Leadership defines the “what and why,” the team knows the day-to-day friction, and both inputs provide guidance for change.
• Pilot before you scale. Find your informal Jira champions, test changes with them first, and let their buy-in bring the rest of the team along.
• Saying no is what keeps it sustainable. Every approved change has a cost, and the discipline to decline requests is what protects the system long-term.

A system as robust and complicated as Jira requires a change management strategy to get right. On the surface, starting an instance of Jira, setting up a project space, and configuring some workflows is easy. Without a strategy, it quickly turns into a mess.
In last week’s post, I evaluated the “why” for Jira and the pillars of a good strategy for Jira. To recap:

1. Jira is your team’s work context
2. Jira must work in service of your team
3. Every change has a cost
4. There must be clear ownership and governance

Once you understand why you’re building out an instance and some guardrails to focus your intent, the next step is to build within a framework.

A Change Management Oriented Jira Framework

Go Back to Basics

In most cases, you’re rarely going to be starting with a fresh slate. That feeling to go look for a new product is really the desire to start from a new setup. Do yourself a favor and start a new Jira space with the most basic Kanban template. Imagine how you could run more of the workflows through this basic framework. It is possible within your current environment!

Work with Leadership

Once you understand how simple a basic space can be, the real work can start with leadership to peel back all the layers and get back to the basics of what is needed. What is the goal leadership has for this tool? Is there specific data to track? Is it for planning work? Is it for roadmapping? What are the 3 things Jira must do for leadership? Work with the leadership team to figure out what is driving their intent for the use of the system.

Talk to the Team

The team is living in Jira and, most importantly, it needs to work for them. I guarantee you that your team knows exactly what does and does not work with Jira. They have all the answers. What information do they need to see? What gets in their way? What do they think needs to change? Bring these types of questions to your team and they’ll bring you some quick wins. Jira should be a tool that helps the team understand and find their work. If it’s not easy and frictionless for them, it’s always going to be a struggle for project leads and leadership to get information out of it.

Review Before You Start Building

Before you start building, put together some visuals and proof of concepts. This can be a great way to leverage an AI tool to produce some visuals quickly. I also like to use Confluence to diagram workflows or make choices like fields for a screen more interactive. Rather than putting users in the Jira administration to drive changes for their team, I give them a simpler, more familiar playground. They use these tools to communicate what they need and then I can build it in Jira.

Design for Reuse

This one feels obvious, but it’s just as easy to paint yourself into another corner and create a mess for future you. You’re going to need to understand Jira’s capabilities. It’s also going to take some pushing on leadership and the team, but the more you can leverage shared settings, shared workflows, permissions, and layouts, the simpler it is to maintain. It’s easier for the team and leadership too. Keep the team at the front and center as you solve for a main table setup. This is especially true for cross functional colleagues who might be across different project teams. These teammates face unnecessary friction context switching and remembering which tickets can move to what statuses depending on the team.

Pilot It, Then Scale It

Find a group of people who already help others with Jira and get excited about helping develop new workflows. Give them early access to the changes and let them test for a couple weeks before expanding access. Make sure to listen and incorporate their feedback. Once they are bought in, they will help bring the others along. From small-to-large organizations, change is always hard for individual colleagues. They are focused on doing their jobs, and while change will make things better in the long term, anyone used to the current setup has to re-learn something.

Document It

Some light documentation should be produced, especially for end users. They should have information available on the basics of the setup, how changes are proposed, and current configuration options. Don’t go overboard in this area or you’ll have more to maintain as things change. I find giving users information on the workflow options, how to request project setups, and where to get help is a good enough baseline setup to have documented.

Establish Ownership and Governance

It should be clear within the organization who the “Jira person” is. The person or team responsible for the environment configuration, communicating changes, and maintaining the setup should be available information. Regardless of organization size, administrator access above the space level should be reserved for this group.

Learn to Say No

This last step in the framework is the most important. The environment doesn’t stay simple and clean without a lot of No. It’s to the benefit of any organization’s systems to have structure and repeatability in order to scale. The individual Nos to people may be difficult at times, but it’s to the benefit of the larger team. Without the authority to deny every field, status, and change request across projects, you will quickly find yourself cleaning up Jira again.

Where Expertise Comes In

This change management focused framework for Jira will help you get your Atlassian house in order. No environment is perfect, but having a strong setup makes it easier for teams to focus on their work and forget about the tool. It also makes it easier to interact with the system through third-party integrations and AI or MCP tools.

One part of the puzzle I see missing in environment after environment is someone in the change management process who understands Jira, Confluence, and the Atlassian tools front-to-back. Without understanding the capabilities, it’s so easy to over-engineer. You need real expertise to stop wasting time.

This is the work I’m doing every day for my clients. Helping them understand the capabilities of the Atlassian tools to align with the needs of their team.