How to get your non-development teams on board for using JIRA Software
Background
As a Jira Administrator, I am passionate about helping others get the most from their Projects, especially within my current workplace. All of our software development teams use JIRA Software. Initially, our non-development teams were not using Jira within their current working processes. Fortunately for me, I was not the only person to notice this opportunity.
If you’re short on time, feel free to skip to the TLDR at the end of this article! Otherwise, grab a mug of something and settle in for some best practices on getting your non-development teams on board with Jira.
How it starts
The initial idea of using Jira was suggested as a way to help the Sales team with their Change Management process. They needed a tool to help track incoming change requests and to report their current statuses, Jira fit the bill.
This was informal, word-of-mouth, my colleague was not actively searching to change the Sales team’s Change Management process. Understandably the Sales team, like any team with established working processes, needed to carefully consider any changes to working practices, ensuring clear business values are apparent, as any negative impact could affect client relationships and potential business.
This is the crux of “how it starts”: we apply a gradual process of gathering requirements for teams and groups of individuals that could attain positive outcomes from using Jira. Be aware though, it is likely to be difficult to change the tools used by other teams without buy-in from their Department Leads. Instead, you need to show potential users that Jira will get them what they want with greater ease and accuracy than their current system.
Breaking down the barriers
So, you have some buy-in and you want to maximise its potential. Time for a meeting!
I sat down with a representative member of the Sales team, listened to their issues, reassured them that I could create a solution that would be specific to their needs from the information they provided to me at today’s meeting. Oh, and of course, thanked them for their time.
I completed all the heavy-lifting and custom tailoring for this project before the next meeting. After building the tailored experience for the Sales team, I had a new board, a new issue type, new fields, a few custom field configurations, and of course existing data imported from their current system. Focus should always, at first, be on project structure and content so that when it comes time to hand over the project, the Sales team is ready to dive in.
We must crawl before we can run
It is the day of the demonstration and I have thought about what I want to present, how I am going to present it and when I am going to pause for feedback on aspects of the solution. I started with the Kanban board, showing the Sales team the big picture of their entire process for managing change requests. There were existing change requests present on the board already (data migrated from the current system to JIRA) to enable the Sales team to see how and where their change requests were represented. Next, I moved onto creating a new Change Request in the project and demonstrated where new requests would be displayed on the board.
From there, I gathered feedback that highlighted the team’s reservations about using a new tool. To mitigate these concerns, I explained clearly that I would make myself available to support them with the onboarding process directly, and we could work on a schedule to transfer all content from one tool to the other.
Tip: If you are going to demonstrate to a prospective user, try to relate the initial part of the meeting to their current system or known content, this will help put the prospective user at ease as it is familiar to them.
Give the prospective user only what they have asked for, nothing more as this will only confuse them and strengthen their resolve to retain their current tool.
Where do we go from here?
The demonstration was complete, the Sales team was happy, and all I could do was think, “Ah, I should have shown them how to set up Components” and, “Oh no, I could have automated some of their workflow steps to make things easier for them.” However, I had set up everything as the prospective user had asked (no more and no less), fulfilling the users requirements and expectations. Attempting to make changes to improve the project at this stage would generally be counterproductive as it is likely to overwhelm any new user.
There will always be opportunities later to respond to further questions and make suggestions for improving their project when new users are familiar with Jira. Providing the aftercare support allows you to speak directly to new users and introduce new configurations gradually that will positively affect their project.
(TLDR) Too Long, Didn’t Read
I find reading through long articles just to find the main points very time consuming and I lose interest quickly. With that in mind here is my breakdown to bring any type of team into your Jira instance.
- Actively listen to people about their problems regarding tools and team processes; you may have a potential solution for them.
- Reach out to senior members within your organisation who have a positive interest in Jira. Ask them if they know of any issues that other teams are currently experiencing.
- Speak to one of the members within the affected team (it does not have to be the team lead). Find out if they are having issues with their current tool, what limitations their current tool has, and what the team would like to get out of their current processes.
- Plan out a viable Jira solution for the team (No need to implement in Jira at this stage as it could be wasted effort if it turns out the team isn’t amenable to the change).
- Speak to the affected team’s Department Lead (either formally in a meeting or informally), ask them if they have any limitations with their current system. Let the lead know you have been working on a solution and ask for a date they are free for a demo.
- Build your Jira solution. Try to match the project with the team’s current tool and add existing content (A familiar tool is an easier tool to transition to).
- Get feedback and ask if the Department Lead would like to trial the solution. Offer active support where possible.
- Actively listen for feedback 😊.
Let me know if you have any questions about moving non technical teams to Jira in the comments section below!
11 comments