Articles

The Technology of Human Interaction Management

In a previous article, The Philosophy of Human Interaction Management, we described some of the main principles underlying Human Interaction Management (HIM), a radical new business theory describing how we really work, and how we can be helped to work better. HIM sets the stage for a step change in business practice, by applying process principles to revolutionize the management of collaborative work.

These principles require 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 behavior typical of humans. People are not programs, and their behavior cannot be properly described, controlled or supported using techniques such as BPEL, BPMN or the UML.

HIM is the theory required to deal with humanistic processes. It permits dramatic cost savings to be achieved across the board, in any organization no matter its type, simply by adopting a new approach to such everyday activities as work assignment, project management and meeting organization.

This can be done whether or not any specialized software is implemented. However, IT is a fundamental enabler of any business practice. In this article we define a Human Interaction Management System (HIMS), describe its technical underpinnings, and discuss specific ways in which it can be used to transform business operations for competitive advantage.

At the heart of Human Interaction Management (HIM) is the Role concept—the recognition that a Role is not simply a label applied to a group of activities, but a rich, multi-layered representation of a process participant. In particular, a Role encompasses the goals and responsibilities of that process participant, as well as the private information resources it owns. HIM provides a number of process patterns and management techniques that can be used to control and support human interactive behavior — and all these depend on a rich Role concept as the fundamental means of process description.

To see why this concept is the most basic aspect of human collaboration, just consider the first question that anyone naturally asks when they agree to join a team, project, committee, or organization. Leaving financial recompense aside, the simple and universal question that enables us to understand at least in outline what we are letting ourselves in for—and to make an initial assessment of whether or not we wish, or are qualified, to get involved—is, “What is my Role in the proceedings?”

Each of us understands at a deep level that any collaborative activity—whether it is a supply chain, a marketing program, or a mammoth hunt—is based on the division of the participants into Roles. Roles tell us such basic things as who signs the checks, who approves the final deliverables, who gets to throw the spears (or catch them)—and who is to blame if it all goes down the spout.

In business life, process Roles may be played by individuals or by organizations—even sometimes by machines. In other words, there are different types of actors, or Users, that play, or take on, Roles. This means that, in practice, some Roles are carried out in a different way from others—shared between people inside an organization, for example, or composed largely of automated tasks. However, this makes no difference to our instinctive perception of the process. We still locate ourselves in a collaborative activity by identifying our own Role(s) in the proceedings, and those of the others we are working with, whatever their nature.

So, what exactly do we get from knowing our own Role, and knowing about the other Roles in a process? Various important pieces of information, including:

- A means of partitioning the work into separate groups of activity

- An understanding of each participant’s individual goals, which may be different from the shared goals of the process as a whole (if such shared goals exist at all)

- A way of subdividing responsibility within the process, so that everyone knows who is taking care of what

- A guide to who knows what about the different things going on—where the information lies within the process

- Who we can talk to—for reporting, access to information, requests for resources, delivery of outputs, and so on

Imagine, for example, that you are engaged by a government agency to help in an investigation into cost reduction. Before you can start work, you need to know with whom you will be working, what you will do as opposed to what they will do, what is expected of you in terms of deliverables, where to go for the information you need, and so on. All this is very different if you are the Project Manager, as opposed to a Business Analyst, as opposed to an Accountant.
Of course, knowing that you are the Project Manager (say) does not by itself give you all the information you need. The name of a Role is not enough—it must be fleshed out with the details of how that Role is to operate, and how it collaborates with the others around it. But without knowing your Role, you cannot even get started—and knowing your Role at least gives you a basic idea of what will be expected from you.

Hence, our starting point for analysis of human-driven processes is the division of a process into Roles—and there is a convenient graphical technique we can use to visualize such a process description. This is based on a long-established notation called Role Activity Diagrams (RADs). A sample Role Activity Diagram is shown in Figure 1.

This figure represents a dummy process in the engineering design domain. It depicts a manager constructing a design concept and brief, assigning some designers to the work, passing each one the same brief, receiving back the completed designs, then approving/rejecting each design for further processing. The diagram omits any interactions between designers, as well as the actions to be taken on approval/rejection. However, it includes the main notational elements we need, of which there are only a few.

Role Activity Diagrams originate from work carried out in the USA during the early 1980s, taken up by the UK government-sponsored IPSE2.5 project during the late 1980s, and used fairly widely by Business Process Reengineering analysts during the mid-1990s. However, partly for lack of tool support from major vendors, Role Activity Diagrams never made it into the commercial mainstream of business analysis, and are currently a niche approach used mainly by academics.

This situation is viewed by those familiar with Role Activity Diagrams as a pity, since the main alternatives adopted for process description are software design techniques (BPEL and the UML, for example), and hence not really suitable for high-level description of business activity. Not only are software design techniques confusing for business people to read, but they force the user into a process modeling approach that is biased toward providing IT support, rather than toward describing human behavior.

Role Activity Diagrams, on the other hand, are not intended for describing software—they show how people work together to accomplish their individual and shared goals. As a result, Role Activity Diagrams have been found useful as a means of documenting all forms of organizational procedure, in a way that anyone can understand—whether or not they have an IT background, and regardless of where they work in the organization. Most people can learn to read the notation in a minute or two. Moreover, the meaning of a Role Activity Diagram is generally clear almost immediately, whether or not you have an interest or any training in business analysis—something that makes the technique very suitable for our purposes here.

However, despite their advantages, there are good reasons why Role Activity Diagrams in their original (and currently standard) form haven’t acquired widespread tool support, and hence remained a niche approach. The standard notation requires simplifications, extensions and enhancements of various kinds in order to provide the foundation we need for Human Interaction Management. In particular, Role Activity Diagrams in their standard form are not well suited to computerized support, which is part of the reason why such support has been lacking. In order to build a Human Interaction Management System (HIMS), some alterations to the standard notation are necessary as well as desirable.
So what, exactly, is a HIMS? Here is the definition in technical terms—the specification for such a piece of software.

A process modeling and enactment system that provides native support for the six Role Activity Theory object types (Role, Entity, Activity, User, State and Interaction), uses a state-based approach to Activity enablement and validation, permits Interactions to be composed of multiple asynchronous channels, and supports management of process change by allowing any process component to be created and configured as a natural part of process execution — not just objects of the six fundamental types, but also the user interfaces by which they are presented (screens, for example) and the means by which they interact with other systems (Web service calls, for example).

A Human Interaction Management System can be likened to a world containing objects of several sorts. At the top level of the world there are objects representing Users, Role types, Role instances, Interaction types, Interaction instances, and Entity types—and other sorts of top-level object may also be required, depending on the system design. Objects have a mixture of human-driven and automated behavior. Some objects know about each other, and some objects communicate with each other. And all of them change, the whole time — a fundamental principle underlying a Human Interaction Management System is that the very fabric of each process can and will evolve as it takes place. Indeed, a large part of human behavior is directly concerned with guiding and agreeing on how processes evolve—this is what much of our daily work is about.

In general, the criteria given above for a HIMS are derived directly from the theory of Human Interactions—they correspond to the principles underlying human collaborative work and its management. The Role concept, in particular, is of primary importance. Some form of Role notion is available by default in many process support systems, since they allow tasks to be allocated to specific roles within an organization. However, the Role concept implicit in a Human Interaction Management System is richer than these notions — a Role in a Human Interaction Management System is an independent object, separate from the User assigned to it at any given time, and in possession of a private information space.

This information space includes both properties that capture data held internally to the Role, and references to other independent objects in the Human Interaction Management System—Users, other Roles, and so on. The Role uses the references as a means both of communicating with and of manipulating the other objects in the world. A Role may also have references to objects that are actually stored outside the process support system, for example documents—this permits them to be created, exchanged, viewed, edited, downloaded and uploaded via the Web in the manner of groupware or knowledge management systems (indeed, such systems may be utilized behind the scenes), yet under full process control.

Further, all the various objects in a Human Interaction Management System, not just Roles, are related to one another in different ways, such as:

- Composition — for example, an Entity instance may acquire other Entity instances as contents

- Specialization — for example, one Role type may be a sub-type of another

- Instantiation — for example, an Interaction instance may be created from an Interaction type

Some of these relationships are to do with the existence of both types and instances in a Human Interaction Management System. Each type needs to know about both its instances and any sub-types made from it, just as each instance needs to know what type it is. It is often sensible to use a successful process as the basis for others, which means utilizing instances effectively as types. And returning to the principle of continual evolution described above, everything in a Human Interaction Management System may change, including object types. Not only may a type be altered, but it may become unavailable (since a Human Interaction Management System world is distributed across multiple machines, possibly in separate locations and belonging to separate organizations) or even obsolete—in all these cases you must then manage the consequent impact on any existing instances.

What sort of technology do we need in order to build such a “world”?
One fundamental requirement that follows from the above discussion is the ability for objects to acquire and retain information about each other. This information is not restricted to enumerating specific properties of an object, but relates also to the object’s general nature—what sort of thing it is, what it can do, and how it does it. In fact, objects in a Human Interaction Management System often need such information about themselves as well as about others—for example, it is common in a Human Interaction Management System for a Role to change its own behavior as a result of circumstances. The ability of objects to “introspect” themselves and others in this way is provided in conventional object-oriented programming languages—in Java, for example, this ability is known as reflection.

Another fundamental enabler for construction of a Human Interaction Management System is the ability to create objects that are really extensions of other objects. For example, the many task types in a Human Interaction Management System can be divided into groups—some create Roles, others configure Interactions, yet others maintain Users, and so on. It is much easier to put such groups of task types in place if each member can draw from behavior defined in a generic task type that underlies the whole group. Otherwise, the same behavior must be defined again and again for each member, which makes maintenance of changes to the core behavior complex and error-prone. Again, the ability of objects to base themselves on others in this way is provided in conventional object-oriented programming languages—in this case the ability is known as inheritance.

Hence, when considering how best to implement a Human Interaction Management System, we should look for software development tools capable of providing object-oriented programming features such as reflection and inheritance. Ideally these features will be there by default, in the toolset itself. Otherwise you will effectively end up trying to recreate them for yourself as you go about building a Human Interaction Management System—a route forced upon you by the nature of the system you are trying to construct.

Leaving the details of implementation aside, why should one bother building such a system in the first place, when many of the improvements available through HIM can be achieved without the use of specialized software?

There are many arguments, not least the opportunity to integrate humanistic and mechanistic processes—to join up the dots in the organization by providing seamless support for the activities within a human-driven process. A HIMS provides not only a simple Web-based interface to all a person’s work—and to all their interactions with their colleagues—but also automated or semi-automated for appropriate activities.

Moreover, you cannot improve what you cannot measure. And while it is possible to capture metrics for humanistic processes manually, it is a lot harder than having them captured automatically, behind the scenes, by a process support engine. If we capture the right metrics, the theory of Human Interactions provides the opportunity to revitalize fundamental aspects of corporate life—since HIM allows us to deal with intangibles in process terms.

Let’s take a fresh look at indicators—the metrics used to measure a sound process. Methodologies such as Six Sigma typically pay constant attention to traditional process metrics such as:

- Is the error rate as low as possible?

- Is the process efficient in resource usage?

- Is the cycle time as short as possible?

- And so on.

Such hard factors are undoubtedly vital, because they have a direct and measurable effect on an organization’s bottom line. However, many quality-driven organizations have now reached the point where there is little improvement to be made in these areas—or little improvement that affects the price or customer perception of their products and services.

So, where does such an organization look for the continual process improvement necessary for business competitiveness, and mandated by ISO 9001:2000? Are there soft factors too—subtler aspects of quality, that turn out also to impact the bottom line? And since we cannot improve anything without measuring it, what sort of metrics should we be gathering in order to understand these soft factors?

General models do exist by which an organization as a whole can be measured, and some of these include a process aspect. For example, two widely used approaches are:

- European Excellence Model. The EFQM Excellence Model, a non-prescriptive framework based on nine criteria, can be used to assess an organization’s progress toward excellence. “The Model recognizes there are many approaches to achieving sustainable excellence in all aspects of performance. It is based on the premise that Excellent results with respect to Performance, Customers, People and Society are achieved through Leadership driving Policy and Strategy, that is delivered through People, Partnerships and Resources and Processes.

- Capability Maturity Model Integration. This is a staged approach to institutionalizing best practices that extends the original Capability Maturity Model for Software to domains including systems engineering, software engineering, Integrated Product and Process Development, and supplier sourcing.

Both these methodologies allow some features of organizational performance to be quantified in process terms. What they do not supply is a rounded and generic set of criteria that we can use to judge an individual process in terms of the humans who operate it. For instance, the European Excellence Model analyses the process aspect of an organization in the following terms:

Excellent organizations design, manage and improve processes in order to fully satisfy, and generate increasing value for, customers and other stakeholders.

- Processes are systematically designed and managed

- Processes are improved, as needed, using innovation in order to fully satisfy and generate increasing value for customers and other stakeholders

- Products and Services are designed and developed based on customer needs and expectations

- Products and Services are produced, delivered and serviced

- Customer relationships are managed and enhanced

The focus is all on the immediate deliverables of the process, whether these are products, services, or a better relationship with the customer. If we are to move beyond the limitation that caused business process reengineering to fail as a movement, we must take a wider view of processes, and assess them in more general terms. In particular, we need a set of criteria by which an individual process can be judged according to how it makes best use of the people involved.

This broader approach will give us an idea of whether or not a particular process is implemented so as to have lasting value, as well as immediate benefit. If a process is designed to capitalize on what enterprises conventionally state is their chief asset—their employees—then it is more likely stay afloat throughout the storms of continual business change, and to deliver its cargo come what may.

The theory of Human Interactions includes a complete set of criteria for measuring processes in terms of how people are used. vii For each criterion, example indicators are given that can be tracked, in order to provide metrics that permit process improvement against the criterion. These metrics are quite different from those conventionally used to measure processes—but they are no less important. Some of the criteria are related to the hard factors mentioned above, while others are softer—which simply means that the impact on the bottom line is indirect. However, the impact on the bottom line is always there, in every case.

Moreover, each criterion is generic—applying to both the public and the private sector, profit and non-profit organizations, SMEs and large enterprises, and all industry sectors. Hence all the criteria are relevant to any organization.

It is often the case that such aspects of process—those focused on human involvement—are handled better in small organizations than large ones. This is because people know intuitively that they should pay attention to such issues—and when direct control over the entire workplace is available attention can be paid to them relatively easily. However, as organizations grow in size, other issues start to predominate. For instance, people who were part of a large company when it was still a small one often bemoan the loss of a culture that they valued. They may declare that as a result their job satisfaction has changed in inverse proportion to their financial status, and say they are only hanging on until they have gained enough stock options to get out.

This benefits no one. Everyone gains more from a job to which they can give their all, wholeheartedly—and the organization gains most of all. Moreover, it is possible for large organizations to maintain a personal approach and values more typical of small organizations. They just need a new approach to quality management—which brings benefits of all kinds, not least financial. All that is required in order to do this is to adopt the next step change in business practice—Human Interaction Management—and corresponding software: the Human Interaction Management System.\