The Post Production Spec; Defining Your Requirements
The specification - used in a bid, tender, RFP/RFQ, or simply to provide vendors a starting point, has been the source of frustration for many a sales engineer. Not because we wish that we could provide all the features that are listed, but because we can’t help but wonder what the author was thinking. Creating a spec should be like designing your ideal product on paper, and asking a vendor to come as close as they can to that ideal. Unlike most other forms of shopping, you avoid the sales process until the salesperson knows exactly what you want. This is good in some ways, but very limiting in others.
I dislike auto industry comparisons because cars are personal and subjective, but in this way you can see the difference in spec vs. evaluation and research. Imagine writing down all the things you want in a car, and showing up at the dealership looking for a match. You want power, beauty, technology, sports-car handling, and seating for 7? Your chances of finding the exact car you want are slim, unless you’re willing to compromise or adjust your budget. The same goes for facility shared storage. Many customers get hung up on the details and refuse to prioritize the important aspects like usability and sustainability, and end up getting quotes that are 2-3 times their expectations of cost, for systems that don’t perform the day-to-day work any better (and often perform worse).
There are three ways to design a specification:
Based on Your Workflow
By far the best method, and will result in the easiest path to getting what you want. Go ahead and plan for years down the road, and challenge the vendors to keep up with your trajectory. Keep it grounded in what you believe is important to your business. This should include data security, usable administration, and efficient management. Lay out your needs for backup strategy and how you’d like that to be automated, and be sure to prioritize these requests so the vendor can focus on what’s most important to you. Be sure to clearly state the applications and what they will be requiring from the storage, and how you expect them to work with the storage. This is highest priority and the true test of a successful shared storage deployment – can you work reliably and consistently to generate revenue. These are my favorite types of specs, because we do platform and application compatibility better than anyone else on the market.
Based on Committee
Some facilities are the victim of their own size and budget. When there’s an active presence from the IT department, or the dollar amounts get too high, it’s not just up to the creative folks to select the right product. The committee can include consultants, system administrators, finance and production management, and everyone wants to justify their existence at the table. People with experience in enterprise storage and “big iron” systems will lean on their past knowledge and add terms like “five-9s uptime”, “no SPOF”, “single namespace”, “multi-path”, and “Magic Quadrant”. In the enterprise storage world these would be important, but they don’t force vendors to take responsibility for priority number 1 - the interactions between the creative applications and the storage, and the usability and sustainability of a solution in the long term. I see these types of specifications and I know that there will be a rude awakening when the quotes are distributed, usually leading to some modifications of the spec.
Based on a Product
The most limiting way to design a spec is by copying the feature list of a single product to create your requirements. I should mention that I help my customers to do this on occasion, so I’m guilty here. When a customer really knows the market, and wants to avoid being bid an inferior product, this can be justified. However, you’d have better completed your research beforehand, because there may be something out there that could change your opinion, and you don’t want to find out about it after you’re locked in the status quo. If you chose to do this, but want to stay on the lookout for another option, simply prioritize the feature list by what’s most important to you. If you really like something about your storage, prioritize that and see if another vendor has something similar. When I respond to these bid specs, I always provide details on our solution and how we can achieve better results than the one that is obviously being requested. Sometimes it works, sometimes not, but at least now they’re educated.
The primary frustration with specifications that miss the mark is the waste of money and time. Enterprise storage features come with enterprise storage price tags, and enterprise storage complexity. This requires training or reliance upon the IT staff to manage, or in some cases completely control the network for you. By dialing back the high-end feature sets, cost savings in the infrastructure can be re-purposed to revenue-generating workstations and artists can be employed instead of full-time techs. There’s a reason that scrappy, grassroots facilities grow faster and larger facilities tend to stagnate. They focus on generating content, invest only where needed and scale the storage as the bigger jobs and larger formats arrive. Stick with a company that makes the process easy, and ensures that you’ll never be without a support person that knows your daily grind. That’s not a big iron company, that’s Facilis.