|
|||||
|
|
|||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I wrote earlier that I didn't have much time for learning and networking during this summer school. I was wrong. I didn't have enough time to do usual networking, so I missed some interesting people, but working together with others to organise this event allowed building deeper connections with some people instead of scratching the surface of "who does what". Learning was different as well. I didn't learn much of the program (which is not surprising as I was involved in organising something during 3 days out of 5), but I've learnt a lot about organising a learning event like this one. So, these are my lessons learnt. They are based on participants' feedback, organisers' debriefing and many one-to-one informal talks. Important conditions to take into account if you think about reusing them:
Team and process We worked as a distributed flexible team; most of the program committee members were volunteers and we didn't have any "formal" leader. Most of us met during last year KM Summer School without knowing we will organise this one. After forming the program committee somewhere in beginning of 2003 we didn't have any single face-to-face meeting with all of us, but few people met each other on other occasions. We had to rely on e-mail (somehow threaded discussion didn't work), bi-weekly phone conferences and occasional phone calls. No conference management system, no document-sharing repository, no centralisation… As some others I'm quite impressed with what we were able to achieve given these settings. But if someone asks me if I would do it this way again, I would say no. It takes too much energy to achieve results in such a distributed network with no formal commitments (as a volunteer you can always have valuable excuses), no process/communication facilitation and no shared understanding/experiences of organising a learning event like KM Summer School 2003. Too many uncertainties altogether. So I would work in a distributed network if there is a clear process and responsibilities or if there is shared understanding of how things work. The last one is probably most important: shared values, shared approaches, being on the "same wave" makes sure that you can work on achieving results and not on achieving shared understanding first. Then there are some practical sides: using conference management system (e.g. free one like ConfMan or ConfMaster), structuring and capturing communication (ideally forum/wiki + file exchange server), a bit more centralisation and face-to-face contact. Program, sessions, networking Presentations
Interactive sessions
Socialising and networking
More on: facilitation KMSS learning learning event
|
This weblog is my learning diary. Sometimes I write about things related to my work, but the views expressed here are personal and do not necessarily reflect the views of my employer.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||