This blog is about knowledge management, personal effectiveness, theory of constraints and other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

Improving collaboration for what

Welcome to September! I've been doing some more thinking about collaboration and the "what does it look like" theme from my post a couple weeks ago (and some useful feedback). In short, I worried that it isn't clear what good results organizations expect get from "better" collaboration.

For some people, the worry just isn't there. It's obvious: more and more work requires people to work together (rather than alone), therefore we need to what we can to support and encourage that working together so that the work can get done. This is collaboration, yes? But for others, this isn't enough meat - what specifically needs to improve about how we are working together? What will be the impact on sales, costs, project cycle time, quality, or other factors of interest?

One of the challenges in the above is that "collaboration" doesn't just happen in isolation, just like Sales can't happen without successful delivery of the product or service. Collaboration is part of the way work gets done, so the "improvement" should be framed in terms of the work - even better framed in terms of the work output.

So pick the area where collaboration improvements are going to help. Then think about how the current organizational structures contribute to (or hinder) the desired collaboration. Incentive and reward programs are a classic example of emphasizing individual contribution over group contributions. Another area to review is the level of work being pushed out to people: do they have the opportunity to stop and help a colleague when their boss is pushing for status reports on her pet projects? How do the current tools support / hinder the desire to improve collaboration? How does our use of these tools support / hinder collaboration?

I've used variations on these questions many times before. They are part of the "questions for technology" that Goldratt articulates in many places, but originally wrote in Necessary But Not Sufficient (my review). I find them a useful framework for thinking about these things.

Many others think along these lines. Here are a couple.

Greg Lowe had a piece in May on Improving Collaboration with a very similar topic. He talks about the jargon around "improving collaboration" and then provides some deeper thinking about what this might look like. Greg ties it to organization design and incentive systems - if people are incentivized to "go it alone" then that is what they will do.

And for a look at what people who just know that collaboration must improve are thinking, there is Rob Preston's Information Week piece, Social Collaboration: A Work in Progress. Improved collaboration is assumed, and the discussion is primarily about the technology. My frustrated read of this is that "if only the technology were right, our collaboration would be great." But I don't see what collaboration needs to "do" for the examples in his column. (Of course, IW is targeted to information technology professionals, so this isn't terribly surprising.)

[Photo: "Happy National Coffee Day" by Richard Masoner (coffee day is 29 September, but I doubt I'll remember to repost this photo I stumbled across, so it is here today - enjoy a cup!)]

3 Comment(s)

Here's one thing that would help collaboration a great deal: imagine a global team with members so located that they can never teleconference unless someone is up during sleep hours (what I call "Ouch meetings"). A tool that would allow them to conduct most of their discussions without meeting synchronously would be a huge help to them. We toyed with this idea back in my Intel days and envisioned a workflow application that would block time on each member's calendar (during their day hours) and prompt them to review team materials, tasks, and other members' latest comments promptly in turn, so the work would be kept moving briskly...

Maybe I need to put more examples in my posts than general statements. This is the kind of thing I was talking about, though. You have a global team and there is some need for them to be able to co-ordinate activities in better ways than those Ouch meetings. (I have found the far-flung outposts get pinched most often.)

But it is not just the tool that will enable this improved coordination, right? It's also the context in which people are running projects. Are the requirements of the activities clear from the beginning, or are many of the back-and-forth discussions revolving around "what are we trying to do" or "what is expected of us"? That should all be decided at the outset, rather than in the middle of projects. And if more than one time bucket goes by and the team are still stuck on the same point, where do you put the blame? The tool, the team, management, the nature of projects?