How a PM Can Transform Art Production: A Case Study in AAA Gaming

Disclaimer

While working as a project manager, I often heard comments like: “Why do we even need PMs? What do they actually do? They only talk and nothing more.” It’s a fairly common opinion.

So I prepared an article about what PM can actually do (together with their team) and how impactful that work can be for a project. As we PMs and producers love — with numbers, tables and charts. There are three part about Art Pipeline, Daily Routing Optimisation and JIRA etiquette.

This case come from my personal experience and focus on how we built a Cosmetics department from scratch on an AAA project and ultimately optimized art production, accelerating it by a factor of 3.3.

Thank you very much. Enjoy the read.

Art Pipeline

The Case

Once I moved into production as a Project Manager with a mission: to build a cosmetics department that would deliver skins (and more) for battle passes and in-game events.

At the same time, we already had a character art department. They had created eight characters at various stages of completion and one high-tier skin with geometry changes. Producing that single skin took the artist 16 months.

My task was to establish a functioning production pipeline and fully meet the publisher’s requirements by the release date: 21+ skins with new geometry and 40+ recolors. After that, we had to release 7+ skins of different types every month — and the following year, double those numbers.

Work

First, I analyzed the previous experience and the current production pace of meshes (characters and a skin). Using data from Jira and tons of Excel sheets, we identified several weak points.

Art production roadmap

There was no structured roadmap for character art production in general and cosmetics in particular. Meshes were considered part of the character development pipeline, and all work related to them was placed into three large stages — L0, L1, L2 — from prototype to final polished version. Each of these oversized tasks could exceed the sprint length not just by two cycles, but sometimes by three or even four.

Lack of a standard

Every mesh was treated as an R&D feature. When we compared L0/L1/L2 stages across different cases, we discovered that they took completely different amounts of time — both clean time (logged hours) and dirty time (the gap between task creation, moving it to “in progress,” and marking it “done”). Even the number of tasks for identical types of meshes varied significantly, and some of them had descriptions that were almost impossible to understand.

A separate thing that stood out: one artist assigned to the task worked on the mesh from start to finish (judging by the assignee history). And during production, there were no logical points where he could have handed it off to someone else without losing quality or time. The entire task looked like one huge, continuous block of work.

Lack of process transparency

It was unclear what was happening during development or how it was being carried out. The quality and consistency of task updates depended entirely on the developer themselves. There was no way to track progress remotely or outside the morning stand-ups. If an artist got sick, the lead could partially take over their task, leave no notes at all, and still close it.

Number of iterations

Even from the basic status history it was obvious that the task went to review, then back again, then back to review, and then back to work. And that’s not to mention the complete absence of comments explaining why the task was being returned to work and then sent back again — not a single word.

We gathered with our small circle of Illuminati — myself (as a PM), the principal artist, and the art lead — and got down to work.

Solution

To begin with, we made two important high-level decisions to stop the confusion at the top level.

We introduced grades

Before that, the project was full of a whole range of terms and labels: recolor, paintjob, skin, premium skin, veterans, and so on. Each word referred to a different type of work, which only confused us further. We dropped all of that and introduced a document that clearly outlined the differences between skins and their grades.

“One skin = One epic = One branch” rule

I borrowed this organizational rule from the character development team. One epic includes all work related to the skin on the development side. Each epic contains a single branch and a single pull request dedicated to that skin. In turn, the epic was linked to the relevant season (or event) initiative/feature for easier navigation.

This was our starting point. From there, we rebuilt the entire workflow.

We got rid of L0–L1–L2

Instead, we divided production according to the actual production logic: Design → Geometry → Textures → Implementation.

Each stage was broken into smaller logical steps, for example: \n Concept: Moodboard – 2D Sketch – 3D Sketch (if needed) \n Geometry: Low Res – High Res – FBX File Import \n Implementation: Rig – GD Setup – Art Review – QA

The skin itself was also split into three parts: the body, the weapon, and the modules. Meaning that from then on we could have three separate tasks, such as: \n Body – Geometry Low Res, \n Weapon – Geometry Low Res, \n Modules – Geometry Low Res.

This transformed what used to be a single massive block of work into a Lego-like constructor that could be distributed among artists depending on their workload. Now it was possible to track exactly which stage production was currently in.

The new art production roadmap

Essentially, everything we had done above was laid out as a sequence of actions. This chart helped us — and any PM who might need to replace me during sick leave or vacation — understand where and which processes could be run in parallel to save time.

Unified formatting for Epics and tasks

The epic now contained only tasks related strictly to the skin’s grade — nothing extra.

Each epic included the skin’s concept in its description, as well as the acceptance criteria from the producer.

This reduced confusion and gave the artist a clear understanding of what was expected at each stage. (Later we refined the task descriptions even more, but that relates to the topic of daily routine, which comes next.)

I also set up a separate section appeared in Confluence with a Mira board where all these descriptions were listed for each task, with comments for the project manager explaining when and what task should be created, along with a Jira formula that could simply be copied and pasted into the task body.

Estimations

We tried to break tasks down so they would be easy to plan. The project used two-week sprints, so we aimed to find a common structure: not exceeding the boundaries too much while still giving each task a logical completion point.

Huge thanks to my colleagues — without their experience we wouldn’t have been able to break this down as precisely. Relying only on Jira numbers would have been much harder, because in art production the individual specialist’s skill matters a lot, and when designing estimations, we had to find a golden middle ground between what we could realistically deliver and what we wanted to achieve. That’s how we arrived at the formula that one development step = a sprint plus two days at most.

Now the artist could see how much time they had for each task and how close they were to finishing it. With proper communication, this became a support tool. If an artist saw that they had three days left for a task but understood they wouldn’t make it — they could proactively tell me.

This meant I didn’t have to “control” the developer; they had all the tools to help me and raise a red flag where we might miss a deadline.

As a result, we managed to achieve developer autonomy. When opening an epic, the artist found a ready, fully prepared task they could start immediately — even if they weren’t completely sure what to do at first. We made review sessions and evaluation criteria transparent.

Result

Straight to the point. Numbers only.

That’s the case.

\ \ \