Projektziele gehören auf den Prüfstand

Jürgen Wulff: Friedrich, du bezeichnest dich als Projektlotsen. Was muss ich darunter verstehen?

Friedrich Behnk: Also Projektlotse ist ein Kunstwort, eine Mischung aus einem Lotsen und Projekt. Der Lotse ist derjenige, der den Kapitän berät. Jemand, der schon mal Kapitän war, steht dem Kapitän in einem bestimmten Fahrwasser beratungstechnisch zur Seite. Also ich verstehe mich als Berater vom Projektmanager in einer Unternehmung, die ein Projekt vernünftig aufsetzen möchten, sodass typische Fehler gleich am Anfang nicht auftreten. Und zeitgleich ist es natürlich auch so, dass der Lotse die Brücke betritt, wenn das Schiff in schwierigem oder unbekanntem Fahrwasser ist. Auf Projekte übertragen bedeutet es natürlich auch, wenn sich das Projekt in einer unbekannten oder gefährlichen Situation befindet, dass der Projektlotse dann auf die Brücke kommt, entsprechend berät und zur Seite steht. Ärmel hochkrempeln, mit anfassen, mit dem Ziel, das Projekt wieder in ruhigeres Fahrwasser zu bringen, aber dann auch wieder zu gehen.

Die erste Aufgabe: Überprüfung der Ziele

Jürgen Wulff: Wenn du ein Projekt aufsetzt, welche Fehler sollte man unbedingt vermeiden und wie sollte man stattdessen herangehen?

Friedrich Behnk: Eine meiner ersten Aufgaben ist immer die Überprüfung der Ziele. Ich wurde einmal beauftragt, ein recht großes Projekt aufzusetzen. Das Unternehmen hatte eine Ausschreibung bei einem der größten deutschen Logistikdienstleister gewonnen. Sie sagten „Friedrich, wir hätten das Projekt gerne vernünftig aufgesetzt und dann würden wir das gerne an einen internen Projektmanager übergeben, damit er das dann weiter steuert.“ In dem Initialmeeting habe ich gesagt „Lass uns doch als erstes bitte einfach mal die Ziele auf den Prüfstand stellen.“ Da gab’s natürlich erst einmal Erstaunen und Widerspruch. „Ja, aber die Ziele, die sind doch hier schon fest.“ Und das sah alles ganz gut aus. Aber wir haben dann die Ziele überprüft und festgestellt, dass die Ziele weder aufeinander abgestimmt noch konkret genug waren. Also mit konkret meine ich jetzt spezifisch, messbar, attraktiv, realistisch, terminiert. Auf den ersten Blick schienen die Ziele gut durchdacht. Aber als wir dann diese Messlatte angelegt haben, merkten wir, das geht gar nicht, da ist noch ganz viel Luft.

Wenn dieses Unternehmen jetzt mit den sehr weit gesteckten Zielen bei diesem recht großen deutschen Unternehmen ins Rennen gegangen wären, wären sie mit dem Projekt erst dann fertig geworden, wenn es dem anderen Unternehmen gepasst hätte. Und damit wäre der ROI definitiv auf einer ganz anderen Bahn gelandet.

Das ist gleichzeitig Don’t und Do. Als erstes die Ziele kritisch hinterfragen, auch wenn die Menschen im Raum sagen, das haben wir doch schon gemacht. Die Ziele gehören immer auf den Prüfstand.

Das Hauptziel muss eine Headline sein

Das Hauptziel, das muss eine Headline sein: Was soll das Projekt eigentlich bringen? Das muss man mit einem kurzen Satz ausdrücken können. Und dann hast du natürlich die ganzen Nebenziele, Teilziele und Unterziele. Wenn man sich da ein bisschen Mühe gibt und das Ganze richtig bearbeitet, dann purzeln automatisch die Teilprojekte raus. Also wenn du jetzt ein großes Projekt hast, brichst du das automatisch herunter. Das ist besonders für große Projekte extrem wichtig, weil du gleich deine ganzen Teilziele und Teilprojekte hast. Das ist damit schon die Grundlage des Projektstrukturplans oder Englisch work breakdown structure und von dort aus kann man sich weiterhangeln. Das bekommt man sozusagen als Beifang, der aber essentiell ist.

In dem anderen Projekt, von dem ich eben gesprochen habe, gab es am Anfang 18 Teilprojekte. Nachdem wir vom Hauptziel auf die Teilziele heruntergebrochen hatten und die work breakdown structure erstellt hatten, waren wir noch bei 13 Teilprojekten. Das ist zwar auch immer noch viel, aber wir haben das alles klar definiert und hatten saubere Schnittstellen.

Wenn das Fundament auf Sand gebaut ist, wird das nichts

Jürgen Wulff: Du gehst also sequenziell und doch klar strukturiert vor, ohne dich zu sehr in Details zu verlieren. Damit schaffst du eine solide Basis.

Friedrich Behnk: Das ist der erste Grundstein, wie bei einem öffentlichen Gebäude. Dann sind die ganzen Kollegen anwesend und der Grundstein wird gelegt. Aber das ist ja nur der erste Stein, bei dem man schon sehr viel falsch machen kann. Wenn das Fundament auf Sand gebaut ist, dann kann ich mir nachher noch so viel Mühe geben, das wird nichts. Was ich häufig in der Praxis sehe, dass versucht wird mit ganz viel Rudern, mit ganz viel Aktionismus, die Sache zu retten.

Der nächste Punkt ist, die work breakdown strucure als saubere Struktur aufzubauen. Ich bin ein großer Freund von Ordnung. Warum, das erkläre ich am besten einer Analogie zum Segeln auf dem Meer. Ich gehe von Zeit zu Zeit mit zwei Freunden, von denen einer Kapitän ist, auch mal nachts mit dem Boot raus. So, und jetzt muss man sich vorstellen, das Wetter kippt. Es wird auf einmal rockig. Es wird laut. Das Boot geht auf die Seite. Es kommt Wasser über. Und jetzt muss man auf einmal arbeiten. Also Segel wechseln oder wie auch immer. Wenn ich dann auf Deck bin, dann will ich mit einem Handgriff genau das haben, was ich brauche. Ich kenne mich auf dem Boot blind aus. Das heißt, ich greife einfach danach und habe das, was ich brauche, in der Hand. Sonst wird es nämlich gefährlich.

Wenn du jetzt die Ziele sauber definiert hast, nimmst du diese Anforderungen und packst sie einfach über das Ziel und fragst dich, wo können wir die denn einordnen. Entweder matcht eine Anforderung und sie zahlt auf das Projekt ein, dann wird sie übernommen. Im anderen Fall brauchen wir darüber nicht zu diskutieren. Wenn eine solche Anforderung übernommen werden soll, muss es einen Change Request im Projekt geben. Das ist ja auch okay. Man weiß ja am Anfang nicht genau, was da noch alles auf einen zukommt. So erleichtern klare Ziele die Diskussionen.

Das hatte ich auch genau an diesem Projekt. Es kam ein Teilprojektleiter zu mir und sagte, „Gut, dass wir das mit den Zielen gemacht haben. Ich konnte eine Anforderung gleich abschmettern. Ich musste mich gar nicht lange damit beschäftigen.“ Das heißt, diese Anforderung hat keine Zeit gestohlen. Es bedeutet ja nicht, dass du komplett dicht machst, aber du hast ein Instrument, was genau hilft, Anforderungen zu beurteilen.

Fortschritt in Prozent erlaubt keine klare Sicht

Auf die work breakdown structure kannst du dein Controlling sauber aufsetzen. Häufig werden die Leute gefragt, „Sag mal, wie weit bist du denn prozentual gesehen? Und wann haben wir das fertig?“ Innerhalb der ersten wenigen Monate sind wir dann schnell bei über 30 Prozent, dann irgendwann bei 70 Prozent. Die Schritte gehen dann in der Regel immer so um 5 Prozent oder 10 Prozent weiter. Man glaubt, man hat etwas ganz Tolles geschafft, weil ja 10 Prozent dazukommen. Und schließlich nähert man sich irgendwann dem Ende. Dann wird’s auf einmal hakelig und man feilscht um jeden einzelnen Prozentpunkt. Manchmal möchte man am liebsten auch wieder zurückgehen, weil Dinge doch nicht so weit sind, wie man dachte. Das ist natürlich politisch immer ganz schwierig. Als Projektleiter oder in der Rolle des Sponsors habe ich so überhaupt gar keine klare Sicht. Wo steht denn das Projektteam? Wie sind wir denn gerade on Track? Wie viel Geld haben wir denn gerade verbrannt?

Du brauchst also ein vernünftiges Controlling. Das hört sich jetzt alles staubtrocken und akademisch an. Man kann das aber auch relativ leichtgewichtig machen, wenn man eine work breakdown structure aufgebaut hat. Es ist ähnlich wie beim Navi im Auto. Wenn man weiß, da hinten ist das Ziel und das Navi hat mir ausgerechnet, wie lange ich brauche, muss ich nach der Zeit X ungefähr an einer bestimmten Stelle auf dem Weg sein. Das kann man sehr gut auf das Projektmanagement übertragen und hat dann ein einfaches Controlling, ohne die Sache zu überreizen.

Gute Projektmanager haben auch früher schon agil gearbeitet

Jürgen Wulff: Diese Vorgehensweise klingt jetzt sehr nach klassischer Planung. Funktioniert das auch bei agilen Projekten?

Friedrich Behnk: Ich bin ja nicht nur nach dem PMI als Projektmanager zertifiziert, sondern ich bin auch Scrum Master. Also für mich ist das kein Widerspruch. Ja, das hört sich erst einmal total old school und verstaubt an. Aber gute Projektmanager haben früher auch schon agil gearbeitet. Sprints hießen früher iteratives Projektmanagement oder iteratives Vorgehen. Das habe ich 1999 an der Hochschule auch schon gelernt. Da gab es Scrum noch gar nicht. Da haben wir über Rapid Prototyping und iteratives Vorgehen gesprochen. Nichts anderes ist ein Sprint ja. Auch bei agilen Projekten habe ich eine work breakdown structure.

Viele „Agilos“ glauben, bei der Wasserfall-Vorgehensweise muss erst mal ein halbes Jahr planen. Das stimmt nicht. Ich muss nicht ein halbes Jahr planen. Und auch bei klassisch aufgesetzten Projekten kommen Änderungen vor. Klar, damit tut man sich häufig schwer. Beim Agilen sind allein durch das Mindset die Änderungen willkommener.

Auch über die Ziele könnte man sagen, ganz schön klassisch und verstaubt. Aber übertragen wir das doch jetzt mal auf den Beginn des Projekts. Ich glaube nicht, dass agile Projekte um deren selbst willen durchgeführt werden, auch sie haben konkrete Ziele. Und wenn ein agiles Projekt um seiner selbst willen durchgeführt werden würde, müsste man das als Ziel formulieren, um das Projekt zu schützen.

Jürgen Wulff: Wir haben bei den agilen Projekten ja eine gewisse Ziel-Flexibilität. Das heißt, wir werden vielleicht nicht 100 Prozent da ankommen, wo wir ursprünglich hin wollten, aber wir werden immer noch im Umfeld des eigentlichen Zieles landen. Wenn ich ein Haus bauen will, wird es nicht auf einmal im Swimmingpool. Aber es kann sein, dass sich eben das eine oder andere Fenster mehr habe. Vielleicht habe ich noch einen Carport dazu gebaut, weil das einfach notwendig erschien.

Friedrich Behnk: Dazu kann es bei beiden Arten der Projektdurchführung kommen. Du kannst zum Beispiel nach der Hälfte in einem klassisch gemanagten Projekt feststellen, dass sich das niemals amortisieren wird. Und dann kannst du sagen, auf Basis dieser Zahlen stampfen wir das Projekt ein. Das geht bei einem agilen Projekt auch. Du lernst während das Sprints auf einmal, die Idee ist ganz schön, aber es war eine fixe Idee. Wir müssen uns hier um 90 Grad drehen. Das ist im Grunde genommen das Gleiche.

Klartext hilft auch beim Abbruch von Projekten

Jürgen Wulff: Ich empfehle meinen Kunden bei Projekten immer, Ausstiegspunkte zu definieren. Das Projekt ist dann nicht gescheitert, sondern sie überprüfen an gewissen Stellen, ob es noch sinnvoll ist, weiterzumachen. Wenn das nicht der Fall ist, fahren sie das Projekt einfach gezielt herunter. Ich erlebe häufiger, dass Projekte aus politischen Gründen nicht mehr gewünscht wird und deshalb versanden. Es wird einfach nicht mehr erwähnt und es wird nicht mehr daran gearbeitet. Es wird allerdings nie offiziell beendet.

Friedrich Behnk: Da müssen wir uns dann an der Stelle fragen: Was passiert mit den Menschen? Das Projekt war ja mein Baby. Und auf einmal steht das nicht mehr auf Prio A. Ich erhalte keine klare Ansage. Ich bin noch weiterhin Projektmanager und werde genötigt, ein krankes Pferd ohne Futter zu reiten.

Jürgen Wulff: Das bindet Energie und es demotiviert auch für neue Projekte. Wer garantiert denn, dass das nächste Projekt nicht genauso wieder wie eine neue Sau durchs Dorf getrieben wird, um dann auch irgendwo auf der Müllhalde der versandeten Projekte zu landen.

Friedrich Behnk: Dann lieber wirklich Klartext, auch schon im Vorfeld, damit die Menschen auch wissen, wie gespielt wird. Dann ist das Projekt halt nicht mehr auf der Agenda und es wird sauber beendet. Die Project-Closing-Phase tritt dann eben ein bisschen früher ein. Dann sollte man die Retrospektive nicht vergessen, die Rückschau. Was haben wir denn gelernt? Du lernst in jedem Projekt etwas, auch wenn das Projekt abgebrochen wird. Dieses Wissen ist wirklich Gold wert. Aber häufig sind alle schon so demotiviert und dann wird dieses Wissen nicht mehr gesammelt. Das ist wirklich schade, weil genau das Wissen wahrscheinlich bei dem nächsten Projekt helfen kann, die Ziele richtig zu setzen und das Projekt zum Erfolg zu führen.

Auch für kleine Projekte lohnt eine Visualisierung für den Überblick

Jürgen Wulff: Das, was wir jetzt besprochen haben, kann man ja nicht nur für große Projekte durchführen, sondern auch auf Projekte im kleineren Rahmen.

Friedrich Behnk: Also ich persönlich, wenn ich Projekte für mich selbst oder im sehr kleinen Rahmen durchführe, setze mir schon ganz klar mein Ziel und ich baue mir auch ein Gantt-Chart als Visualisierung auf. Dafür nutze ich eine Software. Ich mache mir bewusst: Wann will ich was fertig haben? Allein, um mir jedes Mal einen Überblick zu verschaffen. Wo stehe ich? Wie performe ich? Habe ich mich gerade gnadenlos selbst überschätzt?  Das ist manchmal ganz erhellend. Notfalls kann ich die Überprüfung sogar in Excel machen.

Natürlich sind mir meine Ziele klar, aber wenn ich sie aufschreibe, dann sieht man sofort, so geht’s nicht. Und dann weiß ich, die Ziele sind mir mitnichten klar. Häufig sprechen wir auch noch mit anderen Leuten und wollen unsere unklaren Ziele mit denen diskutieren. Wir gehen davon aus, dass sie auch noch das gleiche Bild in deren Kopf haben. Die Ziele müssen dafür vorher ganz klar sein.

Die Strukturierung sollte keine Doktorarbeit sein

Wenn wir dann mit der Strukturierung anfangen, neigen wir häufig dazu, eine Doktorarbeit daraus zu machen. Das heißt, wir verlieren uns da in Details. Hier kann das agile Vorgehen helfen. Eigentlich total cool. Also wir nehmen sozusagen einen Sack, packen Aufgaben rein und die arbeiten wir ab. Dann schauen wir, wie viel wir geschafft haben, antizipieren das auf die nächste Zeit und gehen so schrittweise voran. Du verlierst dich nicht in zu großen Abhängigkeiten, wie du es hast, wenn du gleich alles durchplanen willst.

Jürgen Wulff: In dem Zusammenhang finde ich persönlich wichtig, bei allen Aufgaben im Blick zu behalten, ob diese wirklich auf das Ziel einzahlen. Ich als Autor kenne das sehr gut. Man kann ja die ganze Welt erklären, aber letztendlich ist immer die Entscheidung zu treffen, was ist wirklich so wichtig für das Buch und den Leser und was ist vielleicht ein Randthema? Was sollte man einfach weglassen? Manchmal besteht die Kunst ja darin, zu fokussieren und zu reduzieren. Was ist ein Muss, was ist ein Kann und was ist die Verzierung?

Friedrich Behnk: Das funktioniert auch nur, wenn du dir über die Ziele klar bist, egal, ob du jetzt klassisch oder agil vorgehst. Deswegen wiederhole ich hier nochmals: Schreibe dir die Ziele auf und versuche, sie SMART zu formulieren. Verliere dich dann bei der Strukturierung und Planung nicht im Detail. Wenn du dein Projekt so aufsetzt, dann hast du eine solide Grundlage und kannst loslegen.