Do Processes take over your Projects?

When processes become all too consuming, it means that they have stopped being a means to an end and have become the end themselves. They have become integral part of the project and in some instances can consume projects. This can get to the point that they impede continuous improvement because the people who do them are emotionally invested in them. This sometimes leads to resistance to change when change is badly needed.

That is not to say processes aren’t needed, only that they should act as a support to achieving desired outcomes, not become the desired outcome. Doing things in a consistent way, using a process, is the most effective way to experiment with changes and understand what worked and what didn’t, but it can become a trap, if the end result isn’t kept in mind.

The first identifier of a project being consumed by the process is its overabundance of documentation. Typically, this involves multiple volumes of manuals, protected by a complicated and byzantine approval process. Any change requires a thorough review by several committees and multiple sign offs, by which time the requirements for the change will have become out of date, and all involved will throw up their hands and claim that the whole process is too hard but won’t do anything to fix that either.

Another sign is knowledge hoarding. If you find that only one or two people have full knowledge of how things work, and they jealously guard the information, it’s probably a good candidate for a consumed process. In this instance, there will be very little documentation to enable others to evaluate or analyze the process. Subject Matter Experts (SME) will be reluctant to share or will frequently claim that things are “too complicated” to explain to someone else.

If the work has become more important than the outcomes it produces, then you have encountered a consumed process. Look at the metrics used to measure the process success. Do they relate to business objectives, or are they measurements of execution? Number of complaints processed with a goal that goes up is a process measurement. Number of customers rating their customer service experience as a 4 or better on a 5 point scale measures a business objective of satisfied customers.

Once a process has consumed a project, what can be done about it? The most critical element in this case isn’t the business, but the people in it. There are a number of techniques which are useful in this instance: Acknowledging concerns, and involvement in the solution.

When acknowledging concerns, the pattern to use is Feel-Felt-Found. Start by acknowledging the person’s concerns are legitimate by saying “I know how you feel, many of the people I talk to felt the same way about changing how they work.” Then reassure them with other people’s experiences. “People who’ve been through this process have found that it really made things work better. Can we give it a try?”

Involvement in the solution is the best way to build ownership in the new process and prevent people from subverting change by passively or actively resisting it. The important thing is that they will feel that they improved the process rather than had the changes imposed on them.

Assuming you’ve managed to successfully implement a new process, how do you prevent it consuming the project all over again? It’s easy to assume that the hard work is over, but if you fail to plan for changes to the contexts the process operates within, it’s possible that the next change will require you to start from the beginning rather than make another incremental change. Your first objective is to make sure that you don’t rest on your laurels.

If you’ve taken time during your process review and rework to incorporate a continuous improvement culture, then much of your work is already done, as people will already be thinking about how to review and rework the process on a regular basis. If not, take the time now to set up regular reviews and identify metrics that will allow you to validate that the process is achieving its desired objectives. Make sure that you focus on business objectives, not process objectives. If business objectives aren’t being met, adjust and try again. The most important thing is to avoid falling into the same trap of measuring the process not the outcome.

The second objective to strive for is to make change easy. Keep feedback loops in place to allow the people who provide inputs information on how to improve the quality and usability of those inputs. Make sure that any feedback provided from the people who receive the output is reviewed and acted on a regular basis. Try as much as possible to use a “black box” approach. That means that the people outside the process don’t necessarily have to know the details of how the process works, just that it produces consistent, predictable results. Keep your processes as independent as possible to minimize the impact of changes on other business areas when changes are required.

The final objective is to keep documentation simple and readily available. At all times, the current version of the process documentation should be online and available to everyone who performs the process. Keep the documentation in a centralised easily accessible location. While it’s important to have version control, it doesn’t hurt to make the documentation easy to change when it’s needed. Focus on pictures and short paragraphs. Avoid writing novels. Flowcharts are one of the best ways to describe processes. Keeping the documentation simple means it’s less likely to end up in a paper copy on someone’s desk, which means it’s out of date by definition.