Notes from the trenches …

Andrew McAfee makes a case for prediction markets, citing James Surowiecki:

“[…] the most mystifying thing about [prediction] markets is how little interest corporate America has shown in them. Corporate strategy is all about collecting information from many different sources, evaluating the probabilities of potential outcomes, and making decisions in the face of an uncertain future. These are tasks for which [prediction] markets are tailor-made. Yet companies have remained, for the most part, indifferent to this source of potentially excellent information, and have been surprisingly unwilling to improve their decision making by tapping into the collective wisdom of their employees.”

Janet compiles Enterprise RSS Day of Action posts, pointing out Scott Niesen who calls for altering the conversation about RSS:

Like most new technology companies we had a vision of how RSS could be used behind the firewall and we wanted feedback to see if we were on target. In the early days we started these conversations by focusing on the technology. These conversations didn’t get very far. The inside joke was that we were starting the conversations by asking, “How many pounds of RSS would you like to buy today?” You live and learn. Now we start the conversation talking about communication and collaboration challenges. The conversations last longer and are far more meaningful.

Naming is important, so I like this “Communication & Collaboration Delivery” instead of Enterprise RSS.

And there’s an interesting chart on Enterprise 2.0 adoption here at Read-Write Web (“Enterprise 2.0 To Become a $4.6 Billion Industry By 2013“), citing a report by Forrester Research:

web 2.0 adoption

Yes, it’s sad to see that small and medium-sized businesses don’t see the opportunities. Way to go for social software consultants – more explaining, teaching and coaching – customized to this “long tail” of businesses – is needed. Still, the problem of “getting past the IT gatekeepers” is mostly a problem of big enterprises, which have other upsides still:

Enterprises are keen in adopting web 2.0 principles in both external and internal aspects. Knowledge Management is being replaced with web 2.0 collaboration and social networking applications. The executives understand the need, but knowledge of web 2.0 and how to implement is still missing. They are opting for less risky web 2.0 pilot applications instead of realigning their business strategy with web 2.0. But I am sure success of pilot applications will lead to bigger initiatives. It is just a matter of time and confidence.

Well, there’s nothing wrong with doing pilots first, funding a small team and bringing in external consultants like me to get up to speed quickly. Don’t spend hours pondering the details and splitting hairs – actually use this stuff and find out.

And finally, when shall the next Wiki Wednesday Stuttgart be? My favourite date is July 9th, between the European Football Championships and summer holidays in Baden-Württemberg.

The power of networks and pragmatic adoption

Please take note of my post at bmid on Clay Shirky‘s new book (“Here Comes Everybody: The Power of Organising without Organisations“) as it also explains nicely why it makes sense to think about social software uses in the enterprise: When technology becomes “boring”, i.e. taken for granted, it has the chance to move into the mainstream of people caring more for business problems and efficient solutions than for tech in itself. Now’s the time for pragmatic minded enterprise 2.0 consultants, rosy times ahead, obviously.

Simplicity, adoption and WYSIWYG editors

I was having several conversations at re:publica on wiki adoption (and consulting) topics. Over time, we (that is Andreas Gohr, Christian Kreutz, Tim Bartel, me and sometimes innocent bystanders and fellow twitterati) covered wiki technology, design and a wide array of social software adoption issues. One of the central topics was the question of WYSIWYG editors and their relevance for wiki adoption.

This was triggered by this blog post of Tim Wang (which I found via Tim Schlotfeld), that referred to a short wiki comparison, culminating in this:

Regardless, lack of a WYSIWYG editor continues to scare off most users and therefore wikis lacking one should be eliminated from contention.

This unsettled me, and while I am hearing this argument again and again, I think that this line of reasoning misses some important points. It’s not only about leaving out many able and well-kept wiki engines by restricting evaluation to those with a WYSIWYG editor, and it’s not only about an obvious lack of real research with real users (sure, wiki syntax scares off people and Wikipedia is a miserable failure) – it’s about a fundamental misunderstanding of both efficient knowledge work and user interfaces. While WYSIWYG is supposed to offer clarity, simplicity and easy adoption I hold that this is exactly what wiki markup is good for.

– Wiki markup editing and its restricted user interface makes it easier to focus on content, much like the “dark mode” some people choose for real editing – basically because WYSIWYG editors distract attention.

– We want employees to focus on content, edit it quickly and use the wiki (and the intranet) in an efficient way – we don’t want our employees to fiddle with nice looking but irrelevant eye candy or with overblown full-featured editors like this:

– Antoine de Saint-Exupery, author of The Little Prince, once said, “Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away.” Simplicity doesn’t equal low functionality, and is more important than comprehensiveness (and complexity). Smart web applications need to employ intuitive ways of interaction. Just look at these different user interfaces (by Eric Burke), showcasing common but different approaches to user interface design:

– People with relevant knowledge in the organization (yes, we’re talking about the “empty quarter“, often these are people close to retiring) need simple and clean user interfaces. User interface design ideas like usability, simplicity and clarity suit these people.

– WYSIWYG editors aren’t perfect yet – if  you’re just trying to format text you’ll be OK, but for more advanced stuff like tables etc. you need wiki markup editing anyway. Going the WYSIWYG way is risky too – think of initial user acceptance, that will  suffer when people get disappointed by their efforts at wiki editing. Yes, even when it looks like MS Word it ain’t the same, and becoming frustrated because the wiki obviously scrambles the nice looking word document you just copy-pasted makes for a really bad start. Granted, you can coach and explain this to your users, but then – why not teach them simple markup rules in the first place. Combine this with an explanation why dragging a picture into Word works but won’t (for now) work with a web-based application.

– Advanced users are going to use wiki markup language anyway, beginning wiki users may start with WYSIWYG but will learn soon that the other way is more efficient. When they have grasped a few simple techniques, such as putting ** around a text to make it bold or putting [[ ]] around text to create links, they can create great looking content with minimal fuss, and the look and feel of the wiki pages is consistent throughout the wiki. Providing the choice between both ways, allowing for quick changes between both modes of editing, is one solution. And yes, it’s no big wonder that both Confluence and Socialtext are offering both alternatives in parallel, simple and advanced (yes, that one’s wiki markup mode). Try both modes at the Socialtext WikiWednesdayStuttgart page. So the argument that adoption hinges on the existence of a WYSIWYG editor is flawed – wiki markup can be easily explained and adding some coaching efforts to an implementation project doesn’t hurt, explaining the rationale behind wiki usage etc. I have had decent successes with 15 minute short introductions, followed by “train the (peer) trainer” coachings, after all editing wiki markup editing is neither programming nor rocket science.

– What wiki users really need are standardized wiki markups (like wikicreole). This would make it both easier to export/import content between different wiki engines (and document processors like Word), and to write powerful and easy-to-use WYSIWYG editors. Until then we need to rethink some of our assumptions – especially about what end-users want and need. I see that people want to do their job easily and efficiently and that user interface information overload is a problem. So wiki markup is a solution, not a problem.

Enterprise 2.0 Keynote @ re:publica

Peter Schütt von IBM gibt nun einen Überblick über Motivationen und Herausforderungen die sich im Kontext von Web 2.0 im Unternehmen ergeben. Schön – das Thema ist offensichtlich auch für die anderen Besuchern der re:publica interessant – der große Saal ist fast so gut gefüllt wie bei der Blogger vs. Journalisten Debatte geradeeben. Im Anschluss wird es einen zweistündigen Workshop zur Vertiefung geben.

Weitere Themen:
– Erfahrungen der IBM mit der Transformation zum Unternehmen 2.0 (u.a. Lernschritte und Akzeptanz der Mitarbeiter)
– Unterschiede zwischen großen und kleinen Unternehmen bei der Herangehensweise an Web 2.0 (klar, sie betreten Neuland, die Frage ist welche Schrittfolge und -größe gewählt wird). Die Daten entstammen einer aktuellen Studie des IBM Institute of Business Value
– Web 2.0 allgemein (Long Tail, …) und die Auswirkungen auf die Produktivität und Motivation von Wissensarbeitern
– Schnelligkeit von digitalem Content (durch Schütt mehr auf die Geschäftsmodelle gemünzt, kann aber auch intern interpretiert werden). Schütt leitet denn auch hin zu “digitaler Reputation” & “social sharing”, das interne Teilen und Arbeiten von Content
– Social Networks im Unternehmen als Plattform für Wissensarbeiter und damit zusammenhängend:
– Crowdsourcing und das Nutzen von externen Ideen im Rahmen von Open Innovation, aber auch der persönlichen Netzwerke der Mitarbeiter (mit kleinen Anklängen an die Potenziale von Social Network Analysis im Unternehmen)
– Flexibilität von Geschäftsmodellen und Informationssystemen durch Enterprise 2.0 erhöhen (u.a. mit Nennung von Mashups, Widgets in personalisierbaren Portalen, …)
– Arenen für Social Software im Unternehmen – passt schon, die Idee “schnelle, kollaborative Innovation zu fördern” ist schon sinnvoll. Problematisch ist mehr, dass die IBM Studie hier offensichtlich massive Defizite bei KMU festgestellt hat.

Insgesamt viel “Richtiges und Wahres” im Vortrag, aber eben auch recht generell und damit leider “nicht viel neues bei IBM (und unter der Sonne)” für mich. Jetzt bin ich auf die Diskussionen im Workshop gespannt, die kleinere Runde ist da sicher vorteilhaft.

Projektmanagement mit Social Software @ WikiWednesdayStuttgart

Der vierte WikiWednesdayStuttgart war ein rundum gelungener – weil arbeitsintensiver und dennoch atmosphärisch lockerer Nachmittag (und Abend), allen Teilnehmern und Mitwirkenden ein herzliches Dankeschön (Fotos bei Kai).

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.

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):

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, …

Wikipatterns videos, and more wiki multimedia stuff …

OK, I have to admit it – I failed. While I wanted to add Stewart’s videos on wiki adoption onto this site as soon as he put them up, add some of my own thoughts and elaborate on this stuff, I missed the easy opportunities of blog fodder miserably …

Perhaps it may appease you that I’ve been able to do some very cool client projects instead, visited cool conferences and Barcamp-alike events, presented and evangelized wiki stuff and more …

Anyway, as a follow-up I guess it’s my duty to link to the stuff you missed out, so here you go, there you’ll find all of Stewarts videos, he’s covering a wide range of wiki adoption issues and potential usage arenas.

Today, and with reference to tomorrow’s WikiWednesdayStuttgart I will only embed one video – on project management with wikis:

And if you’re looking for the other wiki multimedia stuff, there’s another post in a minute or so.

Wie Blogs und Wikis (@IBM) die Arbeitswelt verändern

Leider nur noch im kostenpflichtigen Archiv der SZ, dieser Artikel zu den Veränderungen innerhalb der IBM durch Social Software: “Im freien Fluss: Wie Blogs und Wiki die Arbeitswelt verändern“. Damals gelesen und gebookmarked, und daran anlässslich der CeBIT erinnert …

Noch gibt es kaum Unternehmen, die Web 2.0 Technologien so intensiv für den internen Informationsaustausch ausnutzen wie IBM. Dass Big Blue als Anbieter von Software für unternehmensinterne Kommunikationsprozesse auf die Technologie setzt, ist aber nur ein Grund für die starke Nutzung von Web 2.0-Technologien. Das Unternehmen wurde im Jahr 2005 vom Management massiv umgebaut und global ausgerichtet. Die dezentrale Vernetzung wurde dadurch Teil der Firmenstrategie. Viele andere Firmen sind zentralistischer organisiert und tun sich schwer damit, die Kontrolle über die internen Kommunikationsprozese aufzugeben.

Nun ja, rückblickend auf die CeBIT hat IBM meiner Meinung nach das Thema “Kollaboration” dieses Mal etwas verschenkt – zumindest wenn man das Engagement der benachbarten DNUG als Maßstab sieht. Ein, zwei kleinere Angebote am Rand des riesigen Messestands, das war es. Vielleicht auch ganz gut so – schließlich hatte ich so Gelegenheit zu einem ausgiebigen Austausch mit den IBM-/Lotus-Beratern rund um Sametime, Quickr und Connections, und speziell zu deren Erfahrungen in Bezug auf Akzeptanz und Einführungspfade in der IBM. Auch intern sicher kein Selbstläufer, wobei durchaus von wachsendem Engagement berichtet wurde.