single.php
< Beitrag von Bernhard Reuß

Was ist eigentlich ein „gutes Projekt“?

Es war alles andere als ein gutes Projekt, sondern mit Abstand das mieseste, das ich seit Urzeiten zustande gebracht hatte. Mein Projekt hatte in keiner Hinsicht auch nur annähernd die Qualität, die ich etablieren will, nicht mal die, die ich für mindestens erforderlich halte.

Diese Projekt-Geschichte entfaltet ein weites Bedeutungsspektrum der Bewertung „gut“ in Projekten und im Projektmanagement. Ohne den Lehrbüchern ins Gehege zu kommen, die diese Frage systematisch und umfassend beantworten, möchte ich Sie inspirieren, über die Bewertung „gut“ nachzudenken – durch die Erzählung einer Projekterfahrung, die sich als Blumenstrauß voller Anekdoten erweist.

Ich hätte es doch ahnen müssen!

Es war Mitte September letzten Jahres. Der Rekordsommer war noch immer heiß, und auch mir wurde etwas verheißen. Eine Kundin rief an, die mich zwei Tage zuvor „unehrenhaft“ aus einem Projekt „entlassen“ hatte. Tatsächlich war es eine Budgetkürzung, weshalb sie mich, den externen Berater, an die Sommerluft gesetzt und einen internen Mitarbeiter mit der Projekt-Fortführung betraut hatte. Nun überraschte mich genau diese Kundin mit der Frage, ob ich denn schon anderweitig engagiert sei. „Ich habe da ein Projekt in Schieflage, da verliere ich jetzt den zweiten Projektleiter in vier Monaten. Da müsste mal jemand ran mit deiner Erfahrung.“

Ich bin längst nicht mehr naiv genug, um nicht schon damals durchschaut zu haben, dass diese Umgarnung in diametralem Verhältnis zu einem ruhigen Spätsommer stand. Aber meine Eitelkeit gewann doch schnell die Oberhand. So erklärte ich gönnerhaft, dass „ich dann hier mal so … und dort mal so …“, und dass das alles dann schon wieder laufen werde. „Drei Wochen“, dachte ich mir, „dann habe ich auch dieses Tier gebändigt. Wäre doch gelacht. Mach‘ ich doch nicht zum ersten Mal.“ Allerdings muss ich mir im Nachhinein eine große Restnaivität konstatieren, die zudem mit einer Portion Hybris durchsetzt war. Denn mit drei Wochen Taktstock schwingen war es nicht getan, bis das Projekt ordentlich marschierte. Und „ordentlich“ ist hier als sehr mageres Adjektiv zu verstehen, also bestenfalls „ganz ordentlich“ und damit weit entfernt von „gut“.

Los geht’s!

Aber erst mal zurück auf Los in der Geschichte und ran an die Arbeit, die gleich mit Anekdote 1 begann. Ich rief den bisherigen Projektleiter an, der fristlos gekündigt hatte und nur noch eine Stunde zu sprechen war. Ob dieser abrupte Abgang wirklich durch das Projekt verursacht wurde, ist nicht überliefert. Dieser Abschied passt aber herrlich in die Dramaturgie der folgenden Ereignisse. Das Telefonat war nicht sonderlich erkenntnisreich. Ich erfuhr nur erneut, dass es kaum Fortschritte gab, die Übergabe von seiner Vorgängerin knapp gewesen und überhaupt alles sehr schwierig sei. Aha!

Reden ist Silber, Aufschreiben wäre Platin gewesen …

Also den Endkunden angerufen, um mich freudig vorzustellen und um Hoffnung und Aufbruchsstimmung zu verbreiten! Auch das, muss ich heute selbstkritisch anmerken, war mir sehr oft sehr viel besser gelungen. Die Schilderung dieses Telefonats führt direkt zu Anekdote 2: Pascal, wie ich ihn hier nenne, klagte mir nämlich sein Leid. Dabei wiederholte er ständig einen Stehsatz, der dem nun ja meinigen Projekt ein verheerendes Zeugnis ausstellte: „Ja, aber darüber haben wir doch schon mehrfach mit Charly geredet!“

Weitere Recherchen im Team meines Kunden, also des IT-Dienstleisters, bestätigten, dass diese Gespräche zwar durchaus stattgefunden hatten. Aber niemand hatte die Ergebnisse auch nur grob schriftlich festgehalten oder gar Aufgaben abgeleitet und ausgeführt. Es war also immer bei dem geblieben, was wir als ironischen Kommentar kennen: „Gut, dass wir mal drüber gesprochen haben!“

Der Unentbehrliche ist nicht zu fassen

Jetzt muss ich von „Charly“ erzählen, der natürlich nicht so heißt, dessen echter Vorname aber in eine ähnlich amerikanisierte Glättung gebracht war. Ja, Charly hatte ein Problem, er hat es mit Sicherheit noch immer. Er ist nämlich mit einer Seuche geplagt, die wie ein Mühlstein um seinen Hals baumelt, an einer Kette, die sämtliche Projekt-, Programm- und Linienmanager täglich fester um seinen nach Luft japsenden Hals ziehen: hervorragende Sachkenntnis!

Charly wird also überall gebraucht und zu allen Brandherden dieser Hemisphäre gerufen. Jeder Arbeitstag dieses Mannes, der auch noch ein äußerst angenehmer Kollege ist, besteht daraus, sich im 5- bis 30-Minuten-Takt von hohen Damen und Herren von einer Eskalation in die übernächste zerren zu lassen. Überall steht er brav Rede und Antwort und geht wieder mit der Aufforderung im Gepäck, doch bitte dies und jenes auszuarbeiten, abzuwägen, zu bewerten und eine wohlkalkulierte Vorstandsempfehlung für die nächsten drei Jahre vorzulegen. Der arme Charly kommt nicht mal dazu, sich all diese Aufgaben zu notieren, geschweige denn, sie zu erledigen. Und obwohl er keine Chance hat, nutzt er sie erstaunlich oft.

Das war in meinem Projekt aber offenbar selten der Fall, was ich ihm aber nie angekreidet habe. Sicher hat er in jedem der genannten Fälle des „Drüber-geredet-Habens“ immer genau gewusst, was er sagte und sicher ist dies auch immer ein schlauer Lösungsansatz gewesen. Vielleicht hatte er im Wissen um seine viel zu vielen Einserprioritäten auch nie eine Ausarbeitung versprochen. Aber das beeindruckte Auditorium blieb immer in dieser Erwartung zurück, bevor ihn der Hubschrauber zum nächsten Kriseneinsatz abholte.

Wir haben nix, also zeigen wir auch nix!

Tags drauf, also Tag 1,5, folgte Anekdote 3: mein nächster Anruf bei Pascal. Es war ein Freitag, und er verlangte von mir die Bestätigung eines avisierten Workshops für den Dienstag drauf. Als ich dann fragte, was denn dort „geworkshopt“ werden solle, entgegnete Pascal entwaffnend: „Ja, IT-Workshop!“ Als ich mich mit dieser sehr begrenzten Konkretisierung nicht anfreunden wollte, stieg er auf eine griffige Forderung um: „Wir wollen mal was sehen!“

Da ich bereits einschätzen konnte, dass wir sicher nichts gebaut hatten, was in irgendeiner Weise präsentabel war, fragte ich Pascal, ob wir als Lieferanten denn ein Release oder eine Funktionalität für diesen Termin versprochen hätten. „Nein“, antwortete Pascal, „aber sonst erfahren wir ja gar nichts von euch!“ So leid er mir tat und so recht er offenbar hatte, sagte ich zu seinem Erschrecken unsere Teilnahme an diesem Workshop ab, weil wir ja eh nichts zeigen konnten und ich die Zeit meines Teams besser investieren wollte. Rums!

In dem Moment war Pascal zwar nicht erfreut, spürte aber offenbar, dass von nun an ein anderer Wind wehen würde. Für ihn war aber nicht ersichtlich, ob auch in die richtige Richtung, durchaus aber, dass dieser Wind auch für ihn an der ein oder anderen Stelle rauer werden könnte.

Was heißt unmöglich? Wir machen doch IT!

Und mir war nun in apokalyptischer Deutlichkeit klar, wie schlecht es um dieses Projekt stand:

  1. Wir wussten nicht, was wir überhaupt bauen sollten.
  2. Also wussten wir auch nicht, wie wir es bauen sollten und
  3. welche Eigenschaften das haben sollte, was wir bauen sollten.
  4. Wir hatten also keine Anforderungen.
  5. Zwar gab es ein paar ganz kleine Ergebnisse, wir wussten aber nicht, ob das zu dem passte, was gefordert und versprochen war. Denn auch wenn wir keine Anforderungen hatten, hatte ja offenbar irgendwer irgendwen mal mit irgendwas beauftragt.
  6. Die Hälfte der Projektlaufzeit war weitgehend ergebnislos verstrichen. Als Ergebnisse konnten wir nur Verzweiflung, Eskalation und aufkeimende Panik vorweisen.
  7. Unser Endkunde wusste sich vor lauter Unverbindlichkeit und Orientierungslosigkeit nicht anders zu helfen, als mich täglich mit Einzelaufgaben zu bombardieren und „Workshops“ anzuberaumen, um uns die ein oder andere hilfreiche Aussage aus der Nase zu ziehen.

Viele Defizite – was ist auf der Haben-Seite?

In diesem Ausmaß war mir tatsächlich noch kein Projektchaos untergekommen. Doch auch von dieser Erkenntnis war mein in vielen Jahren gestählter Berufsoptimismus nicht niederzuschmettern. Ich hielt mir kurz vor Augen, was es denn auf der Haben-Seite gab. Und das war tatsächlich nicht nichts, es musste nur ausgegraben, poliert und versilbert werden:

  1. Das Ziel: Wir wussten, wofür das Projekt gut war, wir kannten also das Ziel. Oft kranken Projekte daran, das Ziel nicht zu kennen. Und selbst bei weitgehend gesunden Projekten ist dies häufig der Fall. Es gab also einen festen Anker, den ich oft erst auf hoher See gießen und auswerfen lassen muss.
  2. Die Manpower: Es standen motivierte Leute zur Verfügung, wenn ich jetzt mal von Charlys Dauerkriseneinsätzen absehe.
  3. Das Budget: Wir verfügten über ein ordentliches Budget, um diese Leute auch zu bezahlen für das, was sie taten oder tun sollten.
  4. Der Kunde: Unser Kunde war zwar verzweifelt, aber erstaunlicherweise immer noch willens, das Projekt mit uns zu stemmen.
  5. Die Zeit: Wir hatten immer noch die zweite Hälfte der Laufzeit, um etwas zu bewerkstelligen. Zeitlich war das Glas also noch halb voll.
  6. Die Chance: Das Fehlen von Anforderungen ließ sich vielleicht sogar als Chance begreifen. Der Endkunde machte kaum Vorgaben, wie bestimmte Funktionen aussehen sollten, sondern wollte ständig wissen, wie man dies oder jenes denn überhaupt mit der vorgegebenen Standardsoftware umsetzen könne. Die einzige Anforderung war also, es irgendwie im gegebenen technischen Rahmen hinzubekommen! Ich schlug deshalb möglichst leicht zu implementierende, standardnahe Lösungsansätze vor, die wir in der verbliebenen Zeit vielleicht auch umsetzen könnten. Diese recht makabre Sicht eines Krisengewinnlers verhieß zumindest ein Kerzenlicht am Ende des Gotthardbasistunnels.

Einfach machen!

Als ersten konstruktiven Schritt nach meiner Workshop-Absage habe ich die nächsten zwei Wochen damit verbracht, den Lieferumfang zu ermitteln, den ja offenbar irgendwer mal mit irgendwem, wenn auch sehr vage, festgelegt hatte. Danach war klar, dass es nichts Konkreteres gab, als eine Powerpoint-Präsentation mit hellblauen, andersblauen und ganz andersfarbigen Kästchen nebst stichpunktartigen, äußerst knappen Erläuterungen, was diese Kästchen denn ungefähr bedeuten sollten. Die Kästchen mit Ihren Erläuterungen waren so etwas wie grobe Arbeitstitel funktionaler Anforderungen.

Ich habe mir dann von Pascal – schriftlich! – bestätigen lassen, dass für das erste Release – nur! – die ‚hellblauen Kästchen‘ relevant seien. Sie waren zwar nicht annähernd so konkret, so trennscharf definiert und erst recht nicht mit Lösungsansätzen hinterlegt, wie ich mir das erträumt hätte, um wirklich seriös zu arbeiten. Aber ich hatte etwas halbwegs Verbindliches! Es war immerhin der sehr weiche Pudding, den es nun mit Fischstäbchen an die Wand zu nageln galt.

gutes Projekt

Praktisch unmöglich, aber kein Grund aufzugeben!

Darauf setzend, habe ich dann etwas getan, was einer Revolution gleichkam: Ich habe alle Leistungserbringer darauf geeicht, nur an diesen hellblauen Kästen zu arbeiten und an nichts anderem! Das erschien mir überaus vernünftig und naheliegend. Allerdings war es in diesem Projekt völlig unüblich und bedurfte doch erheblicher Motivationsanstrengung und Zweifelsbekämpfung.

Ich ließ von meinem Ansinnen aber nicht ab und habe mir von allen erklären lassen, was wir für welches hellblaue Kästchen tun müssen, was sie dazu beitragen und was sie von anderen benötigen. Dazu habe ich ständig kontrolliert, dass auch niemand vom schmalen Pfad dieser hellblauen Kästchen ausbuchst.

Ich war mehrfach kurz davor, das Projekt komplett zu stoppen und erst einmal ordentlich zu definieren. Das wäre aber Selbstmord aus Feigheit vor dem Tod gewesen. Denn nur im Versuch, den Bus in voller Fahrt in eine andere Richtung zu lenken und gleichzeitig noch mehrere Anhänger anzukuppeln, gab es zumindest eine theoretische Chance, zum Zieltermin fertigzuwerden!

Da es zudem viele solcher hellbauen Kästchen gab und von etwa der Hälfte trotz aller früherer „Wir hatten doch schon drüber geredet!“-Workshops noch nirgends eine Vorstellung bestand, wie man diese mit technischem Leben füllen konnte, hat mich allein das zwei Monate gekostet!

Nieder mit dem Tyrannen!

In dieser Zeit habe ich darauf verzichtet, allen Teammitgliedern das Gesamtbild zu erklären oder sie zu fragen, ob nicht jemand bessere Ideen habe. Stattdessen habe ich alle Teammitglieder auf ihre jeweiligen hellblauen Kästchen geimpft und mich darauf verlassen, dass trotz meiner blanken Unkenntnis der Standardsoftware mein selbstgezimmertes Gesamtbild schon taugen werde. Das war übrigens eine viel größere Hybris als ganz zu Beginn. Dieser Tatsache war ich mir aber zum Tatzeitpunkt in vollem Umfang bewusst. Ich habe aus Mangel an anderen halbwegs realistischen Optionen stur daran festgehalten.

Das hätte um ein Haar zum Teamaufstand geführt. Denn wahrlich versierte Experten habe ich auf einzelne kleine Puzzleteile verpflichtet, ohne auch nur den Versuch zu unternehmen, die Verbindung zum großen Bild aufzuzeigen. Der Flurfunk verbreitete rasend schnell die Überzeugung, dass ich keinesfalls einen Plan haben könne oder dieser Plan – meiner Unkenntnis der Materie gemäß – völlig untauglich sein müsse. Dieser Aufstand brach nur zufällig irgendwann zusammen. Den Grund kenne ich bis heute nicht. Vielleicht kam mir ein Schachzug zupass, der auch von anderen Willkürherrschern bekannt ist: Wenn ein Kriegsschauplatz – gerade im Innern – zu heiß wird, machen sie einfach einen neuen auf, um vom alten abzulenken.

Das Testing kurz vor knapp

Zum Ende dieser zwei Monate mit kleinen Bausteinen zu hellblauen Kästchen und aufziehender Meuterei war der Zeitpunkt gekommen, zu dem in einem gesunden Projekt alles hätte fertig sein und in den Test gehen müssen. Wie Sie aber korrekterweise annehmen, war noch sehr wenig fertig, und es gab es auch noch keinerlei Testwesen. Auch das war mir von Anfang an bewusst, aber aus der beschriebenen Not habe ich es einfach erst mal dabei bewenden lassen, um das Testing binnen weniger Tage aus dem Boden zu stampfen. Ich habe

  • eine Form für Testfälle vorgegeben, die Pascal mangels eines Testteams auch bereitwillig und sehr gut nutzbar befüllt hat.
  • einfach mal jeglichen Regressionstest herausdefiniert, auch wenn auf der Softwareplattform durchaus bereits andere Anwendungen liefen.
  • sogar einen Integrationstest vernachlässigt mit der mutigen Feststellung, die verschiedenen Komponenten gehörten ja zu einem Produkt, da brauche man so etwas nicht.

Schließlich habe ich die Schwelle, die ein erfolgreicher Testfall benötigt, auf das absolute Minimalniveau festgesetzt und uns eine Abnahmehürde verschafft, die kaum oberhalb der Grasnarbe lag. Beim Testzeitplan habe ich mich, und damit natürlich alle anderen auch, belogen, da dieser Plan einerseits fürs Testen zu kurz war, und andererseits eine Entwicklung voraussetzte, die es dann noch nicht geben würde.

Der Test ging also wissentlich zu spät los und konnte sich auch zunächst nur auf bestimmte Funktionen konzentrieren, weil die anderen parallel fertiggebaut wurden, um dann auf den allerletzten Drücker nachgeschoben zu werden. Ich habe angesichts der vielen Risiken, die ich eingegangen war und die ich notwendigerweise ignoriert hatte, täglich gezittert und auf den großen Bug gewartet – also auf den großen Fehler, der uns das Genick brechen und die gerade in Funkengröße entzündete Hoffnung, es tatsächlich schaffen zu können, mit einer Böe löschen würde.

Wie konnte das nur gutgehen?

Doch dieser Bug kam nicht. Die einzelnen Teile haben auch im Zusammenwirken als großes Bild gehalten. Wir haben ein stimmiges Ergebnis geliefert, das den Kunden nicht nur bedient, sondern regelrecht erfreut hat! Sie werden sich nun fragen, wie es so weit kommen konnte. Genau das habe ich mich damals auch gefragt. Es kamen viele Aspekte zusammen, von denen kein einziger hätte fehlen dürfen:

  1. Die Mitarbeiter haben es sich bieten lassen, im Nebel zu stochern, um hellblaue Kästchen zu bedienen. Ich habe keine überzeugende Erklärung warum. Vielleicht haben sie gespürt, dass ich ihre Kompetenz und ihren Einsatz geschätzt habe, auch wenn mein Handeln oft anders gewirkt haben muss.
  2. Die Mitarbeiter haben nicht nur ihr Bestes gegeben. Es kam auch das Bestmögliche dabei raus – mit mancher Überstunde und einer beinahe unerträglichen Verdichtung.
  3. Der Endkunde, insbesondere Pascal, hat alle Ausschlüsse, Begrenzungen, Mitwirkungspflichten und Projektprozesse mitgetragen, die ich ihm oktroyiert habe. Sie haben ihm nicht alle gefallen. Aber er hat offenbar gespürt, dass ein Plan dahinterstand, auch wenn ich diesen Plan nicht mal ihm erklärt habe.
  4. Das Management des IT-Dienstleisters, also meines Kunden, hat mir, trotz aller Rückschläge das Vertrauen nie entzogen. Ich weiß, dass dies nicht allein der Verehrung meiner Arbeitsweise geschuldet war. Entscheidend war auch die Einsicht, dass ein erneuter Wechsel des Projektleiters die Situation kaum verbessert hätte.
  5. Mein Plan hat tatsächlich funktioniert. Das schreibe ich ohne jeden Anflug von Hybris. Dafür habe ich selbst, der beruflich einiges auf sich hält, zu oft daran gezweifelt: Dieser Plan war zu unvollkommen, um die bestmögliche Option zu sein, selbst in einem Chaos wie diesem. Mir ist bis heute kein besserer Plan für diese Situation eingefallen. Ich bin aber nach wie vor nicht sicher, ob es ihn nicht hätte geben können.
  6. Wir hatten schlicht immer wieder Glück. Wir hatten und brauchten Glück als lebenserhaltendes Medikament, worauf ich mich in Projekten nie verlassen will.

Kann „schlecht“ also „gut genug“ sein?

gutes Projekt

Damit lässt sich die Eingangsfrage nun auch einfach beantworten: War dieses Projekt gut?

Im Sinne des eng definierten Projekterfolgs „in Time, in Scope, in Budget“ unter dem Strich mit ein paar blauen Augen, ja. Im Sinne einer Projektreife, die den Erfolg systematisch und fast zwingend „produziert“, hingegen ganz und gar nicht.

Ich habe das Projekt übernommen mit einem Reifegrad von bestenfalls „mangelhaft“, um es in einer Schulnote auszudrücken. Am Ende habe ich ein „befriedigend minus“ erreicht. In diesem besonderen Fall – und erstmals in meinem ganzen Leben – bin ich aber mit dieser Note recht zufrieden.

Folgen
X

Folgen

E-mail : *
Kategorie: Projektmanagement | Schlagwörter: , | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.