The magic of hierarchy

Probably my favourite tool in the arsenal of analyst techniques has to be decomposition. Whether it’s functional or process decomposition there is nothing like it for arranging problems into the big picture. Then breaking that picture down into its component parts so that you can start to make sense of it.

hierarchyAnd yet hierarchy, in recent years, has got a pretty bad reputation. As Stanford professor Bob Sutton wrote this weekend in this LinkedIn article. He was brought up to believe that hierarchy was bad and led to inefficiency, yet research for his new book showed that hierarchy is unavoidable.

Hierarchy is nature’s gift to us in helping us understand the World around us. Citing research by his colleagues Deb Gruenfeld and Lara Tiedens he describes how hierarchy is found in every single group of animals found in nature. To quote Gruenfeld and Tiedens directly:

When scholars attempt to find an organization that is not characterized by hierarchy, they cannot.

Hierarchy structures the relationships between people and things into parent, child and peer relationships. This makes it easier for us to remember those relationships, it provides an organising principle that is standardised across everything. We simply have to know how hierarchy works in order to understand something that is new to us.

This is what makes decomposition so powerful. It comes naturally to us human beings so is not really something that needs much in the way of education. When we apply it, it’s often to an area that seems chaotic and complex. By decomposing we overlay a hierarchy that allows us to understand what was previously incomprehensible. It allows us to break problems down into component parts in order to tackle them effectively and even start to predict what will happen when we make changes.

It doesn’t just aid understanding, it also helps us to remember. Instead of having to remember every single discreet component of an organisation you simply need to remember a small subset. You can then use this along with the hierarchical organising principle and you will be able to fairly accurately calculate the missing pieces.

This is what makes decomposition one of the first things I do when introduced to a new problem.

An extended version of this article is available at the-skore.com.

Why process capture is important for unstructured processes

This article on BPM.com caught my eye yesterday, “Will standard processes soon be extinct?“, particularly the comment from Software AG Chief Evangelist Theo Priestly. Citing Jim Sinur‘s ‘Dark Processes’, Theo recommends exposing these hidden processes and encouraging them. Based on my experience I’d have to agree.

In Theo’s words:

“Jim wrote last year about Dark Processes, those which lurk around the enterprise conducted by many but defy definition.”

One of the problems with undefined and undocumented processes is often they lack the benefit of process improvement experience. And let’s not forget that process improvement techniques have been incredibly effective over the past century in manufacturing and more recently with Business Process Management Systems automating, and ultimately speeding up highly repetitive and high volume transactional work.

What this article, and many others, are discussing is the limitation of process improvement in the modern World and what happens next. In my experience the one area that seems to continually get left out is the human element. These so called unstructured and dark processes are being orchestrated by humans. These are experts in their field, they have experience and skills that allow them to adapt the way they work to the changing environment. They know when to employ a standard process and when something needs to be created ad hoc.

The thing that most of these workers are not, are process experts and therefore the processes they operate are not as efficient as they could be. I find in these areas people are continually bumping into each other, duplicating work or, worse still, getting things wrong.

Simple process capture workshops can be very useful here, the objective is not to create some perfect standardised documentation. The purpose is to get those working together in the same or related areas and to discuss how things are done today. Not tomorrow but right now. In an ever changing environment it’s easy to forget exactly what your colleague is doing, what they expect of you and what you expect of them. Running regular but short and simple workshops keeps people aligned without hamstringing them with over simplified and rigid processes. It allows them to discuss real and potential issues and how to solve them in the immediate future.

I’ve had this experience recently with agile development teams. There’s a high level 4 or 5 step process but what happens in each of these steps is different in nearly every iteration. After every third or fourth iteration the retrospective is run as a process workshop. The process is torn up and re-captured every time with a focus on what went well, that we’d like to do more of, and what didn’t work, that we need to get better at. This allows the team to openly share ideas and improvements and try them out in a highly agile environment.

It doesn’t make people process experts but it acknowledges these so called ‘unstructured’ processes as being essential. It also gives a checkpoint and an opportunity for continuous improvement.