Open Loops

Die Schaffung von Projektstrukturen erfolgt stets in Abhängigkeit von der Größe der zu lösenden Herausforderung. In Großprojekten sind z.B. Lenkungskreis, Expertenkreis, Teilprojektleiter, Projektmanagementoffice, Programmmanagement, Soundingboard etc. mögliche Strukturierungselemente, die hilfreich sein können. Die Strukturierung dient der Bewältigung der vorhandenen Komplexität. Unabhängig von der Strukturierung hat die Projektleitung jedoch immer einen Engpass: die am Tag (Nacht) zur Verfügung stehende Zeit.

Mit der Schaffung der Struktur wird in der Regel der Teil der Kommunikation von der Projektleitung abgedeckt, die nach oben geht (Auftraggeber, wichtige Personen im Umfeld etc.) sowie die unmittelbare Kommunikation mit den Teilprojektleitern. Dies ist auf der einen Seite der gewünschte Zustand, um nicht mit “allen” sprechen zu müssen. Auf der anderen Seite ist es aber notwendig, als Projektleiter zu jedem beliebigen Zeitpunkt eine klare Beschreibung der Lage/Situation des Projektes liefern zu können. Üblicherweise geschieht dies auf Basis der aggregierten Berichte der Teilprojektleiter. Der Projektleiter selbst fasst die Berichte zusammen und berichtet sie den entsprechenden Stellen.

Dieses Vorgehen stellt die Handlungsfähigkeit der Projektleitung sicher, jedoch habe ich festgestellt, dass schnell eine Art “Elfenbeinturmeffekt” entsteht. Die Beschreibungen der Lage des Projektes basieren fast ausschließlich auf den vereinbarten Kommunikationskanälen. Selbst mit sehr sorgfältig durchgeführten Stakeholder und Umfeldanalysen treffe ich immer eine Unterscheidung was system-/projektrelevant ist und was nicht. Eine Möglichkeit diesen Effekt abzuschwächen ist die Planung des Nicht-Planbaren, d.h. ich organisiere mir Zeit, um mit Menschen aus dem Projekt und auch mit Menschen außerhalb des Projektes in Kontakt zu kommen. Dabei handelt es sich nicht um fixe Termine, sondern um mehr oder weniger zufällige Begegnungen, die ich während meines “Rundgangs” treffe. Meine Erfahrung ist, dass die auf diese Weise gesammelten Informationen einen guten Beitrag zur Beschreibung der Projektsituation liefern und damit zum Projekterfolg beitragen. Nicht selten sind es sogar gerade diese Informationen, die sich anbahnende Schieflagen oder unterschwellige Konflikte ans Licht bringen.

Der Begriff “Eskalation” ist häufig negativ besetzt: Man verbindet damit gewöhnlich das (unnötige) Ausufern eines Konfliktes oder eines Problemes, ohne dass damit eine Lösung in Sicht gerät. Immer wieder wird in Projekten auch mit einer Eskalation gedroht, um den Druck zu erhöhen. Diese negative Konnotation von “Eskalation” ist sehr schade, denn richtig angewandt können Eskalationen dazu beitragen, Probleme dort zu lösen, wo sie entstehen. Ich verwende bei Kunden daher gern den Begriff der Konstruktiven Eskalation als Lösung für die im Folgenden beschriebenen Situationen.

In Projekten treten fast zwangsläufig Probleme auf. “Gutartige” Probleme lassen sich in der Regel innerhalb des Projektumfeldes und damit im Wirkungsbereich des Projektleiters lösen. Es gibt jedoch immer wieder auch Probleme, die ihre eigentliche Ursache außerhalb des Projektkontextes haben, das Projekt aber extrem stören können. Solche Probleme lassen sich daher meist nicht alleine durch den Projektleiter lösen. Wenn z.B. ein Mitarbeiter der Fachabteilung nicht im zugesagten Umfang zur Verfügung steht, hat dies massive Auswirkungen auf den Fortschritt der Konzeption oder Umsetzung. Mangels disziplinarischer Macht kann der Projektleiter den Mitarbeiter in der Fachabteilung in der Regel aber nicht zu mehr Mitarbeit zwingen. Meistens möchte derjenige ja auch gerne am Projekt mitwirken, kann dies aber nicht im gewünschten Maße, da er nicht von anderen Aufgaben entbunden wird. Ein solches Problem kann nicht vom Projektleiter allein gelöst werden. Er kann aber mittels einer konstruktiven Eskalation eine Lösung des Problems bei den Verantwortlichen einfordern. Konkret sollte wie folgt vorgegangen werden:

Die eigentlichen Ursachen des Problems sind zu analysieren und zu prüfen, ob diese im Projektkontext gelöst werden können. Ist dies nicht der Fall, muss der potentielle Adressat einer Eskalation ermittelt werden: Durch wen außerhalb des Projektes kann das Problem gelöst werden? Ohne einen Adressaten oder mit einem falschen Adressaten besteht die Gefahr, dass die gewünschte Entscheidung nicht getroffen wird, weil der Angesprochene dazu schlicht nicht befugt ist. Ist der Adressat ermittelt, gilt es Lösungsszenarien aufzuzeigen. Im obigen Beispiel könnte dies sein, den Mitarbeiter der Fachabteilung von anderen Aufgaben zu entbinden oder dem Projekt einen anderen Ansprechpartner zuzuordnen. Die Szenarien sind dann mit Vor- und Nachteilen in Hinblick auf das Projekt und - soweit möglich - auf sonstige Betroffene anzureichern. Es sollten immer mindestens zwei mögliche Lösungen ermittelt werden. Zu viele Optionen wiederum führen aber ebenfalls nicht zu einer schnelleren Lösung. Anhand der Vor- und Nachteile sollte auch immer eine aus Sicht des Projektes präferierte Lösung benannt werden. Zur Aufbereitung eines Szenarios gehört auch das Aufzeigen der Konsequenzen für das Projekt. Dies gilt auch für den Fall, dass keine Lösung des Problems zustande kommt.

Mit den bewerteten Szenarien kann dann von den Verantwortlichen eine Entscheidung eingefordert werden. Dies kann im Rahmen eines Steuerungsgremiums geschehen oder auch unabhängig davon. Die Verantwortung für die Lösung liegt durch die konstruktive Eskalation wieder dort, wo auch die Ursache des Problems zu finden ist: außerhalb des Projekts. Es gilt hierbei natürlich, auch eine solchermaßen konstruktiv durchgeführte Eskalation nicht als Standardweg zur Problemlösung zu verwenden. Es besteht ansonsten die Gefahr, dass die Eskalationen nicht mehr Ernst genommen werden und sich im Ernstfall wichtige Entscheidungen nicht mehr herbeiführen lassen.

Wenn eine Aufgabenstellung nicht durch einen einzelnen Fachexperten zu bewältigen ist, macht man ein Projekt.
Werden für die Aufgabenstellung mehrere Fachexperten mit unterschiedlichen Fähigkeiten gebraucht, so wird eine Struktur benötigt, die die Voraussetzungen schafft, das angestrebte Ziel zu erreichen. Hierbei kann man zwischen harten und weichen Strukturen unterscheiden.

Die harte Struktur beinhaltet Organisation, verbindliche Ziele, Planung, Termine, Raum, Zeit, Budget, Kommunikationswege, Berichtsstrukturen, Regeln, etc.

Die weichen Strukturen arbeiten mit Beschreibungen von rückkoppelnden Systemen, d.h. in der Kommunikation zwischen Menschen entstehen Beschreibungen, die auf sich selbst zurückwirken. Der Sender beschreibt ein Problem, der Empfänger interpretiert die Information und gibt dem Sender seine Interpretation zurück. Durch diese Rückkopplung verändert sich die Beschreibung. Mit der gezielten Beeinflussung der Beschreibung werden neue Strukturen möglich.

Die Schaffung dieser Strukturen ist Aufgabe des Projektleiters. Häufig wird der Schwerpunkt des Projektleiters jedoch gerade nicht in der Schaffung der Projektstrukturen gesehen, sondern in einem inhaltlichem Vorantreiben. Die inhaltliche Fokussierung kann für den Projektleiter für die Anschlussfähigkeit an die Fachexperten sehr hilfreich sein - sie ist aber keineswegs der einzige (und mithin wichtigste) Aspekt.

In letzter Zeit werde ich immer öfter gefragt, ob ich denn schon dieses oder jenes Scrum-Tool kennen würde. Natürlich ist mir das ein oder andere Tool bekannt, und einige halte ich auch für sehr nützlich. Ich rate allerdings dazu, den Einsatz eines solchen Tools genau zu prüfen.

Scrum-Tools dienen üblicherweise der digitalen Verwaltung des Product Backlogs. Außerdem bieten sie ein Taskboard an und generieren daraus automatisch ein Sprint Burndown Chart. Eigentlich ganz nützlich, oder? Man muss keine Task-Karten mehr schreiben und auch das lästige manuelle Aktualisieren des Sprint Burndown Charts entfällt. Echt praktisch! Allerdings hat diese Automatisierung aus meiner Sicht einen gravierenden Nachteil. Um sich den aktuellen Status des Sprints ansehen zu können, muss man explizit im Tool nachsehen. Meiner Erfahrung nach passiert genau das häufig nicht. In der Folge weiß das Team oft nicht, wie es um den aktuellen Sprint bestellt ist. Darüber hinaus ist mir aufgefallen, dass sich niemand mehr für den Fortschritt im aktuellen Sprint interessiert, sobald das Sprint Burndown Chart automatisch berechnet wird.

Ganz anders ist es bei Verwendung eines Whiteboards als Taskboard, wenn dieses für alle sichtbar und anfassbar im Teamraum hängt. Jedes Teammitglied hat ständig vor Augen, wie es um den aktuellen Sprint steht. Die manuelle Aktualisierung von Taskboard und Sprint Burndown Chart ist tägliche Aufgabe des Teams im Daily Scrum-Meeting. Der aktuelle Status des Sprints wird dadurch tief im Bewusstsein des Teams verankert und das Team auf diese Weise ständig an sein Commitment erinnert.

Meine Empfehlung ist der Einsatz eines Taskboards zum Anfassen in Form eines Whiteboards. Bei einem räumlich verteilten Team hat man allerdings oft keine andere Wahl als ein Tool einzusetzen.

Wie stehen Sie zur Verwendung von Scrum-Tools?

Heute möchte ich mal einen Tooltipp in der Kategorie Enterprise 2.0 / Kommunikation abgeben: Yammer. Yammer ist ein unternehmensinterner Microblogging Dienst à la Twitter (wer Twitter noch nicht kennt, hier ein schöner Onepager vom brandeins). Nach kostenloser Anmeldung können Nachrichten verfasst werden, die nur von dem geschlossenen Kreis gelesen werden können. Dieser geschlossene Kreis wird durch die Unternehmensdomain definiert. Nur wer eine aktive Adresse für die Domain hat, kann dem Netzwerk beitreten.

So weit so gut, aber wozu das Ganze? Brauchen wir wirklich ein weiteres Tool, ein weiteres Kommunikationsmedium? Das war die anfängliche Skepsis, die auch bei uns nicht fernblieb. Aber aus Skepsis wurde schon bald Begeisterung. Wir yammern seit Mai diesen Jahres, wobei Yammer sich mittlerweile sehr gut etabliert hat und die interne Kommunikation per E-mail hervorragend ergänzt. Gerade in unserer Tätigkeit als Berater vor Ort beim Kunden hilft es mit den kurzen updates, uns gegenseitig unkompliziert auf dem Laufenden zu halten.

Wir nutzen Yammer hauptsächlich für:

• Empfehlungen auf hilfreiche Fachartikel
• Fragen zu konkreten Problemstellungen
• Statusmeldungen über wichtige Ereignisse

Das schöne an dem Dienst ist, dass man Dinge eher teilt als mit einer Mail, da ein Tweet schneller und unkomplizierter geschrieben wird als eine Mail. Der interne Informationsfluss hat sich so nachweislich verbessert.

Und obendrein ist der Dienst

• mobil nutzbar
• als Firefox Plugin als auch Desktop Programm (via Air) nutzbar
• in Twitter integriert (per Hashtag kann ein Twitter Tweet auch “geyammert” werden)
• nicht auf 140 Zeichen beschränkt und bietet die Möglichkeit Dateien anzuhängen

Die Erkenntnisse aus dem Umgang mit Yammer werden nun natürlich auch in unseren Projektmanagementalltag einfließen. Dazu demnächst mehr.

Kennen Sie den Dienst oder nutzen Sie ihn vielleicht bereits? Haben Sie Erfahrungen gemacht, die Sie teilen möchten?