I wasn’t sure where to put this, so I figured I’d place this in the General chat; I’m currently working at a studio of approx. 300 artists, and we’re working towards shifting our entire pipeline to a ShotGrid pipeline.
I’m am a team of 1 leading this charge, and I want to say that I’m not doing too bad with getting things rolling, with a close imitation of our previous pipeline, but feature requests abound, and we’ve popped a good deal of projects into the software at this point, so time is becoming precious.
I guess what I want to ask is, for anyone who has been a part of the adoption process, how long did it take before you felt the pipeline was pretty much settled, that the bulk of the features you/Production/Corporate wanted were deployed and documented? And how big of a team did you have on hand to accomplish this?
Every studio will be different, but would love to see the wider context from people who’ve gone through the same process
This really depends on many things including:
- how many DCC’s you use
- How many extra servives you may need (AMI’s, Webhooks etc)
- How much your production team and supervisors/lead artists help you with/drive adaptation
However I don’t think any pipeline person will ever tell you its done.
For example, every new client manages to add to the list of demands for deliveries that require automation.
- Multiple exports of the same version
- Exports of your 3d assets and renamed and placed into a specific directory.
While I am in a bit of a different situation, I feel it applies and may help. I use Shotgrid in a University Animation Program where I teach. We use Shotgrid to manage, and teach, the animation workflow for students in production groups in the final year and a half working on their final animated productions.
While I have customised Shotgrid to fit our particular situation, I somewhat leave it up to the students to determine the best use of Shotgrid for their productions. I am the admin and will customise the project templates based on what they want for their productions. This in a way puts it into their control to determine. While I realise that this is probably very different than you may want, or need, I think the tactic of putting them in charge of the process is helpful.
What I have done when getting it adopted in the productions is to find a few students that are key in the project and show them the power and capabilities. This way they become the Shotgrid ambassadors in their project teams. Perhaps that can be of benefit to you, find some people on the team that see how this is beneficial, and let them present how it’s best used to others.
Depending on your workflow, and capabilities, you could use the Shotgrid desktop apps. I was able to get the Shotgrid desktop applications loaded on the student lab computers, so it’s always there for them to use as well. Not sure if you are able to accomplish that though. The Shotgrid Review app is convenient to review and comment on tasks. I also show them Shotgrid RV anytime I review media, and show them the capabilities and how it links to the media in Shotgrid.
Hopefully this all helps. Good luck.
Hey! Yeah, for sure; it’s false hope to assume any part of the process would be “final/done”. If it’s not clients, then updates to the software, or changes within the studio would always beckon for more change (like, Production needs to track a metric we didn’t think to keep tabs on before). And a refusal to change in a world that’s always changing is not always a good tactic for this kind of stuff.
I suppose that’s why I tried to phrase this more as the “adoption” phase; getting people onboarded, getting some initial workflows and automations in place, building up your resources and documentation, etc…
Actually, this is (or eventually will be) fairly similar to my game plan. As you’ve described doing yourself, one of my goals is to try and create standard project templates for our teams; doing that due diligence to see, in the early stages, what works, what doesn’t, what chaffs our creatives XD
This would give everyone the same standard to start off with, which hopefully mitigates the onboarding process, and then provides them a familiar space to grow and expand on their own (once folks with the proper permissions really start learning how to customize their own pages).
Thanks for the advice here! I’ve already set some plans in motion to try and build a team around me that’s confident with onboarding new members without my oversight; get them trained up and more familiar than the average person.