Refactor Your Conference Archaic Planning Routines

Conference organizers and their planning teams should understand, identify and quash organizational debt.

Once they pinpoint and distinguish it, they need to refactor it. “Refactor it?” you say. “What does refactor mean?”

Refactor is a technology concept that meeting professionals can use as a metaphor. Software programmers refactor their code once they develop a better understanding of how and why the program works. They clean up its internal functions, simplifying the program and improving its performance.

Refactoring Is An Improvement Process

Refactoring is the process of changing and improving source code without changing its purpose or behavior. Refactoring code improves some its properties such as readability, complexity, the ease of maintenance, restoring operations and its ability to grow or extend. This is done without radically altering the software functionality.

Refactoring is also known as reengineering.

Refactoring can extend the life and use of the code. It keeps it from becoming legacy code.

The challenge with refactoring is that it is hard to sell to upper management. Supervisors resist refactoring and claim “If the code is not broke, why modify it?” Similarly, management is often hesitant to refactor code due to the time, labor and resources required.

Refactoring As A Metaphor For Conference Improvement

What we need is a conference refactor to fix our organizational debt — to make it possible for our planning and event to evolve. We need the support and freedom to clean up some of our archaic planning processes and sunset outdated legacy procedures. Thus we refactor to improve the conference experience for our customers.

Think of the language used in the above paragraphs about refactoring code. The goal is to improve source code—the set of instructions and statements written in programming language.

That sounds very familiar to an established annual conference planning process. Think of the planning routines, files, procedures and instructions that have been institutionalized over the years. Consider it as your conference source code.

A variety of people from staff to leaders to committee members expect to be involved in the conference planning process based on this source code. Procedures such as the chair of the board chooses the location for the event, serves as the event emcee and decides on a theme are similar to source code. These practices served a purpose for a time and have eventually become outdated.

Your conference has a variety of source codes that need refactoring. What you don’t want to happen is your planning practices becoming archaic hackitectures similar to legacy codes.

Refactoring As A Way To Avoid Creating Conference Legacy Code

In programming, legacy code refers to source code that is continually patched and mended. Over time, we make an unlimited number of modifications based on customer demand. Thus the original program evolves into a complex monster.

This is very similar to some of the planning routines we have with our conferences. Due to customer and volunteer leader demands, we add new steps or criteria to our planning process. These additions resolve immediate demands. However, we end up with an over-complicated, complex maze of planning practices.

Then our senior management doesn’t want us to expend resources to simplify or improve these legacy planning processes. We take the path of least resistance instead of the path of what’s best for the paying customer.

The end result is a FrankenConference. A conference with a patch work of programming components that looks like a hot mess full of expected nostalgic traditions.

Read the next post to see how to take back your conference from organizational debt.

How do you avoid creating FrankenConferences from organizational debt and legacy procedures? Where have you successfully implemented refactoring?