Well, I was blogging about my personal workspace before, and that post and this one have blurring boundaries. See there for my general setup, my choice of browsers et al. Here it’s about processes and ways to channel and refine content.

I got triggered by various posts and inspirations – one being recent posts by Robert Scoble (on what it needs for better content curation), Louis Gray (on how he proceeds with sharing content), Steph Booth (on why she likes Tumblr and how it fits into her lifestream), Andi Gohr (on his lifestream configuration) and Mac Slocum (on how buzz can be perceived as hybrid blogging). Other inspirations include people asking me on buzz how I share links (Christian, yes!), why I continue to use and enjoy buzz (DT, yes!), and how I refine the contents I share.

All this made me compile this post to share some of the tweaks and lifehacks I have chosen to tailor content I share, how I get a grip on the topics myriad of people whose work I am following et al. Basically most of these tweaks are in place to avoid needless redundancy, ie. channels get selected depending upon content (and audience) – hoping that the stuff I share to different platforms will be interesting (or valuable at times).

So here’s the basic setup:

Complicated infographic, yes. So let me explain: Basically I am depicted in the middle (ie. the neat frogpond logo) – and I am busy filtering, refining and curating content (from the top down to the bottom).

Most of the things I am learning on the web reach me via RSS – and in my reader of choice, the Google Reader. Currently I am subscribed to +1000 feeds, including podcasts, Tumblr feeds, a ton of blog feeds, searches and everything – all sorted into folders (yes, these folders have varying importance to me, you sure believe me when I say that the _fun folder is less important and funny than the _e20 folder, will you?). Moreover the Google Reader is the focal point for all the recommendations I am subscribed to, ie. the Google Reader items my buzz contacts and friends are sharing (top left). This is the lions share – and you will understand that I basically live and breathe by RSS.

Other sources of inspiration and content include my buzz lifestream (now following 400 people) and my twitter lifestream (following roundabout 1600) – and the usual suspects, ie. mail, skype, IRC, Google Talk, telcos, talking to actual people, working with customers et al.

All of this – remixed, refined and reworked – gets pushed out via various channels again, the easiest being my delicious bookmarks (bottom right). I am bookmarking and tagging a lot – yet, I must confess that not everything I hamster is public. As of today roundabout 75% of my bookmarks are marked private – I bookmark them so that I alone can find them again, come time. The 25% of my delicious bookmarks that I think are interesting to share in public get spliced into the main feed of frogpond by Feedburner.

Then I am blogging – in WordPress blogs here and there. Mostly I am pretty happy with generic posting, but sometimes it’s more convenient via Posterous, ie. via frogpond.posterous.com. This Posterous blog also allows for manual autoposting to my tumblr, a range of self-hosted internal collaboration wordpress blogs (my interpretations of a linkblog and an aggregation site), to Facebook, to Friendfeed and even to delicious. Heck, I could even tweet directly from Posterous …

All of the posts that make it to my regular blogs are syndicated to Google buzz – which in turn is feeding Twitter (via the Feedburner socialize solution, employing Pubsubhubbub) and Facebook (via Twitterfeed). Notice that I only feed native and generic buzz to Facebook, no @-Replies, no Retweeting, no redundancy, no nothing. And no, it’s not because I like Facebook and I want to keep it clean and easy. It’s more the other way round – if you want to interact with me you better use the spaces I engage in, ie. buzz and to a lesser extent Twitter. No point in aggregating my replies into Facebook when nobody there knows why I am replying ..

Ok, onto buzz – you notice it’s bigger than the rest (hey, almost as huge as Google Reader …). This is for a reason: I just love the platform. And I use it daily. Via mobile access or via old-school generic usage. Daily.

Into buzz there goes
a) generic buzzes – say I want to macroblog a link or an image or, err a tweet
b) my GReader recommendations (GReader is linked with buzz, ie. every time I click on “recommend” in Reader the item gets added to my lifestream)
c) all content I share via my secondary Posterous-Blog buzzpond (this is directly linked to buzz, while frogpond.posterous.com ain’t linked).
d) content from my blogs
e) all mobile (picture) buzzing and all public Flickr additions

Now I should elaborate as to why buzz has hit a nerve with me, but I will keep this for another post …

One – I am really waiting for the Buzz to arrive in my Google Apps domain (mail to frogpond adresses is handled by Google Mail, yes, there are a lot reasons for putting mail and apps into the cloud) – and the official announcement wasn’t clear I think:

We also plan to make Google Buzz available to businesses and schools using Google Apps, with added features for sharing within organizations.

Hmm, does this include the standard edition of Apps or is this planned for Premium alone?

Two – let’s applaud Google for relying on open communication standards for its social web endeavours – it’s playing, integrating and – as Chris Messina writes here – leveraging the fabric of the open web. Of course this is helping Google but it’s also helping us, and it’s a wildly disruptive move too (hey, everything that uses Pubsubhubbub is a friend of mine …).

Three – Right, Buzz both validates and marginalizes Friendfeed (I so dig the tag line “FriendFeed Reborn. On Growth Hormone” at Techcrunch). Indeed, the idea of an aggregated life-workstream was just too good to go unsatisfied – and I am now waiting for rooms and/or persistent searches to find their ways into Buzz.

Knowledge workers they need to arrange their groups and channels of communication, finding information from sources that are contextually relevant (and then act upon them, sometimes this may just mean more information filtering, analysis and refining et al.). All in all the knowledge workers workplace can need some more nifty tools that improve productivity – and yes, this is a big topic in Vulcan too everywhere.

Four – Commencing on the context topic of three, what Buzz already has done for me is a boosting of the volume (and so far the usefulness) of Google Reader recommendations. I really like the pre-filtered stuff that gets channeled to me through my social network (and I hope they enjoy the stuff I am recommending and bookmarking on a daily basis).

And now there’s more of it – and it’s easy to “buzzify content” that may start a discussion on Buzz. So I guess we need some more Backtype wizardry to include the Buzz discourse on blogs. That said – we’re still missing threaded conversation, individual favoriting of comments et al. in Buzz. Until that arrives I would rather have the conversation and discourse in here, yet I am not sure how this will work out in the end. But yes, I see and I like that Buzz will allow for more finetuning, filtering and finding stuff that interests me.

Let’s assume then that the adoption rolls in the enterprise sphere too? That’s asking for much now (and let’s not forget that these are beta status thougts …). One reason is that Google is not exactly in the position to enter the large enterprises market, even taking into account the considerable amount of consumerization of corporate IT and collaboration instruments. But I am sure that collaboration systems that merge IM, mail, wiki style collaborative editing, content sharing and communication will succeed in the enterprise too.

So yes, I think they can mount the 9x challenge – Susan asked here whether Buzz can overcome Andrew McAfee’s famous test – and I commented that it’s the integration with Google Mail that helps Buzz access a huge initial user base and network, of which:

[...] some may use it at times, even when it’s not 9 times better than the other ways we communicate

From this initial user base I guess it’s a downhill battle …

So yes, and to sum it up – for now Buzz may be immature, but it has lots of promise to change the way people collaborate and communicate.

PS. I know this could as well been a BMID post – as Buzz pondering touches and meanders around the cultures of innovation, the nerve and resilience to pull through with your innovation and ideas (some have fears Google may not), all in all the excitement and the wonders of technology innovation. And it’s relevant from a business model innovation perspective too, I feel a bit so …

• Google Wave is poised to reshape (rewires I say) the nature of communication (yes, more face-to-face real-timelineness communication), improving the web experience. We probably need to experience and use it a while to understand its potentials completely …

- A wave is equal parts conversation and document. People can communicate and work together with richly formatted text, photos, videos, maps, and more.
- A wave is shared. Any participant can reply anywhere in the message, edit the content and add participants at any point in the process. Then playback lets anyone rewind the wave to see who said what and when.
- A wave is live. With live transmission as you type, participants on a wave can have faster conversations, see edits and interact with extensions in real-time.

And as we’re moving onto more real-timeness and collaboration already (think Friendfeed lifestreams, real social bookmarking and annotation, social news and more), this is much more than another Google service:

• Yes, it’s a promising product, framework and protocol.

• Yes, it’s got an API which is devised to allow “developers to embed waves in other web services and to build extensions that work inside waves”.  With HMTL 5 and a supportive browser we get an app that is part wiki, part chat, part forum, part collaborative office and document (nah, content) sharing tool and part email. We get multi-user real time editing – be it in uploaded photos, videos or other stuff (alas, you can’t edit the photo or the video but you can collaboratively tag the uploaded files). It’s possible to play-back the history of the document to see how it evolved (think wiki page history on a ton of steroids).

• Yes, the platform will be open-sourced, it will be able to run on any server, so it won’t belong to Google. It’s a standard thing so whoever is hosting waves can build no walled garden (you listen Facebook, do you?) but must ensure interoperability (yes, like with plain old mail). One step closer to living in the cloud of distributed apps and data. And it’s playing along the lines of integration and adaptivity … so I can’t wait to put this on my own servers

At last, one more thing, something that explains why Google is such a remarkable company – it’s the story behind Wave. Starting from the question “Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum? How simple could we make it?” they have achieved a lot. And Google’s introductory blog post has the innovation story, ie. why it must have been Google to say yes to this idea and on the early days of Wave (more on Google innovation culture, ie. a company whose unique culture shows through in small ways):

When Lars Rasmussen first floated the idea, Google co-founder Sergey Brin wasn’t impressed. “He came to me and he said ‘This may sound kinda crazy, but we’re going to reinvent communication and we just need a bunch of engineers to go of to Australia for a while and we’ll get back to you after a couple of years,’” Brin remembers. “It was not a very compelling proposal.”

More wave information at the usual places, like Techcrunch, Tim O’Reilly (Open Source, Open Protocol, and Federated Wave Clouds), Forrester, Mashable

And yes, you can sign up for Google Wave updates

Anfang nächster Woche findet die do it.Konferenz 2008 in der Neuen Messe Stuttgart statt. Bis einschließlich morgen ist noch die Anmeldung möglich (Disclosure: Ich werde auf Einladung der MFG dabeisein – vielen Dank dafür!)

Die Veranstaltung ist Gipfeltreffen, Innovationsschnittstelle, Talent- und Networkingplattform rund um Kreativwirtschaft, Informationstechnologie und wissensbasierte Anwenderbranchen..

In 4 eigenständigen Fachkongressen bieten über 100 Experten aus Wissenschaft und Praxis ein breites Spektrum an Informationen über verschiedene Lösungen, aktuelle Entwicklungen und die wichtigsten IT-Trends der nächsten Jahre. Experten und Entscheider diskutieren, wie Unternehmen der Zukunft aussehen und Medien und Informationstechnologie unsere Wirtschaft und Gesellschaft verändern werden.

Auf der begleitenden Fachausstellung präsentieren sich innovative Unternehmen, Initiativen und Institutionen aus Baden-Württemberg.

Ich selbst werde mich auf die Veranstaltungen, die im Rahmen des ebigo Mittelstandsforums stattfinden konzentrieren. Die Potenziale, die in innovativen Internet- und Softwareanwendungen wie Wikis, Weblogs, Microblogging, Social Networking, Social Bookmarking etc. gerade für KMU und Mittelstand liegen beschäftigen mich schon seit langem. Und wo besser kann man den Kontakt zur Zielgruppe suchen als auf einem solchen Kongress …

An interesting point is while SMBs are proving slow to adopt, large organisation are buying tools today.

Some more notes

Tools that provide high leverage value in E2.0 adoptions are key, as is efficient and effective enterprise search. The gulf between good search on the web and good search inside the wall is significant.

In the comments James Dellow notes that RSS is missing, yes I agree, RSS provides a good investment / benefit ratio (well, after people understand it, we need more explaining, showing and telling).

Obviously, Dion also talked about the importance of understanding Andrew McAfee’s thinking on Enterprise 2.0 (start with the SLATES acronym, full ack Stephen, that “Dion continues to use this set of definitions indicates their ongoing importance.”).  Stephen notes:

At it’s core, the notion of applying the “Web 2.0 effect” at work is critical:

• globally visible (which is not everything, but everything appropriate), persistent collaboration
• use of the tools of the Web 2.0 world
• putting workers into the centre of the contributory world

And for some more interesting coverage see the stuff aggregated at the conference site. Like e.g. that Thomas Vanderwal talked about how to manage the flood of information via social bookmarking and advanced forms of tagging (slides found via John Eckman), btw – good writeup by Stephen:

Next post from Intranet.days 2008 at Frankfurt: Ein Vortrag von Eckhard Oberfrank von Detecon zum Thema “Mitarbeiterbeteiligung im Intranet der Deutschen Telekom – Muss es immer gleich Web 2.0 sein?”

Kleiner Rundown zum Thema Web 2.0 – angelehnt an die Web 2.0 Meme Map von Tim O’Reilly – mit besonderem Fokus auf Folksonomies, Social Bookmarking, … und wie Social Media im Unternehmen eingeführt werden kann.

Intranet 2.0 – welche Elemente der Tim O’Reilly Definition gelten für das Intranet:
- Vision: Intranet wird eine Plattform
- Benutzer steht im Zentrum
- Erschließung der kollektiven Potenziale
- Trust the Mass – kollektives Regularium – Intranets haben aber oftmals nicht die kritische Masse (frogpond: sehe ich nicht ganz so kritisch, in Intranets kann auch mit wenigen aber interssierten und engagierten Mitarbeitern viel wertvolles entstehen – zum anderen reicht es oft aus, wie vorhin bei Leila Summas Vortrag gehört, wenn die Mitarbeiter passiv daran teilnehmen und dadurch besser informiert werden)
- Bewertungen von Informationen -> Bewertung von Personen schwierig
- Kollaborationsanstoss im Unternehmen schwierig

Captain Obvious strikes again: “Social Media for Collaboration is different from generic Social Media on the Internet.”

Einige Beobachtungen:
- RSS ist bei T-Systems anscheinend noch in der Testphase
- AJAX und Eye Candy muss im Intranet anders verstanden und eingesetzt werden – es geht nicht darum Stickyness zu haben
- AJAX und Eye Candy können aber das Intranet (und die Corporate Strategy) emotionalisieren
- Mr. Clemens blog is well accepted – employees are checking the contents, yet there aren’t too many comments until now
- internal blogs at T-Systems try to build up #authenticity, connecting to employees – while talking with authority
- es gibt auch eine nette Reihe von etablierten Kommunikationsmethoden und -instrumenten die dabei helfen können die Authentizität der “corporate message” zu erhöhen
- user generated rich content (videos) im Intranet der Telekom – über 30.000 Beiträge wurden von den Mitarbeitern im Rahmen einer iPhone-Verlosung (?) eingesendet

Johannes Moskaliuk hat die 8 Gegenargumente analysiert – unterteilt in funktionale und psychosoziale “Lösungsmöglichkeiten”. Gefällt mir sehr, und ja, es geht hier nicht um absolute “Wahrheiten” sondern mehr um Gefühle, Einschätzungen und eben auch alternative Umsetzungs- und “Lösungsmöglichkeiten”. Also erweitere und kommentiere ich Johannes’ Ideen aus meiner Sicht:

1. Die krude Wiki-Syntax ist oftmals ein Akzeptanzproblem.

Psychosozial: Neue Software erfordert neue Kompetenzen. Ohne Schulung der Mitarbeiter, Supportfunktion und eine Beteiligung der Nutzer bei der Entscheidungsfindung geht es auch im Wikizeitalter nicht.

Funktional: Mit dem Einsatz eines WYSIWYG-Editors ist das Problem lösbar. Technisch möglich ist auch die weitergehende Integration ins Betriebssytem, wie z.B. beim TWiki mit dem Kupu-Add-on (Linux) oder beim der Confluence-Software mit MS Office (Microsoft).

Zum einen: WYSIWYG-Editoren sind kein Allheilmittel und weisen nach jetzigem Stand der Technik auch gewichtige Nachteile auf. Es ist kein Zufall dass Enterprise Wikis wie Socialtext beide Editor-Alternativen parallel anbieten. Eine ausführlichere Analyse von Pro und Contra findet sich hier (“Simplicity, adoption and WYSIWYG editors”).

Zum anderen: Eine Einschätzung als krude Syntax (sic!) gilt nicht für jeden Markup-Dialekt, man vergleiche einmal die Auszeichnungsalternativen von bspw. Mediawiki für kursiv und bold (” und ”’, bold und kursiv sieht dann so aus: '''''fett und kursiv''''' – eingängig nicht wahr?) mit denen von Wikicreole, an die sich u.a. DokuWiki anlehnt.

Aber die eigentliche Aufgabe liegt natürlich im Bereich “psychosoziale Akzeptanz”, und es ist zweifellos richtig, dass Markup ein Akzeptanzproblem hat. Letztlich gilt das für alle Werkzeuge, die nicht wie Word aussehen (interessanterweise werden manche andere Werkzeuge und Systeme nicht so stark hinterfragt was Usability und Akzeptanz angeht, sie werden Mitarbeitern aufgezwungen und diese müssen damit mit SAP R/3 arbeiten – auch wenn die Usability bescheiden ist). Pragmatisch gesehen liegt die Antwort daher meist in einem “sowohl als auch”, in Verbindung mit einer gewissenhaften Analyse von Anforderungen und Zielgruppen, die Frage ob WYSIWYG sein muss, sollte dabei ergebnisoffen und vorurteilsfrei angegangen werden.

2. Kategorien und Hierarchien lassen sich zwar aufbauen, doch eine entsprechende Navigation kann nur über einen Eingriff im Backend eingerichtet werden.

Funktional: Über den Einsatz semantischer Technologien oder – einen Schritt vorher – die konsequente Anreicherung von Informationen mit Metadaten (z.B. Tags, Projektzuordnung, Themen, Inhaltsklassen) sind die Inhalte letztlich schneller über eine Suchfunktion als über eine Navigationsstruktur zugänglich.

Psychosozial: Dieses Gegenargument ist gleichzeitig ein Pro-Argument: Die Navigation wird eben nicht „von oben“, vom Admin oder Chef festgelegt, sondern wird von der Community kollaborativ erstellt.

Hmm, Navigation nur über einen Eingriff im Backend? Gilt nicht für die Wiki-Engines zu denen ich rate. Und Navigation über Kategorien oder Hierarchien? Es muss eben evaluiert werden, ob es nicht Wiki-Engines gibt, die so etwas von Hause aus mitbringen (bspw. TWiki-Webs, eigentlich alle gängigen Enterprise Wikis oder auch DokuWiki mit dem Namespace-Konzept).

Johannes – großartiger Punkt bei psychosozial. Dieser Aspekt des emergenten Entstehens von Struktur wird zu oft vernachlässigt, obwohl er viel für die flexible Anpassung an veränderliche Aufgabenstellungen (und die Motivation der Mitarbeiter) tun kann. Arbeitsgruppen, einzelne Mitarbeiter, einzelne Projektgruppen etc. können sich situativ angepasste Arbeitsumgebungen, Portal- und Übersichtsseiten einrichten. Das habe ich mit großem Erfolg auch schon begleitet, und es war eine Freude zu sehen wie die Möglichkeiten von den Nutzern aufgenommen und schnell genutzt wurden.

3. Die Kategorisierung spielt bei den Suchergebnissen keine Rolle bzw. sorgt nicht für eine Priorisierung von Suchergebnissen.

Funktional: lösbar, siehe oben

Psychosozial: Kompetenz bei der Anwendung der Suchfunktionalität muss bei den Nutzern vorhanden sein, oder geschult werden. Außerdem kann das Finden von Informationen, nach denen eigentlich nicht gesucht wurde, Prozesse der Wissensemergenz fördern (Serendipity).

Ich würde noch ergänzen, dass wir auch die zunehmende Einbindung von Wiki-Inhalten in Enterprise Search Ansätze sehen werden. Von Social Bookmarking in the Enterprise ganz zu schweigen. Das Problem ist erkannt, daran wird gearbeitet und Wikis sind eigentlich hierbei das kleinste Problem, viel mehr wird zurzeit damit gekämpft relevante Suchergebnisse aus den vielen, verteilten Office-Dokumenten zu generieren …

4. Suchergebnisse zeigen nicht an, welche Unterthemen es zu einem Oberthema gibt oder ob es in einer anderen Sprache einen Artikel zum gesuchten Thema gibt. Die Semantik drückt sich nicht in Wiki-Strukturen aus. Ab einer gewissen Textmenge ist das nicht mehr praktikabel.

Funktional: lösbar, siehe oben. Schlagwort: Semantic Wiki.

Ja, Semantik drückt sich auch nicht in Office-Dokumenten aus. Tagging, Kategorisierung, redundanzfreie Datenhaltung – alles wichtig, das Semantic Web wird auch manches davon lösen. Psychosozial gilt Punkt 3, Informations- und Medienkompetenz ist nicht immer gleichverteilt und gut ausgeprägt. Coaching und Schulung (und Learning-by-doing) kann hier helfen.

5. Die Suche erstreckt sich nur auf Wiki-Inhalte, andere Quellen können damit nicht erschlossen werden.

Funktional: lösbar. Beispiel ist das Confluence Wiki, dass auch zum Durchsuchen von externen Quellen, z.B. Austauschordner oder Servern genutzt werden kann.

Ja, siehe auch oben die Anmerkungen zu Enterprise Search. Enterprise Wikis bieten mittlerweile fast durchgängig die Möglichkeit bspw. hochgeladene Dokumente in die Suche aufzunehmen.

6. Das Rechtemanagement für ein Wiki muss mühsam eingerichtet werden, insbesondere wenn ein nach Personen und Gruppen differenzierter Zugang für verschiedene Bereiche eingerichtet werden soll.

Funktional: Lösbar zum Beispiel durch den Einsatz von Windows Active Directory. Für das Wiki können bestehende Rechtestrukturen übernommen werden.

Psychosozial: Ein Erfolgsfaktor für den Einsatz von Wikis ist eine flache Hierarchie und der freien Zugänglichkeit von Inhalten. Idealerweise ist die Einführung von Wikis in einer Organisation verbunden mit einer Änderung der Organisationskultur im Bezug auf den Umgang mit Wissen und Informationen zwischen Hierachieebenen.

Hmm, was heißt mühsam? Ist in den meisten Wikis nicht aufwendiger oder anspruchsvoller als die Benutzer- und Rechteverwaltung von Windows Server etc. Eine LDAP-Anbindung ist oft vorgesehen, damit ist dann selbst SSO machbar.

7. Nach etwa ein, zwei Jahren kann es für Unternehmen problematisch werden, wenn die entsprechende Pflege fehlt.

Funktional: Tools können die Pflege unterstützen, zum Beispiel das Finden von toten oder falschen Links, das Ändern von falschen Kontaktdaten etc.

Psychosozial: Das Problem tritt bei allen Systemen zum Wissensmanagement auf. Neben der Einführung einer Technologie, müssen sich deshalb auch Arbeitsabläufe, Arbeitsaufgaben und Rollen (Wikigärtner) anpassen, so dass eine ständige Pflege und Aktualisierung von Inhalten gewährleistet bleibt. Anders als bei anderen Werkzeugen kann die Verantwortlichkeit für die Aktualität der Inhalte auf alle Mitglieder einer Organisation verteilt werden.

Ohne Pflege geht es nicht, nicht umsonst werden die Rollen des Wiki-Gärtners oder des Wiki-Gnoms so wichtig eingeschätzt. Und ja, auch in einem klassischen Intranet kann ohne strukturierende Pflege Wildwuchs, wie bspw. veraltete, widersprüchliche oder redundante Inhalte entstehen (ich gebe aber zu dass ich die Möglichkeit an veröffentlichte Seiten ein “Verfallsdatum” zu knüpfen manchmal vermisse). Aber diese Schwäche kann man durchaus auch zum Vorteil wenden, siehe Punkt 8:

8. Wikis eignen sich für Projekte. Über die Jahre werden jedoch immer mehr Wikis eingerichtet, der Überblick geht verloren – man weiß nicht mehr, in welchem Wiki man suchen muss.

Funktional: Lösbar durch eine Suche, die über mehrere Wikis ausgedehnt ist.

Psychosozial: Klassischerweise wird ein Projekt in einem Abschlussbericht dokumentiert. Auch das lässt sich auf ein Wiki übertragen: Am Ende eines Projekts werden die zentralen und wichtigen Inhalte des Projekts in ein zentrales Wiki übertragen und bleiben dort zugänglich. Das Projektwiki wird gelöscht.

Wenn im Zeitverlauf mehrere Wikis entstanden sind (oder Projektunterbereiche etc.) ist es aus meiner Sicht auch eine Chance Inhalte rückschauend zu strukturieren, und dabei positive und negative Erfahrungen zu dokumentieren. Ein After-Action Review mag zwar zeitraubend erscheinen, aus meiner Erfahrung lohnt sich die Mühe aber. Eine Zusammenfassung der wesentlichen Punkte schafft einen Überblick, der bei anderen ähnlich gelagerten Projekten hilft. Ein paar Ideen zum Einsatz von Wikis im Projektmanagement habe ich hier, hier und hier zusammengestellt.

Zusammenfassend: Einige der Punkte entstammen meiner Meinung nach einer weitverbreiteten (aber unüberlegten) Gleichsetzung von Wiki mit Mediawiki bzw. Wikipedia. Die Wikipedia ist aber kein archetypisches Wiki, und Mediawiki ist auch nicht stets die beste Wiki-Engine. So weisen bspw. Enterprise Wikis wie Socialtext oder Confluence einen Großteil der oben vermuteten Angriffspunkte überhaupt nicht auf, sprich es bestehen bereits funktionale (technologische) Lösungen.

Zudem beziehen sich viele der Kritikpunkte der originalen Liste von Kooptech auf potenzielle Nachteile, d.h. mögliche Schattenseiten von Wikis, die erst durch eine “ungeschickte” Einführung und ungeignetes (Wiki-)Management* zutage treten. Die Auswirkungen auf Strukturen und etablierte Routinen etc. können ja groß sein – das ist auch das eigentliche Motiv von Enterprise 2.0. Aber um diese Potenziale heben zu können braucht es auch ein schlüssiges Konzept, sowie die Anpassung an die Unternehmensgegebenheiten und -ziele. Aber wenn etablierte Vorgehensweisen und Erfolgsfaktoren der Implementierung nicht beachtet werden, kann es durchaus schon mal schiefgehen.

<werbung>Deshalb bietet es sich ja auch an professionelle Unterstützung ins (Projekt-)Boot zu holen. Berater wie wir bringen zum einen spezifische Erfahrungen ein, aber auch

einen Überblick über bewährte Vorgehensweisen und

Ideen, d.h. innovative, kreative Problemlösungsstrategien.

Davon kann die organisationsseitige Einpassung – sprich das Change Management in Bezug auf die eigentlich spannenden sozialen und unternehmenskulturellen Aspekte – profitieren. Und weil es bei Enterprise Social Software wie Wikis meist weniger um Technologie, denn um diese weichen Faktoren geht ist eben weniger Technologieberatung denn Organisationsberatung notwendig.</werbung>

* ich lese gerade das Buch Wikimanagement von Prof. Komus, Review folgt.

Ich komme nun erst recht spät zum Bloggen und Dokumentieren – ein kleiner Grund ist der ungeschickte Termin. Beim nächsten mal wählen Cedric und ich auf jeden Fall nicht mehr (Oster-)Ferien, zu eng liegen dann doch die sonstigen Aufgaben.

Dennoch ist das Oberthema Projektmanagement (PM) zu spannend um einfach zum normalen Blogging und Geschäft (was meist eben auch projektbasiert abläuft) überzugehen, zumal wir drei herausragende Vorträge hatten.

• Angefangen hat Lars Zapf von Simprove, der einen Vortrag über Social Project Management (SPM) gehalten hat.
• Karoline Kraus von TQU aus Neu-Ulm hat über Erfahrungen mit Wikieinführungen gesprochen
• Oliver Gassner hat eine spontane GTD-Session gehalten

Einige meiner Notizen (und Überlegungen) zu Lars’ Vortrag:

- wir brauchen neue Methoden im Projektmanagement, die alten Herangehensweisen tragen nicht mehr
- “Social Project Management” ist sowohl gutes Branding, als auch Programm
- 2.0 impliziert eine gewisse Wertung, die mir auch nicht gefällt. Social Web ist prägnanter als Web 2.0.
- klar, es gibt nicht das Werkzeug für PM, Projektleiter (und Programmmanager) brauchen einen gut gefüllten Werkzeugkasten und eine gewisse Virtuosität (und Erfahrung) bei Auswahl und Einsatz des Instruments
- ich schreibe bewusst Instrument und nicht Werkzeug – Instrument ist das Bundle von Methode und Werkzeug
- strukturierte Vorgehensweise bleibt wichtig, aber die Art und Weise der projektbasierten Zusammenarbeit muss sich ändern – und ändert sich auch (manchmal …)
- die Zusammenarbeit via Email stört eher – u.a. weil der “Flow of Work” zu oft und aus zu geringen Anlässen unterbrochen wird, Email ist eine tendenziell unstrukturierte Form der Zusammenarbeit …
- Kommunikation muss weg von Push- und hin zu Pull-Funktionalitäten (RSS anyone?)
- um die weltweit verteilte Zusammenarbeit von (virtuellen) Projektteams besser zu koordinieren und zu unterstützen sind Wikis schon besser geeignet
- Realität sind jedes mal neu zusammengestellte Projektteams, mehr Freelancer, mehr Externe, mehr Kunden und andere (Projekt-)Stakeholder … die mit heterogenen (IT-)Werkzeugen zurechtkommen müssen …
- bittere Realität ist es auch dass allzu leicht (der Schwabe sagt “gerne”) im Stress auf lang (und früh) eingeübte Werkzeuge der Zusammenarbeit zurückgefallen wird (“when the going gets rough nobody edits the wiki”)
- Lars: “Wikis werden in D gerade als potenzielle Lösung verstanden und evaluiert” – stimmt, die breite Akzeptanz fehlt aber noch, entwickelt sich im Moment, 2008 wird WikiJahr
- Social PM lehnt sich an die Ideen von Wikinomics an, konzentriert sich auf das Wesentliche – Kommunikation als erste Priorität
- Simplify your Projects: Reduktion des PM auf Kommunikation, Meilensteine, Aufgaben
- Lars: “Social PM braucht neue Art von PM-Software: keine Balkenplan-Ansicht, keine Vorgangsverknüpfung, kein kritischer Weg, keine Bearbeitungsdauer” – OK, da bin ich dabei, Einschränkungen siehe weiter unten
- Immer wieder gern daran erinnert: Parkinson‘sches “Gesetz”: Ein Aufgabe braucht solange wie man ihr Zeit einräumt (und wenn Pufferzeiten vorgesehen sind, werden diese auch genutzt)
- Social PM ist sicher nicht für jedes Projekt geeignet, klassische Projekte und klassische Instrumente (“Balkenplanung mit MS Project”) haben weiterhin ihren Platz
- Social PM ist sowohl Methodik als auch empfohlene, bewährte Abarbeitungsstrategie für jeden einzelnen (Wissens-)Arbeiter.
- Social PM ist ein Grundgerüst für die Zusammenarbeit in Projekten, benötigt angemessene Toolunterstützung – andererseits sind viele Wissensarbeiter bereits “toolgeschädigt”
- Social PM greift auf verschiedene Vorläufer und deren Instrumente zurück, wichtig sind u.a. Merlin Manns 43folders.com, GTD, die 4-hour workweek (ja, mein Liebling, best quote ever: “doing something unimportant does not make it important”), Getting Real (ja, auch ein Liebling, warum Probleme, Design und Prototyping spannend sind? siehe hier)
- wir sollten neue Instrumente auf Einsatzarenen prüfen, bspw. hat CoreMedia mit Trillr eine Business-Twitter Adaption eingerichtet, wir können aber auch ganz banal den Gruppenchat von Skype verwenden …
- Social Bookmarking und Social Networking in Projekten ist auch spannend
- …

Hier noch die Folien von Lars’ Vortrag (und der zugehörige Blog-Eintrag):

| View | Upload your own

Meine Notizen (und weitergehenden Überlegungen) zum Vortrag von Karoline Kraus vom Steinbeis Transferzentren Qualität im Unternehmen (TQU).

- TQU-Kerngeschäft ist Beratung und Managementunterstützung – Managementsysteme und mehr, d.h. es geht um interne Organisationsgestaltung
- TQU = Projektarbeit, Weiterbildung, Qualifizierung, Information
- aus diesen Aufgaben (Organizational Re-Design) ergab sich der Einstieg in Richtung Wiki ganz natürlich
- TQU setzt internes Wiki seit 2 Jahren ein
- einige interessante Fallstudien und Praxisbeispiele, u.a. aus Gesundheits- und Sozialbereich, aus KMU, etc.
- erfolgreiche Einführungen starten oft mit Erklären, der Grundprinzipien von Web 2.0 und Social Software, der Motivation, der verfolgten (Unternehmens-)Ziele
- erfolgreiches Vorgehen durch Beachten von Erfolgsfaktoren, u.a. kleine Projektteams, Projektmarketing, frühzeitiges Vergeben von Rollen, d.h. Rechten und Pflichten, (initiale) Inhalte, MA-Schulung und Training, …

This is timely, as using social software for project work is a recurring theme in most client talks of late, i.e. it’s a common theme when people are pondering and probing the opportunities of social software in the enterprise. And it’s a good source of examples, especially for the workshop I am doing together with Oliver Gassner on February 18 (register here).

So I thought it a good idea to compile some information and experiences on using social software in project management (yes, most of this is may be valid also for multiproject- or program management, like in this actual project portal I did, depicted on the left).

Project management of course entails different types of activities, of which only some (dare I say most?) can be supported and enhanced with social software like blogs or wikis. And yes, social software uses for project management should ideally be evaluated from the perspectives of diverse target groups (like project members, managers, program managers, a diverse set of stakeholders etc.), but let’s focus on actual project managers this time. So I will focus on usage arenas for blogs and wikis, keeping in mind that these two are only parts of a more elaborate and naturally interlinked social software toolkit for the enterprise (which needs to be applied via effective and elaborate consulting, yes – naturally too). Moreover, the way to go isn’t project blogs OR project wikis OR social networking in projects OR whatever/younameit – so I may write about social bookmarking, social networking platforms, folksonomies or RSS for general project management later on, stay tuned.

OK, then, as activities and tasks of project managers are diverse, perhaps they’re best viewed from the general perspective of an (ideal, virtual) project room that tries to bundle and organize different activities on an integrated platform.

Now, blogs are ideally suited for project communication by project managers, who always need to keep stakeholders and project workers informed. Blogs are an alternative to email for asynchronous communication, especially the sort of 1:m communication that email doesn’t handle well. So the project blog becomes the main communication tool, documenting and tracking the project and the learnings made, and helps in constantly keeping the project status clear.

Wikis are good at fostering collaboration and building up shared understanding. Wiki pages can be collectively defined, refined, explored, tested, and built upon. They are an adaptive platform that can be customized to specific contexts and needs, and emergent and freeform usage patterns, i.e. ever changing (ad hoc) activities, processes and work practices. Wiki pages can be opened easily and securely to partners, customers, suppliers and more – in fact using a wiki as a defacto intranet application makes it easy to extend it into an easy and lightweight extranet, that allows firewall crossing when needed – like when working with project team members that are based outside the organizational boundaries.

Yes, neither project blogs or wikis are meant to replace traditional project management suites or web 2.0-ish platforms like Basecamp. Yet they offer plenty of opportunities to handle and enhance common project management activities, especially those that imply communication, coordination and collaboration tasks – the key elements of actual project manager work. Together they can be used in communicating (blog) and documenting (wiki) milestones, capturing (blog) and organizing (wiki) learnings and issues, and much more.

Now these are only some initial starting points, as I don’t want to spoil the actual wiki wednesday experience – but feel invited to add more points and issues for using social software in project management, either here in the comments or over at the wiki wednesday wiki.

Ist die Projektplanung gemeint – das Zuteilen von Ressourcen auf Arbeitspakete, das Arbeit mit Netzplänen und Gantt-Diagrammen, etc. ?

Ist das operative Projektmanagement gemeint – das Steuern, Kontrollieren und Managen von Projektmitarbeitern, von projektexternen Ressourcen, usw. ?

Ist das Projektcontrolling gemeint – das Vergleichen von Plänen mit der Realität, die Vorbereitung von Zahlenmaterial für das Reporting usw.

Und wessen Arbeit soll mit und durch Social Software erleichtert und beschleunigt werden? Ist der Projektleiter die Zielperson, sind Projektmitarbeiter die Zielgruppe, Unternehmen haben zudem in der Regel mehrere Projekte am Start, mithin auch mehrere Projektleiter, mehrere Projektcontroller, einen Hauptprojektleiter (aka Programmmanager o.ä.), usw. – wie kann all diesen Projektbeteiligten mit Social Software geholfen werden?

Und schließlich in welchen Projektphasen soll welcher Nutzen erreicht werden? Geht es mehr um die Projektdefinition, die Initiierung des Projekts, die eigentliche Projektdurchführung oder erwarten wir den eigentlichen Gewinn nach Projektabschluss (und in der Übergabe an Nachfolgeprojekte, dann reden wir mehr über Projektwissensmanagement mit Social Software)?

Diese ersten Differenzierungen sind zudem nicht das Ende der Fahnenstange – Standardisierungsgremien wie das PMI unterscheiden neun Wissensfelder, d.h. wesentliche Teilaspekte des Projektmanagements:

- Project Integration Management (Integrationsmanagement)
- Project Scope Management (Umfangsmanagement)
- Project Time Management (Zeitmanagement)
- Project Cost Management (Kostenmanagement)
- Project Quality Management (Qualitätsmanagement)
- Project Human Resource Management (Personalmanagement)
- Project Communications Management (Kommunikationsmanagement)
- Project Risk Management (Risikomanagement)
- Project Procurement Management (Beschaffungsmanagement)

Ein Ansatzpunkt wäre es nun die Eignung der Social Software (Enterprise 2.0) in diesen verschiedenen Feldern ergebnisoffen und vorurteilsfrei zu prüfen – vielleicht finden sich ja auch Alleskönner, die in vielen Aufgaben, die die Projektarbeit mit sich bringt vernünftig eingesetzt werden können?

Interessant sind hier die “Was wäre wenn-Fragen”, die Oliver Gassner in Reaktion auf den Beitrag von Matthias gestellt hat. Er macht deutlich, dass Social Software viel mehr umfasst als nur Blogs allein. Auch mein Kommentar in Matthias’ Blog zielt darauf, dass singulär und unverbunden eingesetzte Werkzeuge in Unternehmen nie das volle Nutzenpotenzial erreichen können:

“Elemente des “Social Software Werkzeugkastens für das Projektmanagement” gewinnen an Wert wenn sie im (komplementären) Verbund mit anderen Instrumenten eingesetzt werden.”

Auf die meisten dieser Instrumente – u.a. RSS (und Enterprise-RSS-Server), Social Bookmarking, Tagging, Social Networking Plattformen, Foren, u.ä. mehr möchte ich an dieser Stelle gar nicht eingehen. Dies ist nicht notwendig, weil die Standardbasiertheit und Offenheit der Web 2.0-/Enterprise 2.0-Technologien die Ergänzung und Erweiterung leicht macht. Archetypisch sichtbar wird dies bei RSS-Feeds, die mittlerweile als Standardweg der Bereitstellung und Einbindung von Inhalten von verschiedensten Applikationen im Internet genutzt werden.

Näher betrachten möchte ich aber Projektwikis, weil sie flexibel anpassbar sind und dadurch für viele Aufgaben eingesetzt werden können. Meiner Meinung nach sind Wikis gerade für das Projektmanagement ein viel erfolgsversprechenderer Ansatz als Blogs – sie sind die vielgesuchte “eierlegende Wollmilchsau”. Wikis haben vor allem Stärken im Bereich der gemeinschaftlichen (Projektteam-)Bearbeitung von Inhalten, etwas das in Blogs so nicht vorgesehen ist. Diese sind von Haus aus Werkzeuge des individuellen Publizierens, Gruppenfunktionalität (für Projektteams) ist in der Regel eine nachträglich hinzugefügte Erweiterung. Blogs sind aus meiner Sicht “one trick ponys” der Kommunikation – selbst wenn sie mit Tricks zum Eierlegen gebracht werden können.

Projektwikis können bspw. in den Phasen der Projektplanung und -initiierung eingesetzt werden – sie dienen dann der Erstellung von Fachkonzepten, der Erfassung relevanter Parameter und natürlich der Kommunikation (wobei für Projektkommunikation natürlich auch Projekt-, Projektleiter- oder Projektmitarbeiterblogs sinnvoll sein können).

Projektwikis eignen sich auch in den späteren Projektphasen, d.h. für Projektdokumentation und -koordination, während der Projektlaufzeit aber auch für projektüberdauernde Zwecke (von einfacher Ablage von periodisch angefertigten Statusreports bis hin zur Verwaltung ganzer Projektakten).

Und zuletzt: Projektwikis können leicht mit projektübergreifenden Systemen (wie bspw. einem weiteren Wiki zur Ablage von projektübergreifenden Informationen) aber auch mit bestehenden Systemen des Reporting (Business Intelligence, Management Information Systems, FIS, DSS, u.a.) vernetzt und integriert werden. Zwar sind sie keine “high-end”-Reporting Tools, aber sie können dabei helfen einen schnellen zeit- und realitätsnahen Überblick über den Projektstatus (via Projektfortschrittskontrolle durch Statusreports, Meilensteine und Trendanalysen etc.) zu gewinnen.

Was bleibt zusammenfassend zu sagen? Ich denke dass die Diskussion um Einsatzfelder und Unternehmensnutzen extrem wichtig ist – auch um die Werkzeuge die sich rund um Enterprise 2.0 gruppieren weiter ins Bewusstsein von Unternehmensleitungen (und Programmmanagern, CIOs etc. etc.) zu bringen. Und es wird aus meiner Sicht auch deutlich, dass der effektive Einsatz von Enterprise Social Software unabhängige und weitblickende Beratung benötigt. Unternehmen benötigen nicht nur Unterstützung bei der Evaluierung und Auswahl der Werkzeuge und deren Anpassung an betriebliche Erfordernisse, sondern auch bei der Analyse und Auswahl von Einsatzarenen im Unternehmen. Und auch wenn Projektmanagement ein sehr spannender und relevanter Business Case für Enterprise Social Software ist – es gibt noch mehr zu tun …

Das Blog von Siegfried Hirsch beschäftigt sich mit Nutzen und Anwendung der Content Syndication mit Hilfe von WebFeeds und den Formaten RSS, RDF und Atom.

Stichworte aus dem Vortrag, ergänzt um die eine oder andere Ergänzung:

- Vorstellungsrunde der Teilnehmer (interessante Mischung, u.a. auch Fragen nach sicheren RSS-Feeds, Scuttle etc.)

- Information Overload (nicht nur durch unternehmensinterne Email, aber die CC-Unkultur macht hier schon mal viel aus, Email ist für One2One gut geeignet, nicht aber für One2Many)

- Lösungsansatz RSS (verwendbar für Intranet-Portale, Unternehmenswikis, Weblogs, Social Bookmarking etc etc etc)

- RSS kann ja auch wieder aggregiert, gefiltert etc. werden (sieht man bspw. sehr schön in dieser Visualisierung von Fred Cavazza) … bzw. als “Futter” für den Aufbau einer personalisierten Wissens- und Dokumentenbasis verwendet werden (bspw. indem die Inhalte der abonnierten Feeds bei Bloglines dauerhaft gespeichert werden)

- Kurz zur Motivation Portale durch Wikis zu ergänzen (und vielleicht auch manchmal zu ersetzen)

- Stolpersteine beim Einsatz von RSS im Unternehmen (Anforderungen an IT, vergrößerte Sicherheitsrisiken durch RSS-Reader mit “Browsing”-Funktionalität)

Im Mittelpunkt der Probleme: interne Inhalte können nicht ausgeliefert werden – interne Feeds sind (sinnvollerweise) HTTPS und SSL-geschützt (und hinter der Firewall), in der Folge werden interne Reader notwendig, diese haben aber erhebliche Bandbreitebedarfe und benötigen Spezialkompetenzen in der internen IT-Abteilung.

- Lösungsansatz Enterprise-RSS-Server (bspw. Newsgator, Attensa, KnowNow, David R10)

Zentral: Auslieferung von internen Inhalten – sei es Blogs, Wikis, Portale + CMS etc etc., ebenso die Integration von nicht web-tauglichen Quellen (könnten ja bspw. auch Reports aus Business Intelligence Systemen, Datenbank-Abfragen, etc. sein, frogpond)

Daneben auch wichtig: Unterstützung von Zusammenarbeit, zuverlässige Zugriffskontrolle (bspw. durch LDAP), Auswertung von Feeds und Optimierung, Filtern, gesteigerte Sicherheit und geringere IT-Anforderungen.

Diese sehr offene Atmosphäre lag sicher auch an der Herangehensweise, die die Vortragenden wählten: Die Betonung der vielfältigen (Innovations-)Chancen sowie Einsatzpotenziale und -arenen. Einige Eindrücke:

Prof. Dr. Matthes (Technische Universität München) erinnerte an die Idealversion betrieblichen Informations- und Wissensmanagement (das “ideale” Wissensportal im Unternehmen) und machte dann deutlich, wie und wo sich durch Social Software neue Chancen ergeben diese alten Aufgaben und Herausforderungen neu und anders anzugehen.

Tonio Fruehauf (Rohde & Schwarz) betonte die Enterprise Social Software zugrundeliegenden Paradigmen und Prinzipien, die sich aus einem Verständnis von Unternehmen als komplexen Systemen ergeben. Er ging hier insbesondere auf die kulturellen Aspekte von Wikis ein, mithin auch Fragen der Akzeptanz und des Change Managements. Leider war hier die Zeit etwas knapp bemessen, ich bin mir sicher dass nicht nur ich hier gerne mehr erfahren und gehört hätte.

Auch bei Karsten Ehms (Siemens AG) wurde deutlich, dass der Roll-Out von Social Software in Unternehmen zwar einerseits geordnet und koordiniert (und unterstützt durch Coaching und Workshops etc.) ablaufen muss, sich aber gleichzeitig durch die offenen Plattformen eine Arena für konnektives, kollaboratives und adaptives Wissensmanagement mit vielen Freiheitsgraden ergibt. U.a. ist hier ein positives Menschen- und Mitarbeiterbild vorteilhaft, gerade wenn weitverbreitete und tiefsitzende Mythen und Vorurteile gegenüber Social Software bestehen.

Klaus Wriessnegger (SAP Inspire) behandelte dann inbesondere die Chancen von Social Software für das Innovationsmanagement, insbesondere um dieses zu beschleunigen bzw. produktiver zu machen. Weil er SAP von Anfang an erlebt hat konnte er zum einen einen sehr lebhaften Rückblick auf SAP als junges, schnell wachsendes Unternehmen (mit “Water Cooler Collaboration” und -Wissensmanagement) geben, zum anderen auf die verschiedenen Ansätze und Ideen um dann später “virtuelle Kaffeeecken” bei SAP einzurichten. Interessant sind u.a. das interne Social Bookmarking Projekt bzw. auch die SAP-interne Social Networking Plattform Harmony …

Here we go, first up there’s this Web 2.0 in a Chart by the Sunlight Foundation, connecting a lot of trends related with web 2.0 (real big pdf, hence there’s no useful thumbnail).

Then, there’s FirstPartner’s take on the Enterprise 2.0 market. I appreciate how it tries to integrate and employ value-chain thinking, but I am skeptical if it’s really useful. Anyway, it’s a cute effort, found via SocialComputing Magazine:

Welcome to the FirstPartner Enterprise 2.0 Market Map. Enterprise 2.0 is a term which many struggle to define and understand. We have therefore developed this market map to articulate the different attributes of this emerging sector.

and

[This shows] the flow from the end-customer through the complete value-chain – covering blogs, wikis, collaboration tools, social networking and bookmarking through to RSS readers and Open APIs/Mashups.

An Enterprise 2.0-sided take on visualization comes by Stephen Danelutti, who proposed an Enterprise 2.0 meme map (building upon the well known O’Reilly web 2.0 meme map).

This I must say is my last favourite, as it mingles and mixes terms and concepts and lacks clear structure (but that is true for the O’Reilly meme map and others as well).

And finally, my favourite, is by Ross Dawson of the Future Exploration Network who proposed a Web 2.0 framework, that nicely captures what Web 2.0 is all about and collects the variety of players in the Web 2.0 ecosystem:

This framework provides a concise view of the nature of Web 2.0. While one can debate whether all important issues are collected, this visual approach lends itself to kicking off discussions (where one can elaborate further on). It provides a nice starting and reference point, and this is essential: When advising on the ideas and concepts of Enterprise 2.0 in the corporate world, I’m experiencing that it’s best to explain both instruments (methods and tools, i.e. the “how”) and goals and visions (paradigms and principles, the “why”) intertwined …

[...] unveiling a team collaboration product, social computing software and a suite of tools for building Web mashups.

As part of a new “Web 2.0 Goes to Work” initiative, the IBM tools will bring popular consumer Web 2.0 technologies like blogs, wikis and social networks to the enterprise, [...] The new software should help companies more easily brainstorm and collaborate with partners and customers about business content

[...] Lotus Quickr 8 team collaboration tool helps companies use blogs, wikis and team space templates to share business documents and access libraries through plug-ins [...]

[...] IBM today also announced that Lotus Connections is now available.

The Connections tool includes Web 2.0 components like bookmarking and support for social communities

[...] In addition, IBM introduced Info 2.0, a new suite of tools for customizing and linking Web and enterprise data into mashups

While one might argue that this portfolio of tools and suites is too complex and thus distracting, I think that it’s more or less a reflection of the impossibility to design “solutions” with “one true architecture”. What’s needed is a toolbox whose contents can be flexibly combined and adapted. IBM’s efforts are no “out of the box solution” anyway, which is basically good news for consultants in the social software space – remember it’s not about technologies or tools, it’s about organizations and people.