One of our operators approached me a while ago with an issue. There was a file that we bring in several times a day, but this time around there was a wrinkle. The conversation went a little something like this:
“Well, we received the file fine this morning, but this afternoon the process failed and we weren’t able to retrieve it.”
“Did you manually check the site?”
“Yes, that’s the problem; the site isn’t there anymore.”
There is a structure to changing a process, and sometimes when you ignore steps along the way, important details get missed and the result is not ideal.
What happened in the example above? The vendor changed the process in the middle of the day. As it turns out, they had been working on this change for a while. The credit union knew about the change and when it was coming, but they forgot to engage the core processor (us, in this case). So, an automated process that had been working seamlessly for a long time suddenly failed in the middle of a business day. The site was gone and there was no place to get the file.
There is a method to follow when you work through building a new workflow or changing an existing process. Here is a quick run-through that you might find useful when you are working through a change project.
1. Analyze
A lot of times we jump right into projects. We are pressed for time, we want get the work done, the project is easy, and it’s straightforward; what could possibly go wrong?
This is the time to ask questions like:
- What is the goal? What should our result be?
- Who should be involved?
- What needs to get communicated and to whom?
- Is there more than one way to solve the problem?
- If so, which way is the best? Most effective?
This step is the one that is skipped the most often and is the step that will often save you the most heartache and frustration. Always stop and take the time to analyze your problem and clearly understand what it is, how you will solve it, who needs to be involved. Then move forward.
2. Plan and design
There are many ways to skin a cat, but some ways are better than others. Take what you learned from analyzing your problem and start coming up with solutions, but don’t settle on the first one you come up with—even if it will work. The first solution is probably not the best.
Get together with a few people and kick some ideas around. Bring in people that are not even involved in the project and see if you can explain it clearly enough that they can understand it and offer solutions. Now you have additional sets of eyes looking at your challenge! Come up with a lot of ideas, even if some seem far-fetched. The best solutions start to develop once you move past the expected course of action and come at the problem in new ways.
Make sure that part of your plan to is to get all the stakeholders involved. People don’t like change, so market the benefits of the new process or change that you are making. Provide reasons for other people to get excited about what you are doing.
3. Build
Now you have taken the time to analyze the problem and understand it fully, brainstormed and come up with lots of different ways you can solve your problem, and have chosen the one that works the best for your situation and the people you are working with. It’s time to build!
Set deadlines. It is easy to let other things get in the way of progress and the last thing we feel like doing is making more work for ourselves. Tell other people what you are doing and when it will be done to create time accountability. If the project is large, set measurable milestones to ensure that you are on track. Put reminders on your calendar to maintain urgency.
As part of this phase, make sure that you fully document the process and include any measures that must be taken to recover if the process fails. Test the process to make sure it works the way you planned it. Circle back and make corrections if it doesn’t and adjust your timeline. Report your progress to the people that have skin in the game.
4. Operate
You are set! Now you can put your new tool, service, project, or process into production. Have the users provide feedback and correct any oversights in your documentation. Understand that your new or upgraded procedure or tool has a lifespan and the clock just started ticking. Do not let it outlive its usefulness. This leads us to the final two steps in the cycle.
5. Measure
Once in place, make sure that your process is living up to expectations. What measurements should you use?
- The number of transactions
- How long it takes (did you check to see how long it took before you started building?)
- Increased accuracy
- Reduced staff involvement (“we spend two hours fewer a week” translates to…)
- Money saved
There are a lot of different ways to measure success. What is most important for your project? These are called KPIs, or Key Performance Indicators—the units, whatever they are for your project—that will (hopefully) clearly measure the degree of change and success.
Another good reason to measure performance is that you may find that it degrades over time, or suddenly changes for some reason. We experience that a lot here in operations. We put in a process and it’s cooking along great. Then we make a change somewhere—it may even be to something seemingly unrelated—and suddenly our process is slowing down; but if we weren’t measuring, we would not be able to catch that.
6. Assess
Review your process occasionally. How is it holding up? Some do well over time; others do not. Look at your KPIs and see if it may be time to build a better mousetrap. Is it losing its value? Is it becoming irrelevant? Maybe it is turning back into a bottleneck as other associated tools and processes are upgraded, improved, or replaced. Maybe it is time to retire it, upgrade it, or do something new.
And when it is: repeat!
The whole cycle starts over again: analyze your problem, design a solution, build it, and then put your new and improved process into production. Measure its performance and assess how well it is addressing your business goals.
Why the change cycle is important at your credit union
I am being a little self-serving at this point, but make sure you tell your core processor that you are making a change before it happens. It will save you a lot of time, trouble, and possibly expense.
Go back to the example at the beginning of this article. The credit union was not aware of the change cycle; or was too busy to follow through with it; or thought someone else was on top of it. Whatever the reason, when you are making a change, 1) do not assume it will work, make sure it will and, 2) follow this set of steps and you will probably find yourself better off once your process drops into place.