Articles

The Philosophy of Human Interaction Management

Process management techniques are often touted as a means of cost reduction - typically through better use of established systems via “process projection”, streamlining business activities both within and across organizations, or automating routine tasks that are currently manual. However, the ROI on such efforts can be hard to gauge – not least since process implementation is generally ongoing in which the identification and handling of exception situations, not to mention new requirements driven by business change, keeps on adding to the initial implementation costs.

Hence, many of those with experience in the field would argue that adopting business process management technology is not just about immediate cost reduction, but part of a wider move towards process orientation, that brings important advantages in areas such as cost identification, regulatory compliance, risk mitigation, productivity, and quality of business as well as providing the necessary underpinning for continuous process improvement.

Having said all this, are there specific areas in which process management can provide a quick and effective means of cost reduction?

There is such an area - human interactions, the driving force behind every organization. An organization in which people did not work together to address business issues would stop dead in its tracks. It is these collaborative efforts that underpin every company and public body. Yet in most cases they are poorly understood - and hence poorly managed - from a process perspective.

The article gives examples of collaborative working situations in which human interaction leads to operational inefficiency, outlines techniques that can be used to regain control, and sets the stage for the next step change in business practice: Human Interaction Management (HIM), and the advent of the Human Interaction Management System (HIMS).

Let’s take a simple, everyday situation. Some people agree to work on a specific item together - a document, a design, a new business model, whatever. They meet to brainstorm ideas, and come up with some possible approaches. How are they likely to leave matters at the end of the meeting?

Unless the process has broken down in discussion, the final few minutes of each discussion in the meeting will consist of a consensus - not just on deliverables, but also on the next steps that each party will take. Some will go away and work on specific approaches, for instance, while others may investigate availability of resources such as funding or office space.

Such consensus is conventionally expressed in terms of actions in meeting minutes. However, meeting actions are a weak means of description, since they only say who is to do what - not when they will do it, what resources they require, what the dependencies are on other actions, and so on. At best these details are referenced in the main text of the minutes, quite separate from the description of the actions themselves - at worst, action details are left implicit and unstated. The weakness of actions in meeting minutes as a means of agreement on next steps is a common cause of upset later on. For example, people fail to realize that their own actions were holding up others, and thus unwarranted delays get introduced along with a culture of blame.

For example, each action from a meeting could adapt this technique to provide an improved representation of meeting actions, in which each action from a meeting is described as an interaction between process participants, labeled with a speech act.

What people attempt, and generally fail, to do via meeting actions is to describe parts of the process that the meeting belongs to—the parts that lie in the future. It is possible that after a meeting, the actions will be enshrined in a plan, in which the resources and dependencies will be clarified. However, people do not typically base their daily work directly on a plan—charts such as GANTT and PERT are intended as a means of management monitoring and support, not as a means to facilitate or explain the work itself to those who must carry it out. Moreover, most projects have very complex plans, in which individual people find it hard to locate and place in context their own activities, let alone those of the others they are working with. A simpler, more immediate way of representing agreement on the rest of the process is required.

Only if a clear way of expressing agreement is available will people know that the commitment to working together exists on all sides, and that everyone agrees how this is to be accomplished. Each player needs to know that all other players have signed up to the same process that they have.

One technique that is conventionally used to structure the interactions between process participants is speech acts. These can be used to give each interaction a label that describes its intent, for better mutual understanding among the participants. Shown in Figure 1 is the classic Conversation for Action (CfA) pattern, which represents a generic negotiation for supply of a product or service.

For example, let us suppose each action from a meeting could be better described as an interaction between process participants, labeled with a speech act. Let us suppose that we have just held a meeting to discuss the development of new reports against a corporate database, and now wish to document the agreements made. Actions that might be noted as “Business Analyst to check calculations in report specifications” and “Report Developer to write reports” would be better described in terms of three separate interactions:

- An interaction between the Report Designer and the Business Analyst, in which the designer passes a set of specification documents to the analyst. This would be labeled with the speech act “Declare Complete.”

- An interaction between these two and the Project Manager, in which the documents are either signed off or not. This interaction would be labeled either “Accept” or “Reject,” depending on the contents of the message.

- An interaction between the Project Manager and the Report Developer, passing across the design documents as a basis for starting development. This would be labeled “Request,” to indicate that programming work is being commissioned.

We have applied conventional speech acts, based on those in the Conversation for Action (CfA) pattern, to enhance our interaction list. It is immediately clear that, for instance, the Project Manager will be included in the Accept/Reject notification, and also that it is the Project Manager’s duty - not the Report Designer’s - to initiate report development.

However, even with speech acts added as labels, a list of interactions on its own does not tell us enough. The CfA pattern in its standard form, for example, leaves it open for either party to withdraw at any time - hardly a reassuring basis for anyone on which to start their work. With our list of required interactions above, it is unclear what the consequences are, if any, of the Business Analyst declaring the calculations incorrect - or that some of them are incorrect.

For instance, the Report Designer may believe that if most are okay, the reports will have to be issued with a warning, but development can go ahead as is, at least for now. The Business Analyst, on the other hand, may not feel it sensible to allow the reports to be released at all until every single calculation is accurate. It is quite possible that this difference of opinion was never discussed in the meeting, or if it was, that it was never resolved properly.

The point is that successful co-operation requires more than a list of actions, even if their place in the process is somewhat clarified via the use of speech acts. The need is for:

1. All parties to reach a shared understanding; and

2. Each person to be satisfied all other parties are committed to this understanding.

This does happen sometimes, of course, but the means is generally informal - people talk to one another at sufficient length that they hope things have become clear. If certain things have to be left vague for the moment, people are only happy to do so if they have first established trust. However, you cannot guarantee that informal means will work, and often they don’t.
For a start, collaboration between many people is much harder to synchronize than collaboration between few. Further, we all express ourselves in different ways - even between two people who know each other well, simple misunderstandings can arise.

Suppose two colleagues are working on a document together, and meet to discuss changes that one of them has just made. The person who has made the changes comes away from the meeting with the impression that the other will immediately start reviewing their work - but the other person comes away with the intention only of doing so at some unspecified time in the future. This is a particular weakness of speech acts. It can be hard to distinguish between “I’ll do X straight away” and “I agree that X should be done, and I’m probably the best person to do it.”

What we need is to know is not only that other parties will deliver something to the rest of us and what sort of thing will be delivered, but also that those responsible are aware of how this affects the rest of us. In the example, the person who has made the changes might be hoping to show the revised document to a third party, and waiting anxiously for their colleague’s feedback. When it doesn’t come, it’s no one’s fault - but the relationship may end up breaking down.

This is the missing element from the “list of interactions” approach to documenting meeting actions. Even with speech acts added, there is no implied understanding by each party of the impact that their activities have on other people, or commitment on all sides to resolving any problems that arise.

In order to make everyone aware of this context, we not only need to set and agree upon the expectations of each party - the documents they will supply, the sign-off they will make, the funding they will provide, and so on - but also to show how these expectations are part of a wider process.

We must make a clear, unambiguous depiction of the rest of the process in neutral terms and this depiction must be easier to understand than a GANTT or PERT chart. We have the basis for such a depiction in interactions between Roles together with speech acts as labels, but these must be used in a way that gives us more detail on when things are to take place, what the dependencies are, and so on.

We can achieve this by a specific use of the Role Activity Diagram (RAD) notation. A fully-fledged RAD typically includes multiple activities within each Role, as well as the interactions between them - it shows show how the interactions form part of a process. All we have to do in order to use Role Activity Diagrams for agreement description is to:

- Leave out most of the activities contained within each Role; and

- Label the interactions with speech acts.

Then we have a simple picture that can be used to represent the agreement reached in a meeting, between the participants of a process, on what is to happen from now on.

Returning to the report development example, we can draw the list of interactions plus speech acts on a small Role Activity Diagram, shown in Figure 2. In this diagram, the rounded rectangles are process participants, the shaded boxes represent activities, the clear boxes are interactions, and the circles are states of the process. For simplicity, we leave out what is to happen if the calculations are not correct in the specifications. In practice, this kind of alternative is often left out of meeting actions anyway, as discussed above - an immediate and important benefit of the graphical depiction is that this immediately becomes obvious to all concerned.

Now that we have the Role Activity Diagram, which takes no more time to create than a set of meeting actions (and often less), it is absolutely clear that no development work will start until the calculations have been checked and the reports completely signed off by the Business Analyst.

This not only resolves the implicit difference of understanding about the basis on which report development can start, but may have a more subtle impact on the process. As with our example of the two colleagues working on a document together, without the Role Activity Diagram it is quite possible that the Business Analyst will leave the meeting with the understanding that the calculations should be checked - sometime. Report development is not the main interest, so the two colleagues don’t give much thought to it, and fail to realize that report development is waiting for them. Even if they do think about it, they are quite likely to assume that the developer can at least get started, and only needs their feedback at some point during the programming work.

This kind of scenario is a very common cause of delays, and of frustration among colleagues. To the report developer, it is obvious that there is no point starting development until the specifications have been signed off. Days or weeks go by without draft reports being prepared for testing, with all sorts of concomitant delays arising in other areas, and by the time it’s all sorted out tempers are frayed and deadlines slipping. The impact of such delays and frustration is significant - not least in the increased costs to any project which suffers from them.

It is not simple enough to say in such a case, “the Project Manager is obviously at fault here, since co - ordination of activity is their job.” The example is about as simple as possible - for in a small project containing only a few such activities, no doubt the Project Manager would be able to stay on top of things. Most projects, however, and most teamwork generally, is a lot more complex. Interactions and consequent dependencies arise all over the place - it is hard, if not impossible, for any one person to ensure that all of the dependencies are well understood by everyone, and that all concerned are doing their bit.

Further, teams in which one person takes all the responsibility for everything are not really teams at all, in the true sense of the word. A successful team is one in which the members each understand, accept and live up to their individual obligations. It is preferable for everybody if people are self - motivated, rather than having to be continually prodded by a manager. Much as people may wish to act responsibly, they are unable to unless they have a simple means of understanding exactly what their obligations consist of.

This is almost impossible to do unless all concerned have a clear and up-to-date understanding of the process that they and their colleagues are engaged in. Much of the awareness that people have about the actions of others, and much of the information they exchange, is effected via indirect means - gossip and hearsay, interpretation of observed actions, written material, changed workplace layout, even the discovery that work has been passed on from one person to another. Sometimes confusion can be cleared up in these ways, but often as not, relying on such means of communication just creates more confusion.

Take another simple case - journalists who normally fact-check every column they submit to a Webzine. Suppose that, for some reason, they stop their fact checking for a particular period. This might be due to an instruction from their manager, a change in their terms of employment, the belief that someone else has been delegated to do it instead or simply due to a misunderstanding of what their duties entail. How is the company that is ultimately responsible for the Webzine to know that the fact-checking has ceased, and take steps to ensure they do not publish material that may be factually incorrect?

It is quite possible that the matter will not come to light until someone reports the errors, which could be days or weeks after the fact-checking ceases. By then, material may have been published on the Web that damages the magazine’s reputation, perhaps permanently. If such cases are to be avoided, it is critical for all concerned to have some means of understanding very clearly what they are personally responsible for, and what their colleagues are responsible for - and this understanding must be accurate now, not at some time in the past. One might expect that the managers responsible will act to ensure this, but as often as not, it is unclear who exactly is responsible for what, so important actions simply fall down a black hole and fail to be taken.

Let’s step back for a moment. We have looked at simple examples of human interaction that show how easy it is for collaborative processes to go astray, and how damaging the effect can be. The discussion above shows that conventional means of managing human work (for instance, project planning techniques) often fail to deal with many of the most important activities that people carry out within these processes. So let us suppose that a process-oriented organization adopts better techniques - the techniques of Human Interaction Management - to organize collaborative human behavior. How will the organization as a whole fare better, once such work is defined and managed in process terms?

Our natural expectation is that process modeling techniques help to define the diverse goals and responsibilities of each individual, as well as how they interact to fulfill them. Process modeling techniques should also, surely, capture important working activities based mostly or entirely on mental effort - since it is the analytical and/or the creative capabilities of an individual that often help them to win their job in the first place. Last but not least, such process modeling techniques should form the basis for effective management of that work - in particular, to separate the varied forms of control required.

The theory of Human Interactions distinguishes 3 separate forms of process control:

- Management control: the day-to-day facilitation of human activity - ongoing resourcing, monitoring and process re-design. This is part of operating the process, and comes from within.

- Executive control: determining the primary Roles, interactions and deliverables of a process. This is about setting the framework for a process, and comes from above.

- Strategic control: a yet higher level of management activity, concerned with the general direction of the organization, as expressed in vision and mission statements, corporate policies, corporate roadmaps, and so on.

The first two forms of control are particularly important for the modeling of everyday human working activity.

In general, efficient management of human activity at every level depends on the establishment of process orientation inside the organization - just as with efficient management of machine activity. However, it is difficult if not impossible to capture goals, responsibilities, interactions, mental activities and these forms of control using mainstream approaches to process modeling. How could one even start to do this using BPEL, BPMN or the UML, for example? Such techniques are designed specifically for the description of regulated, routine, largely automatable activity - they are particularly useful when attempting to capture processes driven by machines, with only occasional human involvement. But when it comes to the dynamic, collaborative, innovative processes driven by humans, such techniques fall down — particularly since continual change to the process description is an everyday and integral part of process enactment. This is not a weakness of the techniques - it is simply that they were developed with different ends in mind. We need to supplement them with additional techniques, which enable us to capture the processes centered on human collaboration in a natural way, and build a more complete depiction of business operations.

It is now increasingly recognized that processes are what businesses in the networked future will compete on. At present, however, this competition is restricted to mechanistic processes. How much competitive advantage is there to be gained by organizations that develop an understanding of the humanistic type of processes too? After all, take away the activities of the humans in an organization, and the organization will stop dead in its tracks - so the humans must be doing something important. In fact, it is quite alarming when one considers how much time, effort and money is wasted every day, in almost every organization, due to the inefficient organization of collaborative human work.

Taking another simple example, how many meetings do you attend where all those present are genuinely required, no-one is missing that should really have been there, most of the discussion is pertinent and effective, each agreed action is universally understood, and each agreed action is subsequently acted upon as intended? Probably very few, if any.

It may be hard to calculate the exact hidden cost of such inefficient operations - but they are endemic to organizations of all kinds, all sizes, and all locations. It is a natural part of most people’s nature to depend on interaction with their colleagues in order to carry out their daily work, whether the interaction is face-to-face, by telephone, email, video-conference, or any other means. However, this does not have to mean that interactions should be unstructured - if anything, too little formality just leads to lack of control, stress all round, and wasted time. People will always chat in an informal way, but they should also be provided with the means to get their business done efficiently - both for their own sake and for that of the organization they represent. Even taking as simple and minimal a yardstick as possible, the salaried cost per hour of each employee who wastes time due to inefficient interactions with their colleagues, suppliers or customers, one can see that there are clearly significant savings to be made by giving the human side of business operations a proper process orientation.

However, if we are to deal properly with human behavior in the organization, we need a new approach to process modeling. However well suited current process modeling techniques are to describing mechanistic and repetitive activities, they are very poorly suited to capturing the dynamic, innovative, interactive behaviour typical of humans. People are not programs, and their behaviour cannot be properly described, controlled and supported using BPEL, BPMN or the UML. A new approach is required to deal with human-centric processes.

That approach is Human Interaction Management (HIM) - an emerging discipline synthesizing ideas drawn not only from process theory but also from fields including biology, psychology, social systems theory, and learning theory. Human Interaction Management is a simple, practical and universal method both of modeling and of managing human collaborative working behaviour - a set of principles that describes how we really work, and a method that shows how we can be helped to work better.

HIM permits dramatic cost savings to be achieved across the board, in any organization no matter its type - and whether or not any specialized software is implemented - simply by adopting a new approach to such everyday activities as work assignment, project management and meeting organization.

The ideas are mature, and there is enterprise strength software ready to support them. A new playing field is opening up, and it is the early adopters of the Human Interaction Management System (HIMS) that will reap the greatest benefit, acquiring a competitive edge based on what all companies of all kinds regularly claim to be their greatest asset - their people.

In the second article of this two-part series, we will define a HIMS, describe its technical underpinnings, and discuss specific ways in which it can be used to transform business operations for competitive advantage.