MWT Collaboration Architectures are a critical component of the MWT Model.  In short, a collaboration architecture defines how individuals collaborate on a particular task.  As with most architecture work, the focus is on what needs to be shared and what needs to be standardised.

Collaboration architectures are not sequential (though there my be some shared sequences for some collaboration architectures) and importantly these are not collaboration processes.  Rather than roles and responsibilities their is just enough of a shared framework where the right roles and responsibilities emerge.  There is also just enough of a shared understanding of risks so that their is reward in putting effort into risk mitigation rather than an incentive to avoid working on activities with inherent risk.

It’s a simple concept but effective collaboration is not something the management discipline currently guarantees.  General management provides a mechanism for defining roles and responsibilities; project management provides a means of managing costs, schedule, and risks; and there are of course disciplines of around strategy to get things started, and conflict management when none of this works are it should.

But ultimately there isn’t a lot of focus on how individuals need to actually collaborate around a set of shared artifacts in order to get something done.  It’s been over-stated already – but this situation is not acceptable in the information age.  But nor has it been corrected by the information age.  Business process management (BPM) technologies are rarely implemented –  and when you look at the types of processes they are able to support (i.e. Non-collaborative) that’s almost certainly a good thing.

What’s more, managers themselves are currently facing increasing pressures from the communication technologies that could otherwise support more effective collaboration.  Management disciplines are sufficient if the right information gets passed through the manager.  But communication technologies, resource mobility, and distributed workforces mean this simply doesn’t happen.  Managers are left in a situation where they don’t know what is going on but are still responsible for it.

I’m seen managers response to this challenge in precisely the wrong way.  For example, consider the phrase ‘I only need to make sure my direct reports know what they are doing’.  I’ve heard this before and it drives me crazy.  This is like saying ‘I’ll just manage myself, not the organisation’.

In addition to the above sort of reaction I also see a lot of cases where managers simply refuse to integrate communication & collaboration technologies into their management process.  In this case, there is potential for transparency and technology-enabled collaboration but the managers don’t want to use the tools.  If the tools are then used in this environment the whole management process can break down because sufficient information isn’t passing through the manager.

I can already hear ‘tools wont solve this’ echoing in my head as I type.  This is partially true but the management discipline itself is a tool.  All those catch-phases like ‘we need to work together’ and ‘I don’t want to get involved in the details’ are tools.  Similarly the phase ‘make sure you CC everybody in the team on every email’ is a tool.  But they aren’t tools that help the organisation!

Introducing Human Interaction Management

As I’ve been working through MWT Collaboration Architectures I’ve come across some work on Human Interaction Management (HIM).  I’m please to note that work in this area has a lot of similarity to the MWT Collaboration Architecture approach.  I’m sure it also has adoption challenges as per the discussion above.

If you’d like to read more about HIM try the following links:

‘The First Step for BPM is HIM’:

A ‘Human Interaction Management’ portal:

Google Docs isn’t the answer:

Work 2.0:

“Why Workflow Sucks”:

Presentations and podcasts for people who don’t read good:

The book: