wenamix

We started wisdomclouds some years ago to improve the working life of the so-called “knowledge-worker” by making the sharing of knowledge as easy as possible. 

So, what have we learned so far ?

During the last years running wisdomclouds.com, we found out that:

Once written down, the majority of knowledge is small, not big. It's rather 220 characters than 4000. So think more like Twitter or Facebook rather than Wiki

Knowledge-sharing networks don't follow the pattern of org-charts, but they grow organic and disrupt existing silos

The best form for sharing knowlege is plain text combined with Markdown. Avoid containers such as Word, PowerPoint, etc. To allow for some easy-to-use formatting such as bold, underline and displaying links Markdown is the best choice. It allows for easy sharing across media-corders such as email.

Das größte Problem beim Wissenstransfer ist das Vergessensproblem. Bevor ich in der Lage bin, das, was ich gerade gelernt habe, aufzuschreiben, habe ich es auch schon wieder vergessen.  That’s life, würde man denken. Aber warum ist dem eigentlich so ?

Der größte Knackpunkt: Die Hürden für das Aufschreiben sind einfach zu hoch. Eine neue Wiki-Seite erstellen -- uhh, wie lege ich die nochmal an und wo sortiere ich sie ein ? Was soll ich alles schreiben, die neue Seite sieht erstmal sooo leer aus ! 

Besser: do it the agile way ... einfach und simpel.

Dazu folgender Vorschlag: an einer Pinnwand werden mittels Post-It's kleine Wissenseinheiten angebracht. Nennen wir sie der Einfachheit halber mal “Know-Its”.

Wann werden die Know-Its an der Pinnwand angebracht ? Sofort, nämlich immer dann, wenn ich etwas neues gelernt habe und ich bereit bin, es mit dem Rest meiner Projektwelt zu teilen.

Wie oft werden die Know-Its an der Pinnwand angebracht ? Täglich, Stündlich, wöchentlich, wie auch immer. Je nach Bedarf eben. Aus unsere Erfahrung heraus braucht es anfangs etwas Überwindung, also: Zeit lassen. Einer sollte aber tapfer den Anfang machen und dieser jenige bekommt dann den Titel “Knowledge-Master”.

In welcher Form werden die Know-Its an der Pinnwand angebracht ? Egal, zunächst einmal geht es darum, das Gelernte nicht zu vergessen. Das spätere schönerschreiben, ergänzen, ausbessern, usw. ist kein Problem und Teil der Idee.

Was passiert wenn die Know-Its an der Wand hängen ? Wenn etwas neues an der Wand hängt, dann lasst uns darüber reden. Face-to-Face-Kommunikation im Team ist wichtiger als jeder andere Form der Dokumentation (... siehe Agile Manifesto ...) Dazu bietet sich das Daily-Standup an ... warum nicht einfach die letzten 5 Minuten darüber sprechen, was man neues seit gestern gelernt hat ?

Bleiben die Know-Its dann für immer und ewig hängen ? Nein. Wissen veraltet, Wissen verändert sich, Wissen muss angepasst und gepflegt werden. Also: Anpassen, abhängen, umhängen, neu schreiben, ergänzen ... was auch immer notwendig ist, um das Knowledge-Log zu pflegen.

Wie teile ich die Know-Its mit Remote-Kollegen ? Übernehmt die Know-Its in einen persistenten Wasserspeicher, auf den alle Projektmitglieder Zugriff haben. Letzteres kann ein Sharepoint oder ein Wiki sein. 

Oder nutzt wisdomclouds.com ... hier wird die Idee der kleinen, sehr einfach zu erfassenden Know-Its ohne weiteren Schnickschnack umgesetzt. Einfach mal ausprobieren.

Und diesmal ist auch wirklich der Weg das Ziel: Learning-Logs für agile Softwareentwicklungsteams

Oder:  Wozu noch man Prototypen noch nutzen kann

Letzte Woche meldete sich eine Freundin bei uns. Sie und ihr Team haben von einem Kunden den Auftrag bekommen, einen Prototyp zu programmieren. So weit so gut, möge man denken, das Ziel des Prototyps wäre Technologien gegeneinander abzuwägen, Usability-Patterns zu testen oder eine Architektur zu evaluieren. Weit gefehlt. Bei diesem Projekt ist nicht der Code oder das Ergebnis das Ziel.

Die Erfahrungen, die auf dem Weg zum Prototyp liegen, sind das Ziel.

Nicht der Prototyp selbst, nicht die Software wird gewünscht, sondern die Erfahrungen, Lessons-Learned und Best-Practices, die auf dem Weg zu diesem Prototyp gesammelt wurden. Der Kunde wünscht sich am Ende des Projektes einen Erfahrungsschatz. 

Wie setzt man dieses Projektziel um ? Zunächst einmal stellt man sich die Frage, was den nun konkret gewünscht ist und erarbeitet werden soll. 

Was ist ein Erfahrungsschatz und wie wird ein solcher am Ende eines Projektes übergeben ?

Spannend verpackt in einer Kiste mit goldenen Beschlägen, vergraben unter tausend Jahren alten Bäumen und markiert  auf einer Karte, der man Schritt für Schritt folgen kann ?

So ähnlich. Wie in jedem guten Projekt hat der Auftraggeber die Erwartungshaltung und den Anspruch auf ein ordentliches Ergebnis: in diesem Fall eine saubere und gut strukturierte Dokumentation der Inhalte und Ergebnisse. Was aber sind die Inhalte und Ergebnisse ? 

Wie sich zeigt, kann die Vorgehensweise des Continous-Knowledge-Exchange (siehe unseren Artikel "Brainsharing" in der iX, Mai 2011) weiterhelfen:

Schritt 1: Definiere das Ziel.

Ok, es soll ein Prototyp gebaut werden. Aber für was ? Um Erfahrungen zu sammeln und diese zu dokumentieren. So weit so gut, aber tatsächlich sind wir noch sehr schwammig unterwegs. Meist legen die Projektmitglieder halbblind vor Begeisterung für neue Technologien und der Aussicht auf eine prototypische Spielwiese ohne große Reflektion sofort los. Weil man ja weiß, wie es geht und es dem Kunden nur noch vorführen muss, wie in einer Theateraufführung.

Einen Schritt zurück. Wir müssen sicherstellen, das wir den Kunden nicht in das falsche Theaterstück setzen: Das Ziel muss klar definiert sein. Hierzu ist es notwendig, sich mit dem Kunden vorab über das gewünschte Ergebnis auszutauschen. In den meisten Fällen kennt der Kunde das Ergebnis auch nicht, deshalb sind erste Vorschläge gefragt. Eventuell ist ein Workshop zur Zieldefinition notwendig (i.d.R. sind 2 Stunden ausreichend, sehr viel weniger sollten es aber auch nicht sein).

Dabei müssen mindestens folgende Fragen geklärt werden:

- Wie sollen die gesammelten Erfahrungen dargestellt werden ?

- In welcher Form liefern wir das Projektergebnis (Word, Wiki, PlainText, PowerPoint, ...)

- Gibt es Bereiche, die besonders wichtig sind und fokussiert betrachtet werden sollte (Backend vs. Frontend, evtl. bestimmte Technologien oder Entwicklungsmethodiken wie agile Vorgehensweise) ?

- In welcher Form sollen sie strukturiert werden (falls eine erste grobe Strukturierung bereits gewünscht ist) ?

- Wer sind die Wissensträger, die beteiligt werden müssen ?

- Welche Erfahrungen wurden bereits in der Vergangenheit gemacht und sind diese relevant ?

- Welche Projektmitglieder müssen sollen eingebunden werden (nicht zu viele, evtl. reicht es aus einige lediglich initial zu konsultieren und um ihre Meinung zu bitten)

und ... die Mutter aller Fragen bei der Zieldefinition:

- Welche Entscheidungen will der Kunde auf Basis des gewonnenen Erfahrungsschatzes in Zukunft treffen können ?

Die Antwort auf diese Frage schließt Sätze des Kunden die mit "jetzt weiß ich aber immer noch nicht ... " beginnen aus und deshalb muss sie vor dem Start des Projektes glasklar definiert werden. Am besten: niederschreiben und an die Wand hängen.

Schritt 2: Iteratives Einsammeln des Erfahrungsschatzes

Jetzt erst beginnt der Entwurf und die Entwicklung des Prototyps und damit das Einsammeln des Erfahrungsschatzes.

Ein Erfahrungsschatz ist eine Sammlung von Erfahrungen, Lessons-Learned und Best-Practices.

Dieser Erfahrungsschatz wird während der Entwicklungsphase in der zeitlichen Reihenfolge des Auftretens niedergeschrieben.

Wichtig ist es, gelerntes so schnell als möglich zu erfassen, bevor das Wissen verloren geht. Vor allem in einem Umfeld, in dem neue Technologien zum ersten Mal erprobt werden, ist die Menge an neuen Erfahrung sehr groß und die Gefahr des Verlorengehens ebenso. Deshalb: 

Alles sofort aufschreiben ("Capture knowledge before it gets lost").

Dabei ist es unerheblich, dass das Wissen noch nicht in einer "reinen" und finalen Version vorliegt. Sammeln ist wichtiger als aufbereiten (das kommt später). Sammeln ist wichtiger als strukturieren (auch das kommt später). Zunächst muss sichergestellt werden, dass nichts verloren geht.

Kontinuierlicher Austausch zwischen Projektmitgliedern und iterative Verfeinerungen

Bereits während der Iteration des Sammelns tauschen sich die Mitglieder des Projektes regelmäßig ihre Erfahrungen aus. Auf Basis der erfassten und noch "rohen" Wissenseinheiten wird das gesammelte Wissen verdichtet, doppelte Einheiten werden aussortiert, Unklarheiten geklärt. Dieser Austausch dient auch dazu, die Priorität einer Wissenseinheit festzulegen. Ist das eben gelernte wirklich wichtig für den Kunden und sein gewünschtes Ziel ? Was einem selbst wichtig erscheint, ist im Licht des Kundenwunsches plötzlich nichtig und klein. Für die Erreichung dieser Sichtweise ist die Reflektion der Projektmitglieder gefragt und notwendig. Es geht nicht ohne.

In diesen Austauschen entstehen auch erste Ideen für eine Kategorisierung. Vorschläge für die Kategorien werden an Wissenseinheiten angeheftet. Diese Kategorisierung muss nicht final sein und wird sich weiterentwickeln (wir arbeiten iterativ !).

Wichtig ist, dass der tägliche Austausch über das vorher Gelernte täglich stattfindet.

Der Austausch kann kurz sein und sollte ähnlich einem Standup bei Scrum verlaufen (i.d.R aber länger, bis zu einer Stunde sind einzuplanen). Wichtig ist, dass direkt im Anschluss die bisher erfassten Wissenseinheiten bereinigt, angereichert, korrigiert, ergänzt oder kategorisiert werden. Nur dann sind die Eindrücke aus den Austauschen noch frisch vorhanden sind. Jedes Projektmitglied korrigiert seine eigenen Wissenseinheiten.

Schritt 2.2 findet solange im Wechsel mit Schritt 2.1 statt, bis das mit dem Kunden vereinbarte Ziel erreicht ist. Dies ist nicht notwendigerweise die Fertigstellung des Prototypen maßgeblich, evtl. kann das Ziel dies bereits vorher erreicht sein.

Schritt 3: Dokumentation der Ergebnisse

Meine Damen und Herren, wir verlassen nun unsere iterativen Loopings und setzen zum Landeanflug an.

In diesem Schritt wird aus den gesammelten Wissenseinheiten und Lessons-Learned ein "Enddokument" erstellt. 

Im Unterschied zu den Phasen vorher wird dieses durch einige wenige (i.d.R. nicht mehr als zwei) Personen verfasst. 

Es ist Pflicht, dass diese Personen auch bei der Sammlung des Wissens aktiv dabei waren, da sonst die Reibungsverluste zu groß sind.

Die Dokumentation soll den Wünschen, Ansprüchen und formalen Aspekten (Templates, Logos) des Kunden entsprechen.

Diese Phase stellt das reine "Zusammenschreiben" dar, eine Anreicherung des Wissens ist hier nicht mehr vorgesehen, da dies in Phase 2 geschehen ist. Die in den Schritten vorher angelegte Kategorisierung kann als Maßgabe für die Kapitel des Dokumentes dienen. 

Learning-Logs als fester Bestandteil des Entwickleralltags

Learning-Logs können nicht nur bei der Entwicklung von Prototypen erstellt werden, sie können in den Alltag eines Entwicklungsteams integriert werden. Jeder Entwickler sucht und findet Lösungen zu Problemen, behebt Fehler und lernt neue Technologien, Tools oder Vorgehensweisen kennen.

Learning-Logs sollten fester Bestandteil eines jeden Entwicklungsteams werden.

Stefan Wendel we:namix GmbH

http://bit.ly/MSKqfr

Alles muss schlanker werden. Produktionsprozesse, Softwareentwicklung, wir alle.

"Lean" ist in aller Munde, seit einiger Zeit. Zurecht.

Bei einer Diskussion in der kürzeren Vergangenheit kam die Frage zwischen dem Zusammenhang von "kontinuierlichem Wissenstransfer" und "Lean Management" zur Sprache.

Hier meine Antwort darauf: 

Kontinuierlicher Wissenstransfer (siehe auch: www.wisdomclouds.com/artikel) bedient sich ganz gezielt bei Agilen Entwicklungsmethoden. Diese wiederum bauen auf den Grundprinzipien des Lean-Managements auf. Hier schliesst sich schonmal ein Kreis.

Konkret muss folgende Anforderung an ein "Lean Knowledge Management" erfüllt werden:

Lean Knowledge-Management muss einen einen kontinuierlichen Wissensflusses unterstützen.

"Täglicher Wissenstransfer" statt "sporadische Wissensablage" ist das Motto. Diese Anforderung ergibt sich aus dem Lean-Prinzip "Flow of material and information should be continuous".

Wie kann das umgesetzt werden ?

Mit folgenden Regeln:

1) Schnelle Erfassung.  Als Ziel sollte eine Erfassung in einer oder weniger möglich sein. Barrieren wie aufwändige Anmeldungen oder Erfassungsmasken müssen abgeschafft werden.

2) Kurze und "kleine" Wissensobjekte erfassen. Aus unserer Erfahrung sind Wissensobjekte (z.B. Lessons-Learned, Links, Fakten, Hinweise auf abgelegte Dokumente) im Durchschnitt 221 Zeichen gross. Zum Vergleich: Einträge in der Wikipedia sind durchschnittlich ca. 3000 Zeichen groß und damit ca. 12 mal so umfangreich mit entsprechenden Auswirkungen auf Erfassungsdauer, Qualitätssicherung, usw.

3) Die Verteilung muss in einem vorher definierten und bekannten Netz von Experten stattfinden. Auf diese Art muss der Verfasser nicht jedesmal nachdenken an wen man etwas versendet, sondern die bereits existierenden sozialen Expertennetze werden ständig mit neuem Wissen bedient.

4) "Aus dem Weg gehen": das Tool darf nicht im Mittelpunkt stehen, sondern muss sich in die 

Arbeitswelt des Users einfügen (Bsp.: Hinweise auf neue Wissensobjekte per Mail-Notification oder per RSS-Feed direkt in Eclipse)

5) Qualitätssicherung: Ein "Knowledge-Master" (analog einem "Scrum-Master") bzw. seine Helfer

("Knowledge-Editoren") wachen über die Qualität der Einträge und veranlassen eine Korrektur

falls notwendig. Einige Wenige müssen den Hut aufhaben und andere anleiten (im Gegensatz

zum Wiki-Prinzip). Nur so kann die Qualität von Anfang an gewährleistet werden.

In dieser wisdomcloud sind Bücherempfehlungen und Links zum Thema "Lean Development" zusammengestellt.

Viel Spass beim Stöbern,

Spannende Veranstaltung: kommende Woche werde ich die wunderschöne Hafenstadt Kiel besuchen und auf Einladung der Gesellschaft für Projektmanagement und der Gesellschaft für Informatik / Regionalgruppe Kiel einen Vortrag über das Thema "Kontinuierlicher Wissenstransfer" halten.

  Spannend auch deshalb, da nicht nur Vetreter aus dem Projektmanagement-"Alltag" dabei sein werden, sondern auch namhafte Vertreter aus dem universitären Bereich mit Schwerpunkten im "Knowledge-Management".

Lessons-Learned, Hintergrundinfos und Updates zu diesem Vortrag werde ich in einer wisdomcloud zusammenfassen. Hier schonmal der Link zu dieser wisdomcloud:

http://www.wisdomclouds.com/Brainsharing/40/home

Hier der Link zu den Details der Veranstaltung:

Termin: 26.05.2011

Ort: Restaurant & Café Seeburg, Düsternbrooker Weg 2, 24105 Kiel

Uhrzeit: 18:00 - 20:00

Nicht ganz ohne Stolz hier die Vorankündigung auf die morgen erscheinenden aktuelle Ausgabe der iX (Ausgabe Mai 2011).

Unter dem Titel "Brainsharing" wird der Prozess des kontinuierlichen Wissenstransfers dargestellt. Vielen Dank an die Redakteure und Mitarbeiter des Heise-Verlages für die Erstellung der gelungenden Grafiken und letztendlich für die Idee des "Brainsharing"-Titels.

Eine Online-Version kann unter

http://www.wisdomclouds.com/artikel

eingesehen werden. Wir bitten um Verständnis, dass dieser Artikel aus Copyright-Gründen nicht heruntergeladen, sondern lediglich ausgedruckt werden kann.

Kritik, Fragen, Anregungen, Meinungen zu diesem Thema ? Wir stehen gerne für eine Diskussion zur Verfügung:

stefan [a t] wisdomclouds.com

Viel Spass beim Lesen!

A happy new year, everybody!

Just before starting the final countdown and move over to a hopefully exciting new year, let me briefly reflect on what was, in my opinion, a major milestone in the age of the internet. Here are my 12 lessons I drew from 2010:

Lesson 2010/01: The web is finally how it should have been from the beginning. The Web is changing. Changing from the document-centric model (where web-pages are linked) to a people-centric model (where people are linked).  Tim Berners-Lee invented the web as a knowledge-management-system allowing to share and link documents within the CERN back in the early 1990‘s.

In 2010 documents are still relevant, but people and the links/relations between them become more and more central. It‘s called the social graph. Maybe this is how we always wanted to use the web. This is how we already used the web during all those years via forums, chats or emails.

And by the way: this is how Berners-Lee imagined it back in 1989. In his paper "Information Retrieval: A proposal" which is widely recognized as the "requirement-specification" of what later became the World-Wide-Web, Berners-Lee describes a system where "nodes" are linked. And guess what ? Nodes can be quite a lot of things, such as documents (a.k.a. web-pages), people (!), projects or "software-modules" and many more. So, to be correct: 2010 is the year where we enter Phase 2 of Berner-Lee's original concept: After many years of linking documents ("Phase 1"), now the net starts linking people. A profound and fundamental change which, in my eyes, legitimates an otherwise blurry term such as "Web 2.0".

Lesson 2010/02: All but 3 people are on Facebook. Facebook hits 600 million users. That's 8% of the earth‘s population and 25% of all internet users. I only know 3 people who are not on Facebook.

Lesson 2010-3: Thank god, the net is still growing. Internet Usage has grown by 444% compared to 2000. The big wheel of fortune for all of us is still turning, fueling innovations, developers, entrepreneurs, job-agencies, designers, pizza-bakeries and last but not least the internet itself.

Firing its own growth, I got the feeling that the current net is a perfectly running perpetuum mobile. With every new page created and every new connection between people installed, new "content" is created. New content attracts more and new people. More and new people create pages and connect to each other ... pushing the perpetuum mobile ... pushing the perpetuum mobile ... How long is it going to last ... ?

Lesson 2010-4: Sunset on bare-metal == Sunrise with shiny new clouds In April, Oracle aquires Sun. For me, Sun‘s decline is one of the big signs of the successful and unstoppable rise of Cloud-based Services. The first wave of internet (ca. 2000) was fueled by free available open-source software (Tomcat, Mysql, etc.). Infrastructure and services weren‘t free. You had to build your own services and set up exensive hardware you bought from Sun et al. Now, there are infrastructure and application services available for almost no price and no setup costs.

Rent services, don't buy bare metal. Pay on demand instead of massively upfront. Integrate existing services within hours in your applications, don't build by yourself. Those are the new mottos and they make so much sense.

That's the way to build scalable software the 2010-way.

Lesson 2010-5: eBooks sell like crazy. In July, Amazon lets the world know that it sells more eBooks than printed books. For first time an author (Stieg Larsson) sells more than 1 million eBooks.

Lesson 2010-6: Gestures are the most-easy-to-use usability pattern. The iPad is released in April. Computing now becomes easy enough even for 4-year-olds. The usability-pattern of computers slowly changes from mouse to gestures.

Lesson 2010-7: There's a service for everything. In 2010, Cloud-based Software-as-a-Service offerings are available for everything in life and business. Those services are free or available at an very reasonable price. Email, spreadsheets, word-processing, server-monitoring, music streaming, information databases, infrastructure-services such as email or payment.

In July, 1000memories.com, an investor-backed online-memorial-service went live and probably filled the last available niche. While back in 2000, every possible piece of information could be found on the net, in 2010 every possible service can be rented or used for free over the net.

Lesson 2010-8: TV-Future will be bright. HD television gets mainstream, 3D TV hits the market around the time of the World Championship and is mainstream in cinema since Avatar beginning of the year. It is obvious that 3D-gaming will be big in the next years.

Lesson 2010-9: Social-Media even sells good smells. Social-Media, often mixed with Web 2.0, has gone mainstream and has a significant relevance for marketing. Even established brands benefit massivly from Social Media, as a hillarious Marketing-campaign for OldSpice Body Wash proves.

Lesson 2010-10: Video killed the Blockbuster-star In September, Blockbuster files bancruptcy. That is the most obvious sign that movie streaming via the Internet has gone mainstream with providers such as Netflix, iTunes and T-Home. While 2000 was the year where digital music killed the CD, 2010 is the year where online-streaming whipes out "classic" video-distribution channels, meaning the good old video-stores around the corner.

Lesson 2010-11: "The Art of War" has to be rewritten The internet now officially fights side-by-side of soldiers. In September, the first (publicly known) cyberattack on a nuclear reactor is conducted using an arcane virus called "Stuxnet".

Lesson 2010-12: There's never gonna be "the one" killer-application Remember the key question back in 2000 ? What is going to be the one killer-application for high-speed mobile data access ... ? In 2010 more than 300.000 killer-applications for smartphones are found and new species are dragged to light with each new day. Definitly, mobile apps are here to stay. Another thread to the way we know the internet as it is today ? 2011 and beyond will tell.

All the best wishes for you and your family and to a great, successful and healthy 2011.

Hey everybody,

we are very glad and happy to announce that we will present the concept of "Continuous Knowledge Exchange" at the 1. European Software Solutions Conference (Sosocon) in Hannover, Germany. Date: 30.11. - 01.12.

Continuous Knowledge Exchange is filed under Communication / Future Technologies (please see link below).

http://www.sosocon.de/sosocon/programm/1konferenztag-3011/kommunikation/future-technologies/detail/artikel/continuous-knowledge-exchange.html

Can't think of any better classification.

Please check out the rest of the program, some real high-profile speakers and interesting subjects will be waiting.

Really looking forward to discuss our approach with a great audience.

Cheers,

When working together with clients on effective knowlege-sharing in IT-projects one lesson got obvious in the very beginning:

Knowledge-units are small. Not big.

Re-checking this assumption in wisdomclouds.com turned out to be affirmative: The average size of a knowledge-unit submitted in wisdomclouds.com is 221 characters. 

That's right: 221 characters. That's not even 2 text-messages from a mobile.

And here lies one of the downsides of Wikis and Sharepoints: they are not tailored to handle this. They are tailored to create and handle documents or web-pages.

And because those knowledge-units are small, they are very easy and very fast to be submitted. Which is great for your team, because capturing and submission of knowledge doesn't take long.

Now image: your team consists of 10 people. Let's assume each of the team-members submits just 1 lesson per day.

That's 10 lessons a day. 50 per week. 200 per month. 600 per quarter. 2400 per year.

How and where would you store those knowledge-units in a Wiki or Sharepoint ? One site per entry ? Several entries on one page ?

Wiki's and Sharepoint's (and countless other document-management-systems) are made for storing documents. Documents are aggregations of smaller knowledge-pakets. Like "Point-of-View"- or "Process-description"-documents, which are, in fact, a summary of many small and distinct knowledge-units.

Summary:

 Knowledge-units are small. And in any team, in daily-business, small knowledge-units are relevant for a team to be shared. Documents come later.

Advice: What to do ? 

1) Accept this fact. Inform and teach your team that knowledge-sharing is not about writing huge, lengthy and shiny Power-Point-presentations. It's about writing down as soon as possible what people learned, no matter how incomplete or informal the first version might be. Your team-members will get used to it.

2) Offer your team a  way to store those knowlege-pakets efficiently. Email or shared Excel will do in the beginning.

3) Repeat and train the process of submission of small units: in the beginning team-members are shy to submit, because of the "informal" character of those small-units. Lead by example and find one or two supporters in your team. Over time, team-members will get used in submitting small units.

Tackled with the problem of submitting, storing and sharing of lessons-learned in IT-projects over and over again in the last years one problem became apparent to me:

Knowledge management systems are just a synonym for document management systems. While those document management systems are indeed sometimes needed one huge issue remains unsolved: there is no support for networks of experts that are sharing their informations or knowledge.

There is no such thing as a "Facebook of Knowledge-Management".

That is a huge misfit to reality, because when you look closely into any organization you‘ll find those networks everywhere: they exist in small, midsize, large and sometimes even huge quantities. One can only guess that in any huge software-develeping-company with several thousands or even hundreds of thousands of employees those knowledge-sharing-networks also exists in their thousands. But: they are unsupported by any tool. Left alone in their misery if to use either Word or Excel to write down stuff they learned and where to put it or send it to.

Those existing networks are personal knowledge-networks. People exchanging relevant wisdom and information because they know each other. They‘ve met in person, most likely working on projects together. They respect themselves, the know what the other knows and to what extent he or she can be trusted.

So, how do they share information if they need to ? They write an email. They pick up the phone and call somebody they know. Maybe, if they are in the same office or location they meet over lunch. Or they just go over to the next desk. 

The problem with that: how many people are left outside ? How many people exist in such a large company that also have something to say ? How big is the existing, but deeply hidden knowledge about a topic such as „J2EE-software development“ or „implementing with SAP-HR“ in a software-development company ? Is it really the 5-10 people you personally know ... ? Where are the others ... ?

And the next, immediate following question: even if those experts would meet, how do they not only exchange their knowledge efficiently, but also store the information, so that it‘s easily findable ?

In my opinion,  knowlege-management is mainly about communication. It‘s sharing of information between relevant experts. Storing documents in a Wiki or Sharepoint makes sense, but it is not the essence of knowledge-management. 

Marc Benioff, founder and CEO of salesforce.com raised the point that all business-software should be like Facebook (see: "The Facebook Imperative" http://techcrunch.com/2010/02/24/the-facebook-imperative/ ). I agree and I think it's valid for knowledge-management as well.

Cheers,

Stefan.

stefan.wendel (a t ) wisdomclouds . com

When talking to people about the basic concept of wisdomclouds everybody gets the idea of "submitting" his or her personal lessons-learned immediately.

But: when it comes to point of writing down a lesson-learned, people start scratching their heads, asking "what exactly is a lesson-learned" and, subsequently, "how shall we write it down?"

Let's give them a hand. Definition first:

"A Lesson-Learned is knowledge gained through experience, which if shared, would benefit the work of others." (from: U.S. Army's Center for Army Lessons Learned, yes something like this does indeed exist).

In other (my) words: some experience you made, either good or bad which "enhanced" your knowledge. Made you wiser than before. And: from which others can benefit from. Those are things you have to reflect on, to think about, something that matures over time in your head.

Another kind of lessons-learned are the fact-based ones: the small things you read in the paper, watch on TV, listen to on the news, hear from somebody telling you. Something like: "hey, did you know, there are far more than 100 million people living in Nigeria" (if was so surprised when a collegue of my former company who actually is from Nigeria told me this). If that's relevant to you and you want to remember it: submit it to wisdomclouds. If not, let your brain wipe it out.

You can share both types of lessons. While the first one are more like an "advice" to others, the fact-based ones are real know-how that other might benefit from immediately.

Basically I am working with those two types of lessons-learned and trying to remember both of them.

Cheers,

Stefan.

Techcrunch announcing the "Age of Facebook", I think one thing's still missing for that

Back in early summer 2010 Techcrunch announced  "The Age of Facebook", with the conclusion that "all the momentum is behind Facebook and how they are changing the Web and our culture".

I fully agree to the arguments that lead to this conclusion. But still, I think there is one thing missing for a new age of Facebook. The arguments were:

1) the massive user base of 400 million registered users and

2 ) its new "core feature", the so-called "Open Graph".

Those two combined indeed will change the game. Let's take a quick look at the new feature, the "Open Graph". The Open-Graph is not really a new concept. It was always there, being the "skeleton" that backs Facebook's community from day one. It just didn't have a name yet. And, more importantly, it just wasn't open yet.

The new and revolutionary idea that Mark Zuckerberg released during Facebook's developer conference F8 is simple, but powerful: Like fishermen, they threw out the graph like a net over the web. Like this everyone gets interconnected, even on pages independant and outside of Facebook. The graph is leaving its home base and starts spreading all over the net. It's no longer Facebook's skeleton but it could become the Web's backbone.

"Social will be default", as Zuckerberg called it and he will be right. The start of a revolution. Really no doubt about this. But is that really enough for a New Age ? No. Not yet.

Because: I am pretty sure one step is still missing. LinkedIn, Plaxo, Xing and all of the "other networks" will remain relatively relaxed. Why ? Because we are just talking of ONE graph which is opening. The Facebook graph. In my case, the graph of my friends. Not the graph of my colleagues. Not the graph of my professional contacts. Not the graph of my clients. Just the Facebook graph. Nothing more and nothing less.

Of course, still, it's massive, 400 million IS a lot. It's enough for the start of a revolution. But it is not enough for a new age?

What has to be done for Facebook to fully reach the "Age of Facebook"? It has to be like life!

Facebook has to offer more than one graph. It must start offering multiple graphs. As many graphs any user wants and needs to have. Like the ones I mentioned above. I want one platform and one platform only where I can be, where my identity checks in and resides. My home.

But: from time to time I want to leave the house and spent time in the graphs of my current, after-leaving-the-house life context. The context of my work, my spare-time, my kids. I want multiple graphs, not just one. And I want them to be seperated from each other.

Das Problem: Wissensaustausch in Organisationen ist mangelhaft. 

Lassen Sie es uns besser machen!

Obwohl es in der vergangenen Jahren in nahezu allen Organisationen Bemühungen gab, das „kollektive Wissen“ der Mitarbeiter zu strukturieren und zu erfassen, ist der Prozess des Wissensaustausches bis zum heutigen Tag ineffizient. Der Großteil des Wissen ist entweder in den Köpfen der Mitarbeiter oder in Excel-Sheets, Power-Point-Präsentation und Word-Dokumenten vergraben. Wissensaustausch in Organisationen findet fast ausschliesslich informell statt: durch Flurfunk, Email oder Verweise auf abgelegte Dateien.

Aus meiner eigenen Erfahrung in meiner Arbeit als Entwickler und Projektleiter im Bereich der Softwareentwicklung treten einige Probleme immer wieder auf, unabhängig vom konkreten Projekt oder der konkreten Organisation. Bitte reflektieren Sie kurz, ob Ihnen folgende Aussagen und Fragestellungen bekannt vorkommen:

„Wer in unserer Firma kann uns hier weiterhelfen ?“

„Wir müssten das mal irgendwann für unser Knowledge-Management-Portal niederschreiben“

„Das könnte mehr Leute interessieren. Wo sollen wir das ablegen / an wen sollen wir es alles schicken?“

„Suchen sie doch mal in unserem Intranet, da müsste doch bestimmt was zu dem Thema stehen“

"Ist das noch aktuell ?"

Aus diesen willkürlich ausgewählten Fragen, lassen sich folgende konkrete Probleme ableiten:

„Phantomproblem“: Experten sind nicht bekannt, oder, wenn sie bekannt sind, dann nur über persönliche Beziehungen, weil man sich kennt und das Wissen des anderen respektiert.

„Zeitproblem“: Das Niederschreiben und Verteilen von Wissen ist zeitaufwändig. Zeit ist auf Projekten die knappste Resource.

„Ablageproblem“: Welches der zahlreichen Wikis, Sharepoints oder Verzeichnisse verwende ich für das Einstellen ? Nehme ich ein Excel-Sheet oder besser Word ?

„Verteilerproblem“: An wen wird niedergeschriebenes Wissen verteilt und wie ? Wen setze ich auf den Email-Verteiler, wen nicht ?

„Goldgräberproblem“: um neues Wissen zu finden, muss ich erst aktiv danach suchen. Um wertvolle Informationen zu finden, brauche ich Glück.

„Granularitätsproblem“: Die meisten Wissenssokumente sind zu gross, weil sie eigentlich Zusammenfassungen vieler kleiner Wissenseinheiten sind. Das Relevante muss dabei immer zunächst herausgefiltert werden.

„Aktualitätsproblem“: Ein signifikanter Anteil des Wissen hat ein Verfallsdatum. Wie erkenne ich, ob Wissen noch aktuell ist ? Wie wird veraltetes Wissen gelöscht und nicht mehr weiter verteilt ?

Gehen wir einen Schritt weiter, so wird bei allen aktuellen Lösungen und Bemühungen ein grundlegendes Problem offenbar:

Knowledge-Management, wie es heute gelebt wird, ist dazu da, Wissen zu sammeln, in Dokumente zu bündeln und diese dann zu verwalten. Dieser Prozess ist für einen alltäglichen und ständigen „Wissensfluss“, wie er in jeder wissensintensiven und wissensbasierten Tätigkeit notwendig wäre, ungeeignet.

Schauen wir uns als Beispiel einer wissensintensiven Tätigkeit die Thematik "Softwareentwicklung" an: An jedem einzelnen Tag lernen die Mitarbeiter viele neue, meist kleine, aber sehr wichtige Dinge über Prozesse, Technologien oder Vorgehensweisen. Sie machen ständig neue Erfahrungen und lernen dauerhaft, sei es aus Fehlern, kleinen Rückschlägen oder durch Informationen, die sie extern gesucht und gefunden haben. Softwareentwicklung ist eigentlich das permanente Lösen von Problemen. Auf diese Art kommen die Entwickler der Lösung, dem fertigen Softwareprodukt, Schritt für Schritt näher. Dieser Prozess ist sehr individuell und jeder Entwickler muss ihn zunächst alleine durchleben.

Stünde nun aber ein effizienter Prozess zum Wissensaustausch zwischen vielen Entwicklern zur Verfügung, so wäre der einzelne Mitarbeiter nicht mehr auf sich allein gestellt. Er würde zu einem integralen Bestandteil eines sozialen Netzwerkes von Experten werden, welche sich auf Augenhöhe austauschen und gegenseitig fördern. Schlagartig würde so der komplette Prozess der Softwareentwicklung verbessert werden, mit entsprechend positiven Auswirkungen auf das Endprodukt.

In der Methodik der agilen Softwareentwicklung gibt es schon seit Längerem den Ansatz des sogenannten "Pair-Programming". Die Grundidee dabei ist es, den Entwickler nicht alleine zu lassen, sondern den Code durch zwei Programmierer erstellen zu lassen. Beide arbeiten dabei zusammen vor einem Bildschirm. Dabei profitiert jeder vom Wissen und der Erfahrung des Anderen. In einer gewissen Art und Weise ist dieses "Pair" ein soziales Mini-Netzwerk von Experten. Dort wo Pair-Programming eingesetzt wird, sind die Qualitätsverbesserung deutlich zu erkennen.

Wie besser machen ?

Was muss getan werden, um das Ziel eines effizienten Wissensmanagements zu erreichen ? Um diese Frage zu beantworten ist nachfolgendes Manifest entstanden, welches aus meiner Sicht die Hauptanforderungen an einen solchen Prozess formuliert.

Manifest für einen kontiniuerlichen Knowledge-Management-Prozess ("Continuous-Knowledge-Exchange")

Dieses Manifest basiert auf meiner eigenen, 15-jährigen Erfahrung im IT-Consulting und der Software-Entwicklung und der täglichen Konfrontation mit der Problemstellung "Wissensaustausch" in der Praxis. Unzählige Gespräche mit Kollegen und Experten trugen maßgeblich zur Herauskristallisierung der einzelnen Punkte, sowie deren Schärfung bei.

Wissensmanagement ist Kommunikation Wissensmanagement ist der Prozess eines strukturierten Wissensaustausches zwischen Experten. Wissensmanagement ist Kommunikation.

Wissensmanagement ist kontinuierlich Mitarbeiter lernen jeden Tag viele neue Dinge und wollen sie festhalten. Continuous-Knowledge-Exchange macht das tägliche und somit kontinuierliche Erfassen und Verarbeiten von Wissen zu seinem Hauptcredo.

Maximal eine Minute für Erfassung und Analyse Ein Prozess kann nur dann effizient sein, wenn er einfach und schnell nutzbar ist. Die Erfassung von neuem Wissen, sowie die Entscheidung, ob gefundenes Wissen für mich oder meine Arbeit relevant ist, muss in weniger als einer Minute getroffen werden können.

Relevante Wissenseinheiten sind klein Die wirklich relevanten und für das Tagesgeschäft notwendigen Wissenseinheiten sind klein. Kleiner als 1000 Zeichen. Eine Untersuchung der Durchschnittsgröße von Wissenseinheiten in einem Pilotprojekt mit wisdomclouds.com ergab eine Durchschnittsgröße von 402 Zeichen. Dies entspricht ungefähr dem Umfang dieses Punktes.

Containerisierung von Wissen ist zu vermeiden Die Verpackung von Wissenseinheiten in Dokumentencontainer wie Excel, Word oder PowerPoint erhöht die Komplexität im Wissensaustausch. Ein effizientes Wissensmanagement verzichtet auf diese Verpackungen. Siehe auch: "Why use plain text?", a Conversation with Andy Hunt and Dave Thomas.

Das soziale Netz von Experten ist das Herz eines effizienten Wissensaustausches Es gibt in einer Organisation viele Experten, die Wissen zu gleichen Themenbereichen besitzen. Diese müssen sich finden und vernetzen, um ihr Wissen effektiv austauschen zu können. Soziale Netzwerke sind das geeignetste Mittel hierfür.

Qualität entsteht nur in homogenen Netzwerken Qualitativ hochwertige Wissensbeiträge entstehen nur in homogenen Netzwerken gleichberechtigter Experten, die sich auf Augenhöhe austauschen. Diese Homogene Netzwerke müssen sich selbst bilden. Sie entstehen durch eine Keimzelle, die dann schrittweise weitere Experten zu ihrem Netzwerk hinzufügt. Sie entstehen nicht durch ein oder zwei wenige Administratoren, die dann die aus ihrer Sicht richtigen Leute hinzufügen (i.d.R. auf Basis des Org-Charts).

Wissen muss chronologisch organisiert werden Wissenseinheiten müssen zeitnah weitergegeben werden, sonst verlieren sie ihre Bedeutung. „Wissens- oder Knowledgestreams“ analog des Activity-Streams von Facebook oder der Idee der "Lifestreams" (http://cs-www.cs.yale.edu/homes/freeman/lifestreams.html) sind hierfür am besten geeignet.

Aktive Information statt Warten auf Reaktion vom User Nutzer müssen über neue Wissenspakete aktiv informiert werden. Wenn Sie vorher selbst aktiv werden müssen, um neues Wissen zu erlangen, entsteht ein Reibungsverlust, der gross genug ist, um den Prozess ineffizient werden zu lassen.

 Wissensmanagement ist ungleich Dokumentenmanagement  Im Zentrum eines effizienten Wissensmanagement steht die Kommunikation zwischen Experten, nicht die Verwaltung von Dokumenten.

 Wissensmanagement ist ungleich Collaboration Collaboration ist die Zusammenarbeit mehrerer an einem oder mehreren Dokumenten. Collaboration stellt das Dokument ins Zentrum. Continuous-Knowledge-Exchange stellt das soziale Netz von Experten im Mittelpunkt, nicht das Dokument.

 Wissensmanagement muss flexibel einsetzbar sein Wissen entsteht ad-hoc aufgrund sich ändernder oder neu entstehender Aufgaben und Problemstellungen. Teams finden sich zusammen, lösen eine Aufgabe und gehen wieder auseinander. Regelmässige Retrospektiven fördern Wissen zu Tage, dass erfasst werden muss. Effizienter Wissensaustausch muss flexibel und ohne grossen Aufwand einsetzbar sein.

 Wissensmanagement darf nicht nach dem Org-Chart ausgerichtet sein Das Orgchart ist der größte Feind des Wissensmanagements. Wissen darf nicht an Organisationsgrenzen aufgehalten werden. Wissensdatenbanken, die nach Org-Charts ausgerichtet sind führen zu Wissens-Silos. Soziale Netzwerke von Experten bilden sich Org-Chart-übergreifend.

 Hierarchien dürfen keine Rollen spielen Bestehende Hierarchien in Organisation sind für einen Wissensaustausch nur hinderlich. Vorgesetzte, die in einem Wissensaustausch-Prozess eine Sonderrolle einfordern und einnehmen führen zu Hemmungen bei den anderen Beteiligten und letztendlich zu Ablehnung. Ein effizientes Wissensmanagement fördert den Austausch von Wissen über alle Hierachieebenen hinweg. Siehe auch: Interview mit Google‘s CEO Eric Schmidt: Finally, there are some very smart people in your organization that you don’t know about. The ones who are low in the org, they’re probably miserable. They’re often deep, three levels down, look for it and when you hear it jump on it.“

Wissen muss persistent gespeichert werden Erworbenes Wissen darf nicht verloren gehen, sondern muss in einer Datenbank gespeichert werden. Diese Datenbank darf nur dem einen originären Zweck, nämlich der Speicherung von Wissenseinheiten, dienen.

Die Community verantwortet die Qualität, nicht Einzelne  Die Community entscheidet und überwacht die Qualität der Wissenseinheiten, nicht ein Einzelner oder wenige Einzelne.

Die Community strukturiert das Wissen, nicht Einzelne Die Kategorisierung und somit die Strukturierung des Wissens wird von der Community durchgeführt, nicht von einem Einzelnen oder wenigen Einzelnen.

Wissensmanagement unterstützt autarke Wissens-Communities Es gibt in einer Organisation viele Gruppen, die Wissen in unterschiedlichen, thematisch teilweise unabhängigen Bereichen besitzen. Diese Gruppen müssen autark ihr Wissen austauschen und verwalten können. Mit anderen Worten: Continuous-Knowledge-Exchange berücksichtigt die Tatsache, dass in einer Organisation einer bestimmten Größe viele soziale Netzwerke von Experten zu unterschiedlichen Themenbereichen existieren können.

Storytelling ist das beste Mittel zur Aufzeichung von Wissen Kleine Wissenseinheiten auf Basis von „Erfahrungsgeschichten“ sind das beste Mittel für eine effiziente Weitergabe von Wissen. Microblogging ist die effizienteste Art für die Aufzeichnung und persistente Speicherung dieser Stories.

Konzentration auf das Wesentliche Ein Prozess und das Tool für einen effizienten Wissensaustausch muss ausschliesslich auf Lernen, Lessons-Learned und generell Wissen ausgelegt sein. Features wie Statusmitteilungen oder Chat wie sie bei Facebook, Twitter und anderen Social-Media-Tools im Mittelpunkt stehen, sind für Wissensaustausch irrelevant. Sie erzeugen lediglich "Störgeräusche" erzeugen, die herausgefiltert werden müssen, nicht aber der persistenten Speicherung von Wissen dienen.

Lerne durch Wiederholungen Ein effizientes Wissensmanagement muss im wieder an vorhandenes und bereits gelerntes erinnern, da es sonst vergessen wird. Continuous-Knowledge-Exchange unterstützt ein automatisiertes Wiederholen von einmal erworbenen Wissen.

Ein Prozess, der diese Punkte erfüllt fördert aus meiner Sicht den Wissensaustausch in Teams oder Organisationen erheblich. Im Mittelpunkt eines solchen Prozesses steht der tägliche und einfache Austausch von Wissenseinheiten innerhalb von sozialen Netzwerken von Experten. 

 Der Name "Continuous-Knowledge-Exchange" unterstreicht dabei eine der Wurzeln dieses Manifest in der Agilen Softwareentwicklung, bei der das Erstellen und Ausliefern eines Produktes in kurzen Zeitzyklen ("continuous") im Vordergrund steht.

Feedback gerne willkommen !

stefan.wendel (at) wisdomclouds.com

www.wisdomclouds.com