by Kevin Gepford
Quick question: If a task management tool was offered free for your creative group, yet it was anti-collaborative, punchlist-focused, provided no way to visually manage your work, and worst of all was profoundly ugly… if all these things were true, would you accept it?
Who am I kidding… of course not!
But haha this is a trick question — in the real world you might not have a choice. The tragic truth is that creative teams are often forced into using a massively inappropriate tool, chosen by the IT or business sides of the org without any thought to creative’s needs.
That tool has a name. And its name is Jira.
This has happened to me. Twice. 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. The implementation of Jira was simply awful — a ticket configuration so wrong for our Digital Marketing Group that it increased friction, added a ton of noise to the process, and actually created silos where they shouldn’t exist. (Note: Jira was designed for reporting software bugs. Nature never intended this to be used by creatives.)
Since giving Jira the boot wasn’t really an option, I would have to hack the tool to make it work.
This became something of 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
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?
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 the other side of the department — 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.
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.
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” — a provocative title that got 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
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 remained 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.