When Mac OS X Lion shipped I suggested on that churches hold off on upgrading. Afterwards I realized that my many years of experience in IT, with a lot of it in schools and churches, could be distilled into a series of recommendations for people implementing projection systems. This is the result.
Upfront, I make no apology for the fact that most of what I'm about to recommend costs money. However, I realize that everything listed here has an opportunity cost. It's up to you to make the best decisions with your organization's resources. Not to mention that the church has thrived for 2,000 years without your projection system. If it fails one Sunday, it will not be the end of the world.
To paraphrase Master Yoda, "Winging it is the path to the dark side. Winging it leads to surprises, surprises lead to stress, stress leads to broken relationships."
I'll start with the topic that the tweet covered: planning and testing. Specifically, when you are introducing something new such as a piece of equipment, a software update, or a changed environment, planning and testing are incredibly important. It is best to have test equipment especially where software updates are involved. ("Wait. A whole computer just for testing?" Maybe, but more likely it doubles for another function not-critical to your presentation system.)
Start as early as possible on implementing your change, especially if you don't have test equipment. If you meet weekly, start right after one meeting to give yourself the maximum amount of time to complete the change, test it and fix any glitches. I was personally involved in an equipment upgrade that started on Saturday morning, with a Sunday morning deadline. It unexpectedly turned into an all-nighter lasting until 5 am Sunday.
I've also watched equipment be tested for the first time during a soundcheck. It's not the right moment. People are preparing to lead worship. Don't let your lack of testing and planning distract them.
A special note for portable churches: I appreciate that it's more difficult to test new equipment in your environment given that you don't have 24/7 access. Your planning and testing cycles will need to be longer to handle this.
The discussion on running current versions of software tends to be polarizing. The conservative position favors the "devil you know" older version and is risk averse to introducing new versions.
I favor a more liberal approach. I'll tell you why.
- Newer versions are more feature rich.
- Newer versions have less bugs.
- Software development techniques tend to improve over time on a given project. For example, testing that is introduced, say to detect a bug or class of bug, is very rarely ever removed.
- If the latest version is not widely deployed, edge case bugs and newly introduced bugs, called regressions, are less unlikely to be uncovered.
Read the documentation
"A month in the lab will save you an hour in the library."
In other words, much frustration will be avoided by referencing material provided by vendors for your benefit.
Backups are an incredibly cheap insurance against the inevitable failure of your hard drive. Make sure you regularly backup not just your presentation application's data but your fonts, your license information, and your media files including those on external drives.
Spare equipment is the ultimate in planning for failure. I realize that spare computers and projectors are expensive. At the very least you should carry a spare projector bulb.
If you are portable and regularly plugging and unplugging cables, especially those with small pins, best to have spare cables too.
Have warranties for your computers. I know that it can seem like a money grab by the computer makers, but in 18 months you'll thank me that you're not going cap in hand to ask for money to fix your "new computer". Schedule warranty repair work as early as possible before a meeting, as discussed in the Testing section.
Licensing and legality
I really shouldn't have to include this but here it is. Buy the appropriate licenses for the songs, media, software and scripture translations you use. You know it's illegal not to do so and it's immoral too. It's stealing. We can debate the flaws of the modern copyright system all we want (and whether or not the church should use it), but it won't change the fact that you should do the right thing.
Getting support and filling bug reports
I encourage you to contact vendors when you have problems with products. The great vendors will impress you. Let me motivate you further: if you don't ask, you won't get. In evaluating product improvements, vendors look at the feedback they have received. (Unless the vendor makes a mind-reading gizmo.) You can't assume they know about your problem or that someone else will report it. In fact, a problem reported many, many times will get significantly more attention.
In communication with vendors always use professional language, be as specific as possible, including what you have tried to resolve it, and what model/version you are using. Remember that sometimes you may be pointed to the documentation or asked to upgrade.