Ich bin viele Jahre als Freiberufler durch den europäischen Raum gereist, um frohe Kunde zu verbreiten in Sachen Projekt-Realisierung. Genau genommen wurde ich gebucht, um Projekte zu realisieren oder – und das prozentual nicht zu wenig – zu retten. Und um ganz nebenbei noch ein wenig Struktur reinzubringen und good practices zu vermitteln.
Dabei habe ich die folgenden Erkenntnisse sammeln dürfen, welche ich bei über 80% der Projekte vorfand:
- Viele versuchen oft, fachlich-logisch oder technisch komplexe Projekte erst einmal selber anzugehen, obwohl die notwendigen Skill-Sets ggfls. gar nicht vorhanden waren.
- Obwohl ich schon frühzeitig im Gespräch war, bin ich oft erst dann gebucht worden, wenn der Karren schon knietief im Morast steckte.
- Ich bin immer als „Projektmanager“ gebucht worden, obwohl meine Kernkompetenzen eigentlich woanders liegen, und ich habe aber dennoch fast ausschließlich meine Kernkompetenzen ausgeübt und nicht das Projekt „gemanaged“, im klassischen Sinne.
Die drei Punkte schauen wir und jetzt noch mal genauer an.
Wir fangen schon mal an
Obwohl in überraschend vielen Fällen am Anfang gar nicht so richtig klar ist, was eigentlich im Detail realisiert werden soll, habe ich eine Frage sehr oft gehört:
„Könnt ihr nicht schon mal anfangen?“
Das ist so, als würde ich den Tischlermeister bitten, doch schon mal anzufangen, die neue Küche zu bauen. Welche Fronten dran sollen und welche Schränke ich benötige, … ach, das können wir doch später klären.
Solch Herangehensweisen zeigten und zeigen, dass sich Viele der inhaltlichen und prozessualen Tragweite eines Projektes gar nicht bewusst sind. Und damit lässt sich auch zumindest verstehen, warum ebenso Viele glauben, dass man komplexe Projekte auch von Personen steuern lassen kann, die weder das prozessuale, steuernde noch logische Verständnis für das zu realisierende Produkt oder Projekt vorweisen können. Von technischen Aspekten einmal ganz abgesehen.
Insbesondere wenn Projekte primär einen Bunte-Bilder-Charakter haben, also einen Marketing-Fokus besitzen, bspw. eine Biermarken-Seite oder eine Firmenpräsenz, wird gern mal jemand Junioriges in die Position des Projektmanagers erhoben, weil er oder sie gerade frisch vom Marketing-Studium durch ein Assessment an einen freien Arbeitsplatz neben dem Drucker gestolpert und verfügbar ist.
„Dann kann die/der gleich mal zeigen, was sie/er kann!“
… oder auch nicht kann.
Für manche dieser armen Seelen, die glauben, dass man ihnen mit so einem Projekt einen Gefallen getan hat und eine Chance geboten hat, sich zu beweisen, ist XML eine chinesische Nudelsuppe. Und genau so sieht das Ergebnis dann auch aus.
Das Thema „gescheiterte Projekte“ gehe ich irgendwann in einem separaten Beitrag einmal an.
Der Karren ist wieder frei
Die möglichen Folgen von vergaloppierten Projekten können vielschichtig sein:
- Zeit und Geld verbraten
- unzufriedene Kunden und auch Mitarbeiter
- Image-Schäden
- komplette Projektstops
- im worstcase auch Firmeninsolvenzen
In komplexen Projekten gilt daher meistens: „Wer spart, zahlt doppelt!“ Oder noch schlimmer. Insbesondere an der Besetzung von Schlüsselpositionen entscheidet sich oft der Erfolg eines Projektes. Wer da nicht zum richtigen Zeitpunkt weiß, was wann zu tun und was noch zu klären ist, läuft gern mal wochenlang komplett im grünen Status bis ins offene Messer.
Wenn dann jemand (auch Externe) gefunden und auf das Projekt gesetzt wird, um den Versuch zu starten, dieses zu retten, sind meist erst einmal die folgenden und nicht selten schmerzlichen Schritte zu durchleben:
- Einarbeitung in vorhanden Prozesse des Auftragnehmers/Auftraggebers/Projektes
- Einarbeitung in den aktuellen Projektstand
- Einarbeitung in den bisherigen Verlauf (Kommunikation, Anforderungen, Entscheidungen, Entwicklungsschritte)
- Identifikation der Problemstellungen
- Initiale Schritte zur Behebung einleiten
- Die Fragen des Kunden beantworten, wie das denn alles sein könne und warum er das nun noch mal alles erklären muss und wann wird das Projekt denn jetzt fertig.
Eigentlich bin ich was Anderes
Jetzt ist es passiert, ein Projekt ist gegen die Wand gefahren, ich werde als „Projektmanager“ oder „Projektleiter“ gebucht und soll retten, was zu retten ist.
Nach den üblichen Einarbeitungsschritten stellen wir dann fest:
Nicht das klassische Projektmanagement war das Problem. Denn offensichtlich haben sich viele Projektbeteiligte ja irgendwie zusammengefunden und Dinge begonnen oder schon realisiert, von denen alle der Meinung waren, dass es gut ist, das zu tun.
Nein, es ist das verfluchte alte Leiden der Kommunikation sowie differierender Wahrnehmungen und Erwartungshaltungen. Das kannten bestimmt schon die alten Römer.
Es sitzen also zahlreiche erwachsene Personen in Meetingräumen, Video- und Telefonkonferenzen und schaffen es nicht, zu definieren, was denn eigentlich Phase ist, in diesem Projekt. Der eine sagt grün, der andere versteht rot, beide nicken zustimmend, der Designer designt terrakotta-orange, der Entwickler leitet mangels sauberem Briefings ein eher fäkales Braun ab und am Ende schreit man sich an.
Es ist also nicht das Problem, dass man sich zum Arbeiten zusammenfindet und vielleicht sogar eine einigermaßen schlauen Arbeitsprozess gefunden hat, sondern die Anforderungen sind einfach komplett unklar. Oder schwammig. Oder nicht fachlich durchdacht. Oder nicht logisch durchdacht. Oder mit der Direktoren-Ebene nicht abgeglichen. Oder alles zusammen.
Ein Projektmanager bringt also nichts, wenn sich die restlichen Projektmitglieder nicht „belastbar“ verstehen und der PM diese Missverständnisse nicht ausräumen bzw. nicht einmal identifizieren kann oder nicht klar ist, wer eigentlich das Sagen hat.
Entweder braucht man dann einen Business Analysten oder Requirements-Engineer oder beides oder am besten einen business-analysierenden, Anforderungsmanager mit Projektsteuerungsambitionen.
Zugegeben: Diese gibt es nicht wie Sand am Meer. Nicht einmal in der Sandmenge der Sandkiste meines Sohnes. Selbst die Skills einzeln zu finden, gleicht oft schon einer Suche nach der Büroklammer im Papiermülleimer.
Was bleibt? Wenn du niemanden hast oder einkaufen kannst, der dafür sorgt, dass soetwas nicht passiert, dann gibt es eigentlich nur die folgenden Möglichkeiten:
- Lass die Finger von solchen Projekten…
- … oder hör auf zu heulen und nimm diesen Riesen-Stress mit allen Auswirkungen hin.
- … oder staffe dein Projekt richtig.
Rollen
Das Thema Projekt-Rollen oder erforderliche Skill-Sets gehe ich in einem separaten Beitrag noch einmal an. Die Erkenntnis für den Moment:
Es zeigt sich noch zu häufig, dass viele Entscheider gar nicht dafür sensibilisiert sind, welche Rollen bzw. Skill-Sets mit welchem Qualifizierungsgrad an welcher Stelle und zu welchem Zeitpunkt erforderlich sind.
Erst seit 2021 habe ich merkbar das Gefühl, dass zunehmend solche Skill-Sets gesucht werden. Seit Anfang 2021 erhalte ich nicht nur erstmalig sondern auch gleich so dermaßen viele Anfragen über XING und LinkedIn, in denen Anforderungsmanager oder Product Owner gesucht werden, so dass ich nicht mal mehr die Zeit finde, allen absagen zu können.
Vielleicht ist man da auf einem guten Weg.
Natürlich ist das Problem nicht neu. Auch vor 25 Jahren gab es das schon. Da standen und fielen Projekte jedoch damit, ob man einen „guten“ oder einen „schlechten“ Projektmanager hatte. Alles schön subsumiert unter Projektmanagement. Oder Kundenberatung.