Working with Existing Processes

Introduction

Last week we looked at creating new processes from scratch. This week will be exploring existing processes and how to approach implementing change. Before we make changes though, we should start with research and a curious, “people first” mindset. The fact is, great ideas are only one piece of the puzzle when building successful teams and processes, there is much more to the magic recipe ??

Most of us have been in a situation at some point where a new boss shows up and starts making changes on day one...I know I have! Though they may see some short-term success with this tactic, most of the time it will fail...but why? As I touched on previously, people don’t like being told what to do, and we really don’t like being told that what we are doing is wrong. The other issue at play here is buy-in; your team needs to be involved and their contributions acknowledged. Great...how exactly do I do that ?? ?

Is there an existing process?

Research is your friend. Remember that new boss who changed everything on their first day? Remember how it felt? Exactly! It’s usually an unpleasant experience to say the least, mainly because we do not feel valued. It just "feels good" when someone asks us what we think, especially when that “someone” is in a position of power or influence.  Just as I have talked about not creating process for process’s sake, we should not replace something simply to say we made something new. Sure, it’s OK (recommended, actually) to reevaluate our existing workflows at regular intervals, but we should lean in with empathy and curiosity, involving others as much as possible.

At the heart of the matter is team buy-in. How do we get that? The answer is simpler than you might think...ask the team what they think! Before we make changes to anything, our research should look to uncover:

• Is there a process in place, and does it work? Why?
• Does the existing process function as originally designed? Why?
• Does the team understand and follow the current workflow? Why?
• Would we really benefit from changing the current process? Why?
• Who uses this process today, and what can we learn from them?
• What is the history behind this process?

At the end of the day, there may be legitimate reasons why an existing process is not working and should be rewritten or replaced. This is not the real issue, things break, and we fix them! The primary reasons why so many process implementations fail are lack of research and team buy-in.

The good, the bad, and the ‘Nope, not doing that!’ ??

“OK, ask lots of questions and get people involved early, got it ????”

Yep, that is a great starting point, no problem there! What happens next is not necessarily a problem, but by taking this approach you may find that you are flooded with amazing ideas and feedback. That is a great thing, right? Yes, but it’s also just not feasible to accommodate everyone’s suggestions (Pro tip: You don’t have to!) The important thing is that you involve stakeholders, actively listen, and talk through ideas. You will find that most people are more receptive to change if they are given a chance to contribute, even if their ideas end up not being implemented.

By involving the team, you create an environment of trust and respect, which means you are more likely to hear about the good, bad, and most importantly...the broken! “Broken” can mean many things (it doesn’t work due to a technical issue, people don’t understand it and use it incorrectly, people don’t know it exists, people have to bypass it in order to get work done, people just don’t like it, etc.), but the fact remains that the process is not working and something needs to change. I say “something” because it’s not always the process that is broken, it could be that just some targeted training is all that is required to get things back on track.

During your research, you will (hopefully) also find out what is working well and might not require the same attention as other aspects of your workflows. Regardless of what you discover and how painful some of those discoveries may seem, it will always be easier and more cost-effective to address issues upfront than to correct them after the fact.

The research is done, now can I change things?

Maybe! It’s good to remember that we all have biases, and we should be careful not to let those affect our professional judgment. So yes, if you discovered a big problem that clearly needs to be addressed, then the team should certainly work together to develop a solution, which may or may not involve changing the process itself. Change itself should not be feared, as it is inevitable and necessary for the world to evolve. We just want to be purposeful, implementing change as needed to either fix a known problem or simply make something better. If you can’t provide a “why”, then you probably shouldn’t be doing it.

If you and your organization have done a good job of building diverse teams whose feedback and contributions are welcome, most of the above should fall in place quite naturally. So go ahead, rewrite that outdated workflow that is driving the team crazy, or maybe build something new to help solve a new problem. Whatever you decide to build, keep revisiting those critical questions to make sure you are creating processes that create value and not more work.

What’s next?

We have taken some time to look at the psychological aspects of processes, along with some strategies we can implement to help teams feel more connected to the mission of the business and more valued as individual professionals. Next, we will spend a few weeks looking at what types of processes work best for certain situations (3/14), when to automate versus customize (3/21), and when not to implement process, and why (3/28).

Author - Marc Jobin