IT Directions

You can’t improve collaborative human work unless you can see it. In other words, you need a means of visualizing what is going on before you can even start to standardize then manage work with an eye to making it more efficient and effective.

For complex, high-level work, this is pretty much impossible without using Human Interaction Management (HIM). Planning and workflow tools show you task sequences but not the team and communication structures that enable productivity, empower negotiation, and increase use of knowledge. Further, task sequences in themselves embody a danger, in that using such an inappropriate means to describe complex human work typically results in either a restrictive level of constraint or a dangerous freedom (and often both).

By contrast, HIM provides a simple, business-oriented way to understand what is going on in a complex, high-level work process, by grouping work into goal-directed Stages, in each of which specific Roles work together in a structured way to produce and share Deliverables.

HumanEdj, the software tool for HIM, provides a number of visualizations. There are core operational views for current Plans, showing your personal outstanding work items and the status of each Stage. There are multi-layered views to provide context, showing the structure of each Plan and Plan template in terms of Stages or as conventional GANTT charts (but with advanced features about which I’ll say more in future posts). There are tabular views of Plans and Plan templates that can be copied and pasted into a spreadsheet. Finally, there are resource allocation views, that show by Plan and by person the amount of effort allocated to different processes.

Many of these views identify forms of action that may be required by managers to keep work on track, either by adjusting the structure of work processes or by re-allocating the people assigned to them. In the next posts I’ll look at this in closer detail. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Traditionally, the worlds of project management and process management have focused on different areas. Managers who use project planning techniques are strong on forecasting and monitoring the allocation of people to tasks and the resulting costs. Managers who prefer process-oriented techniques are strong on improving the way in which work is carried out, for example via techniques such as Lean Six Sigma. The project planning approach works well for one-off situations and the process improvement approach works well for work that repeats in much the same way. But what about work that doesn’t fit neatly into either category?

Much human collaborative work not only repeated (i.e., a candidate for improvement) but also highly adaptive - so flexibility on the ground is critical for success. To deal with both concerns, you need a combination of the forecasting/monitoring supplied by project management tools with the structured approach supplied by workflow tools.

This may appear to be close to the domain of Dynamic Case Management (DCM). However, cases do not have the same kind of formal structure as workflows, so it is hard to improve them. Their operation can be tightened up using business rules, but this is not the same thing as finding new and better ways to execute the work. The DCM approach is fine for the sort of low-level work in which it is safe to let the operator make their own judgements about how to do it (simple problem resolution, licensing, medical diagnosis, mortgage processing, invoice discrepancy handling, equipment maintenance, insurance claim processing, and so on). However, DCM is unsuitable for the sort of high-level, business-critical, and often very expensive work that typically crosses boundaries (complex problem resolution, research & development, marketing, complex sales, services delivery, merger & acquisition, organizational change, and so on). This latter kind of work needs careful management, for which managers need to see its structure in a helpful way, and tools that empower people from different organizations to collaborate naturally.

In particular, this means providing a combination of the resource and cost planning/monitoring features found in project management tools with the simple, clear depiction of underlying structure found in workflow tools - although with human collaborative work, you need a different kind of structure. Assigning tasks in sequence and describing their outputs is not enough.

In the next posts I’ll look at how HIM makes repeated, adaptive human work visible, thereby empowering people to improve it via the 5 principles. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Let’s suppose that you are working in a large engineering project and you discover a problem during testing. A particular operation is generating so much heat that some parts are in danger of malfunctioning or even melting. You report the issue to the appropriate Quality Assurance team. What happens next?

It is necessary to determine the cause(s) of the issue, choose a means of resolving it, and implement the corresponding changes. Since this is likely to involve a number of people, including engineers of various different types (structural, systems, safety, …), the work must be planned and resourced like a small project of its own. A first step is for the QA team to find someone to manage the work - and even this is no small task.

For a start, no-one wants the responsibility. Everyone has too much to do already! Further, even if someone willing can be found, approval to use them as a resource must be sought from their line manager as well as from the managers of whatever work packages they are currently involved in. It may be necessary to go round a number of loops, involving a number of different people and teams, before the work can even begin.

In effect, there are a number of different “conversations” involved in implementing a controlled change.

First, there is a conversation for “context”, in which the problem is described in full - the test results that led to it being detected, the symptoms that caused concern, background to the issue, and any other information that might help in its resolution.

Next, there is a conversation for “possibility”, in which people are contacted with a view to putting together a team to resolve the problem.

Then, there is a conversation for “disclosure”, in which full details are shared with possible team members, and their firm commitment is sought.

Finally, there is a conversation for “action”, in which the mini-project is carried out and (hopefully) approval is gained from all necessary parties for the work done to resolve the issue.

This last conversation typically requires creation and execution of structured work to fix the issue, which may be done via a shared workspace, a case management system, or even a BPMS. However, that work is only a part of what truly goes on. Without the surrounding negotiations in the final conversation, and without the previous conversations, the work cannot even be started let alone successfully concluded.

Further, anyone who has carried out such conversations will recognize that they do not happen neatly in sequence - rather, it is necessary to jump back and forth between conversations, adding and removing people, as the negotiations proceed.

Similarly, it will be clear to many people that the structured work at the core of the conversation for action may itself contain many smaller versions of the whole issue, as sub-issues are discovered and rectified. Just like the main issue, each sub-issue will require its own set of conversations.

This pattern is not specific to engineering. It is encountered wherever work crosses organizational and management boundaries, particularly if there is a need to negotiate on allocation of resources. Other examples I have encountered repeatedly in the last few months are implementing transformational change in local government, and planning the assignment of innovation agents to multiple customers.

If you would like to know more about how to deal with such situations, you may be interested in the further information available here.