IT Directions

Keith Harrison-Broninski

Matrix management and the HIMS

Vote 0 Votes
Most organizations interested in process improvement struggle with the classic problem of matrix management.  The key issue is resource allocation - how can process owners and line managers work together to assign work to people and manage the associated costs?

Let's consider the 3 dominant paradigms in modern process management:

1. Workflow (BPM), which is about flow, implemented via concurrent flowcharts - in this approach, as in the BPMN notation, the driver is sequence flow (of Activities) and/or message flow

2. Adaptive Case Management (ACM), which is about data, documents and rules, implemented via shared repositories - in this approach, the driver is knowledge worker judgement, constrained by policies implemented as business rules

3. Human Interaction Management (HIM), which is about goals and knowledge, implemented via dynamic, cross-boundary Plans - in this approach, the drivers are effective teams, structured communication, use of knowledge, time management and dynamic planning.

Organizations adopting Human Interaction Management System (HIMS) technology for managing human work are finding that it provides a universal solution to matrix management.

First, a HIMS provides the information necessary to make the issues associated with matrix management visible (a sine qua non for resolving them):

 - Who is involved in each Plan
 - What their responsibilities are
 - Who they will be working with
 - The deliverables expected from each person
 - The period of time during which each person will be involved
 - What percentage of each person's time will be required during that period
 - Whether this (combined with work in other Plans) results in more than 100% of their time being allocated
 - Who is managing each Plan

Second, a HIMS allows process owners and line managers to work together in high-level Plans, in which they use the information above to allocate resources to lower-level Plans for doing the operational work itself.

This is the approach used by the UK NHS, an early adopter of the HumanEdj HIMS, to manage highly complex, dynamic, cross-boundary processes involving many different teams and departments.

For more information on cross-boundary processes, you might be interested in this article.


Hello Keith:

As far I understood HIM advocates organizational matrix orientation, but this particular way of organizing an enterprise is only suitable for the ones that are project based enterprises like for example professional services.

One thing is managing processes result oriented, other thing is structuring companies in matrix just because somehow results pitch has been implemented across the organization.

Matrix model is also used when a company is executing a R&D portfolio where people get together aiming to introduce a product in a market. When the product is delivered the team disbands and the product it self is managed inside a product division, or a business unit division, or a functional division (Sales). This means that despite there are others business processes regarding sales, marketing and other to be managed, they can continue to be executed on a result oriented fashion - for example gain market share by actors that are spread across organizational units. Its not mandatory that they continue to be matrix oriented. Process actors are independent of the business box they are linked to regarding the activities they must perform everyday.



Hi Alberto

Thanks for this thoughtful comment.

As you know, I believe strongly in what you call "results pitch". My term for this is "goal-orientation" - for instance, the methodology used to implement HIM is "Goal-Oriented Organization Design" (GOOD).

In my experience, for any company large enough to have functional departments, results pitch inevitably results in matrix management.

This is because results are typically measured in terms of customer satisfaction - i.e., in terms of process outcomes. So each person not only reports to the line manager of their functional department but also to a number of process managers.

I think what you are suggesting is that results pitch may result in some process actors reporting *only* to the process owners, and not to the manager of their "business box" (i.e., functional department). This may happen one day, but most organizations are still locked into the departmental model, in which specialist skills and duties (e.g., accounting, logistics, sales, marketing, etc) are associated with a particular functional area, which itself has a manager.

This will probably change as more and more such functions are outsourced (a trend that cloud computing is encouraging), removing the need for organizations to manage their provision internally. Once accounting, logistics, sales, marketing, etc become utilities, there will be no more need for departments! But it may be some time before this happens in more than a few leading edge companies ...

All the best

Hi Keith,

you have described HIMS well enough to for me to find that I do not see significant difference between HIMS and, e.g. ACM. However, this is not surprising since in both cases pre-planning is replaced by the human knowledge workers.

The surprising is the part about 'dynamic'. I do not see a justification for this quality. Even if you say that human logic and actions are not 100% adequate to each particular situation and process-workers have to create flow logic on the fly, it is not a dynamic model yet. It is rather a compensation of the absence of the knowledge about the future (i.e. the next step).

Such model of compensating a lack of being ready for the next step is known for years and years, even in the human management domain. Thus, what is so specific about HIMS and why is it so good for matrix management? Is it better than others because people - process and line managers - do not want to collaborate in spite of they are paid for this?

Hi Michael

Well, you're not alone in considering a HIMS to be a form of ACM - the lead figure in ACM, Keith Swenson, also considers the reference implementation of a HIMS (HumanEdj, to be a HIMS - in fact, he describes it as "very much the prototype of what I would like to see in all [ACM] systems".

However, the use cases are different. ACM is essentially a point solution - you would use it to diagnose an illness, re-route an aircraft, handle a customer complaint, or (the classic case) handle an insurance claim. No-one would attempt to use an ACM system to deal with a merger, manage a strategic transformation programme, co-ordinate related IT projects, or integrate work across multiple government agencies.

For such work, people use a HIMS, since it provides repeatable structure, allows you to integrate management at multiple levels, and supports work that crosses organizational boundaries.

ACM is aimed at unstructured work and HIM is aimed at structured work - just not the kind of rigid, inflexible structure you get with BPM or traditional project management. This is why HIM is a "dynamic" approach - there is structure (so processes can be improved continually) but the structure can flex with business circumstances.

All the best

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives