Tag: cooperation

Where is the Cooperation in International Development and Cooperation

Warning: The following was written in haste, has repetition and can very much stand a good edit. But if I don’t hit post, this won’t go out. Life is busy.

Earlier today my friend and respected KM/KS practitioner Ian Thorpe Tweeted a link to a consultancy announcement.

kmtoolkittweet

I blithely responded:

Now, I was pretty tough on Ian and did not offer any context. Later this morning he posted a really thoughtful blog post on the thinking behind his organization’s desire to have their own internal Knowledge Exchange Toolbox. I started to post a comment, but the comment grew so large I decided a post here was called for.

I’m going to quote a sizable chunk of his post and then my response. But if this interests you, please go read the whole thing.

But, I think there are actually a few good reasons to reinvent or at least adapt.

People working in an organization tend to have more trust, and are thus more likely to use something that has been specifically created for them and has some form of official endorsement. This sounds like “not invented here syndrome” – but it’s not quite that.

The advantages of developing your own toolkit (or platform, strategy, bibliography, taxonomy etc.) include:

  • It can be written in the kind of language (and jargon and buzzwords) people in the organization understand
  • It can include tools selected to meet the specific needs of the organization, and the tools selected (even when sourced from elsewhere) can be adapted and tailored to the organizational context.
  • The tools can be tested on real organizational problems and the feedback obtained can be used to improve them and help communicate them better.
  • The tools can go through a quality review and sign off process that the organization understands and respects.
  • The fact that the toolbox is developed together with internal as well as external expertise means that staff know who they can follow-up with for advice and support on when and how to use them.

Overall these points mean that there is a sense of organizational ownership of the toolbox meaning not only is it officially sanctioned, but also officially supported and adapted to what the organization needs.

Thanks for adding really useful context, Ian. I find your reasoning totally logical. I have also heard it many times at other organizations.

First, can we connect usage to the factors you noted above in the context of ownership? Has anyone objectively looked at how usage of such a tool matters if it is internal or external?

I strongly suspect usage is driven by other, less visible, more informal things like seeing other peers use the tools, having colleagues they value endorse or role model, etc. I don’t have data. But in considering this,  I wonder about our assumptions about

  1. the use of these toolkits in general, and
  2. the importance of the points you make toward use (and improvements going forward).

Or are we just masking or missing the deeper, underlying issues? I really don’t know and I’d really LIKE to know.

I confess, I get totally frustrated when my own clients hire me to do things that are already done. The KS Toolkit came out of that frustration after three separate clients asked for the SAME thing and the differentiating factor was not whether the tool was on a private intranet or public, but branding. Yes, branding. Does that change the value of the toolkit? Should it?  Now, that said, over time the existing Toolkit product needs improvement. And your focus on adaptation is to me SUPER IMPORTANT. The issue of how to create and improve cooperatively sourced products alone deserves another blog post. (Note to self). But lets go back to rationale for internal vs. cooperative, shared resources.

I think a lot of the points you make are right on, but I also worry about some of the underlying causes that make these ideas of “needing internal validation,” “our language” and stuff so important in a field like international development and cooperation. From where I sit, I thought our field has shared goals.   So why do we have these counterproductive insider, invented here, not invented here, we are different from everyone else, etc attitudes? What do they represent? Control? Power? Fear? Territoriality? Reliance on the status quo?

Do we really understand if and why we need our unique products? Or is our vision too limited to see both the value and possibility for, and the mechanisms to cooperatively create, use, and improve resources?

Let me get more specific and look at each of Ian’s reasons for a customized product.

  • It can be written in the kind of language (and jargon and buzzwords) people in the organization understand. Having a sense of identity and ownership is important. But reinforcing organizational buzzwords and jargon does not help wider cooperation in the development field, no? Why might we want to reinforce this behavior? Think of the “beneficiaries” as well. Doesn’t our insider language and jargon distance us from them? 
  • It can include tools selected to meet the specific needs of the organization, and the tools selected (even when sourced from elsewhere) can be adapted and tailored to the organizational context. This is a compelling argument for internal platforms. Curation, adaptation and tailoring are really useful “value added” to a toolkit. But why not do that adaptation in a public, cooperative platform where others can learn from what you do, particularly those closest to your organizational domains. Why not do it WITH those others? Hm, as I write this, I wonder about shifting from “organizational” context to “practice” or “domain” context. So if tool X is more useful in working with Y population, lets make sure all of us working with Y population have access to that tool adaptation and can contribute towards its ongoing improvement?
  • The tools can be tested on real organizational problems and the feedback obtained can be used to improve them and help communicate them better. I can’t figure out the value of this being internal to an organization. Again, it relates to the practice, no? The global public good here is pretty darn high…
  • The tools can go through a quality review and sign off process that the organization understands and respects. Why can’t this happen in a cooperative platform? Heck, it might even contribute to better interorganization practices as a whole? And who is the arbiter of quality at the tool level when we rarely seem to care or pay attention at the application level where the IMPACT happens, right?
  • The fact that the toolbox is developed together with internal as well as external expertise means that staff know who they can follow-up with for advice and support on when and how to use them.  Again, I can imagine this same value on a public/cooperative platform.

Adaptation is an important thing we ignore very often in KM. There is too much sense that replication and scaling are the solution. So I deeply respect this aspect of adaptation that I sense in Ian’s response.

My “yes, and” perspective  is that what you learn/do through adaptation is of value beyond your org. And insights come from beyond your org. And your org exists for public good, right? Why not build more nuanced structures that facilitate open, public, crowdsourced resources, ones that add that layers of adaptation – for example there are other orgs sharing UNICEF’s targets and goals who might also benefit from this need to improve tools.

I fully know that what I’m suggesting is not easy. We have learned through the KSToolkit.org that people DO have different needs, need the material organized or expressed differently. But those reasons don’t appear to be organizational. They appear to be driven by the users context and practice. And that these contexts and practices vary WITHIN organizations, and are often shared ACROSS organizations. And cooperatively creating and supporting a shared resource doesn’t fit into most organizational process or budgeting parameters, so when we see things like the KSToolkit.org we are seeing the work of committed individuals who make things happen, often in spite of their organizations. (And deep bow to all of you, including Ian who has been a toolkit supporter.)

I think there is a much larger, more valuable proposition of opening up some of this work across organizations and getting off the  focus on our organizations. Lets focus on our goals and the ultimate reason we are doing this. So every human being has the right to and access to food, clean water, housing, education and human dignity.

So what are the barriers? What is it we are really avoiding by sharing this “knowledge infrastructure?” Is it convenience? When we work for global public good, what is the cost of this “convenience?” What is keeping us from shifting towards more cooperative and networked structures which can tap a potentially broader and more diverse set of expertise, share the burden of refinement, adaptation, improvement and just simply reduce this recreation? We all need and benefit from the process of adapting and improving tools.  Many of the tools in a Knowledge Exchange toolkit will have relevance to wider audiences. At the same time, so much of what is in these toolkits is not rocket science. What IS rocket sciences is the organizational shifts and changes that actually enable people to USE this stuff. Toolkits are just a resource. And this opens another Pandora’s box for another blog post!

I’ll say it. Lets start breaking down more walls instead of using what is convenient and conventional to maintain the status quo. And a little starting point like KM and KS toolkits seems like an ideal laboratory to find new, cooperative, networked ways to maximize value and minimize waste. Let’s recreate and improve together. Otherwise we are supporting wheel reinvention.

And Ian, thanks for lighting me up to write about this today. You have helped me clarify my thinking. The next two things we need to consider is what it takes to cooperatively create global public goods (and a lot of good people have been doing some great work in other domains from which we can learn), and how to move the tools from toolboxes into practice!

via Why we sometimes need to reinvent the wheel | KM on a dollar a day.

Building a collaborative workplace (or community… or network)

rgg_20080315_134928
Creative Commons License photo credit: rgordon

A while back my friend and colleague Shawn Callahan asked me to pitch in with him and fellow Anecdote-ite Mark Schenk to write a paper on collaboration. It is out today on the Anecdote site –> Anecdote – Whitepapers – Building a collaborative workplace. From the introduction:

Today we all need to be collaboration superstars. The trouble is, collaboration is a skill and set of practices we are rarely taught. It’s something we learn on the job in a hit-or-miss fashion. Some people are naturals at it, but most of us are clueless.

Our challenge doesn’t stop there. An organisation’s ability to support collaboration is highly dependent on its own organisational culture. Some cultures foster collaboration while others stop it dead in its tracks.

To make matters worse, technology providers have convinced many organisations that they only need to purchase collaboration software to foster collaboration. There are many large organisations that have bought enterprise licences for products like IBM’s Collaboration Suite or Microsoft’s Solutions for Collaboration who are not getting good value for money, simply because people don’t know how to collaborate effectively or because their culture works against collaboration.

Of course technology plays an important role in effective collaboration. We are not anti-technology. Rather we want to help redress the balance and shift the emphasis from merely thinking about collaboration technology to thinking about collaboration skills, practices, technology and supporting culture. Technology makes things possible; people collaborating makes it happen.

This paper has three parts. We start by briefly exploring what we mean by collaboration and why organisations and individuals should build their collaboration capability. Then, based on that understanding, we lay out a series of steps for developing a collaboration capability. We finish the paper with a simple test of your current collaboration capability.

I think the issue is beyond building a collaborative workplace. It applies to our communities and networks. But heck, starting with organizations is always worth a try, eh? 😉

While we were co-writing (using a Google doc) I started reading more about the differences between collaboration and cooperation – which we don’t address in the paper, but which are important. So I’ve noted that for future writing. If you are interested in Cooperation, don’t miss Howard Rheingold’s work on this.