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.

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

I #love process workshops

I’ll say that again, I love process workshops. Over the last 10 years I’ve run hundreds of workshops working with teams to reach a common understanding about ‘how things are done around here’ or to design new ways of working. In that time I’ve never been in a workshop that I didn’t enjoy.

There have been times when it’s been hard, generally participants resisted participating for a variety of reasons. But they always ended in everyone getting some value from the experience and I’m not talking about a bunch of flow charts!

If you’ve not been in a process workshop before, or at least one that I’ve run, it goes something like this: you gather a group of ‘stakeholders’ in a given area of process. I say ‘area of process’ but in truth it’s normally existing teams or departments that are not really organized around process. The goal is to reach a shared understanding of the existing process (sometimes called the As-Is) or to design and agree a new process (To-Be). The output is a set of documentation and recommendations.

For me it’s always been about communication and understanding. Get the team together to talk about things they generally assume each other knows but in reality don’t, or don’t see it in the same way. As a result the approach is simple; who are you, what do you do and why, next. With such a simple approach people engage quickly and easily with it. Conversations develop, especially around the why, that gives the team a deeper understanding of what each other does, the challenges they face, the value they add and the help they need. It’s about the team working effectively together and at the end of the session they know it.

A byproduct of this interaction is a set of documentation and lists including pain points and improvement suggestions. As far as the participants are concerned this may well disappear into the ether and resurface as some sort of automated solution in the future. But right now they don’t care as the chances are they learnt something new today that will make their lives easier.

Can Process Improve Communication?

It is with some frequency that I am presented with inaccurate process documentation. The degree of accuracy varies but what’s interesting is that the degree of accuracy varies depending on who you ask. One version of a process, involving multiple actors, can range from a perfect representation of reality (impossible!) to unrecognizable (probably closer to the truth) within a single team!

Keith Swenson, referencing Cognitive Nueroscientist Michael Gazzaniga, describes how process descriptions can be full of inaccuracies because of the mind’s need for coherence. We give more weight to a coherent story than an accurate one. As a result, when interviewing process participants, they are as likely to fill in the gaps of their knowledge of the process with something that makes sense than what actually happens.

In his book Thinking Fast and Slow, Daniel Kahneman describes the human mind as two systems he calls System 1 and System 2. System 1 is your intuitive mind, it is the part of the mind that reacts instantly to sudden events, it is in control when we are completing simple tasks, it recognizes faces, sounds and smells. Often our intuitive minds fly solo, allowing us to complete tasks on autopilot without much thought or concentration.

System 2 is your rational mind, the part that calculates mathematical problems, the part that works through complex puzzles and formulates thoughtful responses to problems and is used in situations where high levels of concentration are required.

Our intuitive mind makes assumptions based on past experience, norms and memories often without consulting our rational mind. According to Kahneman our rational mind is lazy and allows the intuitive side to create these assumptions without question. When an individual describes a process, of which they have incomplete knowledge, the intuitive mind fills in the gaps as it would expect to do those steps in the process it does not know. This feels natural to us, when our rational mind is at rest, the coherence of the described process feels right and the rational mind is not called in to check the validity.

This is why I prefer running collaborative workshops involving multiple process actors rather than individual interviews. Watching them attempt to fill in the gaps for each other can be quite colorful. Process workshops force disagreements and a search for consensus and bring our rational minds into play. It forces us to both mentally and verbally question what we see and hear. While this allows, to some extent, the discovery of the truth it has another powerful effect, it creates a level of mutual understanding between players that improves communication. The act of talking through and visualizing a process can often, in my experience, actually improve the effectiveness of that process without any attempt to change it. Process improvement suggestions are common in these sessions but they are a by-product of improved communication.

The Real Inefficiency?

In my last post I outlined how concepts of product usability might be applied to the work place as Business Usability. I want to expand the idea of the conceptual model and how the modern knowledge worker is often at a disadvantage compared to their historic colleagues.

In everything we do there is a conceptual model and a mental model. The conceptual model describes how something actually works and the mental model is how we ‘think’ something works. The success in anything working properly for us is when those two models converge. When our mental model matches the conceptual model things are obvious and easy to do.

In many workplaces the conceptual model of how things work is embedded in the environment. Think of a train station, there is a ticket desk, a platform and a train. You go in, you buy your ticket at the desk, you go to the platform and then board the train. There are sometimes signposts to help you in larger stations. Here we know what the steps are because the environment, and our cultural knowledge, dictate this. Some stations/airports work better than others.

Think how relevant this is in manufacturing environments, production lines, where every machine and person has a place, the trigger is the incoming widget the output is the outgoing widget+. It’s easy to train people, and for them to sustain their understanding of what to do because their environment provides so many visual indicators. They don’t have to remember everything only enough to mentally piece together what they actually need to do. As humans we use this type of construct to save us having to store information in our long-term memory. For the vast majority of us long-term memory is incredibly inefficient, you know what it’s like when you try to remember the name of ‘that’ song or the author of ‘that’ book. What we are very good at is piecing together, or constructing, memory based on recognizable identifiers.

Now consider the typical office worker, or knowledge worker, where the environment provides no clues as to what happens next. A computer, desk and a telephone. Without these traditional indicators we have become inefficient as we have to work harder to piece together the steps required to meet our goals. We must rely heavily on long-term memory and spend a good deal of time looking for information, discussing with colleagues and guessing at the steps we need in order to get there. This is, perhaps, one reason why process improvement methodologies have not been as successful in the information domain as they have in traditional industries.

As we spend so much of our time staring at the computer screen it seems sensible that these identifiers should be embedded there. There are many software apps available that do a good job of providing the right amount of information at the right time to help you understand what you are supposed to do when you are using them. But outstanding user interfaces are still in the minority and they are generally limited to the activities for which they are used. They do not provide clues that lead you to them in the first place, nor what you do after you have finished using them.

What is required is a common platform that provides just enough information at the right time to the help user achieve their goals. Detailed procedures or complex flow diagrams are not ideal; they require examination and concentration that takes time away from real work. These new ‘conceptual models’ need to be instantly accessible and, where appropriate, interact with the underlying tools and applications that are required in order to complete the process.

Perhaps the biggest inefficiency in modern business is the time workers spend trying to piece together what they are supposed to do.

Make Your Business Usable – Business Usability

Your systems are usable right? They have great user interfaces that are a pleasure to use, everyone loves using them. But what about your business’ usability? For the end users, your employees, how usable is your business? What is the user experience like? If the user experience is bad workers are wasting their time trying to figure how to get work done. If the user experience is good workers are spending their time innovating and delivering the organisation’s goals and objectives.

So how does one make business ‘usable’? In his book, “The Design of Everyday Things”, Donald Norman sets out some simple principles for designers. 1) Provide a conceptual model, 2) make features visible, 3) map actions to features and 4) provide feedback. A conceptual model should provide a framework for what happens when and why. Sound familiar? The conceptual model for business is locked up in the process documentation, manuals and procedures that are common place within most organizations. The problem is that for the conceptual model to be effective it cannot be too detailed, overly complicated or simply unrecognisable to the user that needs it. And this is exactly the problem with much of the process documentation that is captured today. It is not created with the end user in mind unless the end user is considered to be a system or analyst. Care is not taken to provide just the right amount of information to the user completing the tasks.

Humans are intelligent creatures; they don’t need to be told exactly how to perform an action every time they do it. They need a reminder, a framework in which they can place themselves and act to produce a desired outcome. Overly detailed and complicated documentation will simply serve to confuse and frustrate the user. Thought must be given to the level of information required for that person to perform their tasks efficiently. It’s probably less detail than you think. Some areas may need more detail than others. Some processes may be highly regulated while others are completed infrequently or by unskilled labour. There’s a chance that these will need more detail but even then don’t overwhelm the user.

Make the features that make up your business, visible. These are the process documentation, the various systems and tools required by users to complete their work. Think about where the documentation is held today, some in the BPMS, some in the training system, some is on your hard drive and in various intranet and shared stores. Creating a portal and listing everything in it does not make it visible.

The conceptual model needs to be delivered to the user in context. It needs to be easy to locate. Some form of tagging is useful based on a taxonomy that is easily recognisable to the users. When the content is delivered to the user it should not just reference the system to be used it should link the user directly to it. This is about mapping what needs to be done to the tools required to do it.

Finally provide feedback to the users. Instant feedback should be provided when systems are launched, when workflows are kicked of or when data is committed. Holistic feedback should be given through real time metrics displayed in the context of the process.

I believe that improving your organization’s usability is perhaps one of the most important things you can do with regards to efficiency. It also supports the other two aspects of ‘social’ I described in a previous post. Combining all these approaches can make BPM an essential component of your social strategy.

Acronym tennis, BPM back on center court

I’ve never really understood the lengths some go to in order to argue a case for a single, agreed definition for Business Process Management (BPM). At best, the hours of debate bring some fringe insights into aspects of BPM not previously considered. At worst it’s a serious distraction from the real work of helping organizations focus on working better.

In fact I have always seen this as a distinct advantage. I hear a sharp in take of breath at this point. As I’ve discussed previously the words Business, Process and Management are entirely open to interpretation and for good reason. From a customer’s point of view this allows us to shape the definition to suit the organization and it’s specific problems. A definition can be agreed that fits the culture and supports the strategic goals.

However, recently I have found myself engaged in discussions with colleagues and analysts exploring advanced aspects of BPM. In order to fully understand these, and ensure we are talking the same language, I found it necessary to come up with a single definition we could all agree on before proceeding. So here is that definition, I’m sure to many it’s nothing new but perhaps some might find it useful as a simple concise description of BPM.

I start by describing Business Processes as:

• everything an organization does in pursuit of its strategic goals.

Those goals may not be well defined, if at all, but they still exist even if only in the mind of the CEO. Employees may not know what they are supposed to achieve which is why I use the word ‘pursuit’. Business processes exist, they may just be unstructured and have no clear goal.

Therefore,

• Business Process Management is a systematic approach to understanding and improving business processes in order to achieve the strategic goals.

Here I use the word ‘achieve’ because the assumption is that if the organization has matured to the point that it recognizes some form of management of what they do is required then they must know what they are trying to achieve.

It’s simple, it does not attempt to imply a specific tool set, it does not impose notions of customer needs or efficiency and effectiveness. The later are strategic goals and, like tool sets are agnostic of BPM. This definition does not impose specific approaches nor does assume an overly prescriptive methodology for documenting, governing and enforcing process steps. This is entirely up to the organization applying the approach.

Does social technology change the As-Is versus To-Be debate?

In a previous post I discussed how Business Process Management can, and should, be a social experience even without modern social technology. One reader sent me the following message:

 I think [you are] refering to ‘to-be’ processes. Someone still may have to describe today’s reality and sometimes just a good BA and a few knowledgable SME’s gets this job done far quicker, accurately and without too much ‘socialising’.

I don’t wish to add too much to the As-Is versus To-Be debate here except to say that every situation is different and will require an appropriate approach.

I do believe, however, that modern social technology is changing the way we approach this debate. With the new crop of BPM tools available the line between As-Is and To-Be becomes somewhat blurred. When capturing As-Is process, using a simple goal driven approach, the deficiencies in the process are often painfully clear to those present. A good Social BPM product should allow the facilitator to instantly capture those issues, and improvement suggestions, against the point in the process where they were raised. This means, to some extent, that you are simultaneously capturing As-Is and To-Be at the same time. Even if you are proposing a radically new process you can capture potential issues and essential steps during the As-Is capture.

A team of knowledgeable Subject Matter Experts (SME) could undoubtedly capture today’s reality quicker without the interference of end users. But is this the best way? Firstly you are excluding the very people that have firsthand experience of the execution of the process. There are often issues experienced during the everyday execution but there is no forum in which to express these. And if these do exist they are disconnected from the context of the process.

Worker engagement is key to the adoption of any new or improved process. Clearly you cannot invite every worker to a workshop, although I have seen attempts to do this! But you can invite some key influencers and of course the platform should allow everyone to comment on the As-Is as well as being able to see the other comments captured during the workshop.

I would argue that the long term benefits of worker engagement in understanding and improving the process is worth more than a quick capture that ends up on an intranet and never looked at.

Making BPM Usable

This is where I believe social can have one of the biggest impacts on BPM. I’ve heard the following phrase, or variations thereof, many times recently. “Social network platforms have become so ubiquitous in our personal life that people now expect them in their work life.” While there are undoubtedly great benefits to adding this capability to the work place I believe there is more to it than that.

Donald Norman’s seminal work ‘The Design of Everyday Things’ was written over two decades ago and explains in very simple terms how life is made overly complicated by poor design. He advances some very simple principles that help designers create products that are easy to use. Yet many software vendors, especially of the enterprise variety, continue to create products that require advanced knowledge in order to complete simple tasks. There is a multi-billion dollar software training industry that exists to close the gap between poor interface design and helping workers complete tasks.

Products like Facebook, Twitter and LinkedIn are easy to use. Some are better than others; each is a variance on a conceptual model which is becoming culturally recognisable to a larger and larger proportion of society. So when software vendors start to bring this type of technology into their own products they cannot, or rather should not, make them more difficult to use than what people have become used to. A majority of BPM vendors, that have released social enabled platforms, have taken care to preserve those ideas of usability and in many cases even begun to improve the underlying product.

This is a positive and constructive improvement to the industry at large. It will improve adoption by the end user community and help acceptance of BPM as a whole.To be ‘social’ BPM must become more inclusive, to be inclusive it must be accessible and that means better usability than most workers have traditionally had to endure.

It Doesn’t Have to Have Social Tools to be Social

Improving collaboration is perhaps the most obvious benefit to adding social capability to BPM. But don’t we collaborate on processes today? Of course we do but the new social tools add a new dimension to the rich set of communication tools we already possess. Email, telephone, video conference and Instant Messaging, amongst others, are augmented by forums, wikis, blogs and micro-blogging. This new dimension puts conversations and ideas in the public domain. It records and catalogues those discussions and makes retrieving articles easier than searching through your email archive or trying to recall a phone conversation.

There are several stages in the process lifecycle where social technology can have a real impact on collaboration. Marco Brambilla draws an excellent picture of how these technologies can impact the lifecycle in his article “Social BPM: motivation and impact on the BPM lifecycle”. But if Social is to influence BPM as an approach, as much as it does technology, then collaboration must continue to take place across all mediums including traditional forms of communication.

Starting at the initial capture of process, in my experience, nothing is better than doing this in real time with key stakeholders and end users. But simply running a live workshop is not enough. Process has to be captured in a way that is instantly recognisable to the participants. It should really be done live in a capture application as this format will be presented back to the participants later on, they need to recognise it, instantly.

The notation you use is not important; it’s how you use it that’s important. To be social it has to be inclusive, to be inclusive it has to be recognisable to everyone present. To me the best approach is a goal based approach to capture. This is useful for several reasons; getting people to realize why they are doing something is often more important than how or what. This is where you can identify value add, it’s the interface between people and teams and if your stakeholders are not aligned on this then this is great place to get them aligned.

Goal focused workshops are exhilarating. This is because there is normally something for everyone. It’s not a case of documenting the knowledge stored in someone’s head then spending hours poring over it to find inefficiencies and errors. It’s about everyone agreeing what they are trying to achieve, as a result many process issues are solved right there and then by the people responsible for executing them. Best practice is created by those that practice.