Projektkommunikation – Chris' IT Guide to The Galaxy

Podcast von Bernd Geropp über erfolgreiche Projektführung

CJeske — Thu, 07 Aug 2014 15:44:19 +0000

Bernd Geropp hat in seiner Podcastreihe „Führung auf den Punkt gebracht“ eine Folge zum Thema Projektmanagement veröffentlicht.

Als regelmäßiger Zuhörer seines Podcasts kann ich diesen nur empfehlen und diese Folge mit einem Interview mit Stefan Hagen ganz besonders.

FPG058 – Projekte erfolgreich managen und führen! Bei welchen Projekten sind agile Ansätze sinnvoll? Interview mit Stefan Hagen

Agiles Projektmanagement mit Erfolg einsetzen (02) – Kundenanforderungen

CJeske — Sat, 31 Aug 2013 09:49:13 +0000

Der Kunde weiß aus seiner Erfahrung, wie unwahrscheinlich es ist, dass das Team ein System liefert, das den Kundenwünschen entspricht. Das Team hat wiederum die Erfahrung gemacht, dass der Kunde nicht weiß, was er will, und in dem Moment, in dem das Team glaubt, die Kundenwünsche zu kennen, seine Meinung erneut ändert.[…]

– Ken Schwaber: Agiles Projektmanagement mit Scrum. Washington 2007, S. 56 –

Mit meinem ersten Beitrag zum agilen Projektmanagement bin ich mittendrin eingestiegen, ohne jedoch den ersten Schritt anzugeben: Aber am Anfang eines Projektes steht immer die Kundenanforderung. Das obere Zitat von Ken Schwaber, der mit Jeff Sutherland zusammen Scrum entwickelte, trifft oft die Problematik der Anfangssituation.

Aber wie kommt es dazu?

In den meisten Softwarefirmen wird das Wasserfall-Modell oder das V-Modell eingesetzt. Sie beschreiben einen Fluss von mehreren Punkten. Meistens Analyse- und Definition, Entwurf, Implementierung und Test. Nach jedem Punkt wird den Stakeholdern, also allen am Projekt Interessierten, die Ergebnisse präsentiert und überprüft, ob sich das Projekt in die richtige Richtung bewegt. Je tiefer im Projekt oder „Wasserfall“, desto schwerer oder kostenintensiver ist es, frühere unbeachtete Fehler zu korrigieren. Die Vorstellung, man fällt wirklich einen Wasserfall herunter zeigt deutlich: Es ist unmöglich wieder hoch zu schwimmen. Es sei denn, man bestelle einen Kran, der einen wieder hochzieht. Somit ist auch der Kunde daran interessiert, spät entdeckte Fehler oder Fehlinterpretationen zu ignorieren, damit seine Projektkosten nicht explodieren. Das Ergebnis ist ein Produkt, welches nur zum Teil oder im schlimmsten Fall gar nicht den Kundenanforderungen entspricht. Die Bezeichnung Wasserfall Modell passt somit wie die Faust aufs Auge. Viele Projekte ertrinken unterwegs.

Aber was macht Agiles Projektmanagement besser und wo liegen seine Vorteile? Es beruft sich auf kurze Iterationen und Inspektionszyklen. Am Anfang steht bei Scrum eine Kundenvision. Sie enthält den erwarteten ROI, die Releases und Meilensteine. Daraus entwickelt der Kunde zusammen mit dem Product Owner den sogenannten Product Backlog mit allen sich abzeichnenden Anforderungen. Das Team wählt nun aus diesem Product Backlog in dem sogenannten Sprint Planning Meeting Funktionen aus, welche sie innerhalb des nächsten Sprints (30 Tage) zu einem demonstrierbaren Prototyp entwickeln können. Mit diesem Sprint Backlog fängt das Team an zu entwickeln und überprüft alle 24 Stunden im Daily Scrum den Fortschritt. Am Ende jedes Sprints können der Product Owner und die Stakeholder das Projekt im Sprint Review Meeting anpassen.

Der Unterschied ist enorm. Dadurch, dass der Kunde alle 30 Tage Funktionen sieht, kann er Wünsche und Korrekturen kostengünstig äußern und umsetzten. Er sieht, was möglich ist und bekommt genau das, was er wünscht. Durch diese persönliche Einbindung des Kunden wird das Projekt qualitativ hochwertiger und der Softwareentwicklungsprozess schneller. Die Kundenvision, welche am Anfang stand, kann der Kunde durch Sehen des Machbaren immer neu ausrichten und diese folglich von Sprint zu Sprint immer realer erscheinen lassen.

Durch diese einfachen Methoden der kurzen Iteration kann man dem Fluch der Lasten- und Pflichtenhefte entkommen und den Kunden und das Entwicklungsteam wieder näher zusammenbringen.

Das Problempotenzial wird drastisch verringert und beide Seiten können Missverständnisse schneller korrigieren. Dadurch sind alle Beteiligten positiver gestimmt und bekommen ein zufriedenstellendes Ergebnis.

Agiles Projektmanagement mit Erfolg einsetzten (01) – Meetings

CJeske — Mon, 17 Jun 2013 09:01:16 +0000

Seit je her bin ich im Projektgeschäft tätig. Schon in meiner Ausbildung habe ich individuelle Lösungen für Kunden programmiert, wobei Kundenorientierung immer im Vordergrund stand. Frühzeitig habe ich erkannt, dass Pflichten- oder Lastenhefte Vor- und Nachteile haben. Wenn ich zurückblicke sind die besseren Projekte durch klar definierte Ziele aus Anwendersicht geprägt worden und kamen ohne solche Anforderungslisten aus. Mit diesem ersten Beitrag möchte ich eine Serie starten, mit der ich meine Erfahrungen mit agiler Softwareentwicklung und agilem Projektmanagement berichte.

Mit agilem Projektmanagement können Projekte rapide und effizient zum Erfolg geführt werden. Schnelles Feedback und kurze Entwicklungszyklen fördern deutlich die Qualität und bewahren vor Fehlentwicklung. Leider gibt es auch viele Stolpersteine, wodurch die anfänglichen Ziele weit verfehlt werden können.

Ein großes Problem in der Softwareentwicklung ist das „Vorbeiprogrammieren am Kunden“. Ziele müssen klar aus Anwendungssicht formuliert sein. Ist das endgültige Produkt falsch beschrieben, können nachträgliche Änderungen ziemlich teuer werden.

Richtig eingesetzt kann agiles Projektmanagement verhindern, dass ein Produkt entwickelt wird, welches den Anforderungen der Benutzer nur zum Teil oder gar nicht entspricht. Eine essentielle Voraussetzung besteht in der stetigen Kommunikation zwischen allen Projektbetroffenen. Durch wöchentliche Meetings mit den Stakeholdern (Interessenten) und täglichen Meetings des Projektteams kann ein effizientes Exceptionmanagement (Abweichungsmanagement) aufgebaut werden. In der Praxis können so schwammig definierte Projektpunkte konkretisiert und schnell korrigiert werden, falls die Entwicklung sich in die falsche Richtung bewegt.

Allerdings stellen genau diese Meetings gleichzeitig die ersten Stolpersteine dar und dies in mehreren Aspekten.

Aspekt 1: Die Meetings müssen zeitlich begrenzt sein. Sie dürfen nicht zu lange dauern. Die täglichen Meetings sollten sich an einem Zeitfenster zwischen fünf und zehn Minuten halten und die wöchentlichen Meeting nicht über eine Stunde hinausgehen. Zu schnell wird sonst dazu geneigt, Themen zu zerreden und das Projekt unnötig in die Länge zu ziehen. Natürlich sollten bestimmte Problemstellungen zwischen den Verantwortlichen länger besprochen werden. Es ist stets bei den Meetings zu beachten, das es um das weitere Vorgehen im Projekt als Ganzes geht und Teilaufgaben nur als „in Arbeit“, „nicht gestartet“ oder „fertig gestellt“ besprochen werden mit der Angabe, wann noch offene Punkte abgearbeitet sein sollen. Dadurch haben alle Teammitglieder eine Übersicht über den Projektfortschritt.

Das wöchentliche Meeting hat zum Ziel den Stakeholdern eine Übersicht über die schon fertig gestellten Projektschritte zu geben und wie man im geplanten Zeitrahmen steht. Fragen, die beantwortet werden sollten, sind zum Beispiel: „Bewegt sich das Projekt in die richtige Richtung?“, „Werden in den schon fertig gestellten Teilaufgaben alle definierten Punkte richtig umgesetzt?“ oder „Befindet sich das Projekt im vereinbarten Zeit- und Kostenrahmen?“. Bei Meilensteinen sollte das Produkt auch immer zumindest als Prototyp mit den definierten Punkten präsentiert werden. Dadurch haben die Stakeholder auch konkrete Berührungspunkte zum Projekt und Missverständnisse können schneller erkannt und geklärt werden. Hier sollten auch Änderungen von Projektpunkten besprochen werden.

Die Umsetzung dieses Konzeptes mit Beachtung seiner einzelnen Aspekte erfordert ein hohes Maß an Disziplin. Helfen können genaue Rollenverteilungen. Beim Einsatz des Scrum-Vorgehensmodells für agiles Projektmanagement von Jeff Sutherland und Ken Schwaber werden zum Beispiel sechs verschiedene Rollen verteilt. Dabei ist der Scrum-Master für die korrekte Einhaltung der Prozesse zuständig. (Die anderen Rollen: Entwicklungsteam, Product Owner Management, Customer und User werde ich in weiteren Einträgen dieser Serie genauer erklären)

Durch ein erfolgreiches agiles Projektmanagement kann ein Produkt schnell, kostengünstig und qualitativ hochwertig fertig gestellt werden. Jedoch erfordert dies die Disziplin aller Beteiligten und das Umdenken weg vom klassischen Pflicht- und Lastenheft, hin zu einer klar aus Anwendungssicht formulierten Zielsetzung.

Das Babelfisch-Problem

CJeske — Sat, 18 May 2013 18:21:06 +0000

„Der Babelfisch […] ist klein, gelb und blutegelartig und wahrscheinlich das Eigentümlichste, was es im ganzen Universum gibt. Er lebt von Gehirnströmen, die er nicht seinem jeweiligen Wirt, sondern seiner Umgebung entzieht. Er nimmt alle unbewußten Denkfrequenzen dieser Gehirnströme auf und ernährt sich von ihnen. Dann scheidet er ins Gehirn seines Wirtes eine telepathische Matrix aus, die sich aus bewußten Denkfrequenzen und Nervensignalen der Sprachzentren des Gehirns zusammensetzt. Der praktische Nutzeffekt der Sache ist, daß man mit einem Babelfisch im Ohr augenblicklich alles versteht, was einem in irgendeiner Sprache gesagt wird. Die Sprachmuster, die man hört, werden durch die Gehirnstrommatrix entschlüsselt, die einem der Babelfisch ins Gehirn eingegeben hat. […]“

Douglas Adams: „Per Anhalter durch die Galaxis“, S. 54.

Ich wünschte, solch einen Babelfisch würde es geben! – Ich find‘ die Idee klasse! Er würde Projekte und vor allem Projektdefinitionen wesentlich vereinfachen. Das Besondere an einem Babelfisch ist, dass er nicht einfach das Gesprochene übersetzt, sondern das Gemeinte übermittelt. Einige externe Dienstleister würden in vielen Projekten nur die Hälfte an Stunden berechnen können. Somit wäre der Babelfisch auch ein wahres Geheimrezept, um Kosten einzusparen.

In der Kommunikationstheorie gibt es verschiedene Modelle, die Kommunikation zwischen zwei oder mehr Teilnehmern beschreiben. Als Grundvoraussetzung für eine fehlerfreie Kommunikation in diesen Modellen wird jedoch ein gemeinsamer „Zeichensatz“ benötigt. Sprich: Alle verstehen unter einem bestimmten Wort das Gleiche und alle haben den gleichen Wortschatz. Ich denke, bei Wikipedia kann man dies als Beispiel eines perfekten Paradoxons aufnehmen. Klar ist ein Stuhl ein Stuhl. Aber bei Projekten geht es meistens nicht um Büromöbel, auch wenn sie noch so ergonomisch geformt sind, sondern um komplexe Aufgaben und Abläufe.

Wenn Spezialisten aus verschieden Bereichen aufeinander treffen, gibt es häufig bestimmte Begriffe, bei denen die Bedeutung für den Einen selbstverständlich sind und die wiederum bei Anderen ein spontanes „HÄH??“ verursacht. Zudem gibt es unternehmensspezifische Ausdrücke (die berühmt berüchtigten Insider), welche externe Mitarbeiter auch abteilungsfremde Mitarbeiter nicht verstehen. Bei Projektmeetings sollte man also stets darauf bedacht sein, eine verständliche „Sprache“ zu sprechen. Man sollte versuchen, sich in seinen Gegenüber kurz hinein zu versetzten. Vor allem aber sollte man eines tun: Wenn man etwas nicht verstanden hat, nachfragen! Nachzufragen ist für viele eine Hürde. Aber man kann nicht alles wissen. Vor allem bei fachfremden Ausdrücken. Einfach Kopfnicken und dann später (so nach zwei bis drei Wochen im Projekt) zuzugeben, dass man doch nichts richtig verstanden hat, untergräbt die meist hart erarbeitete Glaubwürdigkeit komplett. Also lieber zugeben, dass man etwas nicht weiß. Aber das ist nur ein Teil des Problems, welches sich durch den Babelfisch in Luft auflösen würde.

Ein größeres Problem ist, wenn in einem Projekt falsch formulierte Vorgaben gemacht werden oder gar nicht mit den Betroffenen geredet wird. Somit wird am Kunden vorbei entwickelt und mit dem Ergebnis kann keiner etwas anfangen. Zumal die Nachbearbeitung sehr kostspielig ist – und dadurch nie stattfindet. In der Informatik geht es darum, komplexe Aufgaben und Abläufe mit Computern und Programmen zu unterstützen. Dies setzt eine genaue Kenntnis der zu unterstützenden Bereiche voraus. Informatiker lernen jedoch meist nur die Informatikseite in ihrer Ausbildung. Logischerweise müssen somit besonders Anfänger im IT Bereich aufpassen und auch nachfragen, falls etwas nicht verstanden wurde. Jedoch sind gerade die Jungen ITler gehemmt und glauben, sie müssten alles wissen, denn ansonsten würden sie nicht ernst genommen. Doch wie Paul Watzlawick, einer der größten Sprachwissenschaftler des 20. Jahrhunderts, schon feststellte: Man kann nicht nicht kommunizieren. Die Konsequenz dieser wesentlichen und doch einfachen Erkenntnis besteht darin, dass allein die Körpersprache einen verrät, wenn man bei etwas unsicher ist.

Werfen wir also einen Blick auf die Konsequenz des Ganzen: Viele IT Projekte holen nicht das Optimum an Verbesserung heraus oder scheitern gar durch mangelnde Kommunikation oder Verständnis der eigentlichen Abläufe. Gerade im Mittelstand gibt es komplexe Workflows, die meistens nicht dokumentiert sind und nur in den Köpfen der Sachbearbeiter geordnet werden.

Leider gibt es keinen Babelfisch. Wir können somit den Gegenüber oft nicht sofort verstehen. Die Kommunikation ist gestört und muss erst einmal wieder berichtigt werden; wichtige Zeit geht verloren. Aus diesem Grund ist eine gute Kommunikation im Projektmanagement unverzichtbar. Man kann viele Stress vermeiden, wenn zur richtigen Zeit die richtigen Fragen gestellt werden.