Designing and rolling out an effective and sustainable process-based management environment is not easy, but sometimes we seem to go out of our way to make it much harder than it needs to be.

To start the year, and the decade, here's a rant from a cranky old process bloke!

Stop doing this stuff. It's not needed. It doesn't help. It wastes time. It annoys people. It distracts you from what is really important.

STOP …

Setting KPIs for processes that won't be managed

If you aren't going to actively manage a process, why do you want to waste time defining a KPI? Even just two or three levels of a process architecture will involve hundreds of named processes. You aren't going to manage them all. Assigning KPIs to a process and then not tracking its performance using those KPIs is a massive performance failure. It's classic waste by our own process definitions.

Modeling just in case

I hear people say that they are going to "model all of our process" or we'll "model the first(!) 250 of our processes" and I want to scream ask "Why?!" Model for a purpose. Model just-in-time, not just-in-case. Modeling is important, but no organization has ever had a business problem called "we don't have enough process models."

Defining way too many KPIs

It's not a competition; there isn't a prize for having the most KPIs! If there was to be a prize it would more likely be for having the fewest (carefully selected) KPIs. Making a list of 20 KPIs for a process isn't analysis, it's typing.

Defining too many levels of process architecture

In theory, there is no bottom to the process architecture; we can keep decomposing as deep as we want — it's processes all the way down. In practice, we should only be going as deep as is needed to address a specific issue. Start at the top and work down. You may find that for most of the process hierarchy you don't need to go much deeper than (say) two, three, or four levels.

Mapping functional KPIs to the process architecture

Yes, of course, you have a set of functional KPIs. There may be hundreds of them. They are presumably measuring functional performance. They are unlikely to be measuring the performance of cross-functional processes. One measures the vertical perspective and the other measures the horizontal. (I've written about this in many places, here, there, and everywhere.) There is no need to map one to the other; indeed, you'll find it difficult to in a meaningful way. Functional KPIs have no place in my process architecture until you get low enough in the hierarchy so that the functional and process coincide, i.e., the processes are no longer cross-functional.

Setting up too many Process Owners

I appreciate that it feels right to appoint a busload of process owners from day one and get on with it: Let's get as many processes as possible under active management as soon as possible. I get it, but my experience is that if you start with more than a handful it becomes too complex to make it work. There are too many calendars, too many conflicting demands. Being a process owner is a new and quite different role. It's new for those in the role and for the organization at large. Allow time for everyone to learn what it is and how it works.

Making process governance complicated

Complexity is a killer. Process-based management should be bringing simplicity to management, not additional complexity. In my approach the process owner role, and process governance generally, is as simple as possible. The process owner role's main task is to monitor cross-functional process performance and take appropriate action as required, keeping in mind that the organization chart says little, if anything, about who is accountable across that chart. Process owner is a position of influence, not authority. Don't make it complicated. Process-based management needs to be a solution, not a new problem.

Deciding it's an important KPI but there is no data

If some aspect of process performance is important, if it is a key indicator of performance, then we can't allow it to be unmeasurable. If the KPI is important — and they should all be important (the clue is in the name) — then we must find a way to collect performance data.

Trying to manage "all of our processes"

You can't manage all your processes. Don't even try. There are hundreds, or thousands, of them depending on how deep you are in the hierarchy. Focus. Most organizations can identify, say, 20-30 high-impact processes (HIPs). Focus on those. If you get active process management working very well on those, then add some more.

Confusing artifacts with outcomes

When asked what benefits the process work has delivered, the wrong answer includes things like process models, KPI dashboards, architecture pictures, training courses, etc. The only correct answer involves lists of valued improvements in organizational performance that have been delivered and demonstrated. The artifacts may be necessary, but they certainly aren't sufficient.

Asking the BPM Office to do everything

If you set up a BPM team so that they must be involved in everything — for example, requiring that they run or approve every analysis project or model change — then when they are successful, they must also become a major bottleneck. They soon become the OPPI (Office for the Prevention of Process Improvement). Relax. Set standards. Build capability throughout the organization. Thump the desk occasionally if you need to. Support and enable the rest of the organization to manage and improve their processes. The BPM Office is not there to run the organization; they are there to help managers to manage.

Creating To Be plans

We've all been there. Lots of analysis of the As Is — process flow models, stats, complaints, CX models, options analysis, etc. Then we design the To Be and make the presentation. Standing ovation, approvals all round. And no process has been changed in the execution of this project. We don't want a To Be; we want a new As Is.

Neglecting the need to actively build capability

Process-based management — i.e., end-to-end thinking and working — is different. It's not achieved via an email announcing that everyone is now empowered to improve processes. It's not achieved via an annual presentation. It's not going to happen without conscious and continuous attention. Design and deliver a Process Capability Development Plan that covers every group in the organization.

Assuming everybody agrees with you

Of course, everyone should agree with you — well, with me anyhow. Amazingly, this doesn't always happen. We must remember that before we change a process, we probably must change some minds, quite possibly starting with our own.

Ahhh! That feels better. Rant over. Happy New Year!

# # #