Was bringt agil? – hier zeigen wir, dass Agilität einen positiven Effekt auf die so wichtige Teamentwicklung in Projekten hat. Basis für diese Aussage ist einer Untersuchung von 190 Softwareentwicklungsprojekten, welche ich im Rahmen meiner Diplomarbeit, in Zusammenarbeit mit Eberhard Huber durchgeführt habe.

Von der Gruppe zum Team

Menschen, die in einem Projekt zusammen arbeiten, bilden zwar immer eine Gruppe, aber nicht zwangsläufig auch ein Team. Warum diese Unterscheidung?

Am Anfang eines Projektes erfolgt zunächst die Zusammenstellung eine Projektgruppe. Um von einer Gruppe oder auch von „echter“ Gruppenarbeit zu sprechen, gibt es z. B. folgende Bedingungen:

• Die Gruppe muss aus mindestens 3 Personen bestehen, hat einen gemeinsamen Arbeitsauftrag und verfolgt dementsprechend ein gemeinsames Ziel.
• Die Zusammenarbeit erstreckt sich über einen längeren Zeitraum. Dies ist unerlässlich, damit sich soziale Strukturen entwickeln können.
• Das Gruppenklima ist  zu Beginn durch ein (schwaches) Wir-Gefühl geprägt.

Diese sehr allgemein gehaltenen Gruppenmerkmale sagen aber noch nichts über die Leistungsfähigkeit der Gruppe aus. Auch wenn beispielsweise ein schwaches Wir-Gefühl vorhanden ist, besteht trotzdem die Möglichkeit, dass die Gruppenarbeit sehr ineffizient ist, da sich z.B. nicht alle Gruppenmitglieder aktiv an der Zusammenarbeit beteiligen oder auch eigene persönliche Ziele verfolgen. Ein Team dagegen zeichnet sich durch folgende Faktoren aus: harmonische Zusammenarbeit, stark ausgeprägtes Wir-Gefühl (Teamspirit), eine gemeinsame Vision (die persönlichen Ziele werden dem Primärziel untergeordnet), gegenseitige Motivation und Unterstützung, Fähigkeit zur Selbstorganisation und gemeinsame Problemlösungen. Ein Team ist in der Lage, ohne explizite Anweisungen, Entscheidungen im Sinne des Projektzieles zu treffen und das vor allem auch in Krisensituationen. Francis/Young definieren den Teambegriff wie folgt:

„Ein Team ist eine aktive Gruppe von Menschen, die sich auf ein gemeinsames Ziel verpflichtet haben, harmonisch zusammenarbeiten, Freude an der Arbeit haben und hervorragende Leistungen bringen.“

Die Teammerkmale sind aber nicht einfach so vorhanden, sondern entwickeln sich erst im Laufe der Zusammenarbeit. Im besten Fall entwickelt sich eine Gruppe, im Zuge eines sogenannten Teamentwicklungsprozesses, zu einem echten Hochleistungsteam.

Gibt es aber einen messbaren Zusammenhang zwischen der Teamentwicklung, den daraus resultierenden Teammerkmalen und dem Projekterfolg? Die durchgeführte Untersuchung von 190 Softwareentwicklungsprojekten im Rahmen einer Online-Umfrage zeigt, dass die Erfolgsquote von Teams fünfmal höher als die von Gruppen mit schlecht-ausgeprägten Teammerkmalen ist.

Erfolgsquote von Gruppen und Teams – Berechnung Mittelwert der abgefragten Teammerkmale

Um einen Zusammenhang zwischen der Teamqualität (Ausprägung der Teammerkmale) und dem Projekterfolg zu ermitteln, wurden insgesamt 16 ausgewählte Teammerkmale erhoben, mit denen sich die Qualität des Projektteams feststellen lässt. Eine starke Ausprägung dieser Teammerkmale ist ein Indikator dafür, dass sich die Projektgruppe konstruktiv zu einem Team entwickelt hat – hierzu wurde jeweils für die erfolgreichen, eingeschränkt erfolgreichen und nicht erfolgreichen Projekte ein Mittelwert der einzelnen Teammerkmale ermittelt. Projekte mit stark ausgeprägten Teammerkmalen werden im grünen Bereich, schlecht funktionierende Gruppen im roten Bereich, des Netzdiagramms repräsentiert.

Ausprägung Teammerkmale – Projekterfolg

Die zentrale Aussage ist: Erfolgreiche Projekte zeichnen sich offensichtlich durch gute Teams aus. Hier stellt sich jetzt nun die Frage, was zuerst da war – der Projekterfolg oder die ausgeprägten Teammerkmale? In Hinblick auf Projekterfolg und Teamqualität lauten die möglichen Antworten wie folgt:

• Eine konstruktive Teamentwicklung lässt aus einer Gruppe ein echtes Hochleistungsteam entstehen und ermöglicht somit den Projekterfolg.
• Die Teamentwicklung im Verlaufe des Projektes wird durch den sich anbahnenden Projekterfolg befördert

Die Antwort ist also „sowohl als auch“ – die  gegenseitige Wechselwirkung der Teamentwicklung mit dem sich anbahnenden Projekterfolg ist sicher vorhanden – trotzdem lässt sich folgendes Zwischenfazit formulieren:

Die Ergebnisse der Umfrage zeigen, dass die Erfolgsaussichten eines Projekts mit einem Team höher sind als mit einer schlecht funktionierenden Gruppe.

Was hat das aber nun mit agilen Vorgehensweisen zu tun?

Agile Methoden und Praktiken fokussieren unter anderem den einzelnen Projektmitarbeiter, das Teams als solches und schließlich den Teamentwicklungsprozess. Beispielsweise fördert die Anwendung von Retrospektiven den Lessons Learned Prozess während des Projektes und auch den Mut, Änderungen am Prozess voran zu treiben. Durch tägliche Treffen (z.B. Stand-Up-Meetings oder Daily Scrum Meetings) wird die Möglichkeit zur direkten Kommunikation und zum Informationsaustausch geschaffen.

Die Umfrage-Teilnehmer sollten aufgrund ihrer Erfahrungen einschätzen, inwieweit (agile) Praktiken ausgewählte Teammerkmale beeinflusst hatten. Zusammenfassend kann festgehalten werden: Alle sieben untersuchten Praktiken wurden in Bezug auf deren Einfluss auf die Teammerkmale überwiegend als förderlich eingestuft. Die Praktiken wirken dementsprechend positiv auf den Teamentwicklungsprozess und somit indirekt auf den Projekterfolg.

Einfluss Praktiken und Teammerkmale (Grüne Hervorhebung wenn mehr als 80% der Probanden die Praktik als förderlich eingestuft haben)

Fazit

Nicht jede Gruppe ist auch gleichzeitig ein Team und ein Team ist keine Selbstverständlichkeit sondern vielmehr ein Resultat von „teamorientierten“ Projektmanagement. Hierbei können die agilen Praktiken unterstützen, indem diese auf den Teamentwicklungsprozess und den daraus resultierenden Teammerkmale (Teamqualität) förderlich wirken. Insbesondere bei Teamgrößen von vier bis acht Personen scheint die Teamqualität ein entscheidender Erfolgsfaktor zu sein.

Bei weiterem Interesse bzgl. der Teamentwicklung: ein umfangreicherer Ergebnisbericht findet sich in der Fachzeitschrift OBJEKTspektrum,(Online-Artikel: Teamwork: Warum Projektteams erfolgreicher sind als Projektgruppen)

Projektmanagement mit Web 2.0
In den letzten Jahren hat das Thema Web 2.0 auch für das Projektmanagement zunehmend an Bedeutung, gewonnen. Da es zum konkreten Einsatz von Web 2.0-Anwendungen im Projektmanagement noch wenige wissenschaftliche Arbeiten gab, habe ich mich in den letzten Monaten mit diesem Thema auseinander gesetzt.

Hier eine kurze Zusammenfassung der Ergebnisse der Diplomarbeit. Es wurde dabei von Studierenden der Projektmanagement Lehrgänge der FH BFI Wien, der Alpen-Adria-Universität Klagenfurt und der Fachhochschule Vorarlberg sowie von Mitgliedern der GPM Deutsche Gesellschaft für Projektmanagement e.V. insgesamt 41 Fragen zum Einsatz von Online-Projektmanagement-Tools beantwortet.

Nach der Meinung der Studienteilnehmer liegt der Schlüssel zum erfolgreichen Einsatz von Web 2.0-Anwendungen im Projektmanagement darin, Kontrolle abzugeben und einen Spagat zwischen Hierachie und Anarchie zu finden. Anhand der Umfrageergebnisse lässt sich schließen, dass Web 2.0-Anwendungen hauptsächlich sehr spezifisch eingesetzt werden und sich sehr gut für den Einsatz in Projekten mit geringer Personenanzahl sowie geringer Dauer eignen.
Die Rückmeldungen von Personen aus Großunternehmen mit mehr als 1.000 Beschäftigten ergaben, dass der Einsatz von Web 2.0- Anwendungen in großen Unternehmen bisher hauptsächlich an Unternehmensrichtlinien scheitert und es dort wesentlich schwieriger ist, die nötige Akzeptanz zu erreichen. In großen Unternehmen ist oft bereits eine zentrale Plattform wie Sharepoint im Einsatz, die den Eintritt von neuen Technologien mit dem Hinweis auf bestehende Lösungen erschwert.

Im Projektmanagement geht es darum eine Vielzahl unterschiedlichster Teilleistungen in einer extrem verteilten Wertschöpfungskette zu koordinieren. Das hat sich auch in den Ergebnissen der Frage nach der Zielsetzung für den Einsatz von Online-Projektmanagement-Anwendungen widergespiegelt. Es wurden dabei  Verbesserung von Projektplanung, Projektkontrolle, Kommunikation und Dokumentation als Hauptziele angegeben. Der Einsatz von Web-2.0 Anwendungen erlaubt eine weitreichende Integration aller Projektteilnehmerinnen und Projektteilnehmer und vereinfacht die Abläufe der bisherigen Projektsteuerung. In bereits 45 % der befragten Unternehmen werden Web 2.0- Anwendungen für das Projektmanagement verwendet und die Antwort von 63 % der befragten Personen, dass damit die Projektarbeit schneller und effizienter erledigt werden kann, lässt den Schluss zu, dass mit Web 2.0-Anwendungen Arbeitsabläufe noch effizienter und die Dienstleistungen dadurch in weiterer Folge zu einem günstigen Preis angeboten werden können. Auf dieser Basis werden Kundenzufriedenheit und Wettbewerbsfähigkeit von Unternehmen erhalten bzw. verstärkt.

Der wirtschaftliche Nutzen von Web 2.0 im Projektmanagement liegt für Unternehmen in der der Flexibilisierung der Kommunikation und der Projektprozesse. Serviceorientierte Architekturen sind in Unternehmen auf dem Vormarsch, Web 2.0-Anwendungen bieten die Schnittstellen (RSS/XML), um die Informationen und Services dieser serviceorientierten Architekturen zu nutzen und mit dem Wissen der Mitarbeiterinnen und Mitarbeiter zu integrieren, zum Nutzen und Wohle des Projekts und des Unternehmens.

Thomas Gruber

Die ganze Arbeit kann bei Amazon mit der ISBN: 3640360184 bestellt werden.

Die Grundrinzipien und Leitlinen sind schnell umrissen (siehe auch  hier) und mit gesundem Menschenverstand gut nachzuvollziehen:

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiaion
• Responding to Change over Following and Plan

Verglichen mit klassischem Projektmanagement mit vorab abgestimmten Scope, Zeit und Geld gibt es also den entscheidenen Vorteil, dass sich ändernde oder unausgesprochene (vielleicht auch unaussprechbare) Anforderungen einbezogen und beachtet werden können. Eigentlich ja schön, für Kunden wie auch für den Hersteller.  Doch im praktischen Einsatz scheint das gar nicht so einfach zu sein:

• Kann Agilität bei der Vertragsbeziehung von zwei Partnern funktionieren, die sich gar nicht kennen? Ist nicht eine Vertrauensbeziehung notwendig, um den sich aendernden Scope eines Projektes mit allen Konsequenzen gegenseitig zu akzeptieren?
• Funktioniert agiles Projektmanagement in Ausschreibungsprojekten, wo ich aufgrund eines definierten Kriterienkatalogs (defined scope) eine Zeit- und Kostenschätzuung abgegeben habe?
• Wenn die Projektleistung “NUR” ein Konzept oder eine Studie ist, wie komme ich zu Projektergebnissen, wenn doch die Anforderungen sich sehr dynamisch aendern und wandeln?
• Welche menschlichen / persönlichen Eigenschaften muss ich von den Teammitgliedern fordern, um in einer agilen Umgebung abrechenbare und wertvolle Ergebnisse zu erzielen? Kann das jeder?
• Agiles Vorgehen heisst nicht nur in kurzen Intervallen zeigbare  Ergebnisse zu produzieren, sondern auch diese Ergebnisse schnell zu bewerten und freizugeben – ein Umstand der viele Kunden scheinbar überfordert, denn der allgemeine Kommunikationsaufwand steigt und es müssen kurzfristig, schnell Entscheidungen getroffen werden.

Doch werfen wir auch auf die Vertragssituation einen Blick mit gesundem Menschenverstand: Wenn es noch keine klaren Vorstellung über gewünschte Features und Scope gibt, dann ist doch ein Festpreisvertrag immer problematisch, egal ob agil oder per Wasserfall vorgegangen wird. Im agilen Vorgehen wird nur viel eher transparent, wenn es viele ungeklärte Punkte gibt. Ähnlich können die meisten anderen Bedenken bei genauerem Hinsehen zum grossen Teil entkräftet werden. Also keine keine Ausreden mehr: “Bei uns funktioniert das so nicht!”. Wie schon in Teil 3 unserer Wissensmanagement Präsentation angesprochen: Kultur (Agilität) ist ein Ziel, keine Vorraussetzung.

Agiles Projektmanagement und agile Softwareentwicklung bleiben ein spannnendes Thema und noch viele Fragen zum Praxiseinsatz sind offen. Auch im naechsten Meeting unserer lokalen PMI Gruppe steht das Thema auf der Agenda und die zahlreichen Anmeldungen bisher versprechen auch hier eine interessante Diskussion.

Anhand der Diskussion im Blog lässt sich sehr schnell erkennen, dass eine ROI-Betrachtung für Web 2.0 Tools eher schwierig ist. Das folgende Bild zeigt das sehr schön:

Unsere Recherchen haben ergeben, dass es an vielen Stellen solche Diskussionen zum Thema ROI und Web 2.0 gibt. Hier mal einige Beispiel dazu:

• Forrester Creates a Model to Measure Blogging ROI
• Is It Worth It? An ROI Calculator for Social Network Campaigns
• The FASTForward-Blog: ROI, ROI, ROI
• Wikis as alternatives to email – find the ROI
• Radiowalker – Enterprise 2.0 ROI
• …

Dieser Eindruck lässt vermuten, dass eine solche Rechnung nur exemplarisch und nicht allgemeingültig gemacht werden kann. Diese vereinfachten Rechnungen haben meist nur eine geschränkte Sicht auf die Welt und lassen Umweltfaktoren und Rahmenbedingungen oft außer Acht. Social Software kommt vor allem dort zum Einsatz, wo es keine standardisierten Abläufe und Prozesse gibt. Zum Beispiel in der Zusammenarbeit und Kollaboration von (verteilten) Teams. Daher ist eine ROI-Betrachtung schwierig. Wer will schon ausrechnen können um wie viel effektiver die Kommunikation im Team durch den Einsatz von Social Software geworden ist.

Sicherlich lässt sich aus Umfragen und Erfahrungsberichten ermitteln, inwiefern Projekte durch Social Software schneller und besser durchgeführt werden können. Dieses Bild würde dann aber auf subjektiven Aussagen beruhen (was ab einer bestimmten Anzahl von Leuten wieder relativiert werden kann).

Und mal ehrlich. Kommt es bei Investitionskosten im Unternehmen von 8.000 US$ für ein Enterprise Wiki oder sogar null US$ einer Open Source Lösung wirklich auf den ROI an? Klar kann man jetzt sagen, dass entsprechende Projektkosten für die Einführung, Anpassung und Erweiterung entstehen. Da macht es aus unserer Sicht extrem viel Sinn einen “Perpetual Beta” Ansatz zu fahren, der uns die Möglichkeit gibt Social Software Tools schnell an den Start zu bringen, Erfahrungen zu sammeln und das Tool erst dann gezielt weiterzuentwickeln. Somit ist ein Unternehmen nicht gezwungen Unsummen am Anfang eines Projektes in die Hand zu nehmen, um eine Gesamt- und Endlösung zu erstellen.

Um entscheidende Effekte durch den Einsatz von Social Software im Projektmanagement aber auch im gesamten Unternehmen zu erzielen bedarf es einiger Veränderungen. Der erfolgreiche Einsatz von Social Software bedarf, aus unserer Sicht, neue Arbeitsweisen (im Umgang mit Social Tools), Veränderung in der Organisation (z.B. Berichts- und Abstimmungswege) und die Ausrichtung der Kultur (Schaffung einer Kultur der Offenheit). Erst wenn diese Faktoren gegeben sind, kann sich ein Nutzen (noch nicht in Zahlen ausdrückbar) bemerkbar machen.

Wie Frank in seinem Blog-Eintrag “Projektmanagement 2.0 – Ansätze für eine Definition” darstellt, sind Effekte durch den Einsatz von Social Software in den folgenden Punkten zu sehen:

• Zusammenarbeit und Organisation von Projektteams
• Inhaltliche Abstimmung innerhalb aber auch zwischen Teams
• Ständige Transparenz über den aktuellen Projektstatus

Schlussfolgerung: Social Software richtig eingesetzt (z.B. in Projekten) kann zu nachhaltigen Nutzeneffekten führen. Wichtige Voraussetzung dafür sind Rahmenbedingungen wie Arbeitsweise, Organisation und Kultur.

Vielleicht gibt es aber doch jemanden, der dieses Konzept bereits erfolgreich einsetzt und Aussagen zu Kosteneinsparungen machen kann.

Ich finde diese Sichtweise ein bisschen zu einfach. Der Beitrag von Prof. Kruse zu Selbstorganisation macht deutlich, wie komplex und herausfordernd eine Selbstorganisierende Struktur ist. Eines der wenigen Elemente, das hier ordnend eingreifen kann, ist ein Plan, eine von allen geteilte Vision, wie das Ergebnis der Zusammenarbeit aussehen sollte. Ich habe dazu im Buch “Die Kunst des IT-Projektmanagements” von Scott Berkum ein schönes Zitat im Kapitel “Bewegliche Ziele treffen” gefunden. Es stammt zwar aus dem militärischen Bereich, verdeutlicht aber ein sehr innovatives Verständnis von Plänen:

“Nun, meiner Meinung nach funktionieren Schlachten nie nach Plan. Er ist nur eine allgemeine Grundlage für Änderungen. Es ist sehr wichtig, dass jeder den Plan kennen sollte, damit sie ihn leicht ändern können…moderne Kämpfe sind sehr fließend, und Sie müssen Ihre Entscheidungen sehr schnell treffen – und meist nicht bezüglich des Plans. Aber wenigstens weiß jeder, wo Sie herkommen und wohin Sie gehen wollen – mehr oder weniger. ” (Dan Laner, israelischer Generalmajor)

Für netzwerkartige Organisationen mit keiner oder wenig zentraler Koordination, wird ein übergreifender Plan damit sogar noch wichtiger als er in klassischen Projekt- oder Organisationsstrukturen ist. Diese Planung ist high level. Die einzelnen Akteure brauchen natürlich ihren Gestaltungsspielraum – und hier ist der Ansatz “Bottom-up” auch das Mittel der Wahl. Wer aber “2.0″ mit “jeder plant für sich” verwechselt, wird im Chaos enden.

“Selbstorganisation ist die höchste Stufe der Professionalität des Lernens und nicht die Naivität in Reinkultur.”

Die Frage ist, wie gross ist der Rahmen, den der einzelne füllen kann ( oder muss). Prof. Kruse spricht in seinem Beitrag vor allem über Organisationen – für Projekte (vor allem für kleinere Teilprojektteams) dürfte es leichter sein, selbsorganisierende Strukturen zu etablieren und erfolgreich zu leben.

[Im Feed kann dieses Video nicht angezeigt werden.Klicke zum Blogeintrag um das Video anzusehen.]

“Im Informationszeitalter ist es für einen Manager die grösste Herausforderung, ein Unternehmen zu schaffen, in dem Wissen geteilt wird. Mit Netzwerken ist dies möglich, da sie Menschen mit anderen Menschen oder mit Daten verbinden. Dank der Netzwerke können wir Informationen, die früher den Weg von einer Instanz zur nächsthöheren und von dort wieder nach unten nehmen mussten, direkt untereinander austauschen. Dieser Austausch zerschlägt den bürokratischen Apparat. Bill Raduchel, EDV-Direktor von Sun Microsystems, meint dazu: “E-Mails sind ein bedeutendes kulturelles Ereignis – sie verändern die Organisationsstruktur eines Unternehmens.” Zum einen untergraben Netzwerke unwiederuflich die Autorität des Management; Sie regen einen informellen Führungsstil an: Das typische Chef-Gehabe, zu dem Vorgesetzte neigen, paßt ganz und gar nicht dazu. Menschen, die über ein elektronisches Netzwerk miteinander kommunizieren, sind ihren Vorgesetzten gegenüber weniger ehrerbietig und sagen ihnen auch schon mal die Meinung. “

Wir machen trotzdem den Versuch, uns einer anderen, neuen Art des Projektmanagements etwas neutraler zu nähern. Das hat auch damit zu tun, dass spannende Neuerungen nicht nur durch soziale Software in die Projekte kommen, sondern auch agile Methoden wie Scrum mehr und mehr Beachtung und Anwendung finden. Die folgenden Punkte sind denn auch ein erster Schritt, beide Themen in den selben Rahmen zu stellen.

Was ist ein Projekt?

Eine Aufgabe, die in einer bestimmten Zeit von einer Anzahl Menschen erledigt werden soll. Soweit so gut. Wie immer, wenn viele Menschen gemeinsam auf ein Ziel hinarbeiten sollen, gibt es ein Problem: Die Aktivitäten der einzelnen Handelnden müssen aufeinander abgestimmt – koordiniert – werden. Die bekannteste und bislang erfolgreichst Methode, um die Koordination zu bewerkstelligen ist…

…die Hierarchie!

“Eine Hierarchie ist eine klar von oben nach unten gegliederte, straff in verschiedene Ebenen unterteilte Herrschafts – oder Organisationsstruktur. Als Muster einer Hierarchie kann die Pyramide angesehen werden.” (http://de.wikipedia.org/wiki/Hierarchie)

Die Hierarchie hat keinen guten Ruf. Sie gilt als veraltet, unflexibel und statisch. Sie war und ist aber sehr erfolgreich, wenn es darum geht, viele Menschen zu koordinieren, die in begrenzter Zeit grosses vollbringen sollen. Hierarchien haben sich seit Jahrhunderten sowohl in Organisationen (Kirche, Millitär, Konzerne) als auch in Projekten bewährt.

Hierarchie im Projekt

Die meisten Projekte sind hierarchisch organisiert. Es gibt einen Projektleiter, Teilprojektleiter, eventuell Teamleads und Teammitarbeiter. Egal wie gross oder komplex ein Projekt am Ende ist – man wird in den meisten Fällen die Organisation auf dieses Grundmuster zurückführen können.

Die Koordination in Hierarchien erfolgt vor allem durch die Definition von Aufgaben (”Du baust diese Mauer”) durch einen Vorgesetzen und die Erledigung dieser Aufgaben durch den Untergebenen. Der Vorgesetzte kontrolliert das Verhalten (war immer da, sah beschäftigt aus) und die Ergebnisse (die Mauer steht und hält). Die Motivation des Mitarbeiters ist in diesem Fall nur von mittlerer Bedeutung, da seine Arbeit sehr gut von seinem Vorgesetzen eingeschätzt und kontrolliert werden kann. Wenn nur die halbe Mauer fertig ist, oder am Ende nicht stabil ist, kann dies sofort klar zugeordnet werden.

Die meisten Projekte, die wir heute erleben sind viel komplexer. Diese Komplexität erfordert Spezialisten aus vielen Bereichen, die gemeinsam an einer Aufgabe arbeiten. Das hat im Gegensatz zum obigen Beispiel 2 wichtige Konsequenzen:

1. Der Vorgesetzte wird in vielen Fällen nicht mehr in der Lage sein, die Erfüllung einer Aufgabe zu bewerten, da dies sehr spezielle Kenntnisse erfordern würde.
2. Er kann überhaupt keine Aufgaben mehr stellen, denn er weiss nicht, WIE etwas getan werden muss. Er kann nur noch sagen WAS das Ziel ist. Die Motivation des einzelnen Mitarbeiters spielt hier natürlich ein viel grössere Rolle, denn die Möglichkeit seine Arbeit kontinuierlich von aussen zu messen und kontrollieren ist sehr begrenzt. Natürlich kann überprüft werden, ob das Ziel erreicht wurde, aber gute Ziele lassen sich meist nur auf hohem Niveau definieren (”eine Website mit der wir mehr Umsatz machen”) – wenn das dann kontrolliert werden kann ist es meist zu spät für Korrekturen.

Hier ist das klassische Verständnis von Hierarchien in Projekten am Ende. Ausgeprägte Hierarchien und hierarchische Verhaltensweisen in Projekten mit komplexen Inhalten erzeugen unmotivierte Mitarbeiter, Frust und wenig Kreativität. Dazu kommt der personelle und finanzielle Aufwand für die Koordination und die langen Kommunikationswege und großer Abstimmungsaufwand.

Projektmanagement 2.0

Die Kernfrage ist: Wie kann eine bessere Koordination ohne Hierarchien erreicht werden? Als Hilfe zur Beantwortung noch eine Frage: Was leistet ein Vorgesetzter in einer Hierarchie (z.B. ein Teamleiter) für die Koordination? Antwort: Die zwei Grundlegenden Aufgaben eines Teamleiters für ein Team sind: 1. Aufgabenzuordnung / Motivation / Kontrolle des Teams und 2. Abstimmung mit anderen Teams und dem Auftraggeber/Projektleiter. Eine alternative Vorgehensweise müsste also diese beiden Punkte adressieren und so lösen, dass ein besseres Gesamtergebnis möglich wird.

Wir definieren Projektmanagement 2.0 durch 3 grundsätzliche Merkmale:

1. Ausgeprägte Selbstorganisation der (Teil)Projektteams
2. Transparenz der Zwischenergebnisse
3. Inhaltliche Abstimmung dezentralisiert

Selbstorganisation adressiert die erste Aufgabe ( Aufgabenzuordnung / Motivation / Kontrolle). Transparenz der Zwischenergebnisse adressiert beide Aufgaben. Inhaltliche Abstimmung dezentralisiert adressiert die zweite Aufgabe (Abstimmung mit anderen Teams).

Ein gutes Beispiel, das die Punkte 1 und 2 sehr gut umsetzt ist die agile Projektmanagement Methode Scrum. Soziale Software kann vor allem bei den Punkten 2 und 3 unterstützen.

1. Selbstorganisation

Was sind die Merkmale von Selbstorganisation?

• kleine Teams (5-9 Personen)
• keine festgelegte Rollenverteilung innerhalb des Teams
• Selbsteinschätzung der zu leistenden Arbeit für einen bestimmten Zeitraum
• Team organisiert sich selbst, um die geplanten Aufgaben zu erfüllen
• gegenseitige Unterstützung im Team bei der Erfüllung der Aufgaben
• keine Führung des Teams im Sinne einer Projektleitung; das Team ist selbst in der Lage Konflikte und Probleme zu lösen
• Autorität für Entscheidungen liegen im Team selbst
• jedes Teammitglied weißt entsprechende methodische und soziale Kompetenzen auf

Was sind die Vorteile von Selbstorganisation?

• Mitarbeiter sind motivierter, das sie ein besseres Verständnis für das Ziel und ihren Beitrag entwickeln können
• Komplexität in großen Projekten wird handhabbar
• keine ständige Abstimmung/Reporting mit/an Projektleitung
• mehr Transparenz in der Aufgabenerfüllung während eines bestimmten Zeitraumes
• nahe und direkte Führung innerhalb des Teams; jedes Teammitglied fühlt sich verstanden und beachtet

Allem zugrunde liegt ein verändertes Rollenverständnis der Beteiligten. Die Mitarbeit haben mehr Verantwortung, können dafür Entscheidungen aber autonom treffen. Die Rolle des Projektmanager verändert sich von einem Vorgesetzten zum Coach, der reflektiert, berät, informiert und Hindernisse aus dem Weg räumt.

Rollendefinition PM-Leiter in der Selbstorganisation

• PM-Leiter hat koordinierende Funktion auf High-Level Ebene
• greift bei Konflikten ein
• stellt sicher, dass die Teams in der Lage sind zu arbeiten
• …

2. Transparenz der Zwischenergebnisse

Ein transparentes Zwischenergebnis ist fassbar, leicht begreifbar und erspart dem Betrachter unnötige Details. Es sollte immer eine Antwort oder im Bezug auf die ursprüngliche Kundenanforderung sein und so eine klare Aussage ermöglichen, wie der Stand im Projekt ist. Ein solches Zwischenergebnis hat 3 Zielgruppen:

1. Das Team selbst. Das Team wird durch dieses Zwischenergebnis gezwungen, Bilanz zu ziehen und kommt so immer wieder zu den Tatsachen und dem tatsächlich Stand im Projekt zurück. Das Zwischenergebnis hilft auch – z.B. als Prototyp  – die formulierten Ideen und Konzepte in Aktion zu sehen und daraus wertvolle Erkenntnisse zu erlangen.
2. Die übergeordnete Instanz (Projektleiter, Kunde, Stakeholder) kann den tatsächlichen Fertigstellungsgrad überprüfen und bei Bedarf korrigierend eingreifen.
3. Andere Teams, denen das Zwischenergebnis hilft, Abhängigkeiten zu erkennen und entsprechend zu reagieren.

Das Zwischenergebnis wird im Vorfeld klar als Ziel formuliert. Teams sollten nicht zu lange ohne Zwischenergebnisse arbeiten – dies hätte negative Auswirkungen auf alle 3 Zielgruppen.

3. Inhaltliche Abstimmung dezentralisiert

• Vermeidung von aufwändigen Kommunikationswegen (häufige Abstimmungsmeetings, E-Mail Verkehr)
• Vereinfachung der Kommunikation durch Automatisierung (intelligenter RSS-Feed, einheitliche Online-Arbeitsumgebung, offene Berechtigungsstrukturen -> Wiki)
• Verlagerung von lokalen (Word, Excel, PowerPoint) auf online (Wiki, Blog, RSS) Anwendungen -> kollaborative Arbeitsumgebung (alles wird auf einer Online-Plattform gemacht)
• Schaffung von Flexibilität durch Standards -> “Das Tool ist der Standard” (eine einheitliche kollaborative Arbeitsumgebung schafft Flexibilität für die Kommunikation und den Austausch innerhalb und zwischen den Projektteams)
• Informelle Netzwerke zwischen den einzelnen Teams

Wir werden in den nächsten Posts konkrete Szenarien aufzeigen, wie soziale Software klassische Projektaufgaben unterstützen und verbessern kann.

Herausforderungen bei der Umsetzung

Es ist offensichtlich, dass die oben gemachten Punkte wirklich einschneidende Veränderungen für die Abwicklung von Projekten zur Folge hat – die folgende Liste ist denn auch eher ein kleiner Anfang:

• Nicht jedes Projekt eignet sich gleich gut für eine agile Vorgehensweise
• Kulturelle und methodische Veränderungen
• Verteilte Teams
• Nicht jeder will volle Transparenz – dazu gehört Mut zur Wahrheit
• Standardisierung von Tools – jeder hat seine Lieblingstools und wird diese nur ungern hergeben
• Schaffung und Etablierung einer Online-Arbeitsumgebung (Wiki, Blog, RSS)
• Automatisierung von Informationsflüssen (Informationen erhalten Attribute, intelligenter RSS-Feed) -> die richtigen Informationen (Nutzen für den Leser) müssen zur richtigen Zeit (Aktualität) am richtigen Ort (Person) sein

Jeder der sich mit einem neuen Thema (für ihn oder sie neu) beschäftigt, wird früher oder später den Weg zu Wikipedia finden. Die Suche in Wikipedia war also auch unsere erste Anlaufstelle. Dort existiert seit Februar 2008 ein Artikel zum Thema. Zudem ist auf der Seite eine Definition zu finden

„Project Management 2.0 (social project management) is the natural evolution of project management practices brought by Web 2.0 technologies.“

und eine Gegenüberstellung zwischen traditionellem Projektmanagement und Projektmanagement 2.0. Dazu gibt es einen kleinen Abschnitt, der Kritik übt. Inhalt dieser Kritik ist, dass Projektmanagement 2.0 nur ein neues Buzz-Word ist und nicht wirklich Neues darstellt.

Die Linkreferenzen in Wikipedia verweisen auf weitere spannende Seiten. Der erste Link in Wikipedia zeigt auf ein Blog von Wrike, der den Einsatz von Enterprise 2.0 im Projektmanagement analysiert. Wrike ist ein Anbieter der gleichnamigen Projektmanagement-Software. Verfolgt man den zweiten Link, gelangt man zu einer Präsentation von Leisa Reichelt, die einen Überblick über „Social Project Management“ gibt. Wir haben diese Präsentation bereits im vorherigen Artikel gepostet. Der dritte Link verweist auf die Seite von allpm.com, die den Einsatz eines Projekt-Wikis darstellen und ebenfalls einen Vergleich von traditionellem und 2.0 Projektmanagement aufzeigen. Ein weitere Link führt zu der Seite von Project Management Planet, die sich ebenfalls an einer Definition versuchen und das in einem recht ausführlichen Artikel näher betrachten. Dieser Artikel ist mal wieder gesponsert durch einen Toolanbieter (Daptiv). Anscheinend versuchen einige über entsprechende Blogs und Internetseiten ihre Tools in diesem Gebiet zu positionieren.

Weitet man seine Recherche über die Grenzen von Wikipedia aus, dann stößt man auf die Internetseite von Simprove, die sich als die Erfinder der „Social Project Management“ Methode bezeichnen. Dahinter steht mal wieder ein Tool namens Worktiy. Simprove hat dazu auch schon eine Präsentation veröffentlicht. Einen weiteren spannenden Einblick zum „Einfluss des Web2.0 auf das Informations- und Projektmanagement in Unternehmen und Verwaltungen“ zeigt der Vortrag von Sonja Hierl und Prof. Dr. Josef Herget, der neben einer Einführung in Web 2.0 auch die aktuellen Trends und Herausforderungen im Projektmanagement und die Vorteile der Nutzung von Web 2.0 Anwendungen aufzeigt.

Als Letztes soll hier der Blog von Gantthead erwähnt sein, der aber nicht wirklich mehr zum Thema beiträgt. Neben diesen Quellen, ist es zu heutigem Zeitpunkt, recht schwierig mehr zum Thema Projektmanagement 2.0 zu finden. Als Fazit könnte man sagen, dass sich viele an einer Definition von Projektmanagement 2.0 versuchen, es aber dafür noch keine einheitliche Variante gibt

Wir würden uns freuen, wenn uns weitere Hinweise dazu per Kommentar oder E-Mail zukommen.