Probleme und deren Lösung - Wie der Projektleiter der Problemlösung einen Schritt näher kommt

Das Projektteam oder ein Projektmitglied ist an einen Punkt gelangt, bei dem es nicht mehr weiter kommt. Im Statusmeeting fallen Aussagen wie: „ich schaff es nicht“, „ich komme nicht weiter“, „ich habe ein Problem, das ich nicht lösen kann“ etc. 

Bei solchen Fragestellungen ist es am effizientesten, wenn gemeinsam im Team und mit der betroffenen Person selbst nach einer Lösung gesucht wird. Ziel ist es nicht,  dass der Projektleiter das alleine tut, er weiss die Lösung ja auch nicht immer. Zur gemeinsamen Lösungsfindung können folgende Fragetechniken helfen:

• Fragen nach Ausnahmen: Auf „störungsfreie, erwünschte Zeiten lenken
  Beispiel: Wann war das letzte Mal, dass das Problem nicht auftauchte?
• Erklärungs-/Zukunftsfragen: Ziele in Zukunft konkretisieren
  Beispiel: Was wäre das erste Anzeichen, dass es gelöst werden kann?
• Hypothesen Fragen: Loten Möglichkeiten aus (was wäre wenn)
  Beispiel: Wenn ich dir sagen würde, das Problem hätte diese oder jene Ursache, was wäre dann für Dich anders?
• Zirkuläre Fragen: Fordern auf, aus Sicht eines Anderen zu antworten
  Beispiel: Was würde der Technische Lead zu diesem Ergebnis sagen?
• Fragen aus Zukunft/Vergangenheit: Perspektivenwechsel
  Beispiel: Wenn wir uns in 3 Wochen wieder treffen und ich frage, was aus dem Problem geworden ist, was würdest Du mir antworten?

Persönlich finde ich die Erklärungs/Zukunftsfragen und den Perspektivenwechsel sehr effizient. 

[Quelle: Social competence im Projektmanagement - Projektteams führen, entwickeln und motivieren von Christian Majer und Luis Stabauer]

Startschuss - los gehts - oft in eine Sackgasse. Der Projektstart ist nicht trivial.

"Sage mir, wie dein Projekt beginnt und ich sage dir, wie es endet". 

Alle Projektleiter kennen diesen Spruch und alle denken "ja, ja, das ist ein alter Hund und mir passiert es sicher nicht, dass mein Projekt mit einem Desaster beginnt."

Die Realität und auch meine Erfahrung zeigen, dass viele Projekte trotz nützlichen Checklisten dennoch oftmals nicht gut starten.


Mit dem Kickoff ist der Start nicht abgeschlossen
Oftmals wird angenommen, dass ein Projekt mit dem Kick off gestartet ist und dass danach volle Fahrt aufgenommen werden kann. Ein Irrtum. Im Kickoff wird aufgezeigt, WIE das Projekt aufgesetzt und geleitet wird, es wird definiert, welche Rollen es gibt, was die Eckdaten sind, die Aufgabenverteilung, wie die Reports aussehen etc.
Das heisst aber noch lange nicht, dass das bereits schon so umgesetzt wurde. Ein Projektstart ist dann zu Ende, wenn das Projekt auf Kurs ist und die Rahmenbedingungen nicht nur definiert sondern auch erfüllt sind. 

Alle rennen los - in total unterschiedliche Richtungen
Nach dem Kickoff sind alle motiviert möglichst schnell ein gutes Ergebnis präsentieren zu können. Jeder macht sich an die Arbeit. Dabei wird oft vergessen, dass einem Projekt ein definierter Scope, ein Budget und ein Termin zu Grunde liegt und dass diese Rahmenbedingungen von den beteiligten eingehalten werden sollten. Während der Projektleiter noch mit den Strukturen (z.B. Projektplan, Risiken, Reporting, vielen Kundenmeetings etc.) beschäftigt ist, merkt er nicht, dass das Projekt hintendurch bereits aus dem Ruder läuft. Er muss also bereits steuern, damit die Rahmenbedingungen entsprechend eingehalten werden.
Genau dieser Punkt darf auf keinem Fall unterschätzt werden. Bis das Projekt Fahrt aufgenommen hat, kann schon sehr viel schief gehen und darauf soll geachtet werden.

Eine Checkliste reicht nicht aus
Checklisten können beim Projektstart helfen, aber die Checkliste und die abgearbeiteten Punkte darauf reichen noch lange nicht aus, dass das Projekt auch wirklich gut startet.
Schlussendlich muss der Projektleiter die Fäden in der Hand haben und das Projekt leiten, dabei kann er mit seiner Checkliste eine gewisse Sicherheit kriegen, aber wie das Projekt geleitet wird, seht meistens nicht auf der Checkliste, das muss man selbst tun.

Der Projektplan kann helfen
Einmal mehr ist eine feinsäuberliche Planung, bei der die oben stehende Punkte berücksichtigt werden, notwendig um das Projekt auf Kurs zu bringen.
Lieber zu Beginn nicht viele Aktivitäten parallel laufen lassen. Sondern zuerst die Gefässe/Strukturen schaffen und dann erst mit der Crew loslegen. Gerade zu Beginn muss der Projektleiter die Projektmitglieder sehr stark führen, damit die sich in den vorgegebenen Strukturen einfinden. Aber auch der Auftraggeber braucht zu Beginn sehr viel Aufmerksamkeit, nicht zuletzt auch deswegen, weil in dieser Phase das Vertrauen aufgebaut wird.
Hinzu kommt, dass am Anfang des Projektes von allen Seiten viele Fragen gestellt werden, die es zu beantworten  gilt und auch den anderen mitzuteilen gilt. Das alles braucht sehr viel Zeit und  kann und soll auch nicht parallel laufen. Denn soviel auf einmal kann ein Projektleitder nicht machen und damit sind die Folgefehler vorprogrammiert.

Fazit
Der Projektstart ist nicht tivial. Es muss sehr viel berücksichtigt werden, damit das Projekt erfolgreich Fahrt aufnimmt. Leider passieren am Anfang auf Grund von Überlastung des Projektleiters Fehler, die später dann ziemlich ungemütlich werden können. Achtet darauf - einen Schritt nach dem andern zu tun.

Ein komplexes IT Projekt in 3 Monaten - wie ist das möglich?

Diese Frage hab ich mir auch gestellt, als ich vor einiger Zeit den Auftrag erhalten habe, ein komplexes IT Projekt innerhalb von 3 Monaten durchzubringen.
Die Fakten wargen gegeben:
- Fixer Endtermin
- 10 Entwickler
- mehrere Ansprechpersonen auf Kundenseite
- Grosse Komplexität
- 2 Monate Entwicklung
- 1 Monat Testing und Migration
- ...
Eigentlich unmöglich, ein solches Projekt zum Erfolg zu bringen.

Und dennoch, nach 3 Monaten war das Projekt zu Ende und das Resultat konnte sich sehen lassen. Ich möchte hier aufführen, wie mit einfachen Mitteln scheinbar Unmögliches möglich werden kann.

Der Auftraggeber muss mitmachen
Eines der wichtigsten Erfoglsfaktoren war, dass der Auftraggeber mit im Boot sitzt. Dem Kunden, wie auch dem Projektteam muss bewusst sein, dass der Endtermin kritisch ist und entsprechend müssen auch Kompromisse gemacht werden. Das hat bei diesem Projekt nicht zu letzt dank der transparenten und offenen Kommunikation bei beiden Parteien erstaunlich gut funktioniert.

Auf der Geschäftsleitungsebene wird noch der Vertrag ausgehandelt - ein guter Punkt, auszusteigen
Während noch nicht alle Fakten vertraglich festgelegt waren, wurde bereits mit Hochdruck am Projekt gearbeitet. Dabei drängt sich immer wieder die Angst vor dem Scheitern und die Tatsache, dass die nächsten 3 Montae "stressig" werden in den Vordergrund - zusammen mit der Tatsache, dass der Vertrag noch nicht unterschrieben ist, wären das eigentlich genügend gute Ausreden, um zu argumentieren, dass das Projekt so nicht gemacht werden. Damit wäre aber niemandem gedient, weder dem Auftragnehmer noch dem Auftraggeber. So muss das in den Hintergrund gedrängt werden. Die Projektbeteiligten seitens Auftraggeber als auch das Projektteam hat diese Diskussionen ausgeklammert und alle waren bemüht, das Projekt vorwärts zu bringen. Niemand hat ein Ausstieg oder ein Stopp angesprochen.

Scoping, Scoping, Scoping
Der Projektleiter muss (immer wieder) klar machen, was vereinbart wurde und was geliefert werden kann. Zusatzwünsche und Changes werden in einem weiteren Release geliefert. Entscheidungen und Scopänderungen müssen sauber dokumentiert werden. Gerade in einer hektischen Zeit geht dies gerne unter, ist aber essentiell um den Scope zu verargumentieren. 


Vertrauen ins Team
Schlussendlich darf der Projektleiter nicht einen einzigen Gedanken daran verschwenden, dass das Projektteam die Herausforderungen und Probleme nicht bewältigen könnte. Im Gegenteil, Motivation, Teil vom Team zu sein und gemeinsam nach Lösungen zu suchen ist zielführender. Trotz der schwierigen Konstellation und den Rahmenbedingungen soll das Projekt eine Herasforderung im positiven Sinne sein. 

Tote Linien - Umgang mit Deadlines

Ein Projekt hat per Definition ein Anfangs- und ein End-Datum, sonst wäre es kein Projekt. Somit hat ein Projekt mindestens eine Deadline - nämlich das End-Datum.

Warum Deadlines
Nun, Deadlines sind ein beliebtes Instrument, um ein Projekt noch weiter strukturieren zu können, beispeilsweise mit Zwischendeadlines:

• Zu jedem Milestone
• Ende einer Projektphase
• Ende eines Arbeitspaketes
• Ende eines Tages
• etc.

Der Vorteil ist, dass dadurch eine gewisse Verbindlichkeit im Projekt geschaffen wird und es können Verantwortlichkeiten festgelegt werden.

Doch es gibt auch einiges zu beachten:

• Zu viele Deadlines erzeugen unnötigen Druck beim Projektteam oder beim Kunden
• Deadlines können zu unnötigen Prozessen führen (z.B. Schriftliche Abnahme beim Erreichen eines Meilensteins).
• Zu viele Deadlines können nicht eingehalten werden. Es entsteht ein „Laisser fair“ Feeling im Projekt und keiner hält sich mehr an Termine oder Abmachungen. Hier gilt "weniger ist mehr".
• Deadlines werden am Anfang des Projektes festgelegt und nicht adhoc mitgeteilt.
• Eine der wichtigsten Deadlines ist in der Regel der Endtermin, der sollte eingehalten werden. Sollte es sich während des Projektes herausstellen, dass der Endtermin nicht eingehalten werden kann, so muss der PL frühzeitig reagieren.

Dealines sind für ein Projekt eine Voraussetzung - und dürfen auf keinem Fall als "tote Linie" interpretiert werden. Jedoch sollten die "Termine" mit Bedacht gewählt werden und jeweils transparent aufgezeigt werden. Es nützt nichts, wenn ich am Mittag sage: „bis heute Abend muss das fertig sein“. Hier erzeuge ich nur unnötig Druck und die betroffene Person hat gar keine Möglichkeit, sich darauf einzustellen. Vielmehr ist das eine Aussage "in der Not" weil das Projekt nicht mehr vorwärts geht. Hier sollte man die Ursache lieber wo anders suchen.