Vergabe von IKT-Projekten – Ein Prozessmodell integriert rechtliche und inhaltliche Sicht

Öffentliche Auftraggeber müssen das Vergaberecht als Rahmenbedingung akzeptieren, dessen Regelwerk immer komplizierter wird. Ich habe in der Praxis beobachten müssen, dass sich die vergaberechtliche Optimierung oft verselbständigt: das Vermeiden einer Anfechtung wird wichtiger als der Erfolg des Vorhabens. Das Happy-End ist aber nicht der bestandsfeste Zuschlag, sondern der erfolgreiche Go-Live, oft Jahre danach. Kein Wunder, dass die Ursache für einen problematischen Projektverlauf fälschlicherweise oft nicht einem suboptimalen Vergabeprojekt zugeschrieben wird.

Auf Anregung von Dr. Philip Weihs (consigma) habe ich gemeinsam mit ihm und Dr. Georg Zellhofer von Schramm Öhler Rechtsanwälte ein Prozessmodell für IKT-Vergaben entwickelt, das aus der Perspektive des Gesamterfolges die rechtlichen und IKT-spezifischen Erfordernisse integriert. Hier die oberste Ebene, in der die Phasen und Prozessgruppen definiert sind. Darunter (hier nicht dargestellt) gibt es dann noch die Prozessebene und die Aktivitätsebene.

prozessmodell_uebersicht

Den Prozessen sind die relevanten Bestimmungen des Vergabegesetzes zugeordnet, Erfolgsfaktoren sowie die jeweiligen Prozessergebnisse sind definiert.

Dass so ein Modell ein nützlicher Zugang ist, bewies das rege Interesse an einem Workshop, den wir angeboten haben; es musste ein Zusatztermin eingeschoben werden, weil es doppelt so viele Anmeldungen gab, als Kapazität vorhanden war.

Für Abonnenten meines Blogs stelle ich gerne die ausführlichere Darstellung dieses Modells zur Verfügung. Melden Sie sich hier an und Sie erhalten nach dem Klicken des Bestätigungslinks das Modell zum Download.

Test Driven Development – unterschätzt und oft missverstanden

Man muss auch die Testpläne und die Testfälle testen, ob sie nämlich überhaupt geeignet sind, die Eignung der Endprodukte zur Erfüllung der Anforderungen zu beurteilen. So Tom deMarco u.a. in ihrem Muster 35 („Testen vor dem Testen“) des legendären Buchs „Adrenalin Junkies & Formular Zombies“.

Testen ist viel mehr als nur „Testen“

Jedes Zwischenergebnis in einem Projekt, ob es ein Projektplan, eine Schnittstellenfestlegung, eine Prozessdefinition oder was immer ist, kann gegen die Anforderung getestet werden, die durch dieses Ergebnis erfüllt werden soll.

Bei jeder Verfeinerung oder Konkretisierung einer Anforderung oder einer Lösungsbeschreibung muss geprüft werden, ob diese mit der abstrakteren Version noch übereinstimmt bzw. deren sinnvolle Konkretisierung ist.

Ein Beispiel aus der Versicherungsbranche:

Anforderung: Die Freigabe von Zahlungen aufgrund von Leistungsansprüchen von Kunden soll in definierten Fällen nur nach einem 4-Augen-Prinzip erfolgen können.

Das kann durch folgende User-Stories konkretisiert werden, wobei jede User-Story eine Reihe von Fragen aufwirft, einige sind jeweils in der rechten Spalte ohne Anspruch auf Vollständigkeit angeführt:

User-Story Konkretisierungsbedarf
Wenn ich als Sachbearbeiter (SB) eine Zahlung freigebe, so entscheidet das System, ob diese Zahlung unmittelbar zur Auszahlung frei gegeben wird oder ob noch eine zweite Person ihre Freigabe erteilen muss. Nach welchen Regeln entscheidet das System, ob eine zweite Person notwendig ist?

Wie wird die zweite Person ausgewählt?

Kann der SB erkennen, dass die Kriterien für das 4-Augen-Prinzip erfüllt wurden?

Soll der SB beeinflussen können, welche Person die Freigabe durchführen soll?

Erfährt der SB, ob die Freigabe erfolgt ist?

 Als Leiter der Leistungsabteilung kann ich festlegen, dass bestimmte Zahlungen vom System nur ausgeführt werden, wenn auch eine zweite Person diese prüft und freigibt. Auf welchen Kriterien (Betragsgrenzen, Kundenmerkmale, SB-Merkmale, Zufallsprinzip, …) kann die Entscheidung über die Notwendigkeit einer zusätzlichen Freigabe aufbauen?

Welche Kriterien muss die zweite Person erfüllen, um eine Freigabe durchführen zu können (Rolle, Hierarchiestufe, Zugehörigkeit zu einer Organisationseinheit, …)?

Weist das System den Fall einer bestimmten Person oder einer Gruppe von Personen aktiv zu? Wenn ja, nach welchen Kriterien (z.B. Rotations- oder Zufallsprinzip, Anwesenheit, Auslastungssituation)?

Kann der Leiter diese Regeln selbst definieren und ändern oder müssen diese programmiert werden?

Nach welchen Kriterien werden die Regeländerungen geprüft (logische Konsistenz, organisatorische Effizienz, Internes Kontrollsystem, …) und wird diese Prüfung vom System erzwungen, nur dokumentiert oder bleibt dies der Organisation überlassen?

Bei jeder Konkretisierung der User-Story muss also geklärt werden, welche Person bzw. welche Personen verbindlich beurteilen können, ob die Antwort auf die jeweilige Frage eine korrekte Detaillierung der ursprünglichen Anforderung ist. Es muss auch geklärt werden, ob die Konkretisierungen und Detaillierungen alle Aspekte abdecken oder noch Lücken bestehen, die gefüllt werden müssen. Man muss damit rechnen, dass trotz dieses Vorgehens immer wieder Erkenntnisse erst auftreten, wenn man weitere Konkretisierungsstufen hinter sich hat. Je früher man solche Lücken entdeckt, umso weniger Aufwand und damit auch Durchlaufzeit ist verloren. Trotz allem Bemühen werden manche Erkenntnisse erst erzielt, wenn konkrete Software vorliegt. Daher ist es sinnvoll, möglichst schnell von verbalen Beschreibungen zu anschaulichen Darstellungen überzugehen.

User-Stories mit Testfällen präzisieren

Völlig unterschätzt wird die Möglichkeit, diese Konkretisierung durch die frühzeitige Formulierung von Testfällen vorzunehmen. Oft habe ich schon gehört, man könne die Testfälle erst formulieren, wenn die Software erstellt ist. Natürlich ist es dann leichter, aber möglich ist es viel früher, eigentlich jederzeit.

Jede der oben angeführten User-Stories kann auch in Form von Testfällen formuliert werden.

Nehmen wir beispielhaft zwei solcher Anforderungen:

a. Nach welchen Regeln entscheidet das System, ob eine zweite Person notwendig ist?

Mögliche Kriterien: Betragshöhe der Zahlung, Art des Schadens (Personenschaden, Sachschaden), geschädigte Person im Nahverhältnis zum Schädiger J/N.

Mögliche Testfallbeschreibungen: Es werden verschiedene Merkmalsausprägungen in einer Matrix angeordnet und es wird jeweils angegeben, ob eine zweite Person die Zahlung freigeben muss. Diese Beschreibung wird den Entwicklern als Anforderungsbeschreibung zur Verfügung gestellt. Diese können bei Unklarheiten rückfragen, die Testfälle werden dann überarbeitet bzw. erweitert. Es ist wichtig, dass sowohl Fälle beschrieben werden, in denen das 4-Augen-Prinzip gilt als auch solche, wo kein 4-Augen-Prinzip erforderlich ist.

Wenn Software geliefert wird, kann anhand dieser Testfälle geprüft werden, ob die Anforderungen richtig verstanden wurden und ob die Software so funktioniert. Wird dabei festgestellt, dass nicht an alle Varianten gedacht wurde, werden die Testfälle erweitert und diese ebenfalls als Anforderungsdefinition den Entwicklern zur Verfügung gestellt. Dieser Zyklus kann mehrfach durchlaufen. Auch eine Reduktion der Anforderungen kann auf diese Weise entschieden und kommuniziert werden.

b. Welche Kriterien muss die zweite Person erfüllen, um eine Freigabe durchführen zu können (Rolle, Hierarchiestufe, Zugehörigkeit zu einer Organisationseinheit, …)?

Mögliche Regeln: Sie muss der gleichen Abteilung angehören. Sie muss die gleiche Rolle wie der SB haben (oder muss eine andere Rolle, z.B. Supervisor haben). Sie darf in diesem konkreten Schadensfall noch nicht als SB tätig gewesen sein (z.B. bei einer bereits erfolgten Teilzahlung).

Mögliche Testfälle: Die in Frage kommenden Merkmale werden als Checkliste dargestellt, es wird angegeben, bei welcher Merkmalskombination ein Rolleninhaber als Zweitprüfer in Frage kommt und in welchen Fällen dies ausdrücklich ausgeschlossen ist.

Resümée

Man erkennt schnell, wie komplex selbst diese einfache Anforderungsbeschreibung wird. Wenn diese schon von Anfang an in eine Liste von Testfällen herunter gebrochen werden kann, ist dies für alle Beteiligten leichter nachzuvollziehen als eine noch so detaillierte verbale Beschreibung oder grafische Darstellung.

Daher kann ich die Forderung von Tom deMarco u.a. nur unterstützen: „Der Sinn des frühzeitigen Testens besteht darin, möglichst viele Fehlannahmen, Missverständnisse, Widersprüche, unrealistische Erwartungen usw. so früh wie möglich aufzudecken – bevor sie fest verankert und nur noch schwer zu beseitigen sind“ (a.a.O. S. 91).

Die beste und detaillierteste Beschreibung eines solchen Vorgehens stammt von Gojko Adzic. Sein Buch „Specification by Example“ kann ich ohne Vorbehalt empfehlen.

Projektmanagement-Standards (PMI, IPMA, PRINCE2) — Kurzbeschreibung und Literaturtipps

Das Projektmanagement-Institute (PMI) bietet den umfassendsten und weltweit führenden Standard für Projektmanagement an. PMI ist ein Verein, der 1969 in den USA gegründet wurde. Aktuell (Ende 2016) hatte PMI 450.000 Mitglieder, ich selbst bin seit vielen Jahren Mitglied und finde, dass sich das absolut lohnt. Man hat kostenlosen Zugang zu allen Standards des PMI, zu Webinaren und Whitepapers. PMI ist in sogenannten Chapters organisiert, die lokale Veranstaltungen anbieten. Es gibt ca. 280 Chapters.

Der Standard ist im Form des PMBOK (Project Management — Body of Knowledge) zusammengefasst, diesen gibt es derzeit in 5. Auflage. Es ist am günstigsten, diesen über amazon zu beziehen, da man bei PMI erhebliche Portokosten zu bezahlen hat. Hier der Link zum PMBOK.

Es gibt allerdings eine Reihe von Darstellungen des PMBOK, die didaktisch besser sind. Hier eine Auswahl:

Anton Zandhuis: Zusammenfassung des PMBOK-Guide (5. Auflage)

Niklas Spitczok von Brisinski: Pragmatisches IT-Projektmanagement: Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen.

Thomas Wuttke: Das PMP®-Examen: Die gezielte Prüfungsvorbereitung.

Der PMBOK Guide ist prozessorientiert, d. h., er sieht Projektmanagement als Zusammenspiel der Ausführung von Geschäftsprozessen. Anhand der Prozesse strukturiert der PMBOK Guide das gesammelte Methodenwissen. Für jeden Prozess werden Input, Output und Werkzeuge und Verfahren beschrieben. Es werden insgesamt 47 Prozesse definiert, die in die folgenden fünf Prozessgruppen eingeordnet werden:

  • Initiierung
  • Ausführung
  • Planung
  • Überwachung und Steuerung
  • Abschluss.

Seit 2012 gibt es eine internationale Norm zum Projektmanagement, die ISO 21500. Zusammenfassend kann man sagen, dass der ISO Standard 21500 weitestgehend mit dem PMBOK 4 konform geht, die Prozesse sind bis auf wenige Details identisch. Wer die ISO 21500 unbedingt selbst besitzen will, kann die mageren 44 Seiten für einen stolzen Preis bei einem der Normeninstitute bestellen: Deutschland, Österreich. Das Geld ist aber besser angelegt, wenn man sich z.B. folgendes Buch kauft: Sean Barton: Fundamentals of Project Management: ISO21500 Explained.

Was ist die Stärke des PMI-Standards? Anders als IPMA, wo auf die Kompetenzen des idealen Projektleiters abgestellt wird, vergleichbar den historisch überholten Ansätzen zur Definition von Führung durch Beschreibung der „idealen Führungskraft“, ist die Definition von Geschäftsprozessen, die Projektmanagement ausmachen ein Ansatz, der dem state-of-the-art des Managements entspricht. Dieses Argument gilt allerdings auch zugunsten von PRINCE2, einem ebenfalls prozessorientierten Standard, der allerdings nur in wenigen Ländern etabliert ist und dessen Prozesse sich erheblich von denen der ISO21500 unterscheiden. Wer sich über PRINCE2 genauer informieren will, hier einige Literaturtipps:

Office of Government Commerce: Erfolgreiche Projekte managen mit PRINCE2 (die offizielle Quelle, allerdings relativ teuer)

Bert Hedeman: Prince2® 2009 Edition — Das Taschenbuch (Best Practice Series).

Nick Graham: PRINCE2® for Dummies.

Insgesamt kann man also festhalten, dass man mit dem Standard von PMI am besten bedient ist, da dieser durch die ISO21500 von einer neutralen und international anerkannten Institution (ISO) deutlich über die anderen Standards gehoben wurde. Überdies sind die Prozessdefinitionen des PMBOK aber auch die reichhaltigste Informationsquelle, wenn man wissen will, was Projektmanagement ausmacht.

Die Geschichte der Elb Philharmonie – War das ein erfolgreiches Projekt oder eine Abfolge von Katastrophen?

Die Eröffnung 2017

Als Hamburgs neues Wahrzeichen, die Elbphilharmonie, am 11. Januar 2017 in einem feierlichen Akt offiziell eröffnet wurde, waren die Kommentare von Begeisterung und einhelliger Zustimmung geprägt. Derart positive Reaktionen hat das als Jahrhundertbauwerk bezeichnete Projekt jedoch nicht immer hervorgerufen. Die Planung und der Bau des nun liebevoll Elphi genannten Gebäudes waren begleitet von Pleiten, Pech und Pannen. Lange Zeit wurde sie in einem Atemzug mit anderen Katastrophenprojekten wie dem Berliner Flughafen Willy Brandt oder dem Bahnhof Stuttgart 21 genannt, es galt als Lehrstück für fehlerhaftes Projektmanagement.

Die Anfänge

Begonnen hat Elphis Geschichte im Jahr 2001, als der Projektentwickler Alexander Gérard und seine Frau, die Kunsthistorikerin Jana Marko, dem Hamburger Senat ihre Idee für die Nutzung des nicht mehr benötigten Kaispeichers A in der Hamburger Speicherstadt vorstellten. Im Rahmen des ambitionierten Städtebauprojekts Hafencity Hamburg sollte das Konzerthaus eine ganz besondere Stellung einnehmen und der Stadt neue Impulse im Kultursektor verschaffen. Die Planungen sahen allerdings nicht nur eine Kulturstätte, sondern auch private Wohnungen, ein Hotel, verschiedene gastronomische Einrichtungen und ein Parkhaus vor.

Mit ihrer Initiative präsentierten Gérard und Marko einen Gegenentwurf zum Media City Port, der sich zum damaligen Zeitpunkt ebenfalls in der Planung befand. Die Begeisterung für das Bauprojekt hielt sich bei den Entscheidungsträgern der Hansestadt jedoch in Grenzen. Dies änderte sich erst, als es dem Initiatorenehepaar im Jahr 2003 gelungen war, das renommierte Architekturbüro Herzog & de Meuron für ihr Projekt zu gewinnen. Doch schon gleich zu Beginn formierte sich erster Widerstand in Form einer Klage des Architekten Stephan Braunfels, der monierte, dass es keine öffentliche Ausschreibung für die Auftragsvergabe gegeben hatte. Davon unbeeindruckt traf der Hamburger Senat aber im Dezember 2003, ein halbes Jahr nach der ersten öffentlichen Vorstellung des Projektes, eine Grundsatzentscheidung. Vorbehaltlich der wirtschaftlichen und technischen Machbarkeit sollten die Baupläne umgesetzt werden.

Machbarkeitsstudie positiv

Im Mai 2004 wurde Hartmut Wegener vom Senat der Hansestadt offiziell zum Projektkoordinator bestellt, der unmittelbar dem Ersten Bürgermeister der Stadt, Ole von Beust, unterstellt war. Unterstützt wurde Wegener von einer Begleitgruppe und der ReGe Hamburg, die sich als Managementgesellschaft um alle anfallenden Bauherren-Verpflichtungen der Stadt kümmern sollte. Als im November 2004 ein geplantes Joint Venture zwischen dem Investor Dieter Becken und dem Initiator Gérard nicht zustande kam, übernahm die Stadt den Architektenvertrag und die alleinige Verantwortung für das Bauprojekt.

Die als Voraussetzung für ein weiteres Engagement der Stadt in Auftrag gegebene Machbarkeitsstudie bestätigte im Juli 2005, dass das Projekt in der vorliegenden Form sowohl technisch als auch wirtschaftlich zu realisieren sei. Die Netto-Baukosten wurden darin mit 186 Millionen Euro beziffert. Auf Grundlage dieser Zahlen beschloss der Senat, das Projekt in Angriff zu nehmen und mit 77 Millionen Euro aus öffentlichen Kassen zu fördern. Der Finanzierungsmehrbedarf sollte durch Spenden und die privaten Investitionen in die Mantelbebauung gedeckt werden. Nach der Bewilligung der nötigen Planungsmittel durch die Hamburger Bürgerschaft wurde ein europaweiter Wettbewerb zum Bau, zum Betrieb und zur Finanzierung des Bauvorhabens ausgeschrieben. Mit der Gründung einer Stiftung im Oktober des Jahres 2005 wurde eine weitere wichtige Institution in das Vorhaben eingebunden. Die Elbphilharmoniestiftung kümmerte sich um das Sammeln von Spenden und weiteren Stiftungsmitteln, die erheblich zur Realisierung des Bauwerks beigetragen haben.

Ausschreibung und Auftragsvergabe

Im November 2006 stellte der Regierende Bürgermeister Ole von Beust den Gewinner des Bieterwettbewerbs vor. Gegen die Konkurrenz aus ganz Europa hatte sich das Konsortium Adamanta, bestehend aus dem Bauunternehmen Hochtief und der Commerzbank, mit einem Angebot in Höhe von 241,3 Millionen Euro durchgesetzt. Mit der Beantragung der Baugenehmigung im Herbst 2006 war ein weiterer wichtiger Schritt zur Realisierung des Mammutprojekts erfolgt.

Die Bürgerschaft der Freien und Hansestadt Hamburg gab ihr Einverständnis zum Bau der Philharmonie am 28. 02. 2007. Als Auftraggeber wurde die Elbphilharmonie-Hamburg-Bau GmbH & Co. KG eingesetzt. Die Vertretung in der Gesellschaft übernahm die ReGe Hamburg Projekt-Realisierungsgesellschaft mbH.

Die Zahlen der Machbarkeitsstudie waren allerdings schon bei Auftragsvergabe überholt. Aus den zuvor als Beitrag der Stadt veranschlagten 77 Millionen waren da bereits 114 Millionen Euro geworden. Damit war das Ende der Kostenspirale aber noch lange nicht erreicht.

Konflikte zwischen Auftraggeber und Errichtungsgesellschaft um die Kosten

Im Jahr 2008 sah sich die Stadt mit hohen Nachforderungen von Seiten des Konsortiums konfrontiert. Dem Projektkoordinator Hartmut Wegener wurde vom Senat in diesem Zusammenhang eine krasse Fehleinschätzung der Situation vorgeworfen, was diesen veranlasste, seinen Posten zu räumen. Die Aufgabe des Geschäftsführers der ReGe wurde Heribert Leutner übertragen, der zuvor als Projektleiter tätig war.

Im November des Jahres 2008 billigte der Senat einen Nachtrag in Höhe von insgesamt 209 Millionen Euro. 137 Millionen erhielt Adamanta, mit dem Rest wurden zusätzliche Kosten auf der eigenen Seite ausgeglichen. Die Gesamtkosten für die Stadt stiegen so auf 399,9 Millionen Euro. Nach Abzug von zugesagten Spenden von 77 Millionen Euro blieben immer noch 323 Millionen übrig, die aus den Taschen der Hamburger Steuerzahler finanziert werden mussten.

Doch auch diese Summe sollte schon bald nicht mehr ausreichen. Jeweils zum Jahresbeginn 2010 und 2011 wurden neue Nachforderungen an die Auftraggeber gestellt. Im August 2011 ging Hochtief bereits von Gesamtkosten in Höhe von 476 Millionen Euro aus.

Im Dezember 2012 war die Bausumme schon auf mehr als das Doppelte der ursprünglich vorgesehenen Summe gestiegen. Aus den 241,3 Millionen Euro aus dem Angebot waren einschließlich der Planungskosten 575 Millionen geworden. Auf diesen Betrag einigte sich der Senat nach langen und äußerst schwierigen Verhandlungen mit dem Bauunternehmen Hochtief, das nach einer Neugestaltung des Vertrages als Generalunternehmer fungierte. In dem neuen Vertrag wurde das Unternehmen verpflichtet, das Gebäude zum Maximalpreis von 575 Millionen bis zum Sommer 2015 fertigzustellen und die öffentlichen Bereiche des Bauwerks am 30. Juni 2016 zu übergeben. Die Schlüsselübergabe für das gesamte Gebäude sollte am 31. Oktober 2016 erfolgen. Bei weiteren Verzögerungen sollte das Unternehmen eine Vertragsstrafe in Höhe von 575.000 Euro pro Werktag zahlen. Für diesen Fall soll Hochtief nach Informationen aus Branchenkreisen Rückstellungen von 80 Millionen Euro gebildet haben.

Am 23. April 2013 gab der Erste Bürgermeister Hamburgs Olaf Scholz bekannt, dass die Steuerzahler der Stadt am Ende insgesamt 789 Millionen Euro aufbringen müssen, um das Projekt zu einem erfolgreichen Ende zu führen. Die Gesamtkosten für den Bau gab er mit 866 Millionen Euro an. In diesem Betrag waren die Kosten für die geplanten 45 luxuriösen Wohnungen nicht enthalten. Weiterhin bestätigte Scholz, dass die Differenz zwischen den von der öffentlichen Hand aufzubringenden Mitteln und den Gesamtkosten durch Spenden finanziert werden können.

Die Stadt übernimmt auch die Finanzierung des Luxushotels

Nachdem ein erstes Gutachten aus dem Jahr 2005 für das ebenfalls im Gebäude vorgesehene Hotel noch eine ausreichende Wirtschaftlichkeit bescheinigte, wurde diese in einer neueren Expertise bestritten. In dem 2008 erstellten Papier gehen die Wirtschaftsprüfer von einem Verlust in Höhe von 20 Millionen Euro aus. Ein zuvor interessierter Investor zog sich nach Bekanntwerden der Zahlen zurück, woraufhin auch hier die Stadt einsprang und den Bau mit etwa 200 Millionen Euro aus Steuergeldern finanzierte.

Nach seiner Fertigstellung wurde das 5-Sterne-Hotel mit 244 Zimmern von Adamanta an die Hotelgruppe ArabellaSheraton verpachtet. Bis zum Jahr 2032 sollen die Kredite für das Hotel durch die Pachteinnahmen getilgt sein. Danach ist ein Verkauf vorgesehen. Wir hoffen, dass das so funktioniert, Zweifel sind berechtigt.

Was ist schiefgegangen?

Durch die finanziellen Probleme und die Streitigkeiten zwischen den Vertragspartnern, die erst nach einer Neugestaltung der Verträge im Februar 2013 ausgeräumt werden konnten, musste die Eröffnung mehrfach verschoben werden. Bei der Grundsteinlegung zu dem Bauprojekt am 2. April 2007 waren alle Beteiligten von einer dreijährigen Bauzeit ausgegangen. Doch diese Planungen waren schon bald überholt. Zwar wurde die Bauzeit am Ende nicht so massiv überschritten wie beim größten der deutschen Katastrophenprojekte, dem Berliner Flughafen, allerdings ist eine Verzögerung von sechs Jahren ebenfalls recht beachtlich.

Bereits einen Tag nach der feierlichen Grundsteinlegung begannen mit der Errichtung eines Stahlkorsetts zum Schutz der Fassade und der Entkernung des alten Speichers die Bauarbeiten, die jedoch nicht wie geplant vorangingen. Im Mai 2010, zu einem Zeitpunkt, an dem das Gebäude eigentlich fertiggestellt sein sollte, wurde das Richtfest gefeiert.

Neben den finanziellen Differenzen kam es auch immer wieder zu Auseinandersetzungen zwischen den Behörden, den Architekten und dem Bauunternehmen, die sich gegenseitig Behinderungen vorwarfen. Die mangelnde Koordination und Kommunikation zwischen den beteiligten Parteien sowie Sicherheitsbedenken bei der Statik führten im Oktober 2011 zu einem Baustopp in wichtigen Teilbereichen des Projekts. Neben der technischen Gebäudeausstattung und der Rolltreppe waren davon die Sanierung der Fassade des Kaispeichers und in besonderem Maße die Dachkonstruktion betroffen. Erst nach mehreren Gutachten und verschiedenen Nachbesserungen sowie massiven Drohungen seitens des Senats, die Verträge zu kündigen, nahm Hochtief Ende Mai 2012 die Arbeiten wieder auf. Schon im Herbst 2011 hatte das Bauunternehmen aber verkündet, dass nicht vor dem November 2014 mit einer Fertigstellung des Gebäudes zu rechnen sei.

Aufgrund der Verzögerungen beim Bau war es bereits zuvor zu Mehrkosten in Höhe von 40 Millionen Euro gekommen, die Hochtief seit November 2008 beim Auftraggeber geltend machte. Auch in diesem Punkt kam es zum Streit mit der Stadt, die die Forderungen als unbegründet betrachtete und ihrerseits Schadensersatzforderungen in gleicher Höhe verlangte.

Wie wurde das Projekt schließlich gerettet?

Erst durch eine Vereinbarung im Juli 2012, in der die Eckpunkte für den weiteren Bau und der Sommer 2015 als Termin der Fertigstellung festgelegt wurden, konnte die Grundlage für einen neuen Vertrag geschaffen werden, der im Juni 2013 in Kraft trat. Darin wurden sowohl die Gesamtkosten in Höhe von 575 Millionen Euro, als auch die verbindliche Übergabe des Gebäudes im Oktober 2016 festgeschrieben.

Nachdem auf Grundlage dieses Vertrages alle Zuständigkeiten, Verantwortungsbereiche, Fristen und Kosten eindeutig geregelt waren, kehrte Ruhe in den Baubetrieb ein. Vertragsgemäß und fristgerecht wurde die Elbphilharmonie drei Jahre später übergeben. Seitdem haben schon tausende Besucher den öffentlich zugänglichen Bereich, die Plaza, besucht und den Blick über die Stadt und den Hafen genossen. Der große Konzertsaal wurde am 11. Januar 2017 mit einem großen Eröffnungskonzert eingeweiht.

Was lernen wir daraus für das Projektmanagement?

  • Wenn die Planungsgrundlagen eines Projektes nicht halten, kann das durch kein noch so professionelles Projektmanagement korrigiert werden.
  • Konflikte zwischen den Projektbeteiligten sind der sichere Weg in die Katastrophe. Wenn es nicht gelingt – allenfalls nach einem reinigenden Gewitter – konstruktiv zusammen zu arbeiten, gehen alle Aktivitäten des Projektmanagements ins Leere.
  • Wenn es Probleme in den Produktionsprozessen eines Projektes gibt (hier also im eigentlichen Bau), kann Projektmanagement das Problem frühzeitig erkennen, die Korrekturmaßnahmen initiieren und steuern, aber ohne Lösung des Primärproblems bleibt das wirkungslos.
  • Gutes Projektmanagement ist für den Erfolg eines Projektes notwendig, aber nicht hinreichend!
  • Terminverschiebungen und Budgetüberschreitungen werden bald vergessen, wenn das Ergebnis stimmt. Das magische Dreieck des Projektmanagements hat also einen deutlichen Schwerpunkt.

Projektmanagement in 8 Minuten – IT-Governance Blog

Beim 2. New York Speakerslam der Scherer Academy am 3. September 2016 versuchte ich zwei wesentliche Erfolgsfaktoren des Projektmanagements herauszuarbeiten: 1. Das richtige Maß an Planung zur richtigen Zeit. 2. Engpassorientierung statt Verzettelung.

Zu Beginn erzähle ich, was man beim New York Marathon für das Management von Projekten lernen kann.

Das persönliche Resumée war, dass Projektmanagement einfach Spaß macht und das aus mehreren Gründen. Aber dazu mehr im Video.

Projekt in der Krise – wie schafft man den Turnaround?

In Krisensituationen muss man sich rasch ein Bild von der Situation machen, das Wesentliche erfassen und alles Unwesentliche ausblenden. Leicht gesagt, aber was ist wesentlich, was nicht? Um das zu unterscheiden, benötigt man ein Modell, an dem man sich orientieren kann. Modelle zeichnen sich schließlich dadurch aus, dass sie die Realität vereinfacht darstellen, sodass man dank dieser Vereinfachung schneller und mit geringerem Aufwand zum gewünschten Ergebnis kommt.

Doch welches Modell soll man anwenden? Sollte man die Projektmanagementprozesse hinsichtlich der Prozessqualität checken und die erkannten Schwachstellen beseitigen? Laut ISO 21500 sind das 39 Prozesse, PMI nennt 47 Prozesse, in PRINCE2 sind es immerhin nur 7. Wie lange dauert die Analyse, wer soll das machen und hat man dann wirklich die Erkenntnisse, die man braucht, um das Projekt zu retten?

Dieser Beitrag stellt ein Modell vor, das für solche Herausforderungen gedacht ist, die „Engpasskonzentrierte Strategie“ (EKS). Der Nutzen des Modells lässt sich am besten am Beispiel des Managements von Projektkrisen aufzeigen, denn solche Extremsituationen wirken wie ein Vergrößerungsglas: Die Stärken und Schwächen des Modells werden deutlicher erkennbar als bei Routineprojekten.

In einem Artikel im projektmagazin beschreibe ich anhand von zwei Fallbeispielen, die man als Turnaround-Manager in Projekten mit Hilfe der EKS erfolgreich sein kann.

Wer sich ausführlich mit der EKS vertraut machen will, hier ist das Buch dazu

Lieber gleich richtig! – IT-Governance Blog

Bei einem meiner frühen Beratungsprojekte wurde ich in das soeben eingeführte Qualitätsmanagementsystem des Kunden integriert und musste bzw. durfte an der Mitarbeiterschulung teilnehmen. Das System war das von Crosby & Associates und der Kernsatz dieses Systems lautet: „Lieber gleich richtig“.  Mit dem Schlagwort „Null-Fehler“ bzw. „Zero-Defect“ wurde diese Strategie bekannt.

Interessant ist allerdings, dass dieser Ansatz in IT-Projekten aktuell keine Rolle spielt. In mehreren Großprojekten, die ich in verschiedenen Rollen begleitet habe, war eine Bug-Statistik selbstverständlicher Teil des Projektcontrollings. Alle Einwände von Anwendervertretern, dass die Fehlerzahl zu hoch sei, wurden als Zeichen mangelnden Verständnisses für das Wesen von Softwareentwicklung weggewischt. Es gibt keine fehlerfreie Software, das weiß man doch!

Nun lese ich gerade wieder ein Buch von Tom deMarco, das ich generell sehr empfehlen kann. Das Buch gibt es nur noch antiquarisch, das aber sehr preisgünstig und unkompliziert.

Dort berichtet er von einem Gespräch mit zwei Softwareentwicklern, die vor Jahren ein Programm entwickelt hatten, bei dem kein einziger Fehler gefunden worden war. „Ich fragte einen von ihnen, wie er sich denn diesen phänomenalen Erfolg erklärt, ein Programm ohne jeden Bug schon beim ersten Versuch auszuliefern. Er gab mir folgende Antwort: Ähhh, wir haben gar nicht gewusst, dass Bugs erlaubt sind.“ (a.a.O., S. 333). Und weiter schreibt Tom DeMarco: „Es ist unter Softwareentwicklern allgemein bekannt, dass sie niemals den allerletzten Bug aus einem Programm herausbekommen werden. Bugs werden als traurige Lebensweisheit hingenommen. Wir hoffen, sie eines Tages auszumerzen, können sie aber nie endgültig besiegen. Ich bin mehr und mehr über den Gedanken beunruhigt, dass diese fatalistische Haltung Bugs gegenüber kein produktiver Bestandteil unserer Vorgehensweise ist, wie wir an das Problem herangehen, sondern ein Teil des Problems selbst. Ich glaube, wenn wir damit aufhören, uns selbst einzureden, dass Bugs erlaubt sind, würde es weniger davon geben.“ (ebenda, S. 334).

Ich muss zugeben, dass ich von diesem Konsens der Selbstverständlichkeit und Unvermeidlichkeit von Fehlern schon weichgeklopft war und nicht mutig genug, mich hier als Außenseiter zu deklarieren. Aber es ist doch richtig, dass jeder von uns die Pflicht hat, fehlerfreie Arbeit auszuliefern. Ja, Fehler kommen vor, aber es sind Fehler und wir müssen einen Lernprozess in Gang setzen, denselben Fehler nicht zweimal zu machen. Wenn man Fehler verharmlosend als Bugs bezeichnet (als wäre das eine höhere Gewalt), anstatt zu sagen, dass es Fehler sind, die jemand gemacht hat, geht viel Zeit, Geld und Motivation verloren, um vermeidbare Fehler zu suchen, zu finden, zu melden, auszubessern und dann wieder nach Fehlern bei der Fehlerkorrektur zu suchen usw. usw. Das ist enorm teuer. Tom deMarco rechnet das vor, Philip P. Crosby hat das schon vor Jahrzehnten für verschiedene Branchen getan und das Argument ist immer noch richtig. Es gilt auch für IT-Projekte!

Ich hoffe, ich schaffe es, in den von mir begleiteten Projekten erfolgreich dagegen zu argumentieren. Und um Missverständnissen vorzubeugen: Es geht überhaupt nicht darum, Leute für Fehler niederzumachen. Aber es kann nicht sein, dass man Fehler verschleiert und schönredet. Es stimmt schon: „Wo gehobelt wird, fallen Späne“. Aber das heißt ja nicht, dass der Tischler die Späne ausliefert, weil er das Möbelstück nicht fertigbringt.

Bild: Patrick M. Pelz

Begeisterung für das Unternehmensziel – Agilität bei Zalando

Wohl jeder von uns kennt die Zalando-Werbung, die Begeisterung in den Mittelpunkt stellt und sich durch Selbstironie auszeichnet. Hier ein Beispiel von vielen:

Im Rahmen der PM-Welt am 30.3.2017 in München kam ein Vortrag aus dem Hause Zalando. Wie das? Zalando hat eine beachtliche IT-Abteilung, wobei „Abteilung“ nicht das richtige Wort ist: es sind ungefähr 200 Teams mit Softwareentwicklung beschäftigt, viele davon auf 7 der insgesamt 11 Standorte des Unternehmens verteilt. 1.500 der insgesamt 11.000 MitarbeiterInnen gehören zu diesem Bereich.

Ich habe zwar nicht gekreischt vor Begeisterung, aber der Vortrag war überraschend und anregend, für mich einer unter den Top 3 dieses Kongresses.

Die Zalando-IT strebt „radikale Agilität“ an. Erstaunlicherweise gibt es auch in diesem jungen Unternehmen (gegründet 2008) schon Altlasten in Form eines monolithischen Systems, das nun in Mikroservices zerlegt wird.

Was ist radikale Agilität bei Zalando? Zunächst dazu ein Bild:

Das sind natürlich viele Schlagworte, in so einem Unternehmen muss sich auch die IT reklamig präsentieren. Aber dazu gibt es auch drei konkrete Prinzipien, die für alle anwendbar sind.

 

  1. Purpose: Wir richten uns am Unternehmensziel aus. Dieses lautet: Reimagine fashion for the good of all. Auch wenn es um die Entwicklung einzelner Features geht, soll sich jeder Entwickler bewusst sein, dass alles letztlich zu diesem Ziel beitragen muss. Jede kleine Entscheidung und erst recht jede größere Entscheidung muss im Gesamtkontext beurteilt werden.
  2. Mastery: Jeder Mitarbeiter (und natürlich gilt das, wie alles hier auch für jede Mitarbeiterin) muss danach streben, (insbesondere, aber nicht nur) technische Kompetenzen zu entwickeln und Best Practices  anzuwenden, zu entwickeln und zu verbreiten. Gute Leistungen und ständige Verbesserungen werden erwartet und durch eine intensive Feedback-Kultur gefordert und gefördert.
  3. Autonomie: „Trust instead of Control“ ist ein Leitsatz. Das bedeutet für die Teammitglieder aber auch, Verantwortung zu übernehmen für das, was man tut, die Hierarchie herauszufordern, in Netzwerken denken. Experimentieren bei der Umsetzung der Unternehmensziele (siehe Prinzip 1).

In der Diskussion gab es einige Überraschungen, als es um praktische Details ging. Kostenschätzungen im Voraus sind eine Orientierung, aber keine Vorgabe. Priorität hat immer der Beitrag zur Erreichung der Unternehmensziele, natürlich wird nach höchstmöglicher Effizienz gestrebt, aber diese wird durch das Prinzip 2 adressiert, nicht durch einen aufwändigen Planungs- und Budgetierungsprozess.

Projektaufträge gibt es bei Projekten, an denen mehrere Abteilungen mit widersprüchlichen Erwartungen beteiligt sind. Sie beschränken sich allerdings auf eine Roadmap und Meilensteine. Abhängigkeiten werden eher high level dargestellt und im Vordergrund steht das Commitment zu einem gemeinsamen Ziel. Dazu gehört viel Kommunikation und die Vortragende, Valentine Vierne, konnte deutlich machen, dass ihr Job vor allem darin besteht, mit allen immer wieder zu reden, Informationen weiter zu tragen, Kontakte herzustellen und Missverständnisse zu korrigieren.

Am Ende jedes Projektes steht eine Retrospektive mit den Punkten „Team issues & suggested improvements“ sowie „External issues & suggested improvements“. An diesen Retrospektiven können und sollen auch „Gäste“ teilnehmen, seien es Anwender, Mitglieder des Managements oder andere relevante Stakeholder. Das ist Teil der Kommunikations- und Feedback-Kultur, die als einer der zentralen Erfolgsfaktoren gesehen wird.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

 

Danke Fehler! Du bist mein Coach

Einer der Top-Vorträge der PM-Welt 2017 war der von Jens Corssen. „Klagen Sie noch – oder sind sie schon erfolgreich? Warum Jammern aus Gewohnheit unsere Potentiale reduziert“, der Titel des Vortrages klang schon vielversprechend, der Inhalt übertraf allerdings meine Erwartungen deutlich.

Zunächst seine Grundthese, dass unsere Gestimmtheit (salopp: wie wir drauf sind) bestimmt, wie wir die Welt wahrnehmen. Wenn ich verstimmt bin, treffe ich dauernd Idioten, bin ich gut gestimmt, ist die Welt voll mit angenehmen Menschen. Wenn wir unser Selbstwertgefühl von anderen Menschen oder äußeren Umständen abhängig machen, spielen wir ein gefährliches Spiel das leicht zu einer Abwärtsspirale führt. Es liegt an uns, das zu ändern.

Wir kennen aus der NLP das Konzept des Reframing. Jens Corssen hat einige konkrete Formulierungen beigesteuert, die man jederzeit anwenden kann:

  • Anstatt: „Das gibt’s doch nicht“ oder „Das darf doch nicht sein“ besser: „Das hab ich mir anders vorgestellt“. Das kann man auch wütend, schreiend, auf den Boden stampfend sagen oder zumindest denken.
  • Wenn Dich jemand ärgert: „Er gibt sein Bestes, mehr ist einfach nicht drin.“
  • Das ist kein Idiot, vielleicht ist er nur „Nicht geübt im Denken“.

Was bringt das für das Projektmanagement? Keine Zeit und Energie damit verschwenden, sich über Kollegen, Kunden und wen auch immer zu ärgern. Sag Dir einfach: „Sie geben ihr Bestes, mehr ist nicht drin.“ „Vielleicht sind sie nicht so geübt im Denken wie ich“. Sobald man die Dinge so betrachtet, erkennt man die eigene Rechthaberei, der Ärger verfliegt und man wird offen für Lösungen. Ärgern und Jammern hingegen versetzt uns in einen Stresszustand, der uns daran hindert, aus gewohnten Mustern auszubrechen. Nur ein Paradigmenwechsel bringt den Durchbruch. Corssen erinnerte an Beispiele im Sport: der Fosbury-Flop beim Hochsprung, die V-Stellung beim Schispringen.

Probleme sind nicht lösbar mit dem Denken, das sie verursacht hat, das stammt von Einstein. Watzlawick warnte vor „Mehr desselben“. Daher immer – so der Rat von Corssen – 8 Optionen generieren, erst dann beginnt man, das Denkmuster zu wechseln, die ersten Optionen sind immer nur mehr desselben.

Ich höre so oft die Klage über Moving Targets. Ich kenne kein Projekt, bei dem es keine Unklarheiten und Änderungen der Zielsetzungen während des Projektes gab. Sich darüber zu ärgern, ist verschwendete Energie. Die Auftraggeber geben ihr Bestes, mehr ist einfach nicht drin! Oder ganz ernsthaft: Das Projekt ist wichtig, es nimmt teil an der Dynamik des Unternehmens und seiner Umwelt.

Und wenn was schiefgeht: Danke Fehler, Du bist mein Coach! Ich habe aus einem Coaching vor gut 15 Jahren ein Mantra mitgenommen, das ich immer anwende, wenn etwas so richtig schiefläuft: „Eine interessante Erfahrung!“ Das hilft, wirklich!

Wer Jens Corssen im O-Ton lesen will,
hier eines seiner Bücher.