Die Bugs sind keine Bugs - aber was dann?

IT Projekte sind immer wieder eine Herausforderung, vor allem auch in der Rolle als Dienstleister. In diesem Beitrag wird das Testen auf Kundenseite beleuchtet.

Bevor ein System auf dem Testsystem beim Kunden installiert wird, wird dies intern getestet, je nach Kundenanforderung sehr ausführlich. Dennoch sollte der Kunde, um das System schlussendlich abnehmen zu können, ebenfalls testen. Das steht idealerweise auch im Angebot, im Projektplan und allen weiteren Dokumenten und man hat ein entsprechendes Bug-Tracking-System im Einsatz. 

Nun beginnt der Kunde also zu testen. Und erfasst Issues. Tatsächlich sind  es aber keine Bugs, sondern Issues:

• Der Kunde weiss oftmals nicht, wie das System zu bedienen ist und glaubt, ein bestimmtes Verhalten des Systems sei ein Bug - richtigerweise ist es aber ein Bedienungssfehler.
• Der Kunde bedient mit dem Beginn des Testens zum ersten Mal das System. Zuvor hat er sich beispielsweise in einer Präsentation eines Zwischenreleases den Status zeigen lassen oder er hat nur Screenshots vom Design/oder Wireframes gesehen. Immer wieder erhalte ich dann Issues wie „Der Schriftzug ist zu dominat, wir hätten ihn gerne etwas kleiner“ oder „Können Sie diese Buttons blau einfärben?“.

Solche Issues sind in der Regel aus Sicht des Projektteams kein Fehlverhalten des Systems. Entweder wurde es nicht bis ins letzte Detail spezifiziert oder man sieht, dass beispielsweise das Design mit „realen Inhalten“ doch nicht so ganz passt. Hier einige Tipps, wie mit einer solchen Situation umgegangen werden kann:

• Schulung VOR Testbeginn planen und durchführen: Damit hat der Kunde beim Testen bereits das KnowHow wie das System zu bedienen ist
• Design-Issues mit dem Kunden besprechen. Hier helfen die Designvorlagen, der Styleguide und die Browser, auf die optimiert werden soll. Sind es tatsächlich Fehler, so sollen diese behoben werden. Sind es Wünsche so können diese als Change Requests aufgenommen werden. Ist es nirgends definiert, so muss mit dem Kunden eine Lösung gefunden werden (z.B. Kostenteilung etc.)
• Bei grosser Unsicherheit: Testunterstützung beim Kunden vor Ort anbieten und die Testpersonen beim Testen begleiten. Bedinungsfehler können direkt angeschaut und eliminiert werden.
• Gemeinsame Definition von Bugs: Was soll der Kunde im Bugtracking System erfassen? Wie wird ein Fehler beschrieben. Allenfalls einige Beispiele von guten Fehlerbeschreibungen zeigen.
• Transparente Kommunikation während der Testphase: Aufzeigen, wie ein Issue eingeschätzt wird, gemeinsam mit dem Kunden definieren, wann was korrigiert wird und wann ein neuer Release/Patch geliefert wird. Hier helfen z.B. Testpläne, Releasepläne, wöchentliche Meetings oder wenn notwendig sogar tägliche Telkos
• Ressourcen und Puffer (Kosten, Zeit) für Fehlerbehebungen einplanen

Ich habe bereits die Erfahrung gemacht, dass es oftmals mehr Designissues gibt als funktionale Fehler. Für den Kunden sind diese auch oft schwerwiegender. Verständnis seitens Projektleiter gegenüber dem Kunden aber auch gegenüber des Projektteams ist entscheidend in dieser Phase. So kann der Projektleiter sicherstellen, dass das Projekt auch in der "letzten" Phase vor Going Live auf Kurs bleibt.

Der Schwarze Peter

Niemand will es offen zugeben, aber eigentlich wäre der Schwarze Peter  ein willkommenes Teammitglied. Es wird vieles einfacher, wenn der Schwarze Peter mit an Board ist: Man kann ihm alle Schuld zuweisen. Und das schönste ist, er reagiert nicht darauf, was vieles einfacher macht.

In jedem Projekt tauchen Probleme auf und natürlich wird auch immer fleissig nach der Ursache geforscht, was auch seine Vorteile haben kann. Aber es kippt sehr schnell in die Schuldzuweisung. Plötzlich muss ein Name her, Fragen wie „wer hat das so entschieden?“ oder „wer hat das gemacht?“ werden aufgeworfen und man sucht nach einer Antwort. Meistens ist das Team mehr damit beschäftigt herauszufinden, wer es war, als nach einer Lösung zu suchen. Warum das so ist, liegt auf der Hand: Lösungen erarbeiten können sich als sehr komplex erweisen, sind anstrengend und bedeuten Aufwand. Aber man weiss sehr schnell wie es zu der Situation gekommen ist und wer dafür verantwortlich ist, und meistens soll dann gleich auch der Verantwortliche eine Lösung erarbeiten. Sehr einfach und leider oft die traurige Realität.

Je nach Erfahrung des Projektleiters lässt er solche Situationen zu, oder er kann dem entgegen wirken. Aber vielleicht ist es wirklich gar nicht verkehrt, einen imaginären Schwarzen Peter im Team zu haben. Bei Problemen ist die Frage, wer es war, sehr schnell beantwortet: der Schwarze Peter. Damit gibt es keinen Grund sich noch weiter mit dieser Frage zu beschäftigen, sondern man kann gleich zur Lösunsgserarbeitung übergehen.

Schlussendlich steckt hinter einem Projekt ein Team, das gemeinsam auf ein Ziel arbeitet. Natürlich macht jedes Team Fehler und muss dann mit den Konsequenzen leben. Das passiert nun mal und damit muss das Team umgehen können. In einem funktionierenden Team soll eine Feedback-Kultur gelebt werden, auch Kritik soll zugelassen sein. Aber Schuldzuweisung wenn ein Problem auftaucht, ist aus meiner Sicht kontraproduktiv. Diese soll ganz schnell auf den imaginären Schwarzen Peter abgeschoben werden.

Der War-Room (oder ein Projekt im Ausnahmezustand)

An allen Ecken und Enden brennt es:

• Der Kunde beklagt sich über die schlechte Qualität der gelieferten Software
• Die Entwickler beklagen sich über das zu implementierende Produkt
• Der Produkthersteller gibt dauernd Updates heraus und nach deren Installation läuft die Anwendung nicht mehr korrekt
• Es tauchen immer wieder neue Fehler auf
• Der Projektleiter ist am Ende mit seinem Latein
• Alle sind demotiviert
• Das Projekt kommt nicht vorwärts

Solche Projektsituationen gibt es tatsächlich und sind natürlich für alle Beteiligten ziemlich unschön. Eine Möglichkeit, das Projekt aus dem „Sumpf“ zu ziehen ist der War-Room.
Das Projektteam zieht sich einige Tage zurück und arbeitet in einem Raum am Projekt. Gleichzeitig wird das Team mit Experten angereichert, die zusammen mit dem Team mögliche Lösungszenarien ausarbeiten und gleich auch umsetzen. Im War-Room arbeiten alle am selben Projekt und alle auf das selbe Ziel hinzu.

Was ist dabei zu beachten:

• Definition welche Leute anwesend sein müssen und etwas bewirken können: auch den Kunden mit einbeziehen (er könnte z.B. als Tester mit im War-Room sitzen und wertvollen Input hinsichtlich Qualität/Fehler etc. liefern.)
• Klare Rollendefinition bevor die War-Room Zeit startet: Möglicherweise übernimmt vorübergehend ein erfahrener Experte den technischen Lead oder das Projektmanagement
• Klare Spielregeln: Arbeitszeiten, Mittagspausen etc. müssen festgelegt werden
• Tägliche Briefings- und Debriefings
• Zieldefinition: Was soll nach dem War-Room erreicht sein? Ziel muss es nicht sein, dass das Projekt abgeschlossen wurde, sondern dass die Probleme, welche das Team hindert das Projekt abzuschliessen, aus dem Weg geräumt sind.
• Dauer des War-Rooms zu Beginn festlegen: Eine War-Room Zeit ist für alle Beteiligten ziemlich anstrengend. Deshalb sollte eine War-Room-Situation nicht allzu lange auftreten und vor allem niemals zur „Normalsituation“ werden.
• Die Zeit nach dem War-Room festlegen: Nach einer gewissen Zeit muss das Projekt wieder in seine gewohnten Bahnen gelenkt werden. Die Experten ziehen sich zurück und das Projektteam übernimmt die Aufgaben wieder. Das soll schon zu Beginn zusammen mit dem War-Room Team geplant werden, insbesondere auch um allfällige Unsicherheiten zu eliminieren.

Fazit:
War Room Situationen können helfen, ein Projekt wieder auf Kurs zu bringen. Ich habe damit bis jetzt positive Erfahrung gemacht. Dennoch gibt es auch einige Nachteile, die man beachten sollte: Durch einen War-Room (und durch die Experten) kann das bestehende Projektteam eingeschüchtert werden und damit verliert es das Selbstvertrauen, das Projekt ohne Hilfe zu Ende zu bringen. Das könnte einem Projekt noch mehr schaden. Innerhalb des War-Rooms können schnell Konflikte auftreten: Experten kritisieren, man sucht den Schuldigen etc. Das ist natürlich kontraproduktiv. Kritik gehört nicht in einen War-Room sondern zum Projektabschluss.

Welcher Projektleiter ist der Beste?

Kürzlich habe ich über verschiedene Projektleitertypen geschrieben. In diesem Post möchte ich nun ein übergreifendes Fazit ziehen.

Ich glaube, dass mit allen beschriebenen Projektleiter-Profilen ein Projekt erfolgreich geleitet werden kann. Und zwar weil ich bis jetzt eine wichtige Dimension noch nicht genannt habe: Der Charakter des einzelnen Projektleiters!

Wenn sich der Projektleiter egal zu welchem Typus (IT-Experte, fachfremder Projektleiter, Berater und Projektleiter) er am ehesten passt, sich seinen Schwächen bewusst ist, kann er das Projekt dennoch erflogreich leiten. Nämlich genau mit der Erkenntnis, an seinen Schwächen zu arbeiten und sich Hilfe zu holen, wo es notwendig ist. 

Offenheit, Transparenz gegenüber dem Auftraggeber und dem Projektteam, Ehrlichkeit und ein hohes Mass an Sozialkompetenz gehören heute zu den fast wichtigeren Erfolgsfaktoren als Methodik oder Expertenwissen. Wer sich dessen bewusst ist und diese "Charakterzüge" in einem Projekt geziehlt einsetzt, hat sicherlich Erfolg in seinen Projekten.

Sich zu Beginn des Projektes die Risiken, welche die Situation mit sich bringen könnte offen zu legen, sich das Projektteam genau anzuschauen und sicher zu stellen, dass die richtigen Leute an Bord sind (allenfalls mit Unterstützung eines Coaches) und den Auftraggeber in die Entscheidungen mit einzubeziehen, sind eine wichtige Grundlage für die Wahl des "richtigen" Projektes (oder des richtigen Projektleiters). 

Auch die Erfahrung eines Projektleiters in den Bereichen Fachwissen und Projektmanagement-Wissen deuten darauf hin, ob diejenige Person in der Lage ist, ein bestimmtes Projekt zu leiten.

In der Praxis ist es leider oftmals nicht der Fall, dass der Projektleiter sein Projekt oder der Auftraggeber sein Projektleiter selbst wählen darf. Man wird einem Projekt "zugewiesen". In solchen Situationen ist die Transparenz und Offenheit umso wichtiger.

Teil 3: Der Projektleiter als Experte und Projektmanager

Diese Projektleiter sind vermutlich die Besten! Sie sind Experten im Fachgebiet in denen sie die Projekte leiten und haben ein exzellentes Projektmanagement Knowhow. Sie fungieren damit dem Auftraggeber gegenüber einerseits als Berater, da sie fachliches Beurteilungsvermögen besitzen, andererseits wissen sie aber auch, wie ein Projekt geleitet werden soll und haben Termine, Risiken, Kosten und Scope fest im Griff. 

Sie verfügen über folgendes Wissensprofil:

Der klassische Projektverlauf

Das Projekt verläuft gut, Risiken werden früh erkannt und der Projektleiter steuert das Projekt so, dass es sich immer in den vorgegebenen Zieldimensionen (Termine, Kosten, Leistung) bewegt. Gegenüber dem Auftraggeber kann der Projektleiter kompetente Auskunft auch über inhaltliche Themen geben und weiss somit noch besser, wie es um das Projekt steht. Das Projekt wird ohne grösseren Zwischenfälle abgeschlossen, da sich der Projektleiter in seiner Aufgabe zu 100% sicher gefühlt hat.

Doch am Schluss hat das Projekt die Ziele (Kosten, Termine, Leistung) erreicht, aber es stellt sich die wichtige Frage, ob der Kunde auch tatsächlich zufrieden ist mit dem Ergebnis? Der Projektleiter hat zwar alles gegeben, um das Projekt erfolgreich zu leiten und konnte durch sein Fachwissen mögliche Hindernisse sofort aus dem Weg räumen. Damit läuft er aber Gefahr, alles zu perfekt zu machen. Hindernisse können nämlich auch neue Wege eröffnen. Und der Auftraggeber möchte diese Wege vielleicht sogar gehen, auch wenn es eine Abänderung der vereinbarten Ziele mit sich bringt.

Fazit:

In einem Projekt treten ständig Änderungen auf, diese können ab und zu auch einen grossen Mehrwert mit sich bringen. Der PL beurteilt aber dann eine Situation schnell zu Gunsten des Projektes, ohne den Auftraggeber über die mögliche Innovation überhaupt informiert zu haben. Das kann zur Folge haben, dass das wichtigste Projektziel, die Kundenzufriedenheit, nicht erreicht wird.

Vor allem in Konzeptionsprojekten kann eine solche Situation auftreten. Oftmals konzipiert man im Rahmen der bereits vereinbarten (Kosten) Ziele. Innovative Ideen, die Mehrkosten und Terminänderungen mit sich ziehen werden leider oftmals nicht weiterverfolgt, obwohl diese vielleicht zur grösseren Kundenzufriedenheit beigetragen hätten, als das Einhalten von Kosten, Termine und Leistung. 

Teil 2: Der fachfremde Projektleiter

Es gibt sie, die perfekten Projektmanager! Davon bin ich überzeugt, ich kenne sogar einige. Sie können ein Projekt (egal welcher Komplexität) leiten und managen. Diese Projektleiter tun eigentlich nichts anderes als Projekte zu leiten. Sie haben grosse Erfahrung, verschiedene Projekte gesehen und sind beihnahe schon "Projektgurus".
Der fachfremde Projektleiter weist folgendes Wissensprofil auf:

Doch diese Projektleiter haben einen Mangel - sie haben kein fachspezifisches Knowhow. Sie haben (in unserem Fall) keine Ahnung, wie ein Webprojekt abläuft und was ein solches Projekt beinhaltet.


Der klassische Projektverlauf:
Das Projekt wird sauber geplant und aufgesetzt und der Start verläuft eigentlich ganz gut. Jedoch treten öfters unvorhergesehene Ereignisse auf, auf die der Projektleiter nicht vorbereitet war. In seiner Professionalität weiss der Projektleiter aber wie mit solchen Situationen umgegangen wird, er kann immer wieder das Team neu motivieren und das Projekt "gerade" noch vor dem Ruin retten. Am Schluss kann er ein ansehlicher Abschluss, ein  motiviertes Team und einigermassen vernüftige Zahlen vorlegen - und er ist um eine Projekterfahrung reicher und weiss, aus seinen Fehlern im nächsten Projekt zu lernen.

Fazit:
Die fachfremden Projektleiter können Projekte leiten, sie behaupten vermutlich sogar, dass es egal ist, in welcher Branche und wie gross das Projekt ist. Sie wissen, dass, wenn sie ein fachfremdes Projekt leiten, ein umso stärkeres Team haben müssen, damit das Projekt zum Erfolg wird. Die Projektleiter "wappnen" sich für das Projekt mit erfahrenen Experten und steuern das Projekt nur. Das ist eigentlich ganz gut, jedoch muss der PL aufpassen, dass er keine "Marionette" seiner Experten wird. Wenn er sich immer auf die Meinungen von anderen stützen muss, ist er womöglich nicht in der Lage, die richtigen Entscheidungen zu treffen. Sich in alle Details einzuarbeiten und sich das Wissen anzueignen bevor eine Entscheidung getroffen wird, wäre  der richtige Weg jedoch fehlt oftmals die Zeit dafür. So verlässt man sich auf die Experten. Haben die aber noch weitere Interessen, die dem Projekt womöglich schaden können, kann das ziemlich fatal ausgehen. Der PL muss seinen Experten vertrauen und das darf von diesen nicht ausgenutzt werden.
Meine zweite These: Ein fachfremder erfahrener Projektleiter kann mit dem richtigen Team ein Webprojekt durchführen, wobei eine starke Vertrauensbasis zwischen Team und Projektleitung vorhanden sein muss.

Teil 1: Der Projektleiter als IT Experte

Oftmals werden aus der Situation heraus Projektleiter ernannt. Meistens gibt es ein Projekt, bei dem „noch schnell ein PL her muss“. Der Teamleiter ernennt ein IT Experten zum Projektleiter. Er kennt die Materie gut und die Risiken können somit minimiert werden. Der IT Experte hat folgendes grobes Wissensprofil:

Der klassische Projektverlauf:

Der IT Experte legt einen überzeugenden inhaltlichen Projektstart hin: Es liegt eine excellente Spezifkiation vor, ein technisches Konzept, eine überzeugende Architektur. Eigentlich eine ideale Grundlage für ein Implementierungsprojekt. Nun beginnt es aber schwierig zu werden: Der Auftraggeber hat immer neue Anforderungen, die auch alle in der Spezifikation ergänzt werden. Nur hat sich der IT-Experte nie auf den Projektscope festgelegt. Es gibt keine Fortschrittskontrolle, nur einen rudimentären Projektplan… Der weitere Projektverlauf ist klar: Unzufriedenheit, Kosten nicht eingehalten, Termine nicht eingehalten – kurz: Chaos.

In der Praxis gibt es die IT Experten in der Rolle des Projektmanagers aber sehr oft. Coaching und PM Ausbildungen können den IT Experten zu einem sehr wertvollen Projektmanager machen. Wichtig ist, dass er eine Starthilfe kriegt und sich des Wissensmangels im PM Bereich bewusst ist. Leider ist das oft nicht der Fall (weshalb vielleicht auch einige IT Projekte scheitern).

Fazit:

Die Fachexperten sind enorm wichtig für die inhaltliche Definition des Projektes, doch ohne Projektmanagement-Wissen sind Projekte mit einem IT Experten als Projektleiter zum Scheitern verurteilt. Organisation, Kommunikation, Scoping etc. sind für einen Projekterfolg unabdingbar. Diese Punkte müssen von einem Projektleiter berücksichtigt und gelebt werden. Der IT Experte legt den Fokus auf das Fachliche, nicht auf das Organisatorische. Meine erste und vermutlich auch sehr "banale" These: „Projekte sollten von einem Projektleiter mit PM Wissen geleitet werden“.

Wieviel sollte der PL vom Projektinhalt verstehen?

Es gibt Leute, die behaupten, dass ein  Projektleiter unabhängig vom Projektinhalt jedes Projekt leiten kann, er muss einfach ein guter Projektmanager sein. Für den Inhalt hat der PL ja dann die Fachexperten. Andere meinen, dass ein Projekt ohne die Kenntnis über den Inhalt des Projektes nur schwer, resp. gar nicht zu managen sei. 

Den Vergleich zwischen einem Bauprojekt und einem IT Projekt möchte ich an dieser Stelle nicht machen, sondern ich möchte auf Web Projekte eingehen. Wie viel muss ein Projektleiter von Software-Entwicklung und Web verstehen um ein solches Projekt managen zu können? Aus meiner Sicht gibt es hier unterschiedliche Ansichten (die sich allenfalls auch auf andere Projektarten anwenden lassen). Damit verbunden sind gegebenenfalls auch unterschiedliche Rollen, in die der PL schlüpft:

• Teil 1: Der Projektleiter als IT Experte
• Teil 2: Der fachfremde Projektleiter
• Teil 3: Der Projektleiter als Berater und Projektmanager

In den nächsten Blogeinträgen werde ich die einzelnen Ansichten genauer erläutern und zum Schluss ein übergreifendes Fazit ziehen. 

Hilfe ein Change Request

Es gibt praktisch kein Projekt, in dem es keine Changes gibt.  An und für sich ist das auch nicht schlecht, doch sollte der Projektleiter auf Changes vorbereitet sein und bei dessen Auftreten entsprechend handeln können.

Auswirkungen von Change Requests (CR)

Änderungen während eines Projektes wirken sich oft drastisch auf die Projektdurchführung aus. Insbesondere dann, wenn der Änderungsaufwand so gross ist, dass ein neues Arbeitspaket gebildet werden muss und mit in die Projektplanung einbezogen werden muss. Hier entstehen neue Teilziele (weil neues Arbeitspaket), zusätzliche Kosten und neue Termine. Dies kann zu einer Änderung des vertraglichen Liefer- und Leistungsumfanges führen.

In der Regel bringen  Änderungen eine Neukalkulation der Kosten, Termine und Risiken mit sich. Um vom Auftraggeber Mehrkosten, respektive eine Terminverschiebung zu verlangen ist eine saubere Dokumentation der Änderungen, inklusive  deren Kosten und Termine unumgänglich.

Aufwandschätzung von CR's

Es wird sehr oft unterschätzt: ein Change Request bringt auch einen grossen administrativen Aufwand mit sich. So muss der PL prüfen, ob sich der CR mit den ursprünglich vereinbarten Zielen verträgt, wo dieser im vorliegenden Projektplan eingebaut werden kann, wie die Risikoeinschätzung aussieht, ob andere Arbeitspakete dadurch "gefährdet" sind und nicht zuletzt muss der CR auch geschätzt werden.

Um eine optimale Schätzung abliefern zu können, sollte der PL untenstehende Fragen, welche er mit dem Projektteam klären sollte bereithalten:

• Wurde bei dieser Schätzung das Testing berücksichtigt?
• Wurde bei dieser Schätzung das Deployment berücksichtigt?
• Können allfällige Risiken auftreten? (Risikopauschale mit einberechnen)
• Wurde bei dieser Schätzung die zusätzlich anfallende Dokumentation und Spezifikation berücksichtigt?
• Sind die Projektleitungs- und Administrationsaufwände mit einberechnet?

Kommunikation von CRs  
Tritt ein Change Request auf, so muss dieser natürlich auch als solcher erkannt werden. Nicht selten schleichen sich CRs nämlich ins Projekt ein, ohne dass dagegen etwas unternommen wird.
Sobald aber ein CR auf dem Tisch liegt, muss dies entsprechend kommuniziert werden, beispielsweise über das Issue Tracking System oder im Weekly Report.
Dem Auftraggeber muss transparent aufgezeigt werden, welche Auswirkungen der CR in Bezug auf Kosten, Termine und weitere Arbeitspakete hat. Der CR muss anschliessend vom Auftraggeber genehmigt werden.

Delegieren ist nicht immer einfach

Ein Projektleiter muss in der Lage sein, Dinge delegieren zu können. Fehlt ihm diese Fähigkeit, so kann es passieren, dass er sehr schnell mit Tasks überlastet ist und darunter leidet schlussendlich das gesamte Projekt.

Es gibt ein paar Dinge die beim Delegieren beachtet werden sollten:

Klare Aufgabenformulierung: 

Der PL muss sicherstellen, dass die Aufgabe, die delegiert werden soll, klar formuliert ist. Dazu gehört ein Briefing und vor allem ein "Lieferobjekt". Der PL soll veranschaulichen, was er als Resultat gerne hätte.

Allenfalls sind auch die Definition von "Zwischen-Lieferobjekten" resp. Reviews sinnvoll, insbesondere bei grösseren Aufgaben.

Identifikation mit dem Task: 

Der PL muss sicherstellen, dass sich derjenige, der eine Aufgabe übernimmt, sich damit identifiziert und dass die Verantwortung dafür übernommen wird.  So kann der PL auch darauf vertrauen, dass der Task auch wirklich erledigt wird. Dies kann er beispielsweise erreichen indem...:

• ...die Wichtigkeit der Aufgabe betont wird
• ...die Auswirkungen bei Nichterledigung veranschaulicht werden
• ...allenfalls Belohnung in Aussicht gestellt wird 
• ...zum Voraus gelobt wird ("Wenn Du das alles gemacht hast, bin ich sehr stolz auf Dich")

Sich zurückziehen: 

Ist der Task übergeben, so soll sich der PL bewusst zurückziehen. Ansonsten läuft er Gefahr, dass er sich trotzdem um alles kümmert und somit schlussendlich doch selbst den Task erledigt. Das ist aber genau nicht im Sinne des Delegierens. Deshalb soll er den Beauftragten einfach mal machen lassen (man hat ja Zwischenreviews definiert), auch wenn er dadurch allenfalls ins „Kalte Wasser geworfen wird“. Gerade bei grösseren Aufgaben, die einem vielleicht selbst Spass machen, muss der PL besonders darauf achten (z.B. auch bei einer Projektübergabe). 

Frühzeitige Übergabe: 

Wie alles in einem Projekt, sollte auch das Delegieren geplant sein. Derjenige der die Aufgabe übernimmt, soll genügend Zeit erhalten, sich sorgfältig einzuarbeiten, sodass er sich auch angemessen um die Aufgabe kümmern kann. In der Praxis ist das natürlich der Idealfall. Meistens muss man Dinge ja delegieren, wenn etwas Unvorhergesehenes passiert ist und deshalb bleibt auch keine "Planungszeit" übrig. Trotzdem sollte der PL versuchen, auch wenns hektisch ist, diese Dinge zu beachten. 

In diesem Post gibt es noch weitere Tipps.

Projektmanagement auf dem Weg ins Web 2.0

Kürzlich durfte ich an der SPM Frühjahrstagung ein Referat über Web 2.0 und Projektmanagement halten. Hier die Präsentation dazu: 

Projektmanagement 2.0 - Erfolgreicher Einsatz von Web 2.0 im Projektmanagement

View more presentations from Nina Braschler.

Wichtigste Erkenntnisse:

• Projektmanagement erfährt unter dem Aspekt Web 2.0 eine Veränderung in der gesamten Projektkommunikation
• Web 2.0 im Projektmanagement schafft Transparenz
• Web 2.0 im Projektmanagement eliminiert E-Mails
• Web 2.0 im Projektmanagement schafft Projektidentität

Quelle: Namics Blog

Fortschrittskontrolle - was der PM berücksichtigen sollte

Wie messe ich den Fortschritt in meinem Projekt? Eigentlich eine tägliche Arbeit des Projektleiters, allerdings eine nicht ganz anspruchslose Aufgabe.
Der Projektleiter muss sich bei der Fortschrittkontrolle (wie bei der gesamten Projektsteuerung auch) sich im Klaren sein muss, was der Trade-Off des Projektes ist. Darauf aufbauend soll auch die Fortschrittskontrolle gemacht werden.

Aus meiner Sicht gibt es folgende Grundregeln, die bei der Fortschrittskontrolle zwingend gemacht werden sollte:

Ganzheitliche Fortschrittskontrolle
Für eine zuverlässige Aussage über den aktuellen Projektstand. müssen immer alle Dimensionen (Kosten, Termine und Leistung) berücksichtigt werden sollen. Dem Auftraggeber hilft es wenig, wenn ihm mitgeteilt wird, dass für das Arbeitspaket X 5 Tage aufgelaufen sind. Wenn er aber gleichzeitig weiss, dass das Arbeitspaket zur Hälfte fertig gestellt ist und dass es planmässig abgeschlossen werden kann, ist das um einiges aussagekräftiger.

Prognosen erstellen
Dies ist integrierender Bestandteil der Fortschritssmessung: Je nach Trade Off muss der Projektleiter eine zuverlässige Aussage über die Endkosten, resp. Endtermin des Projektes machen können. Gerade bei fixen Kosten (oder Terminen) muss er wissen, ob mit dem bereits geleisteten Umfang des Projektes die Kosten oder der Termin gehalten werden kann. Kann er dies nicht bestätigen, so muss er entsprechend steuern. Entsteht ein Mehraufwand, gibt es zwei Methoden die hilfreich sind:

• Additiv
  Der Projektleiter zählt den zum Zeitpunkt x angefallenen Mehraufwand zur Kostenschätzung, resp. Endtermin des AP’s hinzu. Diese Methode kann dann angewendet werden, wenn der Projektleiter davon ausgeht, dass der angefallene Mehraufwand einmalig ist (beispielsweise auf Grund einer einmaligen Einarbeitung eines weiteren Projektmitarbeiters).

• Linear
  Hier zählt der Projektleiter den angefallenen Mehraufwand auf sämtliche folgende Arbeitsschritte bis zur Fertigstellung des Arbeitspaketes hinzu. Diese Methode wendet der Projektleiter an, wenn er sieht, dass der angefallene Mehraufwand sich wiederholen wird (beispielsweise wenn ein Projektmitarbeiter regelmässige Unterstützung eines Experten benötigt).

Transparente Kommunikation gegenüber dem Auftraggeber ist hier unabdingbar, insbesondere dann, wenn es eine Planabweichung gibt (Vgl. Post über Verhandlung und Projektleitung)
 

Nicht nur auf Zahlen fixieren:
Wichtig ist, dass sich der Projektleiter nicht nur auf die Zahlen fixiert, sondern auch das persönliche Gespräch mit dem Projektteam wie auch mit dem Auftraggeber sucht. Insbesondere bei einer Abweichung sollte der Auftraggeber informiert werden. Es soll ihm aufgezeigt werden, was man tun kann, damit das ursprünglich vereinbarte Ziel dennoch erreicht werden kann. Das ist schlussendlich eine Teamarbeit, die von allen Teammitgliedern Kreativität und Mitdenken erfordert.

Der Projektleiter darf auch mal "Nein" sagen

Ich wurde kürzlich gefragt, wie man lernt, "Nein" zusagen. Ehrlicherweise hatte ich keine Antwort auf diese Frage. Vielleicht liegt das im Naturel der Person, dass man selbst merkt, wenns genug ist, und wann man "Stopp" sagt. Trotzdem kann ich ein paar einfache Tipps mitgeben, die das "Nein" sagen aus Projektsicht allenfalls erleichtern.

1. Erkenntnis 
Bevor man überhaupt "Nein" sagen kann, muss der Projektleiter erkennen, dass für einen zusätzlichen Auftrag, Task oder Meeting nun wirklich keine Zeit (oder auch kein Budget) mehr übrig ist. Fehlt diese Erkenntnis, ist der Projektleiter gar nicht in der Lage, etwas zurückzuweisen. Um diese Erkenntnis zu erhalten, muss der Projektleiter den Projektumfang, den Fortschritt, die Abmachungen etc. sehr gut kennen. Eine saubere Dokumentation der Entscheide, des Scopes etc. ist hierfür zwingende Voraussetzung.

2. Sachliche Begründung
Der Projektleiter ist eigentlich immer in der "konfortablen" Situation, dass nahezu alles sachlich in den Dimensionen Kosten, Termine und Leistung (das Magische Dreieck) ausdiskutiert und begründet werden kann. Kommt der Projektauftraggeber mit einem zusätzlichen Auftrag oder einer zusätzlcihen Anforderung, so muss der Projektleiter sich sofort über folgendes Gedanken machen:

• Welche Auswirkungen hat das auf meinen Endtermin?
• Welche Auswirkungen hat das auf das Budget?
• Welche Auswirkungen hat das auf den Rest des Projektumfangs? (Birgen sich darin allfällige Risiken, die andere Leistungen/Funktionen massiv beeinträchtigen?)

3. Die Entscheidung zum "Nein" verlagern
Kann oben genannte Begründung dem Auftraggeber veranschaulicht werden, so erreicht der Projektleiter eine Verlagerung des Entscheides. Die Entscheidung, ob nämlich allenfalls der Termin nicht gehalten werden kann, oder das Budget erhöht werden muss oder ob das Risiken mit sich bringt, liegt beim Auftraggeber und nicht mehr beim Projektleiter. Trotzdem ist es hilfreich, wenn der Projektleiter hier eine Empfehlung abgeben kann. Sind nämlich die notwendigen Mittel vorhanden, so braucht es allenfalls gar keine Zurückweisung.

4. Es darf nicht endlos weitergehen
Nichts desto Trotz braucht es irgendwann ein (Projekt)-Ende. Für das Projekt ist es nicht immer von Vorteil, wenn ständig noch was dazu kommt, auch wenn dafür das notwendige Zeit- und Kostenbudget zur Verfügung gestellt wird. Der Projektleiter soll sicherstellen, dass der Projekt kein "Endlosprojekt" wird und entsprechend dagegen steuern. Dies kann er ebenfalls mit einer Argumentation hinsichtlich der Risiken sicherstellen.

5. Ein "Nein" gegenüber dem Vorgesetzten oder dem Projektteam
"Kannst du nicht noch schnell den Task erledigen und die Dokumentation fertig schreiben?" "Kannst Du nicht schnell in einer Stunde das Projekt vor der Geschäftleitung vorstellen?" Auf den Projektleiter treffen täglich unvorhergesehene Aufgaben. Klare Arbeitspriorisierung ist Voraussetzung, dass alle Aufgaben seriös gemacht werden können. Genau wie beim Auftraggeber auch, muss der Projektleiter auch gegenüber dem Team und dem Vorgesetzten argumentieren, warum eine Aufgabe nicht zum gewünschten Zeitpunkt erledigt werden kann, oder wenn eine andere wichtigere Aufgabe unter der sofort angeforderten Aufgabe leidet. Transparente Darstellung der eigenen Tasks und entsprechende Argumentation helfen hier.

Hilfe in meinem Projekt stimmt die Qualität nicht mehr

Diese Situation ist nicht neu: Ein grösseres Softwareentwicklungsprojekt wurde mit einer 10 köpfigen Mannschaft begonnen. Man hat gute Fortschritte gemacht, der Auftraggeber ist mit den ersten Resultaten zufrieden. Alle Entwicklungstasks sowie die internen Test sind nahezu abgeschlossen, das Projekt neigt sich dem Ende zu. Längst können nicht mehr alle 10 Team Mitglieder beschäftigt werden sondern diese sind teilweise bereits wieder in anderen Projekten tätig. Plötzlich merkt der Projektleiter, dass die Qualität im Projekt nicht mehr stimmt. Wann die Fehler aufgetreten sind, ist an dieser Stelle gar nicht mehr wichtig, sondern viel mehr, was der Projektleiter in einer solchen Situation tun kann, respektive wie er solche Situationen vermeiden kann:

1. Das Team bleibt bis zum Schluss ein Team
Obwohl das Projektteam nicht mehr ausschliesslich für dieses Projekt arbeitet, bleibt es bis zur Projektabnahme ein Team. Es kann durchaus sein, dass einige Leute auf anderen Projekten arbeiten und nahezu nicht mehr für das eigene Projekt tätig sind, dennoch muss der Projektleiter sicherstellen, dass die Informationen an alle Team Mitglieder verteillt werden. Statusmeeting, oder persönliche Updates an Leute, die keine konkrete Tasks mehr haben sind unerlässlich. Und warum?

• Der Entwickler soll bis zum Schluss für seine Komponenten verantwortlich sein und wenn möglich auch darin gefundene Fehler beheben. Wenn er sich jedesmal für eine Fehlerkorrektur komplett neu orientieren muss, so dauert das unter Umständen viel zu lange. Ist er aber informiert, was im Projekt gelaufen ist, so kann er geziehlt mit der Fehleranalyse beginnen. 
• Wird die Verantwortung plötzlich abgegeben, so müssen andere Personen die Fehler glatt ziehen. Das ist nicht im Sinne eines Teams, in dem jeder seine Verantwortung übernommen hat.
• Wird das Team Mitglied nicht mehr informiert, verliert es sehr schnell die Motivation. Selbst wenn dann Fehler behoben werden müssen, wird dies allfällig lieblos und ohne ausführliches Testing / Review erledigt.  

Wenn ein Team Mitglied gar keine Zeit für das Projekt mehr hat, so muss der Projektleiter eine saubere Übergabe an einen anderen Entwickler sicher stellen, damit dieser die Verantwortung über die entsprechende Komponente übernimmt.

2. Nach den ersten Erfolgen darf die Qualitätssicherung nicht vernachlässigt werden
Ist der Auftraggeber mit den bisherigen Leistungen zufrieden, besteht sehr schnell die Gefahr, keine ausführliche Qualitätssicherung mehr zu machen wie bis anhin. Das Vertrauen des Auftraggebers hat man ja durch die ersten Erfolge für sich gewonnen. Sehr schnell kommt jetzt die Denkweise "die können ja auch mal testen" auf. Das ist kontraproduktiv und nicht sinnvoll. Code Reviews, Überprüfung der Code Qualität ist auch in einer späteren Phase des Projektes unerlässlich. Durch eine schnelle Fehlerkorrektur können sich auch schnell Folgefehler einschleichen. Darunter leidet die (Code) Qualität zwangsläufig. Ein sorgfältiges Retesting der Fehlerkorrektur durch Entwickler und Tester ist in dieser Phase besonders wichtig.

Das hier Beschriebene klingt sehr stark nach dem "Idealfall". Mir ist bewusst, dass oftmals weder Zeit noch Budget für eine ausführliche Qualitätssicherung resp. für regelmässige Updates im gesamten Projektteam vorhanden ist. Dennoch soll sich der Projektleiter der Thematik bewusst sein und früh gegen dieses Problem steuern.

Teil 6: Stakeholder Kommunikation

Über Stakeholder und Stakeholderkommunikation gibt es gute theoretische Grundlagen, wie beispielsweise die Stakeholderanalyse oder die Kommunikationsmatrix. Ich möchte in diesem Post nicht diese theoretischen Grundlagen erläutern oder nochmals wiedergeben, sondern viel mehr beschreiben, was man nebst diesen Methoden als PL für die Kommunikation mit den Stakeholdern verwenden kann. 

Für die gezielte Kommunikation mit den Stakeholdern ist eine ausführliche Stakeholderanalyse unerlässlich. Auch wird der Projektleiter vermutlich zu Beginn des Projektes sich überlegt haben, welche Stakeholdergruppen wann wie und worüber informiert werden (Kommunikationsmatrix). Aber hat man mit einer sauberen Analyse und den entsprechenden Reports die Stakeholder wirklich im Boot?

Persönliche Kommunikation als wichtigste Ausgangslage für die Stakeholderkommunikation:

Ich glaube, dass bei der Kommunikation mit den Stakeholdern genau wie beim Projektteam die persönliche Kommunikation eine ebenso wichtige Rolle spielt. Je nach Stakeholder vielleicht nicht in der Intensität wie innerhalb des Teams, aber von Zeit zu Zeit ein Anruf oder bei einen gemeinsamen Kaffee zu plaudern schadet nichts. Dies aus folgenden Gründen:

• Stakeholder, die nicht so nah am Projekt sind, haben oft gar keine Zeit, alle Reports zu lesen und zu verstehen, die ihnen einmal im Monat zugeschickt werden. Da hier keine tägliche Kommunikation stattfindet, vergisst man oft den Zusammenhang. Hilfreicher sind hier Projektpräsentationen, bei denen in der Pause auch mal das persönliche Gespräch gesucht werden kann.
• Im persönlichen Gespräch kann der Projektleiter mit gezielten Fragen eher herausfinden, wo allenfalls der Schuh drückt, als in einer Einwegkommunikation.
• Im persönlichen Gespräch hat der Stakeholder die Möglichkeit Fragen zu stellen und das ist für den Projektleiter die ideale Möglichkeit falsche Annahmen aus dem Weg räumen.
• Es ist besser möglich, im persönlichen Gespräch das Vertrauen eines Stakeholeders zu gewinnen. Der Stakeholder kennt danach das „Gesicht“ hinter demjenigen, der regelmässig Reports schickt. Und wer weiss, vielleicht werden diese Reports dann doch angeschaut ;o)

Es ist klar, dass in einem grossen Projekt nicht jeder einzelne Stakeholder persönlich durch den Projektleiter betreut werden kann. Aber der Projektleiter könnte im Projekt jemanden bestimmen, der für die Stakeholderkommunikation verantwortlich ist. Diese Person entscheidet dann auch, wann der Projektleiter dabei sein soll/muss.