Summary: It sometimes happens that creative teams are given a digital tool that might not be best suited for their needs. Jira is a great example — it might be brought in by the IT department as a “safe” choice without understanding some of the core needs of its potential users. But all is not lost. Despite Jira’s reputation as sub-optimal for managing creative work, you can make the best of the situation if you know how to create a ticket type and develop workflows that are more friendly to your needs.
It’s happened to me twice.
Two times I’ve faced Jira as the mandated tool in my creative workplace.
The first time, at Comedy Central, I just shrugged and tried to make the best of it. Second time, at AT&T, was a different story. I decided to fight. Our existing implementation of Jira was simply awful — a ticket configuration so wrong in our Digital Marketing Group that it increased friction, added a ton of noise to the process, and actually created silos where they didn’t naturally exist. (Note: Jira’s roots are in the world of software, originally designed for reporting bugs. You can often understand a lot about a tool by knowing its original purpose, and where it evolved from.)
Since giving Jira the boot wasn’t really an option, I would have to hack the tool to make it perform better for us.
This became a Product Manager challenge. I worked through as much of a classic development process as made sense to establish a baseline, then…
- Figure out what the problem is
- Identify solution
- Build the solution
- Test and iterate
- Launch!
1: Admitting the Problem
Here in my Digital Media Group, it’s the Producer who generally initiates a job by opening a ticket.
- Noise and Busywork. Our existing creative job form was at least 65% irrelevant for our creative process. The form contained excess fields we had to skip over, as well as mandatory fields that served no purpose for us. This forced users to enter text like “N/A” in several places just to be able to save the form. Yes, terrible.
- Inappropriate. The form was poorly structured, with generic fields that didn’t help… and over-specialized fields that bogged us down.
- Fragmentation. A single job could get chopped up into as many as four separate “subtask” tickets. Because Jira hates collaboration and will not let you assign one ticket to multiple people. If you wanted a Designer and Copywriter (not to mention their managers) to be on the same job, you’d begin with a master “tracker” ticket. Then duplicate it as needed for each of the various participants. These tickets were sort of linked to each other, but conversation threads were not. So, chatter on one ticket was completely invisible to the others.
- Isolation. Jira pretty much forced each person into their own rabbit hole, and managers had no easy way of seeing the bigger picture, or even knowing who all the stakeholders and participants were.
- Spam. Jira was a spam machine. If you make a simple edit, such as changing a comma to a period, Jira will spam every single person on the ticket. Imagine multiplying this by 1,000 — on a daily basis — and soon any relevant or useful information gets drowned in a sea of noise. This was by far the biggest pain point for the team.
- Scheduling. Dates and schedules were put into the “Job Description” text field because there was no where else for that info to go. The form had only one date field, titled “Due” — a term that meant something different to each participant. In other words, it was basically useless.
- Mystery. Finding context or useful information was a treasure hunt, due to subtask
2: Road Mapping
Whew — where to start? I plotted my roadmap around high-level issues and questions, knowing that improvisation would be my modus operandi for the actual journey.
- Can Jira actually be adapted, in this company? If so, who do I contact, and how does the process work?
- Who within my group was an expert on existing processes, and did they also have good opinions about what currently work… and how it could be better?
- Within my group, who would benefit the most from any changes?
- How can I conscript people into helping me with research, testing, etc.?
- What were the biggest risks?
- Who outside my group might be affected?
3: Researching
I started off with some personal observations and some hunches. Based on what I was hearing from my own creative teams, I had a clear idea of pain points and issues on the creative side. But what about on the other side of the house — the folks who took in job requests from our business-unit partners and initiated projects within our group? That was where Jira first touched our workflow. It was the source of all our pain, and I needed to understand all this a little better.
Job intake was where Jira first touched the creative workflow, and it was the source of all our pain.
This called for focus groups — one for each of our three areas of business. With each group I took stock of the existing Jira form and we stripped out all the crap. Then I said: Let’s shoot for the stars — what do we wish Jira could do? This gave me some great insights into the various pain points, what was currently working OK, and actionable ideas for making it better. I showed my findings to the creative team for their feedback, and made one last loop back to my focus groups to get their final thoughts.
However, my research would not be complete until I waded into the murky waters of Jira itself. I needed an expert — a company insider — who could help me. I eventually found my Jira admin in an office located on the other side of the country. The two of us had several great conversations about how much the tool could be configured, options I could exploit, practical limits to what I wanted to accomplish, and the established process for getting there.
4: Discovering
My research findings boiled down fairly concisely to a few achievable points.
- Eliminate spam. Let users “Opt In” or use “@” mentions to send comments to a specific person.
- One ticket per job. Put all the information in a single ticket, including entire creative team, stakeholders, and deadlines.
- Tighten up the form. The job form should guide creators to define the work in a clear linear fashion, and to think about what needs to happen (and by whom) downstream in order to get the job done. In other words, less prose and jargon, and more clearly defined actions and deliverables.
- Dates and deadlines. I discovered nine different dates that mattered to various members of the team, during the course of a project. Instead of putting that in prose form within the Description field, we could set up calendar widgets that could power sophisticated searches and dashboards.
- Clearer roles. Unlock the power of custom fields to gain better insight into each job’s participants. Create custom fields for various roles within the team, so a single job could be associated with multiple people.
5: Bettering Jira
Jira is designed to be very configurable. Corporations, not so much. My hack was more in the corporate sense — in that I needed to change a process, and create a new technological solution, within an environment that was resistant to change. Every step forward required a workaround. But I had found my Jira ally. All I needed to do was write up my requirements in a format that adhered to the corporate process. Then, some waiting was involved. Once the new “issue type” was completed and tested, I asked my focus group members for their critique. Their reaction surprised me — almost total approval. Their minor comments and suggestions were easily accommodated.
6: Training
Within a week after launch I was conducting all-hands training via teleconference and screen sharing to our team across five states and three time zones. I invited the whole group to “Come See Jira Suck Less” — and my sensational title helped get the high turnout I needed. (FWIW, One of our copy writers also nominated it for “Best Meeting Title, Ever”!)
My communication plan focused on two very different types of users:
- People who created the job request tickets
- People who receive the request and produced the work
Not only would these groups see the form from very different points of view, but also their risks, and necessary behavior changes, would be different.
In general, however, the new form allowed for a more nuanced state of our projects — making use of “workflows” rather than the binary Open/Closed. Also, with auto notifications turned off, users needed to “opt in” to receive updates, they would start using “@” mentions for comments with intended recipients, and dashboards would finally be useful.
With a VIP approach, I stood a greater chance of getting everyone on board.
7: Evangelism — The Personal Touch
I know how training sessions work — you can’t expect everyone to remember everything you say.
Personal attention gets much better results.
So I put on my concierge hat and followed up with all 75 or so team members across the country, checking them off a list as I made my rounds. I had my own reason for being so obsessive — risk avoidance. Success depended on total user buy-in, and adherence to the new ways of working. With a VIP approach I stood a greater chance of getting everyone on board.
Plus, I wanted to make sure everyone understood the benefits not just for them as individuals, but also for the entire team.
- Less Noise — reduced duplicate tickets by 75%
- No Spam — eliminated all the useless notifications
- Collaborative — Copy Writers and Designers brought closer together
- Visibility — See all the participants and stakeholders in one place
- Tracking — Date fields allow user in any role see just the deadlines they care about
Postlog:
Adoption was immediate, and nearly universal. The new process was familiar enough that it wasn’t a shock, and the benefits were pretty obvious to everyone. Within a week and a half all but the most recalcitrant users were on board.
Those last holdouts remain a personal challenge — for me to see how much I could accomplish with persuasion and patience. We’re getting closer. But ultimately, the stragglers will get on board because I hold the trump card: I’m responsible for our traffic team. When the time is right, Traffic will start bouncing old-style tickets back for a do-over. This will bring compliance to 100% in short order.