Tuesday, 30 April 2019 08:06

You've Got Processes With A Capital P and That Stands For Trouble!

Written by

In Meredith Wilson’s “The Music Man” there is a scene where Harold Hill, the conman,

attempts to alarm the people of River City about the local pool hall to get them to buy band instruments. The refrain is “You got trouble my friends, trouble with a capital T which rhymes with P and that stands for pool!”

I’m going to turn that around and tell you that you may have processes with a capital P and that rhymes with T and that stands for trouble. When processes become Processes with a capital P, it means that they have stopped being a means to an end and have become the end themselves. They have become enshrined, which is the term I’ll use in the rest of this article. 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 for an enshrined 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 of an enshrined process 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 an enshrined process. In this instance, there will be very little documentation to enable others to evaluate or analyze the process. SMEs 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 an enshrined 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 you’ve identified an enshrined process, what to do about it? The most critical element in this case isn’t the business, but the people in it. I want to share a couple of techniques I’ve found useful in the past: Acknowledging concerns, and involvement in the solution.


Advertisement

When acknowledging concerns, the pattern I’ve learned to use is Feel-Felt-Found. I learned this during my sales career. 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. If you’ve done your job in carefully listening to the people doing the process, and gathering their input, they will feel a sense of ownership in the new process. 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 from becoming enshrined 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. Sharepoint or an online wiki are great places to keep shared documentation. 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.

I hope by following the suggestions in this article, you’ll be able to recognize, fix, and avoid enshrined processes in your projects. I think you’ll find the benefits of doing so are substantial.

Read 8193 times
Larry Blankenship

Larry has performed nearly every role in the SDLC over the last 20 years, having at various times worked as a developer, technical writer, Business Analyst, database designer, and trainer. His focus is on helping people, learning, and helping other people learn. He currently serves as a BA at Intoxalock, a leading vendor of ignition interlock systems, where he is focused on utilizing Agile techniques to improve the software development process. In his leisure time, he collects fountain pens and writes. He holds a PSM-I certification from scrum.org and is working on his Agile certification from the IIBA.

© ProjectTimes.com 2019

macgregor logo white web