I think we can all agree – change is hard. Some of us deal with change better than others, and some kinds of change are often easier to adjust to than others. No matter how much better the proposed change will make life, or how much more efficient it will you, or how much time it will save you, Newton’s First Law tends to take over — every object persists in its current uniform motion unless it is compelled to change… most people get into a rhythm, a habit, a comfortable norm, and change forces them out of their comfort zone.
Having done numerous technology transitions and migrations over my career, I knew that the human aspects of migration from Community Church Builder(CCB) to Planning Center Online(PCO) would be a challenge. People form their processes around the way tools work, good or bad, and now we are asking them to form new habits and new processes around new tools. This instinct to stick to the familiar can be exceptionally strong – I once worked for someone who would create long 4-5 page customer documents in Microsoft Excel, rather than learn MS Word or PowerPoint, because their comfort with Excel was so strong. Can it be done? Sure! But not exactly the most robust tool for the job.
Change needs to be marketed
One of the best ways I have found to overcome some of this resistance is to sell the line level team – office staff or others that will be working day to day with the existing tools — on the advantages and benefits that the migration will bring, particularly to *them* and their specific roles or tasks. Telling them that it will make their bosses job easier, or that its better for the entire organization is not as persuasive as telling them *their* job will get easier. Of course, this also has to be true — if it really will be more difficult, this is a much harder sell. Find positives for each of the roles that will work with the new tool, and sell them on the advantages. If done correctly and with ample time to absorb the new tools, this can move them from being resistance to potentially being advocates and helping you get the migration completed more smoothly.
Change needs to be managed
Telling people how great the new system will be is a start, but they still need some shepherding through the change process. People need to have a clear plan, laying out a path to success, and knowing how to get issues addressed. Large or complex problems need to be divided into manageable chunks, so since our migration to PCO involved multiple serving teams (giving, check-ins, resources, registrations, as well as people and services), I engaged functional leaders to drive the migration for each of these apps. With some coaching, each of the leaders first defined the tasks required to roll it out across all campuses, groups, or whatever the scope for their app. This included testing and training to ensure that all of the team members knew not only how to use the tools “on the front lines” of Sunday morning, but also how to fix things if/when they break, how to communicate issues to the proper leaders so they get addressed, and any standards around the use of the app. We then laid these tasks across an overall timeline to define the migration schedule and made adjustments to make sure that we were trying to squeeze too much in on any given weekend.
Depending on your situation and the teams you have available, you may find that it might be easier to spread out the app rollouts into phases. For example, let’s assume your church was already on Services, so you roll out Giving first over 30 days, then when that is working well, roll out CheckIns, etc. This takes longer to complete the migration AND you will be operating both systems in parallel, which increases the complexity and cost, but it has the advantage of allowing the team(s) to focus on one app at a time, increasing their confidence and efficiency around the migration.
To manage and track the migration project, we held weekly status calls with all team leaders, having them read out their progress on tasks, as well as (very important!!) any issues or questions that came up as the migration proceeded. As we kicked off this process, I shared with them a principle that I’ve used throughout many years of project management experience, shared with me by one of my favorite bosses (he knows who he is!): Bad news does not get better with time. This means if you see an issue, or you think something might become an issue, raise it early and often to give the team time to address it. Waiting and hoping a problem just goes away rarely resolves anything, and only burns down the available time to address the problem.
Change needs to be documented
One familiar, unattributed quote reads “The definition of insanity is doing the same thing over and over expecting different results”. We often spin our teams up to accomplish something, lead them through inspiration, then quickly high-five when done, moving on to the next project, initiative, program. Nothing wrong with the inspiration or the high-five, but unless we find some method to document what worked, what didn’t work and lessons learned (i.e. what you would do next time), you are likely to make some of the same mistakes in the future. And since it’s likely that, for the next project, you will have different people involved, the risk of repeating errors is even higher.
Formal Project Management methodologies, like PMBOK or Agile have very defined documentation and processes, but these are usually too heavy for small teams, particularly for teams of volunteers. For these smaller teams and projects, I have often used a lighter weight tool, as simple as an Action Item Register spreadsheet with 2 tabs. For example:
- Action Items
-
- This is a simple list of general tasks that need to get done, with info on: who its assigned to, current status (Open, In Progress, Closed), Priority (1/2/3, High/Medium/Low, etc), and notes on why the task is important
- Issues/Questions
-
- For every outstanding question or issue that comes up in the project, add a line with info on: what component (PCO App for example), whats the question/issue, who is it being directed to, Open/Closed, Next Steps
Using this kind of simple tracking doc keeps everyone on the same page, and ensures that everything that comes up as the project progresses gets captured and (hopefully) addressed.
Any training, either for end users or for staff using the tools, needed to be documented in some way as well, to simplify passing on info to new people consistently. Often times, tribal knowledge training tends to be inconsistent, making for inconsistent end user experience. With video recording being available on just about every device we carry, it’s pretty simple to create simple training videos for people and make these available as new people volunteer or come on staff.
One last point of documentation: when the project is complete, and things are “in operation”, it’s good to do a lessons learned session, to discuss how the project could have been done more effectively, rapidly, less expensively, with less frustration, etc. The point of this lessons learned session is to discuss *what* was right or wrong, not *who”. The output of this can be as simple as an email to the team and leadership outlining what to do next time to improve things.
I’m hoping these tips and tricks are useful to you and your team. Have some tips that we should add here? Leave them in the comments below.