Die Zeit, in der man Projekte von vornerherein mit ausreichend Zeit, Personal und damit letztlich Geld ausstatten konnte, nur weil man dem Auftraggeber oder Chef mal kurz “Toll Collect” sagte, die sind leider vorbei. Das Paradebeispiel ist aus unserer aller Erinnerung verschwunden bzw. verblasst und ähnlich prominente Nachfolger gibt’s nicht.
Der Zusammenhang zwischen großzügiger Austattung mit Zeit und Geld einerseits und der Chance ein Projekt erolgreich zu beenden, besteht nicht unbedingt – aber es war textlich mal eine halbwegs gute Einleitung.
Zur Sache: Was tun, wenn ein Projekt richtig in die … läuft?
Ein Buch das wirklich lesenswert ist, beschreibt wie man solche Situationen meistert und wie man sie vermeidet. Es handelt diverse Themen ab: Angefangen bei der Frage, was eigentlich eine Projektkrise ist über Vorgehenstipps zur Frage, was vertraglich geregelt werden kann und schließlich: Wie man Krisen von vorneherein vermiedet.
Zum Thema “meistern” die aus meiner Sicht wesentlichen Punkte (nicht nur aus dem Buch sondern aus meiner langjährigen und ereignisreichen (hüstel…) Erfahrung:
- Der “Turnaround Manager” darf nicht der Projektleiter sein. Es muss eine Person aus dem Management mit entsprechenden Fähigkeiten und Kompetenzen sein. Am Besten fachfremd und ohne Bezug zum Projekt und Kunden. Seine eigenen Interessen stehen so in geringstmöglichem Widerspruch zum Projekterfolg.
- Zuhören und kommunizieren: Oft menschelt es einfach und darunter leidet die für einen Projekterfolg notwendige Kommunikation. Zur Not Personen auch Mitarbeiter mit hoher fachlicher Qualifikation ersetzen. Das ist wie im Fussball: Die Stürmer müssen auch nach hinten arbeiten (nein, hier steht kein Phrasenschwein).
- Das Projektziel bewusst machen und die Projektarbeiten daraufhin überprüfen und priorisieren.
- Wenn man das Projekt mit Kennzahlen steuert: Die Kennzahlen auf die wesentlichen reduzieren – und die Konsequenzen aus den Kennzahlen ziehen.
Zum Thema “vermeiden”:
- Die Ziele und die Anforderungen müssen klar sein, verbindlich vereinbart und dokumentiert sein.
- Bei Projekten, die Neuland sind, eignen sich agile Methoden wie Scrum. Wenn man hiermit keine Erfahrung hat: Externe mit Erfahrung einbinden!
- Die Kommunikation (wer mit wem, wie und wo dokumentiert) muss geregelt sein. Häufig wird Software eingesetzt, aber der Umgang ist nicht geregelt oder – wie ich es schon erlebt habe: Nicht alle Mitarbeiter sind darauf berechtigt.
- Es gibt einen definieren Projektbeginn und ein definiertes Projektende.
- Überlegen und definieren, wie man den Projektfortschritt zuverlässig misst.
