We’ve all heard the time-tested, “if it ain’t broke, don’t fix it,” and have probably applied it to many situations. If something is working, why go in and make changes? On the surface, this statement seems valid; in the context of today’s marketplace, it is very flawed. Companies can’t afford to wait until a product or process breaks in order to fix it or make it better. There are times when something that is working just fine needs to be thrown out the window and something new needs to take its place, such as updating systems and processes to introduce efficiency and profitability.
Projects that improve the process are trickier than projects that fix or introduce something totally new, because people using a current process and system may not see the need for change. They may be perfectly comfortable with the way things work, and to introduce a change will only complicate their daily efforts…initially.
Case in point: I am finishing up a project for a company that revamped their entire process for getting work out the door. The project introduced changes in workflow, software, approvals, and a dozen other processes that had devolved over the course of a decade. A tangled web of staging areas, approval and rejection processes, and rework queues had been cobbled together and it was now time to streamline in order to increase efficiency and visibility.
The problem was that the patchwork of processes worked! Everyone had become knowledgeable about the nuances and quirkiness of the existing system and wasn’t ready to charge forward with change. Management decreed that it must be done, however, and so it shall be done. However, at nearly every stage of the project, users grumbled that it would only complicate things and make it just that much harder for them. Sure, they saw the big picture and future benefits, but they were primarily focused on their little slice of the process.
Remodeling projects need to be managed differently than startup projects, to make sure the new system and processes are adopted throughout a company. The following are 6 steps you can take to help make sure this type of project is successful.
1. Make Sure Everyone’s Needs are Understood
A big part of successfully managing a process improvement change is to make sure that everyone’s needs are understood. Notice that I used the word understood and not addressed. The reality is that a project focused on improving a process will not be able to address everyone’s needs. For example, someone may come back with the requirement that they need the system to act exactly the way it did before. Now, we all know that’s not possible. But, you can acknowledge the fact that you understand what they are asking for and will do what you can to make sure the new system behaves somewhat similar to the existing system.
How can you do this? Requirements gathering is absolutely critical at this stage. Thoroughly interview all users until you know what they do, what they don’t do, and what they need to do. Keep track of each user’s requirements in a traceability matrix that links their requests or needs to a particular feature or new way of doing things. This serves as an important reference throughout the life cycle of the project so they know their needs are not being overlooked or swept under the carpet. It communicates that all of their needs may not be addressed, that some things have to be done a different way or may not be able to be done at all.
2. Start Rolling Out with a Small Group
As soon as a new piece of functionality or revised processroll-out with a small group first is in place, give it a trial run with a small group of users, preferably those who were involved in the original requirements gathering sessions. Watch and listen to them closely. Where do they get stuck? What questions come up? What objections are raised? Their responses are an early indication of how smooth (or not) the roll out to a larger group of users will be.
Give them a bit of time to get used to the new way of doing something, and then come back for more feedback. Don’t discount or dismiss what they are saying. Listen. Seek to understand their position before you say, “Yeah, but….” You won’t be able to address all of their concerns, but they will at least know you understood and listened to them.
3. Create a Mechanism for Issue Reporting
No new system, process, or software is going to be perfect out of the gate. You need to ensure there is a way to easily and unobtrusively capture any issues people report. I’ve seen issue tracking systems that require super-secret agent ninja skills just to create a trouble ticket. Then, you have to be an expert in hierarchical classification skills to pick the exact granular issue type to attach to the issue. Don’t do this. Make sure your issue reporting system is simple and straightforward in order to not frustrate the user.
4. Focus on Stability
Stability is the biggest area of focus when improving a new process or system. People always refer back to the old way of doing things, and argue that they never had a problem the way it was before. That may or may not be true, or they may not remember all the workarounds they had to come up with to get through the old way. Regardless, you want to remove any instability (broken processes, error messages, performance issues, etc.) from the new way of doing things immediately. Put your best team on standby, so that they can make any adjustments necessary. Stability is increased when minimal time is wasted between an issue quickly being reported (remember #3) and resolved.
5. Develop the Right Training
Training can range from a 30,000 foot overview of what is being taught to a face-pressed-against-the-window-pane view of the subject matter. Make sure the training for the new process or feature set addresses how something was done before, and compares how it is done now. Show the differences and improvements, and talk about the reasons why it’s been done this way. Zero in with a hands-on approach with real information so when everyone leaves they can return to their desks knowing exactly what they need to do.
6. Put Phase 2 Together
Your feedback is going to fall into two categories: 1) hey, this is broken and 2) wouldn’t it be nice if. Address the broken issues immediately (see #4), and listen closely to the wishful feedback. Put those improvement requests into a wish list for Phase 2, and you can begin to prioritize how to change something that is already running well to run even better.
Also, be up-front about known issues. Something may be reported that can’t be fixed for a while. You have two choices to make: you can pretend a particular issue doesn’t exist and hope that people don’t come across it, or you can publicize it, address when it will be fixed, and instruct how to deal with it in the meantime. People appreciate transparency and forthrightness, as opposed to stumbling across the issue in the middle of trying to get something important done.
Today’s competitive environment requires that we throw the “if it ain’t broke, don’t fix it” mentality out the window. Be mindful of the fact that process improvement projects are very different than others, and follow the points above to make the transition from good to great that much easier.