Im Folgenden Artikel geht es um die Übernahme eines, sehr in die Länge gewachsenen Projekts, welches vorher keinen klar definierten Projekt Manager in der Führung hatte.

Paula muss nun dieses Projekt übernehmen und fragt nach Tipps, Tricks und Erfahrungsberichten, um sich selber ein Bild über ihre Möglichkeiten und nächsten Schritte machen zu können.


Folgende Ausgangssituation ist gegeben:

Paulas Firma, zur Vereinfachung "Alpha" genannt, bietet eine Softwarelösung an, welche deren Kunde bei einem Vertreter Alphas gekauft hat.
Der Kunde plant drei Monate für die Umstellung auf die neue Softwarelösung ein. Es werden von Alpha, sowie dem Kunden, Mitarbeiter benötigt, welche diese Umstellung durchführen.

Die Mitarbeiter aus Alpha koordiniert der Vertreter von Alpha, die Mitarbeiter des Kunden werden von einem IT Administrator aus der Firma des Kunden koordiniert.
Beide sind im Kontakt und liefern sich gegenseitig die Ergebnisse ihrer Arbeit zu. Die einzelnen Mitarbeiter beider Firmen stehen selber nicht in Kontakt. Alles wird über den Vertreter und den IT Administrator abgewickelt.

Nun sind zweieinhalb Jahre vergangen und die Softwarelösung ist noch immer nicht richtig übernommen worden.
Der Kunde entschließt sich nun also dazu von Alpha eine PM Dienstleistung zu erwerben.

Hier kommt Paula ins Spiel. Sie wird zum Kunden geschickt, um den Umstieg auf die neue Softwarelösung endgültig zu bewerkstelligen.

Ihre Frage lautet nun: Was würdet ihr in meiner Situation tun?
Sie selber hat bereits mit dem IT Administrator des Kunden ein Gespräch geführt, um eine grobe Rollenverteilung abzustecken und sich ein erstes Bild über den Stand zu machen.
Geplant ist auch ein Kickoff Meeting mit dem Team auf seiten des Kunden. 


In der daraus folgenden Diskussion wurden einige Ideen, Vorschläge und Lösungsansätze erörtert:

 

Nicht die verstrichenen zweieinhalb Jahre im Detail aufarbeiten!

Das detaillierte Aufarbeiten der zweieinhalb Jahre würde niemandem etwas bringen. Es ist wichtig jetzt nach vorne zu sehen und Zukunftsorientiert zu handeln.
Zwar ist es sinnvoll eine "Lessons Learned Session" im Kickoff einzubauen, um die Probleme auf einer sachlichen Ebene zu erörtern, aber niemals auf die Personen bezogene Ebene gehen.

Einzelgespräche mit den Mitarbeitern sollen gesucht werden. Dennoch sollten Argumente wie "Das lief alles schief, weil Person XY nicht richtig gearbeitet hat." vorläufig ignoriert werden. Damit ist gemeint, dass über Person XY keine Meinung anhand dieser Aussagen gebildet werden sollte. Erst, wenn Person XY die von den Mitarbeitern aufgezeigten Symptome im neu aufgenommenen Betrieb wiederholt, sind die Aussagen der Mitarbeiter relevant.
==> Von Null anfangen. Nicht auf persönliche Ebenen die Fehler suchen, sondern die sachlichen Gegebenheiten abklopfen. Jegliche Nachforschungen als Bestandsaufnahme durchführen. (Rat eines Diskussionsteilnehmers an Paula: "Geh zu den Mitarbeitern des Kunden hin und sag: "Hallo ich bin die Neue und stelle nun lauter dumme Fragen." Dadurch trittst du nicht direkt jemandem auf die Füße und sie werden dir von sich aus einiges erzählen, was du zur Bestandsaufnahme verwenden kannst.") 


Genau Rollen aller Parteien klären

Paula muss mit dem Kunden eine genaue Spezifikation ihrer Aufgaben erstellen.

  • Hat der IT Administrator noch immer das letzte Wort? Dient er nur noch in einer beratenden Funktion, da er sich in der Firma des Kunden auskennt?
  • Was ist genau im Vertrag zwischen Paulas Firma und dem Kunden beschlossen worden?
    --> Muss Paula laut Vertrag nur Aufgabe A, B und C erledigen, aber der Kunde will bei ihrer Ankunft ihr noch D, E, F, G und H aufhalsen?
  • Wen  vertritt Paula wirklich? Den Kunden gegenüber ihrem Arbeitgeber? Ihren Arbeitgeber gegenüber dem Kunden? Oder das Projekt gegenüber beiden Parteien?
    --> Diese Klärung ist wichtig, damit Paula weiß, was ihre genauen Aufgaben sind, wo ihre Grenzen liegen und wie sie Vorgehen kann um an ihr Ziel zu gelangen.


Sofern Möglich: Projekt über beide Parteien stellen

Es wurde Paula geraten, das Projekt über beide Parteien hinweg zu stellen. Sie arbeitet in erster Linie dafür, dass das Projekt endlich zu einem Abschluss kommt. D.h. sie muss wissen, wo ihre Grenzen liegen. Sie muss schriftliche Zielsetzungen haben und Mandate einholen.
Da sie nun die Mitarbeiter ihrer eigenen Firma koordinieren wird und auch die des Kunden übernehmen soll, muss sie den Mitarbeitern klar machen, dass sie alle gemeinsam in einem Boot sitzen. Die Grenzen zwischen den Firmen müssen aufgehoben werden, da das Projekt gleichermaßen beide Parteien betrifft.
Somit kann sie im Interesse des Projekts arbeiten und die besten Interessen für dessen Lösung durchsetzten.


Generelle Tipps

  • Wenn das Projekt läuft, laufen lassen. Man muss nicht alles aufs Perfekte hin optimieren.
     
  • Nicht von der derzeitigen negativ Stimmung im Projekt beeinflussen lassen. Man soll sein Ding durchziehen.
     
  • Sicherstellen, dass man das bekommt was einem zugesichert wurde. (Ressourcen, Informationen usw.
     
  • Klären ob das Projekt überhaupt noch umsetzbar ist. Es hilft niemandem, wenn man noch einmal ein Jahr drauf setzt und dann ist immer noch nichts bei rum gekommen. Auch in diesem Zusammenhang die Ziele von früher mit den jetzigen Vergleichen --> Hat sich hier vielleicht etwas geändert und wurde nicht richtig Kommuniziert?
     
  • Jour Fix Termine mit dem Kunden erstellen, um ihn auf dem laufenden zu halten. Wenn man sich einen Monat lang nicht meldet, kann das Gefühl aufkommen, dass nun alles funktioniert.
     
  • Aufpassen, dass nicht in das alte Muster verfallen wird. Man ist als PM angestellt worden und nicht als Hilfe für den IT Administrator.

 

  • No labels

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen