Before my current position at Autodesk, I did a lot of freelance consulting for studios using Shotgun. Usually a client brought me in because they liked Shotgun as a product and could see that it could have a big benefit for their bottom line, but they knew that the way they had implemented it was less than ideal. They didn’t know how to fix it, but they knew something was wrong, and now that they were already using the tool in production they needed help to backtrack and change their configuration.
Now that I’m working with the Shotgun presales team, I’m much more likely to talk to clients when they are first getting started. It is a lot harder to fix a database that has gone indescribably wrong than it is to set one up correctly at the beginning, but it is also hard to know how to set something up correctly when you haven’t used the product ever before.
Here are 5 simple tips to help you get started on the right foot.
1. Start with one project
It is a lot easier to roll out a new pipeline for one project than to roll it out across an entire studio at once. It makes it easier to change course if it turns out something isn’t working, and it lowers your initial investment of time and resources. Shotgun comes with a free 30-day evaluation - that may be enough to get you started on one project. If you need more time for an eval, reach out to support and we will do our best to accommodate.
When I’m helping studios choose their pilot project to try out Shotgun, there are 3 things that we look for:
1) Avoid enormous projects for your pilot. Trying out something new is easier on a small or medium-sized project.
2) Avoid a project that is radically different from the usual work you do. If it’s a one-off situation, what you learn from the pilot might not apply to the rest of your workflow.
3) Most important, choose a project where the team working on it is excited about trying out something new.
Everyone has a different appetite for risk and change; some skepticism is healthy, but if someone is cynical about any improvement you might want to introduce them to the new pipeline after someone else has tried it out first.
These three criteria can be summarized like this: choose a project that is not too big, not too weird, and not too cranky.
2. Make a roll-out plan
Once you know which project you are using to try out with a Shotgun data-driven pipeline, it’s time to come up with a plan. We look at pilots in three phases.
This is just taking a look at what kind of pipeline you currently have. This is the most important step in the roll-out process, even for studios with relatively simple pipelines. Take the time to talk to the people doing work at your studio and find out how the work is actually getting done today. Often there will be some surprises - tools aren’t always used the way they were originally intended. Because a pipeline is made up of people, it is always changing and adapting to new circumstances - so starting with a discovery process can help avoid surprises later.
This phase can take on different shapes at studios. If there are a lot of automated tools, you may need to allocate some time to get those working with Shotgun. You will also need time to build out your Shotgun pages and configuration. There is always some training needed for the team. Even if your team has used Shotgun before (and that certainly helps) you need to decide how to set it up at this particular studio for this particular workflow. This is a good time to reach out to support for a tuning session and someone from Shotgun Street Team can help you configure your Shotgun site to match how you work.
This is the term we use to describe the first few weeks of using Shotgun in production for the first time. We want and expect that you will use our support services more heavily during this period, usually the first 2-6 weeks after Shotgun goes live. This is when any big issues with the new pipeline will become clear, so you want your team to be ready to address them quickly. This is also a good time to look for small usability issues with your setup that can be easily fixed early on in the process and will save time and frustration later. These won’t always get reported - you may have to seek them out by talking to your team as they’re ramping up.
After the first few weeks of use, Shotgun should become a natural part of your workflow. From that point on, you will continue to maintain and develop your pipeline as you did before, but with Shotgun now integrated into it. You can then start rolling out Shotgun on other projects at your studio, repeating the phases above.
3. Ask for help
We have a lot of resources to help clients who are getting started with Shotgun. As I said before, it’s a lot easier to set it up correctly at the beginning than to correct it halfway through - and we have resources to help you with that too.
The Shotgun Street Team should be the first place you turn for help with Shotgun. You can create support tickets at our support site or by emailing firstname.lastname@example.org. Street Team is a small team of industry experts, and you will get to know them personally if you reach out for support. They have all been on the other side as clients before they joined our support team, so they understand your pain.
Pipeline Services Team
The Shotgun Pipeline Team offers help with on-ramp and integrations (such as new Toolkit setups) on a consulting basis. They can come to you for an on-site tuning session, on-site training, develop custom solutions, or implement a variety of specific pipeline tools that match your workflow. Reach out to support and we will put you in touch with someone about a visit.
Online Documentation and Forums
Our support site includes online documentation, training videos, and a forum where users ask questions and share feature requests. You can create support tickets, check out our forums, and make feature requests all in the same place. Shotgun developers also have a user group where they share tips, tricks, and pipeline woes to a community of like-minded folks.
Both the Street Team and the Pipeline Team can help you at the beginning of rolling out a new Shotgun instance, and they can also help you improve your setup once you are up and running. The Pipeline Team offers some of the same services in terms of tuning and training, but they will go more in-depth, like coming on-site and delivering custom code to help you automate and integrate key parts of your workflow. Pipeline Team work is negotiated as a separate consulting contract from your Shotgun licenses.
4. Configure Shotgun to match your existing workflow
Everyone can see ways that their pipeline needs improvement. When you introduce a tool like Shotgun, there is an opportunity to take stock of the current situation and possibly streamline how things are done.
However, it is usually a mistake to change your workflow in order to match a new tool. Shotgun is highly customizable, and the more you are able to match Shotgun to the way you work currently, the easier the transition will be.
Because it’s so easy to make changes to the configuration in Shotgun, you can further develop your pipeline as you continue - in fact, you can never really lock down your pipeline completely. Pipelines are always changing. The hardest part of making the switch to a new tool is helping people become accustomed to a new way of working - and that transition is easier if the new tool matches their old habits as closely as possible.
Most of the time you are working under a deadline at high performance: your team depends on having their work be second nature. Make changes incrementally, and it will be easier for them to incorporate the changes into their workflow. If you need to make big changes, account for the adjustment time in your schedule.
We don’t, however, recommend keeping production managements systems in place simultaneously on the same project. Sometimes there is a temptation to keep the old system and the new system running in tandem, so you can really compare apples to apples. No production team wants to enter data into two redundant systems -- either integrate the systems together or cut the cord and enjoy the benefits the new system brings.
5. Collaborate with your team
I talk a lot about data-centric pipelines because I believe that basing your pipeline on a flexible, metadata-rich database will make your work more efficient. But pipelines aren’t just data. Pipelines, first and foremost, are made of people doing work. Those people may use tools, and those tools may generate and share data--but when you’re looking to improve any part of your pipeline, it’s important to collaborate with the people actually doing the work.
We advise against what we call the "eat your spinach" approach to rolling out new pipeline tools or processes. It rarely works to say, "Everyone start using this now because we said so and you have to." Show people the shiny new media they can view, the crucial data that is automatically updated where they used to hunt for it, the painful process that is now reduced down to one click. You will have a hard time keeping them away from the new system.
On the other side of the spectrum, sometimes I hear clients say, “We don’t have any pipeline! We just need something, I don’t care what.” This also isn’t true. Everyone has a pipeline, but some pipelines are more manual and some use more automated tools--and you do care about your pipeline, even if you aren’t happy with it right now. It affects your costs, your ability to meet deadlines, and your experience at work. This is why I put a lot of emphasis on the discovery phase of the roll-out process, more so even than integration.
Some pipelines are more organized and some are more improvised--each comes with benefits. A very manual, improvised pipeline is also extremely flexible. This can work great for small teams, but often becomes a problem when the team begins to grow. A highly automated pipeline is great for efficiency but can become too rigid and require a lot of overhead when your workflow needs to change.
The important thing is to recognize that you have the pipeline you have for a reason, and it was developed over time by your team so that they can get their work done. Take the time to find out how they are currently working and why that method was developed.
The only example where someone really doesn’t have a pipeline is a new studio starting up that hasn’t done work before. In that case, don’t try to solve everything in advance--expect to make changes as you move forward.
No one can provide a “pipeline-in-a-box” that works for everyone, but we do have experience seeing hundreds of pipelines in action. We can recommend best practices as your pipeline evolves. A pipeline is always changing like a living organism. We give you flexible tools that you can adapt to how you work, but it’s a good idea to start out by doing a little research to learn about your own process. Our Street Team can help with a tuning session or our Pipeline Services Team can offer you a comprehensive pipeline assessment.
I hope that this gives you a little insight into how we approach the process of rolling out Shotgun at a new studio. If you are thinking of trying out Shotgun and you have any questions, please don’t hesitate to reach out. We’re here to help!
About Eli: Eli has been working in computer graphics, animation and visual effects for 20 years. He has worked as a production manager, pipeline developer, and virtual set operator. Before joining Autodesk, he was a freelance Shotgun consultant helping studios to optimize their Shotgun pipeline. He is also an award-winning filmmaker.