If you read the “About Us” page you have heard me mention “use-cases” before.
Failure to understand the intended use-cases of a system often results in the fantastic opportunity to introduce a level of instability. Why? Because our organizations are full of well intentioned volunteers, that know how to get the job done, and will!
Let’s say we design a system with Functionality X and Y, since that’s 95% of what you do. But 5% of the time you need functionality Z. If we don’t design into the solution either the ability to support use case Z, or the ability to easily augment the system to support use case Z, then here’s what will happen.
Someone in leadership tells a volunteer on the tech team (who has an awesome heart to serve) that an upcoming event has the need for Z. The volunteer will “make it work” using whatever resources and tools the church already owns (and hopefully avoiding those tactical purchases!) This will usually require reconfiguration of the system, and if it’s a well designed system that makes use case X and Y work well, then use case Z often times requires that the system for cases X and Y be disassembled so that the components can be reassembled into use case Z.
The challenge is that this often happens at the last minute, and rarely does the equipment ever get back into the original case X and Y configuration. This poses instability issues, as often the real “test” of the proper reassembly of the system comes right before the next service – and often with a more junior volunteer who does not I hate technologyhave the triage skill set to make things better. This causes undue stress on the organization, tension between leadership and the teams that execute, and ultimately it’s unfair to the volunteer. Our enemy loves the opportunity to create dissension at times like these (yes, I did just allude to the fact that a properly designed technology infrastructure can help keep communication whole, and the enemy out of our teams!)
Designing a system that supports as many of the upcoming use cases that we can envision minimizes the chances of this unfortunate situation happening. Many times, this does not involve extra technology or even expense, but just a well defined process for what to do when use case Z comes along. The more we cable/un-cable/re-cable our solutions, the more we introduce the chance that when we call upon them during that very narrow window of time that we have on Sunday morning to get all of our technology doing what it’s supposed to do, the greater the chance of discovering it does not work that morning, for whatever reason. And if that 30 minutes of troubleshooting was involving worship technology, we may have robbed our worship team of the opportunity to have the space to clear their minds, and prepare their hearts to lead our congregation in worship prior to taking the stage. So the “opportunity cost” of not handling that occasional use case may have cost us a lot more than we first thought.
The path to healthy technology begins with a few key factors. First and foremost, let’s vow not to design or modify any of our tech infrastructure without involving all of our major “stakeholders.” I define stakeholders as individuals or teams that have a vested interest in the systems that we are proposing to design or modify, and it generally goes beyond just those that will use or operate it. For example, a list of stakeholders for a sound system retrofit might include the mix engineers, worship leader, worship team (one of the major users,) and might also extend to those responsible for pre/post service music, lobby/foyer ambiance, etc. Just begin to think to yourself “If I change X, who all will be affected?” And it does not mean that you plan on meetings with casts of thousands as we al know how productive that can be, but at least have a representative sample. You may choose to meet offline with different people. You will be surprised at the feedback you will receive that will help you arrive at a more holistic solution. And even better, all those that you touch will feel an involvement in the solution. Everyone wants to play a part, and it makes change more palatable when you are part of the process, versus simply having change thrust upon you without your input.
So go forward and create – and in the process, involve your teams for solutions that meet the needs of the whole organization, not just the part you see. And in the process, you will gain a greater understanding of the way your organization uses the technology that you touch, which in turn allows you to design solutions that meet all needs, and avoid the stability-robbing effect of forcing a system to do something it was not intended to do.
And if I can be of service in helping with this kind of design work, drop me a note.