Intranet.days 2008: Muss es immer gleich Web 2.0 sein?

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

Wiki – Gegenargumente und Gegengegenargumente

KoopTech hat eine Liste von Wiki-Gegenargumenten vorgestellt. Nicht alles davon ist stichhaltig. Manche Punkte benötigen schon einer Relativierung – oder auch direktem Widerspruch. Aber ich will nicht überkritisch sein, denn Kooptech hat ja auch 10 Gründe für den Wiki-Einsatz gefunden.

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

  1. einen Überblick über bewährte Vorgehensweisen und
  2. 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.

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

Exploring social software use for project management

As I am pondering the program for the next Wiki Wednesday Stuttgart with the special topic of “project management and social software” I thought it’s a good idea to collect some ideas and observations in advance.

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

projektportalSo 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.

Einsatzmöglichkeiten von Projektwikis (und eierlegende One-Trick Ponys)

Matthias Schwenk hat hier Überlegungen angestellt wie (und wieviel in Bezug auf Amortisation, ROI etc.) Weblogs im Projektmanagement sinnvoll sein können. Ich möchte seinen Artikel und die Kommentare als Ausgangspunkt nutzen um die generellen Einsatzpotenziale von Enterprise Social Software im Projektmanagement zu diskutieren. Klar ist dass diese nicht in einem einzigen Blogpost abgedeckt werden können, sondern eigentlich mehrere Artikel und Perspektiven notwendig wären. Denn über was sprechen wir eigentlich wenn wir von “Projektmanagement” reden:

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 …

Barcamp München Tag 2

OK, es geht weiter. Die erste Session verspricht interessant zu werden – Siegfried Hirsch wird zu Enterprise RSS (wo einsetzen, welche Inhalte, …) sprechen:

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)

Enterprise 2.0

– 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.

IEEE Web Collaboration – Lessons Learned

Hier einige meiner Gedanken zum IEEE Web Collaboration Workshop am Freitag in München: Für mich waren insbesondere die Erfahrungen aus den jeweiligen Unternehmen und Einführungsprojekten von Interesse. Damit meine ich nicht nur die Vorträge an sich, sondern auch die Gespräche in den Pausen, die in sehr angenehmer Atmosphäre stattfanden. Ein Grund dafür war sicher, dass viele der Teilnehmer das Thema offen angehen und daher auch neugierig auf Neues waren. So standen denn auch in den Gesprächen an denen ich teilnahm eher die Chancen und Potenziale denn die üblichen Befürchtungen und Sorgen im Vordergrund.

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 …