VVorwort zur 8. Auflage

Zunächst ein Motivationsschub für Projektmanager und solche, die es werden wollen: Dass Projekte das wesentliche Vehikel sind, um technischen und organisatorischen Wandel zu realisieren und dass sie damit letztendlich für wirtschaftliches Wachstum sorgen, ist nicht neu. Leider war aber bislang die quantitative Bedeutung der Leistungserstellung mit Projektcharakter in einer Volkswirtschaft unbekannt. Das hat sich jetzt geändert: In einer gemeinsamen Studie* der GPM Deutsche Gesellschaft für Projektmanagement e.V. und der EBS Universität für Wirtschaft und Recht wurde der Anteil der Projekttätigkeit in der deutschen Wirtschaft branchen- und projektartenübergreifend gemessen. Es zeigte sich, dass der Anteil der Projektarbeit im Jahre 2013 an der Gesamtarbeitszeit in Deutschland 34,7 Prozent betrug. Nimmt man an, dass dieser Wert auch für den Anteil an der Bruttowertschöpfung gilt, ergibt sich ein Betrag von 877 Mrd. €. Die Forscher prognostizieren außerdem wachsende Werte. Für systematisches Projektmanagement ist also großer Bedarf.

Kommen wir zu den Trends: Das Gedankengut des agilen Projektmanagements hat sich stark ausgebreitet. Immer mehr Erfahrungsberichte, aus denen wir lernen können, liegen vor. Aus diesem Grund haben wir auch diesem Themenkreis in der 8. Auflage besondere Aufmerksamkeit gewidmet. Eine weitere Entwicklung ist zu beobachten: War agiles Projektmanagement anfangs nur für IT-Projekte mit zunächst wenig vollständigen und stabilen Anforderungen gedacht, so werden jetzt nicht nur hybride Ansätze in Projekten erprobt, in denen die Informationstechnik nur eine Komponente von mehreren ist, etwa in der Mechatronik, sondern Agilität wird mehr und mehr auch als allgemeines Konzept für das Projektmanagement gesehen.

 

Wald, A.; Schneider, Ch., Spanuth, Th.; Schoper, Y.: Ergebnisse einer Studie zur Messung der Projekttätigkeit. Die Projektifizierung der deutschen Wirtschaft. Projektmanagement aktuell 5/2015, S.60–65.

VIEine weitere Beobachtung ist, dass das „Magische Dreieck“ (in den Kosten, in der Zeit und mit der vereinbarten Qualität und den zugesagten Funktionen) zwar immer noch Bestandteil der Zielfunktion des Projekts ist, aber ergänzt und eventuell sogar dominiert wird durch den Nutzen, den das Vorhaben für die Organisation stiften soll. Die Konsequenz aus dieser Erweiterung des Zielbaums muss die Einführung von Nutzencontrolling sein.

Besonders erfreulich ist, dass die Organisationspsychologie mehr und mehr Projektmanagement als Forschungsgebiet entdeckt und klassische, sozusagen schon dogmatisierte Vorgehensweisen wie z. B. im Risikomanagement, radikal infrage stellt.

Auch in das Stakeholdermanagement ist, nicht zuletzt durch den Aufstand der Wutbürger angestoßen, Bewegung gekommen. Organisationspsychologen und Kommunikationswissenschaftler üben heftige Kritik an der traditionellen Vorgehensweise.

Schließlich wird als Ziel von Projekten zunehmend die Nachhaltigkeit betont und angestrebt, die Vielfalt der Mitarbeiter in der Organisation (Diversity) nicht nur zu tolerieren, sondern auch für den Projekterfolg zu nutzen.

Wenn in diesem Buch von Projektleitern, Kollegen oder Mitarbeitern die Rede ist, so sind gleichermaßen Frauen und Männer gemeint. Alle Leserinnen bitten wir dafür um Verständnis.

Ein letzter Punkt: Die ICB 4.0 liegt uns jetzt in drei umfangreichen Bänden vor. Die Professionalisierung im Projektmanagement schreitet voran. Werner Schmehr wird im Kapitel 24 Qualifizierung und Zertifizierung darüber ausführlich berichten. Keiner kann es besser als er. Dafür an dieser Stelle herzlichen Dank. Dank auch an Hermann Schenk vom Beck-Verlag für die Geduld und die Betreuung und Prof. Dr. Gerold Patzak für die akribische Fehlerkorrektur der 7. Auflage.

Im Mai 2018

Heinz Schelle
Oliver Linssen

1Einführung

Wegweiser durch das Buch

Eine Fallstudie zum Einstieg

Die Einführung beginnt mit der Schilderung eines fiktiven, wenig erfolgreichen Software-Entwicklungsprojekts (1. Kapitel „Ein misslungenes Projekt“), in dem sowohl der Auftraggeber als auch der Auftragnehmer viele Fehler begangen haben. In den folgenden Kapiteln wird immer wieder Bezug auf dieses Projekt genommen und gezeigt, wie man es hätte besser machen können.

Grundlagen des Projektmanagements

Das 2. Kapitel („Was ist ein Projekt, was bedeutet Projektmanagement und welche Erfolge bringt es?“) klärt einige grundlegende Begriffe, identifiziert typische Fehler und Versäumnisse in Projekten und zeigt, welche Erfolgspotentiale das Führungskonzept „Projektmanagement“ hat.

Im 3. Kapitel („Grundsätze des Projektmanagements“) werden wichtige Prinzipien des Projektmanagements wie z. B. die Strukturierung von Vorhaben und die starke Betonung der Definitionsphase herausgearbeitet.

Im 4. Kapitel („Projektmanagement lohnt sich auch bei kleineren Vorhaben“) wird der Nachweis versucht, dass Projektmanagement auch bei kleineren Projekten mit Erfolg angewandt werden kann. 2Ein „Minimalschema für kleine Projekte“ spiegelt die Auffassung des Verfassers wider, welche Vorkehrungen zumindest getroffen werden müssen, damit von systematischem Projektmanagement gesprochen werden kann.

Was man für erfolgreiche Projekte tun und was man lassen sollte

Nach diesen einführenden Kapiteln beginnt der Methodenteil. Das 5. Kapitel („Die,richtigen‘ Projekte machen: Projektauswahl“) befasst sich mit einem wesentlichen, in Lehrbüchern in der Regel allerdings vernachlässigtem Aspekt des strategischen Projektmanagements, nämlich der Frage, welche Vorhaben aus einer größeren Menge von Projektvorschlägen ausgewählt werden sollen bzw. ob ein Projektangebot an einen Kunden gemacht werden soll oder nicht.

Das 6. Kapitel („Das Projektteam formieren: Projektleiter und Projektgruppe einsetzen“) erläutert wichtige Voraussetzungen für den Projekterfolg wie die Auswahl des Projektleiters und seine Ausstattung mit Befugnissen, die Zusammensetzung des Projektteams und Fragen des geeigneten Führungsstils.

Das 7. Kapitel („Projektziele mit dem Auftraggeber zusammen definieren und den Beteiligten vermitteln: Projektdefinition und Projektstart“) gibt Ratschläge für die Formulierung von Projektzielen (Lastenheft und Pflichtenheft) und die Durchführung von Projektstartsitzungen.

Das 8. Kapitel („Das Projektumfeld berücksichtigen: Umfeld- und Stakeholdermanagement“) bietet detailliertere Ausführungen zu einer wesentlichen Aufgabe des Projektmanagements in frühen Projektphasen, der Ermittlung der Projektinteressenten (Stakeholder) und ihrer Ziele, sowie der Formulierung einer Strategie für den Umgang mit den Projektinteressenten.

Im 9. Kapitel („Projektrisiken aufdecken und Vorsorge treffen: Risikomanagement in Projekten“) wird eine weitere wichtige Aufgabe erläutert, die bereits beim Projektstart von der Projektleitung 3in Angriff genommen werden muss, dann aber auch während des Projektablaufs immer wieder einmal durchzuführen ist: Die Ermittlung und Bewertung der Risiken, die den Projekterfolg gefährden könnten und die Ausarbeitung einer entsprechenden Risikopolitik.

Ein Ergebnis des Projektstarts (7. Kapitel) sollte ein zumindest grober Projektstrukturplan sein, der dann im Laufe des Projekts in der Regel weiter detailliert wird. Das 10. Kapitel („Das Projekt gründlich strukturieren: Der Projektstrukturplan“) behandelt die Zwecke des „Plans der Pläne“ und zeigt, worauf bei seiner Erstellung zu achten ist.

Arbeitspakete, d. h. Aufgabenbündel, die im Projektstrukturplan nicht mehr weiter aufgegliedert sind, werden im 11. Kapitel („Projektablauf und Projekttermine planen: Es muss nicht immer Netzplantechnik sein“) zu Netzplänen verknüpft. Die Regeln der Errechnung von Terminen in Netzplänen werden erläutert. Daneben werden einfachere Verfahren der Terminplanung vorgestellt.

Die Aufgliederung des Projekts in Arbeitspakete ist in der Regel auch eine Voraussetzung für eine solide Aufwands- und Kostenschätzung in Projekten (12. Kapitel „Einsatzmittelbedarf und Kosten schätzen: Den Königsweg gibt es nicht“). Für Projekte aus verschiedenen Branchen (u. a. Bau-, Organisations- und IT-Projekte) werden entsprechende Verfahren demonstriert.

Die projektbezogene Planung des Bedarfs an Einsatzmitteln (im allgemeinen Arbeitskräfte verschiedener Qualifikation und Betriebsmittel) in den einzelnen Planungsperioden, z. B. Arbeitstage oder -wochen gehört zu den schwierigsten Aufgaben im Projektmanagement. Es wird im 13. Kapitel („Arbeitskräfte und Betriebsmittel richtig einsetzen: Projektbezogene Einsatzmittelplanung und Projektportfolio- und Programmmanagement“) begründet, warum die Projektion von Bedarfsgrößen auf die zuvor durch die Terminplanung im Zeitraster fixierten Arbeitspakete zwar theoretisch sehr elegant ist, in der Praxis aber auf erhebliche Schwierigkeiten stößt. Einfachere Alternativen werden empfohlen. Außerdem wird aus den Zusammenhängen zwischen Projekten, die über den Zugriff auf gemeinsam genutzte Einsatzmittel oft weit hinausgehen, die Notwendigkeit des Multiprojekt – bzw. Programmmanagements abgeleitet.

4Nach der Planung der Kosten (12. Kapitel) müssen in der projektbegleitenden Kostenverfolgung (14. Kapitel „Die Projektkosten unter Kontrolle halten: Mitschreitende Kostenverfolgung“) für die einzelnen Arbeitspakete zumindest die laufend angefallenen Istkosten ermittelt werden. Neben dieser sehr einfachen Technik, mit der lediglich festgestellt werden kann, wie weit der Planansatz bereits ausgeschöpft ist, werden auch kompliziertere Methoden erklärt, mit deren Hilfe der Soll-Ist-Vergleich an Aussagekraft gewinnt.

Die zu Beginn eines Projekts einmal festgelegten Sachziele (7. Kapitel) ändern sich sehr häufig im Verlauf des Vorhabens. Systematisches Änderungsmanagement oder die erweiterte Form des Konfigurationsmanagements (15. Kapitel „Änderungen im Griff haben: Änderungs- und Konfigurationsmanagement“) müssen, vereinfacht gesagt, sicherstellen, dass diese Änderungen dokumentiert und ihre Durchführung überwacht wird, aber auch, dass die Auswirkungen auf Termine, Kosten und unmittelbar nicht betroffene Komponenten des Projektgegenstands überprüft werden.

Neben der Einhaltung des Termin- und Kostenziels ist der Projektleiter auch dafür verantwortlich, dass die dem Auftraggeber bzw. dem Kunden zugesicherte Qualität erreicht wird. Das 16. Kapitel („Qualität im Projektmanagement: Der Kunde soll zurückkommen, nicht das Produkt“) bietet einen Überblick, was Qualität im Projektmanagement bedeutet, über die besonderen Probleme des Qualitätsmanagements in Projekten, wie das Thema Qualität in gängigen Standards behandelt wird und welche Methoden den Projektleiter dabei unterstützen, im Projekt die gewünschte Qualität zu erzeugen und zu prüfen.

Neben einem zumindest groben Projektstrukturplan sollte beim Projektstart ein Phasen- oder Vorgehensmodell erstellt werden. Im 17. Kapitel („Haltepunkte im Projekt setzen: Phasen- und Vorgehensmodelle“) werden individuelle und standardisierte Phasen- und Vorgehensmodelle aus verschiedenen Branchen aufgeführt, der Zusammenhang mit dem Projektstrukturplan und der Ablaufplanung (10. Kapitel und 11. Kapitel) hergestellt und die Vorteile einer derartigen Planung erläutert. Phasenmodelle setzen durch Meilensteine, die im Projekt zu erreichen sind, signifikante Haltepunkte, 5mit deren Hilfe der Projektverlauf aufgrund von Zwischenergebnissen überprüft werden kann. Vorgehensmodelle sind Best-Practice-Sammlungen, welche Prozesse in Projekten ausgeführt werden sollten, welche Dokumente und Zwischenprodukte erzeugt werden sollten und welche Rollen in einem Projekt besetzt werden sollten. Hier wird außerdem auf das Konzept des agilen Projektmanagements eingegangen, das in den letzten Jahren zunehmende Verbreitung gefunden hat.

Bereits laufende Projekte müssen ständig überwacht werden, alle Beteiligten sind durch das Berichtswesen über den Projektstatus zu informieren. Bei unerwünschten Planabweichungen muss der Projektleiter gegensteuern. Im 18. Kapitel („Das Projekt auf Erfolgskurs halten: Projektberichtswesen und Projektsteuerung“) werden die Anforderungen an das Projektberichtswesen formuliert und einige Projektberichte gezeigt. Am Beispiel von Termin- und Kostenabweichungen wird aufgeführt, welche Alternativen bestehen, um die gesetzten Projektziele dennoch zu erreichen.

Konflikte sind in Projekten nahezu unvermeidbar, schon weil häufig mehrere Fachdisziplinen an ihnen beteiligt sind. Im 19. Kapitel („Konflikte im Projekt beherrschen“) werden die verschiedenen Konfliktursachen erläutert und Möglichkeiten der Konfliktlösung behandelt.

Für die Planung und Überwachung des Projekts ist heute der Einsatz von entsprechender Software unumgänglich. Im 20. Kapitel („Den Rechner nutzen: Auswahl von Projektmanagement-Software“) wird demonstriert, welche Unterstützung Software dem Projektmanagement heute bieten kann und worauf bei der Entscheidung für ein bestimmtes Programmpaket zu achten ist.

Im 21. Kapitel („Das Projekt systematisch beenden und Erfahrungen auswerten“) werden schließlich zwei in der Praxis häufig vernachlässigte Aufgaben behandelt: Die systematische Beendigung des Projekts und das Lernen aus erfolgreichen und fehlgeschlagenen Projekten.

6Was ist zu tun, um Projektmanagement erfolgreich in der Organisation einzuführen?

Das 22. Kapitel („Die Einführung und Optimierung von Projektmanagement in Organisationen“) ist aus der Sicht des Verfassers das wichtigste. Das beste Projektmanagement-Konzept nützt nichts, wenn die Einführung von den Betroffenen systematisch boykottiert wird. Deshalb wird ein Vorgehensmodell erläutert, mit dessen Anwendung sich die Chancen einer erfolgreichen Implementierung beträchtlich erhöhen lassen.

Was können Bosse für den Projekterfolg tun und wie können Mitarbeiter in Projektmanagement aus- und weitergebildet werden?

Im 23. Kapitel („Zum guten Schluss: Was Vorstandsmitglieder, Geschäftsführer und Behördenchefs für erfolgreiche Projektarbeit tun können – Ratschläge an das Topmanagement“) findet der Leser Tipps für Führungskräfte, die zwar in der Regel nichts mit dem operativen Projektmanagement zu tun haben, die aber dennoch einen erheblichen Beitrag zu erfolgreichen Projekten leisten können.

Im 24. Kapitel („Qualifizierung und Zertifizierung im Projektmanagement“) informiert Werner Schmehr über die Möglichkeiten der Qualifizierung und Personenzertifizierung in der Bundesrepublik.

Was sollte man zur Vertiefung lesen?

Die Zahl der Bücher zum Thema „Projektmanagement“ wird immer größer. Das Angebot ist nur noch schwer zu überschauen. Deshalb werden im Anhang einige Literaturempfehlungen gegeben.

71. Kapitel

Ein misslungenes Projekt: Eine Fallstudie1

Das Projekt Proma-net war von der Pro-telligenz GmbH, einem kleineren Softwarehaus mit etwa 30 Mitarbeitern, durchgeführt worden. Auftraggeber war die Cloudwired AG, ein Unternehmen, das sich auf Cloud-basierte Lösungen für den Mittelstand spezialisiert hatte. Das Projektziel war, eine im Browser laufende Groupware- und Projektmanagement-Lösung für die Cloudwired AG zu entwickeln. Diese Groupware- und Projektmanagement-Lösung sollte folgende Eigenschaften haben:

Mit der Anwendung sollten kleine bis mittlere Projekte geplant und durchgeführt werden können. Als Zielgruppe waren insbesondere Unternehmen im Dienstleistungs- und IT-Bereich vorgesehen.

Da das Projekt in eine Krise geraten war, wurde ein externer Berater hinzugezogen. Er hatte den Auftrag, den Stand des Projekts zu analysieren, Probleme zu identifizieren und Lösungen vorzuschlagen.

8Vorgehensweise

Es wurde eine erste Besprechung abgehalten, an der Frau Schwarz, die bei der Cloudwired AG für die Produktlinie „TeamApps“ verantwortliche Managerin, Georg Westerhage, der Geschäftsführer der Pro-telligenz GmbH und Hans Braun, der Projektleiter für das Projekt Proma-net, teilnahmen. Nach dieser Besprechung wurden fünf Mitglieder des Projektteams, ein früherer Projektmitarbeiter und drei Mitarbeiter der Cloudwired AG interviewt. Schließlich wurden die Vertragsunterlagen, die gesamte Projektplanung, das Lastenheft, das Pflichtenheft, die bislang vorliegende Benutzerdokumentation und die bis zum Stichtag angefallenen Projektkosten analysiert.

Projektverlauf

Die Cloudwired AG hatte für Proma-net ein Lastenheft erarbeitet und verschiedene Softwarefirmen gebeten, Angebote einzureichen. Das Lastenheft war am 15. Juli 2016 an diese Firmen übergeben worden.

Folgende Terminmeilensteine waren durch den Auftraggeber festgelegt worden.

15. Juli 2016

Übergabe des Lastenhefts

14. August 2016

Einreichung der Angebote

1. September 2016

Annahme eines Angebots durch Cloudwired AG

15. September 2016

Projektstart

1. März 2018

Auslieferung der Software

Die Konkurrenzsituation

Fünf Firmen hatten ein Angebot abgegeben. Drei Softwarehäuser hatten sich nicht um den Auftrag beworben, und zwar mit der Begründung, dass die Zeit für die Entwicklung zu knapp bemessen sei. 9Zwei der Anbieterfirmen waren ganz offensichtlich nicht qualifiziert genug. Der Preis eines Anbieters lag erheblich über dem Preis der verbleibenden zwei Firmen, der Pro-telligenz GmbH und der DynamiqProducts AG. Das Angebot der Pro-telligenz GmbH lag bei 2.100.000 €, das Angebot von DynamiqProducts bei 2.875.000 €. Die Pro-telligenz GmbH erhielt daraufhin den Auftrag.

Westerhage war der Ansicht, dass der Auftrag der Cloudwired AG insbesondere aus strategischen Überlegungen für die Firma wichtig sei. Die Pro-telligenz GmbH hatte in der Vergangenheit schon einige Standard-Anwendungen entwickelt, hatte aber weder Erfahrung mit umfassenden Projektmanagement-Anwendungen, noch mit Lösungen im Bereich Social Software.

Nach Meinung des Geschäftsführers würde der Entwicklungsauftrag dem Unternehmen dazu verhelfen, Know-how und eine führende Position bei Groupware-Anwendungen zu gewinnen, einem Markt, den er als zukunftsträchtig einschätzte.

Außerdem benötigte das Unternehmen dringend einen Auftrag, um einige qualifizierte Programmierer, die zzt. nicht mit Kundenprojekten beschäftigt waren, nicht entlassen zu müssen. Braun verpflichtete sich dem Auftraggeber gegenüber, das Produkt am 1. März 2018 zu liefern. Das Projekt konnte planmäßig am 15. September 2016 beginnen.

Projektstart

Eine Reihe von Mitarbeitern wurde in der Pro-telligenz GmbH mit dem Projekt Proma-net betraut. Sie kamen aus zwei verschiedenen Abteilungen der Firma und blieben ihren Linienvorgesetzten disziplinarisch unterstellt. Außerdem wurde von der Geschäftsführung dem Projektleiter Braun eine stellvertretende Projektleiterin, Frau Grau, zur Unterstützung gegeben. Frau Grau war erst seit kurzem im Unternehmen. Die Aufgaben des Projektleiters waren in einem Projektmanagement-Handbuch, das vor einigen Jahren von einem Beratungsunternehmen erstellt worden war, im Detail beschrieben worden. Befugnisse für den Projektleiter waren darin allerdings nicht formuliert worden. Die Geschäftsleitung hatte damals durch 10ein Rundschreiben angeordnet, dass der Leitfaden ab sofort die Grundlage für die Abwicklung von Projekten im Unternehmen ist.

Herr Braun hatte Erfahrung mit der Entwicklung von reinen Projektplanungsanwendungen auf der Basis der Betriebssysteme der Windows-Familie, aber keine Erfahrung im Bereich Groupware-Anwendungen.

Frau Grau hatte beträchtliche Erfahrung mit der Programmiersprache Java, verstand aber nicht viel von Anwendungen im Bereich Groupware und Projektmanagement.

Braun und Grau hatten unterschiedliche Vorstellungen davon, wie die Benutzeroberfläche (User Interface) im Detail bei Proma-net aussehen sollte. Die Vorgaben des Auftraggebers ließen in diesem Punkt Interpretationsspielraum. Wegen des Zeitdrucks hatte man auf die Erstellung von Prototypen (siehe 17. Kapitel) verzichtet. Alle Mitglieder des Projektteams wurden in die Diskussion über dieses Thema einbezogen. Die anderen Komponenten der Anwendung wurden darüber etwas vernachlässigt. Eine Einigung wurde nicht erzielt. Nach ungefähr einem Monat bekam der Projektleiter ein schlechtes Gewissen und beschloss, sich auch um die anderen Programmteile etwas intensiver zu kümmern. Er ließ Frau Grau die Benutzeroberfläche weitgehend nach ihren eigenen Vorstellungen entwickeln.

Erste Probleme

Im März 2017 waren einige Programmteile geschrieben und getestet. Braun nahm einen ersten Integrationstest vor. Das war zunächst sehr schwierig, weil Testdaten und Testwerkzeuge fehlten. Dieses Problem war aber bald behoben.

Der Projektleiter merkte rasch, dass er und seine Mitarbeitern ganz offensichtlich bei der Spezifikation der Schnittstellen geschlampt hatten.

Es erwies sich als notwendig, einige Änderungen vorzunehmen. Das führte zu ausgedehnten Diskussionen mit der stellvertretenden Projektleiterin, die Frau Grau dadurch beendete, dass sie kündigte und 11die Firma verließ. Sie hatte sehr trickreich, kompliziert und wenig nachvollziehbar programmiert. Deshalb hatten alle anderen Programmierer große Mühe, sich in den Code einzuarbeiten.

Mit der Programmierung des Programmteils, der die Projektstrukturpläne einschließlich der Arbeitspakete verwaltete, waren zwei jüngere Programmierer fachlich überfordert. Hinzu kam, dass diese beiden Mitarbeiter und zwei weitere Kollegen zwar ein vorangegangenes Projekt offiziell beendet hatten, in ihrer Abteilung aber aufgrund von Beschwerden des Kunden noch erhebliche Nachbesserungen (Fehlerbeseitigung, Ergänzung der Dokumentation, Ergänzung der Software um einige Funktionen; Erstellung von Schulungsunterlagen) machen mussten und somit nicht voll für das Proma-net-Projekt zur Verfügung standen.

Eine Reihe von Funktionen des Programms fehlte noch und die Funktionen, die schon fertig waren, liefen zum Teil sehr langsam. Der Bedienungskomfort war gering. Robert Silber, der Datenbankspezialist bei Pro-telligenz, wurde für das Projekt abgestellt, um vor allem die Dokumentenverwaltungskomponente doch noch zufriedenstellend zu Ende zu entwickeln.

Der Projektleiter greift durch

Mitte Mai 2017 gingen die Arbeiten aufgrund verschiedener Sonderaktionen einigermaßen voran. Obwohl es keinen detaillierten Terminplan gab, sondern nur zu Beginn des Projekts einige Ecktermine – die entsprechenden, dazugehörigen Meilensteinergebnisse waren wenig präzise formuliert – gesetzt worden waren und ein grober Balkenplan existierte, der nach Projektstart nicht mehr aktualisiert wurde, war Braun zuversichtlich, dass die Probleme, die sich im Projekt gezeigt hatten, gelöst werden könnten. Er berichtete deshalb an die Geschäftsführung, dass das Projekt im Termin sei.

Unglücklicherweise gab es aber mehr Schwierigkeiten als er dachte. Bei Versuchen, die Programmteile, die Frau Grau geschrieben hatte, etwas zu verändern, zeigten sich immer wieder mysteriöse Fehler.

12Ein weiteres Problem ergab sich aus Kontakten, die Herr Silber, der Datenbankspezialist, mit einem Vertreter der Marketingabteilung der Cloudwired AG geknüpft hatte. Der Marketingmann vertrat die Ansicht, dass seine Firma für Proma-net unbedingt die Anbindung an Cloud-Dienste anderer Anbieter brauche, um die Arbeit mit extern gespeicherten Dokumenten zu verbessern. Silber kam diesem Wunsch begeistert nach, ohne seinen Projektleiter über diese erhebliche Erweiterung der Spezifikation zu informieren.

Braun erfuhr von dem Alleingang erst Mitte Juni. Er war der Meinung, dass diese zusätzlich übernommene Aufgabe so erheblich sei, dass sie in der noch zur Verfügung stehenden Zeit nicht bewältigt werden könne. Silber versicherte ihm, dass er es schaffen werde. Braun wollte keinen Ärger mit Silber und entschloss sich, aus der Angelegenheit kein Drama zu machen und auch mit dem Kunden nicht darüber zu reden, genauso wie er auch über andere Schwierigkeiten im Projekt mit dem Auftraggeber bisher nicht gesprochen hatte.

Seine Hauptprobleme lagen bei der Integration der verschiedenen Komponenten von Proma-net. Diese Aufgabe nahm seine ganze Zeit und Aufmerksamkeit in Anspruch. Manche Komponenten der Anwendung existierten zu dieser Zeit in verschiedenen Versionen und man war sich nicht ganz einig, welche davon man nun eigentlich für die weiteren Arbeiten an Proma-net verwenden sollte. Aus Zeitgründen hatte man die Entwicklungsdokumentation zunächst vernachlässigt.

Versuche des Projektleiters, die Linienvorgesetzten der Teammitglieder dazu zu bewegen, sich mit ihm zusammenzusetzen und über die Lösung einiger aufgetretener Probleme zu reden, wurden mit dem Hinweis abgeblockt, in einer Matrixorganisation seien die Fachvorgesetzten für das „Wie“ der Aufgabenerfüllung verantwortlich. Der Projektleiter möge sich gefälligst um seine Managementaufgaben kümmern.

Das alles führte zu weiteren Diskussionen, zu Verzögerungen und ließ die Motivation des Projektteams sinken.

13Eine Rettungsaktion wird gestartet

Ende Juli 2017 war auch dem Projektleiter klar, dass die aufgetretenen Probleme mit dem derzeitigen Projektteam nicht so schnell gelöst werden könnten und dass der zugesagte Liefertermin (1. März 2018) nicht zu halten sein würde. Er wandte sich deshalb an den Geschäftsführer und wies darauf hin, dass zusätzliche Wünsche des Kunden, wie etwa die Anbindung externer Cloud-Dienste, zu Verzögerungen geführt hätten.

Er bat Westerhage, ihm für sechs Wochen vier weitere erfahrene Programmierer zu geben, die bei der Integration der Komponenten helfen sollten. Wenn er die neuen Leute bekomme, meinte der Projektleiter, könne der Termin gehalten werden.

Westerhage zog zunächst in Erwägung, zum Auftraggeber zu gehen und nicht nur um Terminaufschub, sondern auch um eine Aufstockung des Budgets zu bitten. Braun riet davon ab. Der Geschäftsführer entschloss sich daraufhin, vier Leute aus anderen Projekten der Firma abzuziehen und dem Projektleiter Braun zu unterstellen.

Die vier zusätzlichen Programmierer waren fähige Leute, sie hatten aber vom Aufbau von Proma-net (der sog. Softwarearchitektur) keine Ahnung. Da es zu diesem Zeitpunkt, wie schon erwähnt, nur eine rudimentäre Entwicklungsdokumentation gab, die außerdem nicht auf dem neuesten Stand war, mussten die neuen Teammitglieder sehr viel fragen und hielten damit die anderen Projektmitarbeiter von der Arbeit ab.

Der Auftraggeber greift ein

Ende August 2017 war klar, dass der Projektfortschritt gering war, und dass die Groupware- und Projektmanagement-Lösung am 1. März 2018 vermutlich nicht dem Kunden übergeben werden konnte. Der Geschäftsführer der Pro-telligenz GmbH entschloss sich zu einer Präsentation bei der Cloudwired AG. Man führte dem Auftraggeber vor allem die verschiedenen Funktionen der von Frau 14Grau geschriebenen Programmteile vor und gab einen kurzen Überblick über die zusätzlichen Wünsche, die von Mitarbeitern der Cloudwired AG geäußert worden waren und die man aus Gefälligkeit akzeptiert hatte. Man gab zu verstehen, dass die Pro-telligenz GmbH zwar zum vereinbarten Termin das Programmpaket liefern könne und dass es im Großen und Ganzen auch die im Vertrag z. T. nicht immer ganz eindeutig formulierten Eigenschaften haben werde, ließ aber auch keinen Zweifel daran, dass mit dem Ergebnis niemand zufrieden sein könne. Es wurde darauf hingewiesen, dass die Pro-telligenz GmbH bereits erhebliche zusätzliche eigene Mittel aufgewendet hatte, um Proma-net zum Laufen zu bringen Schließlich wurden ein Terminaufschub von drei Kalendermonaten und zusätzliche Mittel gefordert.

Die Produktmanagerin, Frau Schwarz, und ihre Mitarbeiter waren von diesem Vorschlag alles andere als begeistert. Sie waren auch von der Vorführung nicht sehr angetan und der Meinung, dass die Benutzeroberfläche nur sehr beschränkt den aktuellen Ansprüchen an Usability (Gebrauchstauglichkeit oder Benutzerfreundlichkeit) genügen würde. Die Firma hatte im Hinblick auf eine bevorstehende Messe schon erheblich die Werbetrommel gerührt und nun zeigte sich, dass die bisher erstellte Lösung in keiner Weise den Ansprüchen genügte, die die Cloudwired AG an Proma-net stellte.

Einige Leute in der Firma meinten, dass man die Pro-telligenz GmbH verklagen sollte. Die Mehrheit war allerdings der Ansicht, dass die Aussichten, den Prozess zu gewinnen, nicht allzu hoch seien. Was man brauche, sei eine Groupware- und Projektmanagement-Lösung und keinen Rechtsstreit.

In einer Besprechung beschloss die Geschäftsführung, Proma-net nicht auf der Messe zu präsentieren und einen externen Berater zu engagieren, der die Lage analysieren und Vorschläge machen sollte, wie das Projekt noch zu retten sei. Der Geschäftsführer der Pro-telligenz GmbH sagte die volle Unterstützung der Firma bei dieser Projektanalyse zu.

In der Zeit vom 15. August bis 15. September 2017 wurde das Vorhaben dann überprüft. Der Berater führte auch eine Reihe von Interviews.

15Über den Stand des Projekts wurde zu folgenden Punkten berichtet:

  1. Eigenschaften der Groupware- und Projektmanagement-Lösung, insbesondere der Benutzeroberfläche
  2. Management des Projekts Proma-net
  3. Personal
  4. Kosten

Zu (a) Eigenschaften der Groupware- und Projektmanagement-Lösung

Das größte Problem bei Proma-net war, dass sich die einzelnen Funktionen der Lösung in der Benutzerführung erheblich unterschieden und teilweise wenig intuitiv waren.

Der Berater stellte außerdem eine Reihe anderer Mängel fest. Zum Teil waren sie darauf zurückzuführen, dass die Entwickler der Cloudwired AG während der Arbeit an Proma-net einige Änderungen an Basiskomponenten der Anwendung vorgenommen hatten, die man der Pro-telligenz GmbH nicht mitgeteilt hatte. Die Drag-and-Drop-Funktionalität war nicht überall vorhanden. Das bedeutete, dass man z. B. am PC die Arbeitspakete im Projektstrukturplan nicht einfach mit der Maus verschieben konnte.

Eine Reihe von Funktionen, die Protext laut Angebot haben sollte, gab es nicht. Ein Beispiel dafür war das automatische Erzeugen von Controlling-Berichten. Auch die Erstellung, Bearbeitung und Berechnung von Netzplänen, eine der wichtigsten geforderten Eigenschaften, war viel zu schwerfällig.

Auch der Berater fand heraus, dass einige Funktionen, die entwickelt worden waren, vom Auftraggeber nicht gefordert worden waren.

16Zu (b) Management des Projekts Proma-net

Keine detaillierte Ablauf- und Terminplanung, kein Projektstrukturplan: Eine detaillierte Ablauf- und Terminplanung, die regelmäßig auf den neuesten Stand gebracht worden wäre, gab es, wie schon erwähnt, nicht. Ein Projektstrukturplan war überhaupt nicht erstellt worden. Das war wohl auch der Grund, warum eine Reihe von notwendigen Maßnahmen, z. B. die Bereitstellung von Testdaten, im Trubel „vergessen“ worden waren.

Keine regelmäßigen Projektüberprüfungen: Regelmäßige Überprüfungen der erzielten Ergebnisse zu bestimmten Meilensteinen durch Mitarbeiter der Pro-telligenz GmbH, die nicht am Projekt beteiligt waren und durch den Kunden, gab es nicht.

Von den wenig aussagefähigen Meilensteinen (siehe 17. Kapitel) im ursprünglichen Balkendiagramm, die zeitlich viel zu weit auseinander lagen und die eher Alibifunktion hatten, einmal abgesehen, gab es keine systematische Meilensteinplanung zur Verfolgung des Projektfortschritts. Die Mitglieder des Projektteams berichteten zwar wöchentlich in schriftlicher Form an den Projektleiter und gaben dabei Schätzungen ab, zu wie viel Prozent sie ihre Aufgabe erledigt hatten, sie verhielten sich dabei aber häufig entsprechend dem 90 %-Syndrom, d. h. sie meldeten oft bereits nach der Hälfte der Zeit, die sie tatsächlich für ihre Aufgabe brauchten, dass sie fast fertig seien. In den frei formulierten Fortschrittsmeldungen fanden sich Formulierungen wie

Der Vorschlag, den vor einem Jahr ein junger, gerade frisch diplomierter Informatiker gemacht hatte, dass man nämlich, wie andere Softwarehäuser auch, ein Vorgehensmodell (manchmal auch einfach „Phasenmodell“ genannt) wie z. B. das V-Modell XT des Bundes einführen sollte, wurde von den Abteilungsleitern mit dem 17Argument abgelehnt, man wisse nach z. T. 15-jähriger Praxis im Softwaregeschäft schon selbst, wie man bei der Entwicklung von Programmsystemen zu verfahren habe. Das Vorgehensmodell, das im Projektleitfaden der Firma enthalten sei, habe sich nicht bewährt. Vorgehensmodelle seien längst außer Mode und würden nur in die Projektbürokratie führen und die Entwicklungszeit verlängern.

Kein systematisches Konfigurations- und Änderungsmanagement: Im Projekt Proma-net gab es kein systematisches Konfigurationsmanagement und kein nachvollziehbares Änderungsmanagement. Zwar hatte die Firma vor einiger Zeit ein Tool für diese Aufgabe gekauft, die Entwickler fühlten sich aber durch die Forderung der Geschäftsleitung, es auch anzuwenden, gegängelt und benutzten es nicht konsequent. Änderungen bei den Spezifikationen waren oft ohne Absprache mit dem Auftraggeber durchgeführt worden. Der jeweils erreichte Entwicklungsstand wurde nicht „eingefroren“, um Änderungen „unter der Hand“ zu verhindern oder zumindest zu erschweren. Die Auswirkungen der Änderungen auf andere Programmteile und vor allem auf Termine und Kosten waren nicht überprüft worden.

Zu (c) Personal

Geringe Motivation der Teammitglieder: Die Motivation des Projektteams war gering. Das war dem Projektleiter zwar bewusst, er stand dem Problem aber ziemlich hilflos gegenüber. Alle zweifelten mehr oder weniger daran, dass das Projekt erfolgreich abgeschlossen werden könnte. Es gab immer wieder größere Meinungsverschiedenheiten zwischen den Mitgliedern des Teams über technische Details. Die Linienvorgesetzten der Teammitglieder hatten in Gesprächen mit ihren Mitarbeitern, die dem Projekt Proma-net zugeordnet waren, wiederholt die Ansicht geäußert, dass es ein Fehler der Geschäftsführung war, dieses Projekt anzunehmen, da die Pro-telligenz GmbH auf dem Gebiet Groupware- und Projektmanagement-Lösungen nicht das nötige Know-how habe. Es wäre ihrer Meinung nach besser gewesen, die von der Firma an andere Kunden bereits 18gelieferten Produkte (u. a. Anwendungen für Logistik und Vertriebsdisposition) ordentlich zu pflegen und weiterzuentwickeln. Einige Teammitglieder waren für ihre Aufgabe – nach eigenen Angaben – nicht genügend qualifiziert.

Zu (d) Kosten

Kostenüberschreitungen: Von der Cloudwired AG waren Teilbeträge des vertraglich vereinbarten Preises an Pro-telligenz bezahlt worden. Bei Pro-telligenz gab es ein System zur projektbegleitenden Kostenkontrolle, für das Projekt Proma-net konnte aber keine Aufteilung in Arbeitspakete vorgenommen werden, für die Kosten gesondert geplant und Istkosten hätten erfasst werden können. Den monatlichen Projektberichten, die aus verschiedenen organisatorischen Gründen erst zwei Monate nach Abschluss des jeweiligen Berichtsmonats vorlagen, konnte deshalb nur entnommen werden, dass insgesamt für das Vorhaben bereits vor Abschluss Kosten angefallen waren, die rd. 250.000 € über dem Festpreis lagen. Außer den tatsächlich monatlich angefallenen Kosten und den ursprünglich geplanten Kosten waren keine anderen Kostenangaben in den Kostenberichten zu finden.

192. Kapitel

Was ist ein Projekt, was bedeutet Projektmanagement und welche Erfolge bringt es?

Beispiele für Projekte

Projekte verändern unsere Welt: Der Bau eines Flughafens oder eines Krankenhauses, die Umorganisation eines Betriebs oder einer Behörde, die Umsetzung einer Unternehmensstrategie, die Errichtung einer Meerwasserentsalzungsanlage, die Vorbereitung der Serienfertigung eines neuen Automodells, die Entwicklung von Produkten oder eines EDV-Programms, der Aufbau eines Datennetzes, eine Operninszenierung, der Umzug einer Betriebsstätte oder eine große Sportveranstaltung wie die Fußball-Weltmeisterschaft 2006, all das sind Beispiele für Leistungserstellung mit Projektcharakter.

Projekt und Projektmanagement: zwei Definitionen

Die DIN-Begriffsnorm 69901 definiert ein Projekt sehr allgemein als „ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.

20Diese Begriffsbestimmung hält im Gegensatz zu vielen anderen einer kritischen Betrachtung stand und hat sich bewährt. Sie hat allerdings einen kleinen Schönheitsfehler. Es fehlt ein Merkmal von Projekten: die Beteiligung von mehreren Menschen, Arbeitsgruppen und Institutionen. Projekte sind also arbeitsteilige Prozesse. Ein(e)-Mann/Frau-Projekte gibt es nicht.

Unter Projektmanagement versteht man nach DIN „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projekts“.

Begreift man Führung als die „Steuerung der verschiedenen Einzelaktivitäten in einem Projekt im Hinblick auf die Projektziele“, so wird der Begriff „Projektmanagement“ noch etwas klarer.2

Projektmanagement als Führungskonzept

Schon diese Definition macht deutlich, dass Projektmanagement ein umfassendes Führungskonzept ist und nicht mit einzelnen Techniken wie etwa der Netzplantechnik oder einer speziellen Form der Aufbauorganisation, wie z. B. der Matrixorganisation, gleichgesetzt werden kann. Aus dieser Betrachtung ergeben sich Konsequenzen: „Wird das Projektmanagement als Führungskonzeption verstanden, so bedeutet dies, dass die Ziele, die Aufgaben und Methoden des Projektmanagements mit der strategischen Entwicklung des Unternehmens verknüpft werden müssen.“3

Projekte gibt es in allen Wirtschaftszweigen, also beispielsweise auch im Versicherungs- und Bankwesen, im Handel und in der Verkehrswirtschaft. In bestimmten Wirtschaftszweigen, etwa in der Bauwirtschaft, im Anlagen- und Maschinenbau, in entwicklungsintensiven Industriezweigen, z. B. in der Elektroindustrie oder in der Software-Branche, sind aber Projekte dominierend und werden für einen speziellen Kunden bzw. den anonymen Markt durchgeführt. In anderen Branchen, wie z. B. im Handel, sind Projekte vor allem interne Vorhaben. Beispiele dafür werden weiter unten angeführt.

Projekte gibt es natürlich auch in großer Zahl in der Öffentlichen Verwaltung, die erst in den letzten Jahren dieses Managementkonzept 21für sich entdeckt hat und in Not-for-Profit-Organisationen. Ein Raumordnungs- oder Planfeststellungsverfahren ist beispielsweise ein Projekt, auch wenn der Handlungsspielraum der Beteiligten durch den Gesetzgeber stark eingeengt ist. Auch in Bereichen der Öffentlichen Hand, wie etwa bei der Polizei,4 gibt es umfangreiche Projekte.

„Management by Projects“: Das projektorientierte Unternehmen

In den letzten Jahrzehnten gewinnt die Vision des projektorientierten Unternehmens erheblich an Bedeutung. Sich rasch ändernde Bedürfnisse des Marktes, starker Konkurrenzdruck, immer kürzer werdende Produktlebenszyklen (z. B. auf dem Gebiet der Informationstechnik) und vielfältige Umwelteinflüsse im weitesten Sinne wie etwa die Umstellung auf den Euro, neue Bilanzrichtlinien, neue Gesetze etc. geben der Projektarbeit auch in Branchen, in denen die Leistungserstellung für den Markt keinen Projektcharakter hat, eine wachsende Bedeutung.

Mit den Worten von Patzak und Rattay: „Projektorientierte Unternehmen führen alle komplexen, neuartigen und teamorientierten Aufgabenstellungen in Form von Projekten durch.“5 Oder wie es in der IPMA Competence Baseline (ICB 2.0) formuliert wird:6 „Durch das Management by Projects werden die organisatorische Flexibilität und Dynamik gesteigert, die Managementverantwortung dezentralisiert, das Lernen im Unternehmen verbessert und die organisatorischen Veränderungen erleichtert.“

Ein BEISPIEL: In einer Einzelhandelskette mit dem Unternehmenszweck, den Konsumenten mit Gütern des täglichen Bedarfs zu versorgen, gibt es zu jedem Zeitpunkt eine ganze Reihe von Projekten (Projektportfolio), z. B.

Mit Projekten den langfristigen Unternehmenserfolg sichern

Projekte sind in diesem Fall das Mittel, um technischen und organisatorischen Wandel zu realisieren. Sie sichern, soweit sie erfolgreich sind, den langfristigen Bestand der Organisation, während das Routinegeschäft für den kurzfristigen Erfolg sorgt. Der systematischen Auswahl von Projekten (vgl. 5. Kapitel), eine Aufgabe des strategischen Projektmanagements, kommt damit im projektorientierten Unternehmen eine ganz besondere Bedeutung zu. Ein Lenkungskreis muss aus der Fülle von möglichen Projekten die „richtigen“ auswählen und klare Prioritäten setzen. Die Prioritäten müssen sich dabei immer in der Zuweisung von Ressourcen niederschlagen. Auf diese Thematik wird im 5. Kapitel näher eingegangen.

Die Chancen von Projektarbeit

Projektarbeit bietet die Möglichkeit,

Darüber hinaus kann sie auch zur Personalentwicklung und zur Motivation der Mitarbeiter („Unternehmer auf Zeit im Unternehmen“) beitragen.

23Projektorientierte Unternehmen: Vision und Realität

Viele Unternehmen und andere Organisationen der Bundesrepublik nutzen allerdings nach der langjährigen Beobachtung des Verfassers (H.S.) die Chancen der Projektorientierung nur unzureichend. Der Sündenkatalog, der vom Verfasser vor vielen Jahren erstellt wurde, ist leider immer noch aktuell.

Die Entwicklung der Disziplin „Projektmanagement“

Selbstverständlich wurden in der Geschichte der Menschheit schon einige Jahrtausende lang große Vorhaben durchgeführt, von einer Disziplin „Projektmanagement“, also einer systematischen Lehre von der Planung und Abwicklung von Erst-und-Einmal-Vorhaben, lässt sich aber erst seit der Mitte der 50er Jahre reden. Die Anfänge wurden sehr stark vom militärischen Auftraggeber und der Weltraumbehörde in den USA geprägt. Die Instrumente und Konzepte waren in der Hauptsache für die Luft- und Raumfahrtindustrie erarbeitet worden. Die Gründe für ihre Entwicklung waren erhebliche Kosten- und Terminüberschreitungen bei militärischen Entwicklungsprojekten 25und die Erkenntnis, dass die überkommene Linienorganisation mit komplexen Vorhaben überfordert ist.

„Projektmanagement“ by „über die Mauer werfen“

Fachabteilungen neigen dazu, ein Vorhaben vor allem aus dem eigenen Blickwinkel zu betrachten. So werden notwendige Arbeiten z. B. nicht in der Reihenfolge erledigt, die für die Weiterbearbeitung in nachfolgenden Abteilungen und den Fortschritt des gesamten Projekts am günstigsten ist, sondern in einer Abfolge, die den abteilungsinternen Termindruck möglichst gering hält.

Die Praxis hat auch gezeigt, dass Linienabteilungen sich in Projekten gerne nach dem „Postkastenprinzip“ verhalten und ihre Ergebnisse vor der „Haustür“ der in der Bearbeitung nachfolgenden Abteilung abliefern, ohne besondere Rücksichten auf das Projekt als Ganzes zu nehmen. In den USA wird dafür der Ausdruck „über die Mauer werfen“ gebraucht. Dem steht das gesamthafte Denken des Projektmanagements gegenüber, das immer das Projekt als Ganzes und die Projektziele (im Gegensatz zu den Zielen der einzelnen Abteilungen) im Auge hat.

Ein BEISPIEL aus der Praxis: bzw.26