The Process of Communication

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 process at all stages.

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 begin 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.

It’s at this point that collaboration culture becomes the most important thing for success.

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.

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. 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 on 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 you trust 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 and aren’t yet invested in this concept.

Much of the work of process improvement isn’t changing workflows, it’s about breaking down silos and enabling communication. Doing that means creating a collaborative working environment 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.