Jeder Projektleiter steht vor folgenden Fragen, wenn er sein Projekt gegenüber unterschiedlichen Stakeholdern vertritt:

• Wie verkaufe ich mein Projekt?

• In welcher Form stelle ich es gegenüber welchen Stakeholdern dar?

• Kann ich den Kommunikationsplan so erstellen, wie ich ihn brauche und wie die Firma es erwartet?

• Wie kann ich mein Team sowie seine und meine Leistungen gut und korrekt präsentieren?

Hinter diesen vordergründigen Fragen stehen weitergehende Überlegungen:

• Was erwarten der Sponsor und der Lenkungsausschuss von mir?
• Wie viel Wahrheit vertragen welche Stakeholder?
• In welcher Managementkultur befinde ich mich?
• Welchen Eindruck von mir persönlich gewinnen die Stakeholder?
• Will und brauche ich einen Folgeauftrag von diesem Auftraggeber?

Von den Antworten auf diese Fragen hängt ab, wie der Projektleiter Projektmarketing und -kommunikation gestaltet: Die Bandbreite reicht hier vom Understatement bis zur reißerischen Propaganda.

Projektmarketing – eine zweischneidige Sache

Geschicktes Marketing kann Projekte durchaus über Krisenzeiten retten. Ein niederländischer Kollege erzählte mir vor ein paar Jahren, dass bei ihm im Unternehmen die Geschäftsführung zu viele Projekte gleichzeitig begonnen hatte. Unter anderem sollte auch eine Betriebs-Kindertagesstätte (Kita) ausgebaut werden. Als in einer Wirtschaftskrise ein Auftragsrückgang zu verzeichnen war, wurden alle Projekte angehalten und hinsichtlich ihres Nutzeffekts für die Firma evaluiert. Dann sollte entschieden werden, welche Projekte weitergeführt und welche gestoppt werden sollten. Nur das Kita-Ausbauprojekt nahmen die Verantwortlichen von der Untersuchung aus und ließen es weiterlaufen. Der Projektleiter und die Sponsoren des Kita-Projekts hatten vorher intensives Marketing betrieben. Sie hatten den Führungskräften beständig aufgezeigt, was es für die Firma, die Mitarbeiter und das Image der Firma bedeutete, wenn das Projekt gestoppt oder auch nur angehalten werden würde. Dadurch hatten Sie eine allgemeine Stimmung geschaffen, die es der Geschäftsführung unmöglich machte, dieses Projekt auch nur in Frage zu stellen.

Das Projektmarketing war in diesem Fall ein voller Erfolg, zumindest aus Sicht des Projekts. Aus Unternehmenssicht kann Projektmarketing dagegen dazu führen, dass die falschen Projekte gestoppt werden. Theoretisch ist es eigentlich nicht sinnvoll, gegenüber allen Stakeholdern das Projekt nur in den schönsten Farben zu schildern. Schließlich haben manche von ihnen ja die Aufgabe, dem Projekt bei Schwierigkeiten zu helfen. Allerdings stehen in der Praxis einer ehrlichen Darstellung des Projektstatus gegenüber den Stakeholdern einige Hürden im Weg.

Wie viel Ehrlichkeit vertragen Stakeholder?

Was soll der Projektleiter machen, wenn er z.B. den Sponsor selbst als das größte Projektrisiko identifiziert? Kann er diese Risikoanalyse den anderen Stakeholdern zeigen oder im Lenkungssausschuss vorstellen? Jeder Projektleiter steht aus verschiedenen Gründen immer wieder vor der Frage: "Wie viel Ehrlichkeit und Transparenz verträgt der Stakeholder?" Ich kenne viele Projektleiter, die deshalb zwei Risikolisten führen: eine interne für sich selbst und eine externe für den Lenkungsausschuss und andere Stakeholder.

Gleiches gilt auch bei der Stakeholder-Analyse. Kann ich in einem offiziellen Projektdokument darstellen, dass ich den Sponsor oder einen anderen wichtigen Stakeholder als Gegner des Projekts oder zumindest als neutral einschätze? Dies ist nicht unrealistisch, denn oft müssen Top-Manager aus formellen Gründen oder weil ihre Vorgesetzten andere Prioritäten für das Unternehmen sehen als sie selbst, als Sponsor für ein Projekt auftreten, obwohl sie weder Zeit noch Motivation dafür haben.

Darf es Probleme geben?

Ein wichtiger Aspekt des Projektmarketings ist, den Stakeholdern den Erfolg des Projekts zu "verkaufen". Ich kann als Projektleiter nur dann offen über die Probleme berichten, wenn die Mitglieder des Lenkungsausschusses für eine ehrliche Kommunikation bereit sind, um mich entsprechend unterstützen zu können. Wenn sie hingegen eine "Yes, we can!“-Mentalität erwarten, wird niemand etwas von Problemen hören wollen. Auch kann ich nicht in jedem Lenkungsausschuss Ross und Reiter für die Probleme benennen, sondern muss mich sehr diplomatisch ausdrücken.

Ich habe hierfür sehr unterschiedliche Situationen erfahren – ein extremes Beispiel schildere ich weiter unten. Eines hatten bisher fast alle meine Projekte gemeinsam: Die echte, offene, ehrliche Wahrheit wollte niemand hören bzw. es gab in jedem Lenkungsausschuss stets ein Mitglied, das vom geschilderten Problem nichts hören wollte.

Es ist aber auch nicht ratsam, ein Projekt als absolut problemlos darzustellen, da dies niemand glaubt. Für das Projektmarketing gegenüber dem Lenkungsausschuss ist es für den Projektleiter am vorteilhaftesten, wenn er darstellt, dass es viele Probleme gibt, die er aber alle aufgrund seiner hohen Kompetenz voll im Griff hat (s. "Der Projektleiter – "Versager" oder "Held"?", Projekt Magazin 13/2013).

Was ist mein Eigeninteresse?

Der dritte Aspekt, über den meiner Erfahrung nach jeder Projektleiter nachdenkt, ist die eigene Position: "Wie stehe ich als Repräsentant des Projekts da?" Wenn der Projektstatus dunkelrot ist, weil z.B. ein Linienverantwortlicher die bereits genehmigten Ressourcen kurzfristig wieder abgezogen hat, kann ich objektiv gesehen nichts dafür. Aber kann ich das auch so darstellen? Was ist, wenn dieser Linienverantwortliche im Lenkungsausschuss sitzt oder vielleicht sogar der Sponsor ist?

Bevor ich dem Auftraggeber oder dem Lenkungsausschuss von Schwierigkeiten berichte, muss ich als Projektleiter einschätzen, ob ich Unterstützung bekommen werde, so dass ich das Projekt doch noch frist- und budgetgerecht abliefern kann. Wenn ich dagegen damit rechnen muss, von den Verantwortlichen "an die Wand gedübelt" zu werden, hilft mir die Wahrheit bei meinem Problem nicht weiter. Aber darf ich andererseits die Führungskräfte wissentlich anlügen, weil ich befürchten muss, dass sie ansonsten "mit gesundem Halbwissen" und falschem Aktionismus das Projekt gefährden?

Als Projektleiter muss ich mir zudem die Frage stellen, was es rechtlich bedeutet, wenn ich vollständig ehrlich kommuniziere oder eben nicht ganz die Wahrheit sage. Nehmen wir einmal an, dass eine Konventionalstrafe von 10.000 Euro pro Tag Verzögerung droht. Wenn ich bei der Überprüfung des Projektstatus die Gefahr einer Verzögerung sehe, kann es besser sein, nicht gleich die Alarmglocken schrillen zu lassen, sondern zu versuchen, die Situation zu klären, ohne dass jemand etwas davon merkt. Manchmal muss man zumindest intern die Gefahr darstellen, um entsprechende Unterstützung zu bekommen. Wenn aber alle Stricke reißen, muss ich wohl oder übel gegenüber allen die Wahrheit sagen, da ich sonst des Betrugs bezichtigt werde. Meiner Erfahrung nach gibt es hier keinen Königsweg. Meist ist es aber besser, von Anfang an mit offenen Karten zu spielen, dann ist die andere Partei meiner Erfahrung nach eher gewillt, eine einvernehmliche Projektlösung als eine Gerichtslösung anzustreben.

Ich habe mehrmals die Situation erlebt, dass Auftraggeber und Auftragnehmer in einem Projekt, das ab einem gewissen Zeitpunkt nicht mehr rund lief, die restliche Projektlaufzeit damit verbrachten, sich gegenseitig den Fehlschlag des Projekts in die Schuhe zu schieben. Hätten sie dagegen gemeinsam die Probleme angepackt, hätte es durchaus noch mit einem akzeptablen Ergebnis abgeschlossen werden können.

Potemkinsche Fassaden für Projekte

Das sind viele Fragen, die sich jeder Projektleiter implizit oder explizit stellt. Auf jeden Fall kommt er öfter als ihm vielleicht lieb ist in die schwierige Lage, unangenehme Informationen kommunizieren zu müssen. Sehr viele Projektleiter bauen dazu "Potemkische Fassaden" (s. Infokasten) auf.

Dies kann aus ganz unterschiedlichen Motiven geschehen. Z.B. können diese Fassaden dem Projektleiter helfen, das Projekt ohne störende Einmischungen des Top-Managements weiterhin in seinem Sinne zu steuern und erfolgreich abzuschließen. Viele Projektleiter empfinden die Probleme innerhalb ihres Projekts als zu klein, als dass sie diese nach außen kommunizieren müssten. Dies geht allerdings nur solange gut, wie sie sich nicht selbst überschätzen.

Ein anderer, häufig anzutreffender Grund für diese Fassaden ist, dass der Projektleiter das Projekt in Ruhe bis zu dem Punkt bringen möchte, ab dem es nicht mehr gestoppt werden kann, sondern höchstens noch der Umfang reduziert werden kann. Dann hat sein Team wenigstens nicht umsonst gearbeitet. Projektleiter, die so handeln, wollen vermeiden, dass ihr Projekt vorzeitig abgebrochen wird, was ihre Teammitglieder und sie selbst demotivieren würde.

Diese und manch andere Gründe sind zwar nachvollziehbar, aber auch riskant. Wenn die Potemkinschen Fassaden einstürzen und die Topmanager dann sehen, welche Probleme sich dahinter angesammelt haben, kann es für den Projektleiter kritisch werden. Er setzt nicht nur seinen Ruf aufs Spiel, sondern evtl. sogar seine ganze Karriere.

Projektmarketing und Projektkommunikation sind zugleich heikle Themen und kritische Erfolgsfaktoren. Selbst wenn ein Projektleiter sein Projekt noch so gut durchführt, wird dies keiner wahrnehmen oder entsprechend würdigen, wenn er es nicht gut verkauft.

Auch das Gegenteil habe ich erlebt. Projekte, die objektiv gesehen gar nicht gut liefen, wurden vom Management aufgrund guten Marketings positiv wahrgenommen. Deren Projektleiter, die meiner Meinung nach weniger kompetent waren, genossen im Unternehmen hohes Ansehen. In einem Unternehmen hatte ich einen Kollegen, der während unserer gemeinsamen Zeit aus meiner Sicht kein Projekt erfolgreich abschloss. Trotzdem sagte unser gemeinsamer Chef immer wieder, dass er sein bester Projektleiter sei und dass er ihm blind vertraute. Offensichtlich gelang es meinem damaligen Kollegen bestens, sich gut darzustellen.

Die Potemkinsche Projektfassade – ein Beispiel aus der Praxis

Die folgende Geschichte spielte sich tatsächlich so ab, allerdings habe ich die Details verfremdet, sodass weder Personen noch Unternehmen erkannt werden können. Wenn Sie dennoch ein Déjà-vus haben, liegt dies daran, dass die geschilderte Situation häufig anzutreffen ist.

Es war mein erster Tag als Projektleiter in einem neuen Unternehmen. In den Vorstellungsgesprächen hatte ich den Eindruck, die Firma mache gutes Projektmanagement, hätte interessante und spannende Projekte und ein professionelles Projektvorgehen. Mein neuer Vorgesetzter nahm mich in Empfang, um mich nach einer Stunde an einen anderen Kollegen weiterzuleiten. Dieser wusste nichts mit mir anzufangen, weil niemand ihn darauf vorbereitet hatte und er, wie alle anderen, eigentlich keine Zeit für mich hatte. Alle waren im Stress.

Der Grund dafür war, dass sie gerade ein großes Software-Release mit einem mittleren achtstelligen Budget in Produktion gesetzt hatten und mit den Nacharbeiten beschäftigt waren. Offensichtlich war das Release sehr wichtig und allen war bewusst, dass es höchste Priorität hatte, dieses Projekt schnell und mit guter Qualität abzuschließen. Ich war beeindruckt: Alle Kollegen schienen am selben Strang zu ziehen, engagierten sich und wollten den Erfolg. Zwar sah ich meinen Chef in der ersten Woche nicht wieder, aber ich hatte das Gefühl, hier richtig zu sein.

Eine fröhliche Party mit Fragezeichen

Zwei Wochen später organisierte das Management eine große Party. Das Team hatte das Release erfolgreich abgeschlossen. Die ganze Firma freute sich darüber und war erleichtert, dass der Stress vorbei war. Ich hörte, dass viele Mitarbeiter nicht nur bis spät in die Nacht, sondern auch an mehreren Wochenenden gearbeitet hatten, um diesen Erfolg sicher zu stellen. Ich war auch zur Party eingeladen und fühlte mich ein wenig deplatziert, da ich nichts zu diesem Release beigetragen hatte. Aber ich nutzte die Gelegenheit, um mich mit den neuen Kollegen zu unterhalten und mich mit Ihnen bekannt zu machen.

Dabei hörte ich erste Zweifel am Erfolg. Es waren nicht die Manager und Projektleiter, sondern die Entwickler, die mir ansatzweise eine etwas andere Sicht präsentierten. Da sie mich noch nicht so gut kannten, waren sie sehr zurückhaltend und sprachen für mich in Rätseln. Ich nahm aber zwischen den Zeilen wahr, dass nicht alle das Release als vollen Erfolg sahen. Ich hatte den Eindruck, sie wollten mich auf die neuen Aufgaben vorbereiten oder gar warnen.

Während der nächsten Tage hörte ich mehr von diesen Andeutungen und ich begann, mir Protokolle aus den Sitzungen dieses Projekts anzusehen. Dies wollte ich sowieso tun, um mehr über Projektmitarbeiter, Entscheidungsprozesse und Rollen von Mitarbeitern in Projektteams zu erfahren und um daraus für meine künftigen Projekte zu lernen.

Ich fand heraus, dass das Release viel früher in Produktion hätte gehen sollen und der ursprüngliche Termin mehrere Monate nach hinten verschoben worden war. In Gesprächen mit Projektleiterkollegen stellte sich heraus, dass regulatorische Änderungen des Gesetzgebers Grund für diese Verschiebung gewesen waren. Zum geplanten Termin war noch nicht alles fertig entwickelt, geschweige denn getestet gewesen. Die verordnete Verschiebung hatte sich als Glücksfall für das Unternehmen und das Projektteam erwiesen: Das Team hatte die restlichen Arbeiten ausführen können und der Projektleiter hatte nichts Negatives an das Management berichten müssen.

Weiterhin las ich in den Protokollen, dass die Projektleiter und Teilprojektleiter trotz der Verschiebung alle Budgets eingehalten hatten. Das verwunderte mich. Also schaute ich nach den Anfangsbudgets und den ursprünglichen Aufwandschätzungen in den Unterlagen. Die Zahlen, die ich fand, waren viel niedriger als die Ist-Kosten bei Projektabschluss! Jetzt wurde ich neugierig.

Ein Blick hinter die Fassade

Als erstes untersuchte ich das Risikomanagement, da dies für mich ein aussagekräftiger Indikator für die Qualität des Projektmanagements ist. Ich stellte u.a. fest, dass es kein Risikomanagement gab, so wie ich es verstehe. Risiken wurden z.B. erst dann als solche dokumentiert, wenn sie eine Eintrittswahrscheinlichkeit von 100% hatten. Wenn ein Risiko mit Sicherheit eintritt, ist es aber kein Risiko mehr, sondern bereits ein Problem.

Weiterhin schaute ich mir die Statusreports im Projektportal an. Ich konnte sie nicht nachvollziehen. Die Kommentare waren klar, aber die Ampelindikatoren, die Budgets und die Art der dort vorgegebenen Earned-Value-Methode verstand ich nicht. Wann die Projektleiter rot, gelb oder grün gemeldet hatten, und welche Kriterien dazu geführt hatten, war für mich nicht nachvollziehbar. Im Projektmanagement-Handbuch (PM-Handbuch) standen Kriterien, welche die Projektleiter offensichtlich nicht einhielten. Ich fand grüne und gelbe Einträge, die aus meiner Sicht, verglichen mit den Kriterien im PM-Handbuch, geschönt aussahen und eigentlich rot hätten sein müssen.

Dieser Eindruck, den ich aus den alten Statusberichten gewonnen hatte, verstärkte sich in den nächsten Wochen bei den Projektbesprechungen. Der Teamleiter der Projektmanager beharrte immer wieder darauf, dass wir nichts beschönigen sollten, sondern die Ampeln gemäß den gesetzten Kriterien stellen sollten. Allerdings war er in seiner Kommunikation inkonsistent, so dass ich nach einigen Besprechungen nicht mehr wusste, wann ich rot oder gelb berichten sollte. Auch meinen Kollegen schien es so zu gehen. Da der PM-Teamleiter zudem gegenüber den Projektleitern sehr aggressiv auftrat und sie unter hohen Druck setzte, wenn sie Probleme meldeten, vermieden es die Projektleiter immer mehr, einen roten Ampelstatus zu berichten, solange dies möglich war.

Die Situation verschärfte sich, als der PM-Teamleiter wechselte. Der neue vertrat die Meinung, dass wir alle viel zu negativ eingestellt wären. Es sei eigentlich unmöglich, den Status eines Projekts mit "Rot" zu bewerten, da dies bedeuten würde, dass das Projekt kaum noch eine Chance auf Fertigstellung hätte. So lange es noch Chancen für einen erfolgreichen Projektabschluss gäbe, könne der Projektstatus höchstens gelb sein. In diesem Sinne berichtete er auch selbst an seine Chefs. Er unterstellte uns, dass wir eine viel zu hohe Qualität liefern wollten und deshalb den Projektstatus bereits dann auf "Rot" setzen würden, wenn die "Nice-to-Haves" nicht mehr umgesetzt werden könnten. In seinen Augen war der Projektstatus "Grün", solange noch ein ablauffähiges Produkt geliefert werden konnte.

Schließlich fand ich auch noch heraus, warum alle Projekte stets ihr Budget einhielten. Der Grund dafür war das Controlling. Bei der Projektplanung wurden die Aufwände geschätzt und dann vom Management genehmigt. Die Mitarbeiter mussten daraufhin ihre Stunden gemäß diesen Aufwandsschätzungen buchen und nicht, wie sie tatsächlich daran gearbeitet hatten. Wenn der Projektleiter den Aufwand für eine Aufgabe mit fünf Tagen abgeschätzt hatte, durfte der daran arbeitende Entwickler auch nur fünf Tage darauf buchen. Die Hoffnung dabei war, dass die Ist-Aufwände mal höher und mal geringer als geschätzt ausfallen würden und sich dadurch insgesamt ausgleichen würden, sodass am Ende der Gesamtaufwand stimmte. Das galt für interne Entwickler. Von Consultants erwartete die Firma, dass diese mehr als acht Stunden für ihre Tagessätze arbeiteten und nicht mehr Stunden buchten, als sie geschätzt hatten. Wenn dies nicht mehr ausreichte, stellten die Projektleiter Change Requests, die das Budget erhöhten.

Am Ende verglich das Controlling nicht das ursprünglich geplante Budget mit dem tatsächlichen Aufwand, sondern den gebuchten Aufwand mit dem Planbudget plus Change Requests. Auf diese Weise blieb natürlich jedes Projekt immer im Budget.

Des Rätsels Lösung und vergebliche Liebesmüh

Auf die Fragen, die sich mir bei der Party gestellt hatten, hatte ich jetzt die Antworten gefunden: Wenn man nur die künstlich geschaffene Fassade betrachtete, war das Projekt ein großer Erfolg, da das Team scheinbar pünktlich die geforderten Funktionen geliefert und das Budget eingehalten hatte. Dies war die Sicht des Managements. Die Mitarbeiter, die hinter diese Fassaden blicken konnten, wussten, dass nur ein glücklicher, äußerer Umstand dem Projekt mehr Zeit verschafft hatte und dass das offizielle Budget nichts mehr mit der ursprünglichen Planung zu tun hatte.

In diese Situation kam ich mit meinen Vorstellungen von Projektmanagement, Projekterfolg, Budgetierung und Termineinhaltung. Ich war voller Engagement, meine Erfahrungen in die Firma einzubringen und das Projektmanagement zu verbessern oder zumindest zusätzliche Methoden einzubringen, die dem Unternehmen und den Projektleitern weiterhelfen konnten.

Nach einigen Wochen schlug ich einige kleine Veränderungen vor, z.B. beim Risikomanagement. Der PM-Teamleiter lehnte diese Vorschläge mit folgender Begründung ab: "Schau Dir unser letztes Release an. Wir haben alles richtig gemacht. Wir brauchen nichts zu ändern. Wir hatten die Risiken im Griff. Auch ohne ausuferndes Risikomanagement."

Diese Abfuhr erschreckte mich. Grundsätzlich habe ich die Einstellung, dass es stets ein mehr oder weniger großes Verbesserungspotenzial gibt. Ich war entsetzt, dass nicht wenigstens mal darüber nachgedacht oder diskutiert wurde. Selbst wenn man das Release als vollständig erfolgreich betrachtete, hieß das aus meiner Sicht noch lange nicht, dass es keine Verbesserungsmöglichkeiten gibt. Insbesondere das Risikomanagement war nach den mir zur Verfügung stehenden Informationen sehr verbesserungsbedürftig.

Dennoch versuchte ich weiterhin, an anderen Stellen Verbesserungen oder Veränderungen vorzuschlagen.

Der PM-Teamleiter führte mit den Projektleitern eine Projekt-Nachbetrachtung durch. Ich nahm daran teil, um daraus für meine Projekte in diesem Unternehmen zu lernen. Im Anschluss sprach ich mit dem PM-Teamleiter, um ihm meine Erfahrungen mit solchen Meetings zu schildern und einige Vorschläge zu machen.

Ich regte an, Projektnachbetrachtungen nicht gleich nach dem Go Live durchzuführen, sondern etwas später, wenn die Emotionen abgeklungen sind und die Beteiligten klarer beurteilen können, wie erfolgreich das Projekt wirklich war und welche Nacharbeiten notwendig waren. Weiterhin empfahl ich, zur Vorbereitung den Teilnehmern vorab einen Fragenkatalog zuzusenden, den sie entweder bereits vorher ausgefüllt zurücksenden oder zumindest als Vorbereitung auf das Meeting verwenden sollten. Meiner Erfahrung nach hilft ein solcher Fragenkatalog dem Projektleiter dabei, während des Meetings einen roten Faden zu haben. Dies ist vor allem dann nützlich, wenn doch noch Emotionen hochkochen sollten, weil z.B. die Mitarbeiter offene Rechnungen begleichen wollen, die sie während des Projekts unterdrückt hatten, um den Erfolg nicht zu gefährden. Zum Schluss war ich noch der Meinung, die Teams sollten maximal drei Punkte aufnehmen, die sie für das nächste Projekt verbessern wollen und nicht 19, wie es hier der Fall war. Meiner Meinung nach kann weder der Projektleiter so viele Punkte überwachen noch können die Mitarbeiter im nächsten Projekt an 19 Punkte denken, die sie anders machen sollen.

Seine Reaktion darauf war: "Unser letztes Release war größer, als alles was du bisher geleitet hast. Wir haben dabei alles richtig gemacht und brauchen nichts zu verbessern. Wir wissen, wie man Projekte und Releases in dieser Größenordnung macht."

Ich entgegnete ihm: "Wieso machst Du dann überhaupt eine Projekt-Nachbetrachtung und wieso hast Du 19 Verbesserungspunkte definiert, die im nächsten Projekt besser gemacht werden sollen?"

Ich bekam keine Antwort, er empfand mich wohl als Querulant. Oder hatte ich einen wunden Punkt getroffen? Vielleicht hatte er das Projektreview nur gemacht, "weil man das halt so macht" oder weil der Prozess es vorschrieb?

Und so ging es weiter. Es war unmöglich, auch nur einen Vorschlag anzubringen. Einige Monate später, als ich den Eindruckt hatte, ich wisse sehr genau, wie Projekte laufen, das Vorgehensmodell verstand, und von den Kollegen wusste, was nicht so gut lief, machte ich einen letzten Versuch. Ich bereitete eine Präsentation für das Projektleitertreffen vor, in der ich drei Verbesserungsvorschläge vorstellte und ausführlich begründete:

• Umstellung des Wasserfallmodells auf RUP oder Scrum, auf jeden Fall aber auf eine agilere Vorgehensweise als bisher.
• Anpassung des Risikomanagements
• Verbesserung der Statusreports

Aber erneut wurden alle meine Vorschläge mit dem Totschlagargument des erfolgreichen Release abgeschmettert. Auch meine Hinweise, dass sie den ursprünglichen Termin nicht hätten einhalten können und es schon deshalb Gründe geben könnte, sich Gedanken über Verbesserungen zu machen, akzeptierten sie nicht. Vor allem der PM-Teamleiter, der auch für das PM-Handbuch zuständig war, schien nicht bereit zu sein, auch nur einen Gedanken an Verbesserungen zu verschwenden. Das große und erfolgreiche Projekt bewies aus seiner Sicht, dass das bestehende Projektvorgehen perfekt war.

Ich galt als Außenstehender, der keine Ahnung hatte und nur herumkritisierte.

Die Fassade bricht zusammen

Das nächste Release war das erste, an dem ich verantwortlich mit meinem Team teilnahm. Es lief wesentlich schlechter, sodass Anforderungen kurz vor Go Live gestrichen werden mussten. Die Tester hatten viele Testfälle nicht ausgeführt und die Entwickler kamen mit den Fehlerbehebungen nicht hinterher. In einem Projekt des Releases wurden in kurzer Zeit 600 Fehler gefunden. Es stellte sich heraus, dass die Tester und Entwickler unterschiedliche Spezifikationen verwendeten.

Aus Gewohnheit wurde bereits einen Tag nach Produktivsetzung im Intranet vom IT-Management ein Artikel veröffentlicht, der den Erfolg des Projekts beschrieb. Ein wichtiger Kunde, der die meisten Anforderungen eingegeben hatte, sagte in einem Managementmeeting nach der Produktivsetzung: "Das war der schlechteste Go Live, den wir in der Firma je hatten. Ihr schreibt im Intranet wie erfolgreich das Projekt war, vielleicht war dies ja aus IT-Sicht so. Wir können aber die Applikationen nicht benutzen." Die anderen Kunden äußerten sich ähnlich.

Die Quintessenz war, dass der PM-Teamleiter ab diesem Release das Risikomanagement verändert in das PM-Handbuch aufnahm. Weiterhin wurden zwei der 19 Punkte der letzten Projektnachbetrachtung in das Statusreporting aufgenommen. Von den ursprünglich 19 Verbesserungen hatten die Projektleiter und Mitarbeiter keine einzige einheitlich verbessert. Der eine oder andere Entwickler hatte vielleicht ein oder zwei Punkte übernommen, aber dies war weder dokumentiert noch sichtbar.

Etwas später, nach dem nächsten Release, das nicht viel besser lief, führte ein Team Scrum ein und lieferte. Scrum wurde neben dem Wasserfallmodell in das PM-Handbuch aufgenommen. Ein Kunde machte danach seine Aufträge davon abhängig, dass wir mit Scrum arbeiteten.

Fazit: Man darf nicht auf das eigene Projektmarketing hereinfallen

Ein erfolgreiches Projekt kann ein Segen für ein Unternehmen sein, selbst wenn es dies nur vermeintlich war. Das Erfolgsgefühl kann Mitarbeiter motivieren, Lust auf ein neues Projekt erzeugen und einen positiven Kreislauf in Gang setzen. Es kann aber auch die Sicht vernebeln. Ich habe bisher kein einziges "perfektes Projekt" gesehen. Jedes Projekt und jedes Projektvorgehen hat Verbesserungspotenzial. Auch in diesem Fall wollte ich nichts schlecht reden, sondern lediglich helfen, das nächste Projekt noch besser zu machen. Die Manager waren jedoch "erfolgstrunken" und wollten davon nichts hören. Die Strafe dafür folgte auf dem Fuß.

Das muss nicht sein, wenn das Unternehmen eine Kultur aufbaut, in der alle daran interessiert sind, sich und die Firma permanent zu verbessern und die Kultur eines "lernenden Unternehmens" einzuführen. In dieser Kultur werden Verbesserungsvorschläge und konstruktive Kritik als positiv und hilfreich aufgenommen. Jeder schätzt die Meinung des anderen und unterstellt implizit, dass der Kollege Kommentare und Meinungen abgibt, damit die Firma sich verbessert und nicht, um sich damit auf Kosten anderer zu profilieren. Wenn alle Beteiligten immer davon ausgehen, dass es nur um das Ziel der Firma geht und nicht um persönliche Befindlichkeiten, wäre allen geholfen.

Ein Vergleich: Der FC Bayern gewann 2013 das Triple. Würde er einfach so weitermachen wie bisher, würde der FC Bayern sicherlich keine Rolle in der nächsten Champions-League Saison spielen. Ein neuer Trainer und neue Spieler sorgen für die notwendigen Änderungen um sich nicht auf den Lorbeeren auszuruhen. Das garantiert keinen Erfolg, es macht ihn aber wahrscheinlicher.

Später lernte ich in einer Management-Weiterbildung das Graves-Modell kennen, das ich im Folgenden kurz vorstelle (Bär u.a., 2010). Seitdem passieren mir derartige Fehler nicht mehr.

Orientierungshilfe: Das Graves-Modell

Der US-amerikanische Psychologieprofessor Clare W. Graves (21.12.1914 – 3.1.1986) befasste sich intensiv mit der Entwicklung der menschlichen Persönlichkeit. Auf seinen Forschungen beruht ein achtstufiges Ebenenmodell von Entwicklungsstufen, das sowohl für Personen als auch für Organisationen angewendet wird. Die Psychologen Don Edward Beck und Christopher Cowan entwickelten das Graves-Modell weiter zum kommerziellen Beratungsmodell unter der Markenbezeichnung "Spiral Dynamics®" (Beck und Cowan, 2011).

Ich lernte das Graves-Modell im Rahmen einer Fortbildung kennen. Hier möchte ich nur einige Aspekte davon vereinfacht herausgreifen. Wenn Sie sich näher dafür interessieren, können Sie sich auf der Website http://www.clarewgraves.com und in der Fachliteratur (z.B. Krumm, 2012 oder Bär u.a., 2010) näher informieren.

Meiner Meinung nach kann das Graves-Modell ein hilfreicher Indikator sein, um als Projektleiter einschätzen zu können, welche und wie viele Fassaden man in welcher Umgebung benötigt oder erwarten kann. Dies gilt vor allem dann, wenn man neu in ein Unternehmen gekommen ist.

Das Graves-Modell definiert – ähnlich den Reifegraden im CMMI – Stufen, wie sich ein Unternehmen entwickeln kann. Allerdings ist hier nicht die oberste Stufe die beste und die unterste die schlechteste. Jede Stufe hat ihre eigene Berechtigung und stellt ein bestimmtes Wertesystem dar. Es liegt am Unternehmen und an den Führungskräften, eine Kultur zu entwickeln und zu etablieren, die zum Unternehmen passt. Der "Tante-Emma-Laden" um die Ecke muss und soll anders agieren als ein globales Unternehmen.

Für das Graves-Modell gelten die fünf Axiome:

• Die Stufen des Graves-Modells beschreiben, wie Menschen bzw. Systeme handeln und denken, nicht aber wie sie sind.
• Alle Stufen des Modells sind absolut gleichwertig, keine ist besser oder schlechter. Es kommt vielmehr darauf an, wie das Unternehmen in seine jeweilige Umwelt (Branche, Markt) passt.
• Jede höhere Stufe entsteht aus den niedrigeren Stufen als Reaktion auf Veränderungen.
• Die Entwicklung geht schrittweise von unten nach oben (in seltenen Fällen auch von oben nach unten), das Überspringen einer Stufe ist nicht möglich.
• Obere Stufen integrieren untere Stufen.

Bild 1 zeigt die acht Existenzstufen, die jeweils ein Wertesystem darstellen. Die Farbgebung ist Bestandteil des Modells – Berater, die das Modell anwenden, sprechen demgemäß z.B. von einem "orangen Unternehmen".

Bild 1: Existenzstufen nach Clare W. Graves (in Anlehnung an Bär u.a., 2012).

Jede Stufe steht im engen Zusammenhang mit den Werten und Fähigkeiten eines menschlichen Systems. Diese beschreiben zentrale Zusammenhänge für Veränderungsprozesse. Tabelle 1 beschreibt diese Stufen mit den Werten, den Produkten, der Firmenkultur und den typischen Unternehmensformen.

Tabelle 1: Graves Stufensystem für Unternehmen (in Anlehnung an Bär u.a., 2010).
Bild vergrößern

Eines der wichtigsten Zitate von Graves lautet:

"Menschen sollten sich nicht zu sehr verändern müssen, um ihre Arbeit zu tun. Setze sie gemäß den vorhandenen Stärken ein."

Pragmatisch bedeutet dies, dass Mitarbeiter und Unternehmen sich möglichst auf derselben Stufe oder höchstens auf benachbarten Stufen des Modells befinden sollten, um Konflikte zu vermeiden und um kein Übermaß an Potemkinschen Fassaden zu benötigen. Eine Differenz von zwei Stufen oder mehr zu überspringen steht im Widerspruch zu den Axiomen des Modells und wird nicht gelingen.

Wenn wir diese Theorie auf Projektleiter und Unternehmen übertragen, wird es z.B. zu Problemen kommen, wenn ein Projektleiter, der 20 Jahre lang in einem "blauen Unternehmen" (loyal, eher bürokratisch) angestellt war, sich für eine neue Karriere in einem "grünes Unternehmen" entscheidet. Beide Stufen sind zwar tendenziell auf andere bezogen, aber sie liegen um mehr als eine Stufe auseinander. Die Mechanismen, die den Projektleiter im "blauen Unternehmen" erfolgreich gemacht haben, z.B. Regeln und Prozesse einzuhalten und diese vom Unternehmen zu erwarten, werden ihn womöglich in einem "grünen Unternehmen" scheitern lassen. Wenn er Prozessbeschreibungen, genaue Arbeitsanweisungen und klare hierarchische Strukturen einfordert, wird er in einem grünen Unternehmen, bei dem es um Flexibilität und Kreativität geht, keinen Erfolg haben. Im Gegenteil, der Projektleiter wird als Exot oder als Außenseiter angesehen werden und wird sich nicht wohl fühlen. Selbst wenn er sich an die neue Unternehmenskultur anpassen will, wird er feststellten, dass es für ihn schwer bis unmöglich ist, das auf Dauer durchzuhalten.

Stellen Sie sich konkret vor, ein IT-Projektleiter eines behördlichen Rechenzentrums wechselt zu Google. Er ist weitgehend geregelte Arbeitszeiten gewohnt, Sicherheit und Fehlerfreiheit der Anwendungen stehen in seinen Projekten an oberster Stelle, er ist in eine strikte Hierarchie eingebunden, die ihm kaum persönliche Gestaltungsfreiheit gibt. Bei Google aber gibt es z.B. einen FedEx Day, an dem jeder Mitarbeiter einmal die Woche einen Tag arbeiten kann, was er möchte, es darf nur nichts mit seinem eigentlichen Job zu tun haben. Für den oben beschriebenen Kollegen wäre das ein Kulturschock.

Aber umgekehrt gilt das Gleiche! Wenn ein Projektleiter von Google zu einem Rechenzentrum der Öffentlichen Hand wechseln würde, wäre vermutlich bereits sein erster Projektstatusbericht ein Kündigungsgrund noch innerhalb der Probezeit.

Ein Projektleiter sollte sich stets bewusst sein, auf welcher Stufe er sich selbst befindet und welche Erfahrungen er auf ihr gemacht hat. Ebenso sollte er sich genau anschauen, welche Stufe das Unternehmen hat, bei dem er arbeitet oder arbeiten wird. Wenn diese Stufen nicht zusammenpassen, wird er zu viele Potemkinsche Fassaden aufbauen müssen, um einigermaßen unfallfrei durch das Projekt zu kommen und froh sein, wenn er den Absprung zu einem anderen, passenderen Unternehmen schafft.

Projektsponsoren oder Linienmanager sollten bei der Einstellung eines Projektleiters darauf achten, in welchen Firmen dieser bisher wie lange gearbeitet hat. Ein Projektleiter, der immer nur in Großunternehmen mit Prozessen und Vorgaben gearbeitet hat, wird sich in einem dynamischen New Economy Unternehmen wahrscheinlich nicht wohl fühlen und auch nicht die erwartete Leistung bringen können.

Literatur

• Beck, Don Edward und Cowan, Christopher C.: Spiral Dynamics - Leadership, Werte und Wandel: Eine Landkarte für das Business, Politik und Gesellschaft im 21. Jahrhundert, 2007
• Krumm, Rainer: 9 Levels of Value Systems, 2012
• Wikipedia: Grigori Alexandrowitsch Potjomkin, http://de.wikipedia.org/wiki/Grigori_Alexandrowitsch_Potjomkin, aufgerufen am 11.8.2013
• Bär, Martina; Krumm, Rainer und Wiehle, Hartmut: Unternehmen verstehen, gestalten, verändern. Das Graves-Value-System in der Praxis, Wiesbaden, 2010, zitiert nach: Businessforce AG: Schulungsunterlagen "Graves Präsentation", 2012