We’re definitely aware of the downside associated to the restriction of being able to map only one Department to a Pipeline Step. Indeed, we do support mapping multiple Pipeline Step to a single Department but not a single Pipeline Step to multiple Departments. This all about being able to categorize tasks workload properly in a single Department.
We did see this pattern of using a combination of Asset Type or other properties with a single Pipeline Step to map to different Departments. All the solutions that we evaluated to be able to deterministically distribute the task workload to a single department out of many were not clear or easy enough to use. Duplicating the total workload in all Departments does not make sense neither nor distributing it in equally.
In the end we went with what we call a “golden path” approach. As we understand that adopting a 1 Pipeline Step = 1 Department coupling might have some implications, it is really what we recommend (the golden path). Hopefully, adapting to this way of using Pipeline Step and Department is something that can be considered to be able to leverage Resource Planning for those departments.
Hoping this sheds the light on the reason behind the restriction. We’re definitely open to suggestions and ideas related to this though.
Thx again Brandon for dropping your relevant questions here! High value! Definitely worth sharing!
LB
Thanks for splitting this out to a separate topic, Luc.
I don’t see how we can make use of this new tool without completely rearchitecting the paradigm of how we organize and schedule work by Departments here. We’d need to go hyper-granular with pipeline steps to be as specific as “Character Modeling”, “Character Texturing”, “Character FX”, etc. That seems to go against what clients have been advised to do over the years, which is to abstract common tasks/workflows between departments so you don’t have this over-inflated set of pipeline steps.
Should I submit this feedback to product board? Is that still being monitored?
Yeah it’s definitely worth submitting to the product board. Would a limited solution only targeted at Asset and performing specific Department association based on Asset > Type – Pipeline Step pair be sufficient you think?
That sounds like it could work as a way to designate which Asset Types belong to which departments. With that sort of setup would any Tasks on those Assets would be attributed to that Department?
Hello again @brandon.foster, let’s explore possible solutions here so that I can add more precision to the improvement request. Basically, I’m wondering if having an option to map specific Asset Type + Pipeline Step pairs to a given Department would be sufficient.
For example, the default Pipeline Step > Department mapping could be overwritten for a specific Pipeline Step A on Asset of Type X if a “pair” mapping is present.
So for example, in the example here the workload of a Task in the “Model” Pipeline Step could be attributed to the “Character Modeling” Department for Assets of Type “Character” or to the “Environment Modeling” Department for Assets of Type “Environment”.
When no “pair” mapping exists then the single Department associated to a Pipeline Step could be used. So for both Asset of Type “Texture” the Pipeline Step Texture would map to the single Texture Department.
We need a heuristic to be able to categorize workload in a single Department basically. Would strictly relying on Asset > Type / Pipeline Step pairs be sufficient to cover your use case?
Thanks for the example, Luc! This may work for us. Would it be able to attribute multiple Types per Department? For example we may have multiple Asset Types that the Character team would be responsible for (Character, Creature), or Hard Surfacing team (Vehicles, Weapons).
Sure, a solution like this would allow to map multiple Types / Pipeline step pair to the same Department. Similar to how multiple Pipeline Steps can currently be mapped to the same Department. This isn’t an issue.
Good to hear that a solution like this might work with you. I’ll bring/connect this info with the Product Board proposal.
Is there a way to leverage the department the person is in? Or does that complicate things further?
Our production team is department-based, so we’ve built our schedule pages based on the department the person is in, rather than the pipeline step to give us more flexibility.
Are you saying that, for task workload categorization should be pulled from the AssignedTo > Person > Department?
As we’re looking at computing workload for Tasks that are scheduled but potentially not assigned yet, the “artistic resource department” required by that specific task needs to come from a Task property. That’s why we’re relying on Pipeline Steps that are actually connected via a Link field to the person Department currently.
Maybe directly being able to assign a Department to Tasks would work better for you? Even if it’s close to a Pipeline Step information duplication…
Thx for jumping into the potential solution exploration
I guess I’m wondering if you could do a mixture.
So if the task is assigned, pull from assigned to > person > department.
If the task isn’t assigned, use pipeline step > department.
In regards to your second thought about being able to directly assign tasks to departments, we currently do this by using groups. We have “ToAssign” groups that can be assigned to any task under any pipeline step. i.e. both groups below can be assigned to our model task under model pipeline step:
“ToAssign_ENV”
“ToAssign_Model”
We haven’t gone as far as giving those groups a department, but I assume we could.
Our task template for ENV assets, have their model tasks assigned to “ToAssign_ENV” group.
Our task template for character type assets will get assigned “ToAssign_Model” group.
Our schedule page filters are something like, if any:
assignedTo > Person > Department > ENV
assignedTo > Group > ToAssign_ENV
What about just having a department field for the task itself? We use a mixture of filtering by the department field in the task and filtering by the assignee, depending on if we need tasks that havent been assigned yet.
@samantha.thrupp This “assigned to” override idea is interesting. It would solve differently a case where a Task is assigned to Artist in a different Department. We’d basically move the Workload to the Assigned Department. Right now we keep the Workload in the specified department and highlight that it’s assigned to an artist not part of the department instead. This is interesting.
The “ToAssign_X” Group concept is interesting as well. Basically it species that the Workload could be tackled and compared to capacity of multiple Group/Department. I feel we should join a functionality like this with being able to understand the “could” vs the “strict” workload needs.
@xizted Having a department field is definitely a considered solution. How do you feel about having to maintain both the Department and Pipeline Step fields and potentially having to keep those in sync? This seems like the major usability drawback of that approach.
We use pipeline steps for pass definitions, so our pipeline steps are “Beta”, “Alpha” and “Previz” just as an example. As pipeline steps and departments contain very different kinds of data, it makes sense for us to maintain both fields .Our departments work with basically all pipeline steps, so the current way resource planning works is unusable for us.
I understand, thanks for sharing with us how you’re using Pipeline Steps. I clearly see the need of a “Department” field on Tasks with a usage pattern like this and the fact that it’s not an issue for you to maintain both fields.
Hello Luc, how are you? 2 years after this message, I’m facing the same issue. Is it possible to apply this solution to my pipeline I’m working with? Thank you very much.
Always happy to brainstorm this stuff