Culture Over Process

In an earlier post, I talked about the need for collaboration rather than cooperation and basing that on open communication. I also wrote about factors to consider when discussing things with people, particularly when there’s a problem.

Those posts provided the foundation for this one.

As you may be aware the mission of The Better Process Company is to make your company run better. To make you more efficient we look for ways to improve your workflows, process, and operational models. 

Communication is a vital part of any change project at all stages. 

Project Communication

Our process starts with “Discuss & Discover” Without doing this step you have no idea where you currently are, and without open communication, you will only get a partial picture. That is very likely to cause problems down the road as the things you haven’t been told about start to impact, or be impacted by, the changes you’re making. 

Communication is just as important when you “Document & Decide” The findings need to be clear and decisions shared with all those involved. Open communication provides important feedback, and may well prompt people to consider new factors that are relevant to the project.

As you “Deliver & Do” the new process open communication provides valuable feedback on what’s working and what isn’t. It is said that no battle plan ever survives first contact with the enemy. Similarly, no project plan survives first contact with reality - you are going to have to adapt. And that should be based on feedback, which of course means honest communication. 

Once the new process is fully operational the communication doesn’t end. 

Keep Communicating

It’s at this point that collaboration culture, and the communication needed to sustain it, become the most important thing for success. Even more so than the processes you have put in place.

Why?

No process can cover every possible situation, and nor should it. 

If you try to design a process to cover every possible contingency or scenario you’ll end up with something that looks like a map of the London Underground drawn by a three-year-old.

The Better Process Company strongly advocates KAPS - Keep All Processes Simple. (It’s the process improvement version of the KISS principle.)

This is not to say that your process should only have one workflow; one path to deliver value, you might have several depending on the situation. But equally, it probably shouldn’t have 12 paths either. 

In software engineering, you document all the possible paths a user could take through your application. The user journey for if everything goes as planned, and then one for every possible error or mistake. We’re familiar with these; forgotten password, credit card expired, cart abandoned, changing address, etc, etc. 

In an operational model, you wouldn’t put every possible error into the workflow diagram. You only document the few ways in which a particular outcome might be achieved and the value delivered. 

That doesn’t mean you ignore the possibility of issues or problems. Those need to be considered and recorded as risks with suggested and/or agreed mitigation strategies. Ideally, this would be short. Not because you have very few risks, but because you have a culture of collaboration and open communication so everybody trusts everyone to pull in the same direction should things go wrong. 

If someone feels there needs to be a detailed list of mitigation strategies covering every possible problem this is a red flag. They probably have low levels of trust in their colleagues and aren’t yet invested in the concept of collaboration.

Much of the work of process improvement isn’t changing workflows, it’s about breaking down silos and enabling communication - the workflows are a means to achieve that. Silos break and a collaborative working environment is created through open communication. That requires trust, which starts with understanding. 

Using PESTLE you can really begin to understand those you’re working with and thus begins your journey of collaboration.