Perhaps you’ve heard this story before: a congregation invests a great deal of money in a new church management software, rolls it out to pastors, secretaries, and other users. Everything goes perfectly smoothly. The software is ready to help leaders collect information on the congregation’s attendance, finances, and everything else they want to know.
But once the honeymoon is over, the new software package starts causing problems. The software is working fine, but users are having difficulty accomplishing day-to-day tasks and have slowly (or sometimes quickly) fallen back into old habits with familiar tools. Spreadsheets are once again the norm, and the new software (and all the time and money invested in it) starts gathering dust.
It’s a story I’ve heard before, and I’ve actually led the way through it a few times. New tools can make your church staff more effective, but only if they are useful and used. Fortunately, we have more control over that than we think. Let’s explore a few simple steps you can take to ensure that your church gains the most benefit from any new software or system you’d like to put in place, particularly if you’re looking at a system like church management software that’s going to affect many different users.
Church Technologist: Describer or Prescriber?
One of the first concerns you should have when approaching a problem with a possible technology solution is whether you want to take a descriptive or prescriptive approach to the solution. (As a side note, the distinction between these approaches is something that comes from the CIO at Concordia Theological Seminary, Fort Wayne, Jason Iwen). A descriptive approach encourages the end user to define the requirements of the software and, sometimes, even to research and suggest solutions of their own. A prescriptive approach tends toward the technology folks determining the solution and giving it to the users when it’s ready. Unfortunately, there’s not a clear-cut best way here. Much depends on your users and the nature of the problem itself.
| Descriptive |
Prescriptive |
| End user leads the process |
Technology staff leads process |
| Best for stand-alone systems |
Good for systems that must integrate with existing software or systems |
| Requires tech-savvy users |
Requires less tech knowledge on the part of the users |
| More likely to solve the problem because decision makers are close to the issue |
More likely to result in solutions that don’t quite fit the issue at hand |
| High buy-in for users |
Low buy-in for users |
| Low control for techs |
High control for techs |
| Better for problems with less definite requirements |
Best for problems with very tightly defined requirements, especially those with legal ramifications such as FERPA or HIPPA |
A descriptive approach almost always leads to a better training and change management scenario, but sometimes circumstances require particular compatibility or technical understanding that will require a technology person at the table. Sometimes we have to prescribe, but the more you can let user requirements lead the way, the better it is for everyone involved.
Is it a Training Problem?
So what happens when we’ve gone to great lengths to select that new desktop publishing program and get everything installed and configured perfectly, only to find that the next six newsletter issues are still laid out in Microsoft Word? Well, maybe we have a training issue . . . but more than likely, we don’t.
Many times, when we see what psychologists and educators call a performance problem, the issue isn’t a matter of training. Most of the time there’s external factors influencing performance, and technology is absolutely no exception. Before you start plotting out your training course, consider whether you’re actually solving the right problem. Robert Mager’s book Analyzing Performance Problems or You Really Oughta Wanna is a particularly useful tool here. I won’t spoil the whole text, other than to say that a very helpful diagnostic question is to ask whether the staff member could perform the tasks in question if their life depended on it. If they could perform the task under the most dire circumstances then the issue is not one of training. Something else is in the way.
This can be as simple as time available to adjust to the new method, a lack of templates being built out for the new system, and hundreds of other possibilities. Learn what the issue is before attempting to solve it with training. Sometimes a good quick reference sheet can be more valuable than hours of training, and a church office culture that supports taking time to learn new skills will pay off big time in the long run. Training is one tool, but it’s only one in a whole toolbox of other options.
The Training Class
Let’s assume that we’ve established that we have a training issue. The secretary isn’t using the new newsletter system because he doesn’t understand how it works. What kinds of training actually work for teaching people new systems? Another helpful model from the instructional design world comes to us from Dr. John Keller. Keller’s model is encompassed in the acronym ARCS:
- Attention—Users require a reason to pay attention to the content of the training. Varying your teaching methods, such as using humor and real-world examples, helps push the user to better focus on the things you're hoping they’ll learn.
- Relevance—Users need to see how the skills they’re learning are going to directly impact their daily lives. If they don’t expect to use the training, then they won’t retain the content for the long term. We all have too much on our plates to spare brain space for stuff we won’t use.
- Capability—Users must believe they are capable of using the system. The more supports we place ahead of the training, the better off we’ll be. This includes an intentional focus on your learners' foundational skills, graphic organizers and screenshots to help learners organize the information for long-term retention, and an encouraging attitude toward your learners’ efforts.
- Satisfaction—Users need to succeed at using the new system both in training and in the real world as quickly as possible. Quick wins help the brain retain training more effectively than almost anything else. Users must quickly apply what they’re learning to their day-to-day tasks to receive the rewards (in efficiency and intentional recognition) to reinforce those skills going forward.
Wrapping Up
Once you’ve conducted your training, be sure to go through the evaluation forms (you did prepare evaluation forms, right . . . ?) and see what gaps remain for future training. Encourage those whom you’re training (and especially their supervisors) to implement the new skills as soon as possible. Change can be challenging, but with some extra planning, it can be made easier.
Join the conversation as we live-chat with Bill about how church workers can implement software training for successful change.
Thursday, October 4 at 11:30 a.m. (CDT) on Facebook
