Lean Project Management E-Book

Claus Hüsselmann

• Herausgeber: Schäffer Poeschel
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 396

Beschreibung

Viele Organisationen stehen vor der Herausforderung, ihre Projekte zu agilisieren. Allerdings sind die Gegebenheiten oftmals nicht dazu geeignet, das Werkzeug Agilität passt entweder nicht auf die vorliegenden Projekte oder es fehlt an ausreichender Systematik. Lean Project Management vereint die Vorteile verschiedener Methoden im Sinne eines adaptiven, zielgerichteten und flexiblen Projektmanagements. Dabei kommen − neben den etablierten Methoden des klassischen und agilen Projektmanagements − bewährte Methoden und Tools aus dem Lean Management zum Einsatz und werden mit Blick auf die Erfordernisse des Projektwesens weiterentwickelt (z.B. Gemba, 5S u.a.). Das Buch zeigt, wie eine Organisation ihr Projektmanagement systematisch professionalisieren und zielgerichtet flexibilisieren kann, um mit weniger Aufwand mehr Wert im Sinne des Projektnutzens zu erzielen. Mit Downloadmaterial auf myBook+. Die digitale und kostenfreie Ergänzung zu Ihrem Buch auf myBook+: - Zugriff auf ergänzende Materialien und Inhalte - E-Book direkt online lesen im Browser - Persönliche Fachbibliothek mit Ihren BüchernJetzt nutzen auf mybookplus.de.

Leseprobe

[11]Inhaltsverzeichnis

Hinweis zum UrheberrechtImpressumGeleitwortVorwortAbkürzungsverzeichnis1 Hintergrund und Motivation1.1 Herausforderungen im modernen Projektmanagement1.2 Motivation des Lean Project Managements2 Grundlagen2.1 Management von Projekten2.1.1 Wertschöpfung durch Projekte2.1.2 Unified Project Management Framework – der Ordnungsrahmen für PM 2.2 Grundlagen des Lean Managements2.2.1 Herkunft aus der Produktion2.2.2 Identifikation von Verschwendung2.2.3 Kernprinzipien des Lean Managements2.3 Das Wesen der Agilität2.3.1 Motivation2.3.2 Herkunft des Begriffs2.3.3 Agilität – eine Begriffsbestimmung2.3.4 Kernprinzipien und Praktiken von Agilität2.3.5 Hybride Vorgehensweisen2.3.6 Beispiele hybrider Projektvorgehensweisen2.4 Wie viel Projektmanagement steckt in Scrum? 2.4.1 Das Scrum-Rahmenwerk2.4.2 Die Delta-Analyse2.4.3 Ergebnisse der Praktiken und Methoden2.4.4 Die Prozessanalyse im Detail2.5 Der Umgang mit Komplexität2.5.1 Was bedeutet Komplexität?2.5.2 Begriffsfestlegung2.5.3 Vorgehen2.5.4 Handhabung2.5.5 Das Dilemma der Komplexität2.5.6 Die Quintessenz der Handhabung von Komplexität3 Kernprinzipien des Lean Project Management3.1 Definition von Lean Project Management3.2 Verschwendung in Projekten3.3 Interpretation der Lean-Management-Gestaltungsprinzipien3.3.1 Kunden- und Wertbegriff3.3.2 Fluss- und Pull-Prinzip3.3.3 Perfektion3.3.4 Projektprodukte3.3.5 Anwendung der Lean-Prinzipien3.4 Handlungsmaximen für das Lean Project Management3.4.1 Ausgewählte bekannte Handlungsleitsätze3.4.2 Die 3P für Lean Project Management4 Praktiken des Lean Project Managements4.1 Was sind Praktiken?4.2 Integrative Vertragsgestaltung4.2.1 Charakteristik4.2.2 Der relationale Vertrag4.2.3 Der agile Festpreisvertrag4.3 Atmender Scope 4.3.1 Begriffsbestimmung des atmenden Scope 4.3.2 Die MuSCoW-Systematik4.3.3 Target Value Design4.3.4 Weighted Shortest Job First4.4 Zielorientierte, flexible Projektplanung4.4.1 Last Responsible Moment4.4.2 Set-based Design4.4.3 Rollierende Planung4.4.4 Last Planner 4.5 Prozessorientierte Steuerung4.5.1 Wertstrommethode4.5.2 Projekt-Kanban4.6 Kontinuierliche Verbesserung4.6.1 Kaizen/Kontinuierlicher Verbesserungsprozess4.6.2 Retrospektiven/Lessons Learned 4.7 Weitere Praktiken4.7.1 Voice of the Customer und User Story4.7.2 Aufwandskalkulation4.7.3 Fehlervermeidung4.7.4 Ursachenermittlung 4.7.5 Arbeitserleichterung4.8 Agil oder Klassisch? – das Agilometer4.9 Die Projektmanagement-Wertstromanalyse4.9.1 Die Identifikation der Wertströme4.9.2 Prozessmuster: Lean Project Risk Management4.9.3 Prozessmuster: Lean Project Knowledge Management5 Anwendung des Lean Project Managements5.1 Praxisfall 1 – Das Projekt PVS (Personalverwaltungssystem)5.1.1 Das Projekt in der Übersicht5.1.2 Personal und Organisation5.1.3 Prozeduren und Projektablauf5.1.4 Umfangs- und Aufgabenmanagement5.1.5 Weitere Elemente5.2 Praxisfall 2 – Das Projekt ZLP (Zentrale Leitstelle der Polizei)5.2.1 Das Projekt in der Übersicht5.2.2 Scope Management5.2.3 Projektorganisation5.2.4 Projektplanung und -steuerung5.2.5 Auftragsorientierung5.2.6 Weitere ausgewählte PM-Disziplinen5.3 Systematische Anpassung des Projektmanagement-Systems5.3.1 Die Einordnung von Projekten5.3.2 Kriterien zur Projektcharakterisierung5.3.3 Gesamtsicht der PM-System-Adaption6 Implementierung des Lean Project Managements6.1 Organisationelle Einordnung6.1.1 Kultureller Rahmen6.1.2 Systemische Betrachtung6.1.3 Mitarbeiterbezogene Führung6.1.4 Projektbezogene Anwendung des Lean PM6.2 Vorgehensweise zur Einführung6.2.1 Einführung Lean PM als Change-Projekt6.2.2 Fachliches Vorgehen6.2.3 Praktiken bei der Projektdurchführung6.2.4 Erfolgsfaktoren bei der Einführung von Lean PM7 Perspektive Lean Project Portfolio Management7.1 Hintergrund des Projektportfoliomanagements 7.2 Kritik am klassischen Projektportfoliomanagement 7.3 Erfolgsfaktoren im Projektportfoliomanagement 7.4 Ansätze zur Erhöhung der Agilität des Projektportfoliomanagements7.5 Anwendung der Lean-Kernprinzipien7.5.1 Grundlagen7.5.2 Kunde und Wert im PPM7.5.3 Wertströme im PPM7.5.4 Verschwendung im PPM7.5.5 Flussprinzip im PPM7.5.6 Pull-Prinzip im PPM7.5.7 Perfektion im PPM7.6 Schlussbemerkung zum Lean Project Portfolio ManagementDanksagung QuellenverzeichnisStichwortverzeichnisÜber den AutorArbeitshilfen Online

[1]

Hinweis zum Urheberrecht:

Alle Inhalte dieses eBooks sind urheberrechtlich geschützt.

Bitte respektieren Sie die Rechte der Autorinnen und Autoren, indem sie keine ungenehmigten Kopien in Umlauf bringen.

Dafür vielen Dank!

Schäffer-Poeschel Verlag für Wirtschaft - Steuern - Recht GmbH

[4]Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de/ abrufbar.

Print:

ISBN 978-3-7910-5234-2

Bestell-Nr. 10656-0001

ePub:

ISBN 978-3-7910-5236-6

Bestell-Nr. 10656-0100

ePDF:

ISBN 978-3-7910-5237-3

Bestell-Nr. 10656-0150

Claus Hüsselmann

Lean Project Management

1. Auflage, Juli 2021

© 2021 Schäffer-Poeschel Verlag für Wirtschaft · Steuern · Recht GmbH

www.schaeffer-poeschel.de

[email protected]

Bildnachweis (Cover): © Hinterhaus Productions, gettyimages

Produktmanagement: Dr. Frank Baumgärtner

Lektorat: Traudl Kupfer, Berlin

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte, insbesondere die der Vervielfältigung, des auszugsweisen Nachdrucks, der Übersetzung und der Einspeicherung und Verarbeitung in elektronischen Systemen, vorbehalten. Alle Angaben/Daten nach bestem Wissen, jedoch ohne Gewähr für Vollständigkeit und Richtigkeit.

Schäffer-Poeschel Verlag Stuttgart

Ein Unternehmen der Haufe Group

[7]Geleitwort

Mitte des letzten Jahrhunderts entwickelte Toyota Managementprinzipien, die wesentlich dazu beitrugen, dass die japanische Automobilindustrie trotz schlechter Ausgangssituation zunehmend zu den westlichen Automobilproduzenten aufschloss und diese an vielen Stellen sogar überflügelte.

Die westlichen Automobilhersteller hatten sich zu lange auf ihren vermeintlichen Skalenvorteilen und einer vermeintlich sicheren Marktsituation mit einer stabilen Nachfrage ausgeruht. Prozesse und Planung waren nicht in der Lage, auf kurzfristige Schwankungen zu reagieren. Langfristige detaillierte Pläne, die wenig Raum für Veränderung ließen und oftmals nicht realitätsgerecht waren, führten zu Managementmethoden und Produkten, die den Kundenwünschen hinterherhinkten, hohe Kosten, Fehler und Ausschuss zur Folge hatten.

Ende der 1980er-Jahre wurden die Chancen des sogenannten »Toyota Production System« oder auch Lean Production erkannt, fanden seither weltweit Eingang in Managementsysteme und -literatur und sind heute vor allem aus der Produktionsplanung und -steuerung nicht mehr wegzudenken.

Betrachtet man die Entwicklung des Projektmanagements, so drängen sich Parallelen auf. Auch das Projektmanagement musste seinen Weg zu einem systematischen und methodischen Management erst finden. Vergleichbar mit dem Übergang der wenig strukturierten und nicht auf Skalenvorteile ausgerichteten Produktion in den Anfängen des Automobils. Mit zunehmender Akzeptanz und Professionalisierung des Projektmanagements wurden die Planungs-, Management- und Controlling-Instrumente immer professioneller, aber teilweise auch aufwendiger und weniger flexibel. Im Ergebnis verloren viele Projektmanagementsysteme den notwendigen Pragmatismus, vor allem aber die Flexibilität, Kundenorientierung und Wirtschaftlichkeit. Es sind auch diese Defizite der »klassischen« plangetriebenen Projektmanagementansätze, die den Raum frei machten für den großen Erfolg der »agilen Methoden«, die sich im Kern von vielen der Prinzipien des plangetriebenen Projektmanagements abgrenzten.

Gleichzeitig zeigt sich in unseren Studien zum Status quo agilen Managements in Projekten seit 2012 immer wieder, dass die Praxis nur selten rein agil agiert, sondern in der deutlichen Mehrzahl der Fälle hybrides oder selektives Projektmanagement anwendet. Dabei werden die Ansätze des klassischen Projektmanagements mit den Ansätzen des agilen Managements verbunden. Analysiert man, welche Vorteile die agilen Impulse für das Projektmanagement bringen sollen, so zeigt sich eine signifikante Deckung mit den Zielen des Lean Managements, z. B. bei der Betonung der Kundenorientierung. Es ist mehr als ein Zufall, dass sich fast alle Konzepte und auch die Vordenker agiler Methoden sehr stark auf die Lean-Prinzipien beziehen – unabhängig davon, ob dies auf Teamebene oder auf übergeordneter Ebene ist.

[8]Das vorliegende Buch von Claus Hüsselmann trägt diesem Umstand Rechnung und vollzieht den notwendigen nächsten Schritt für das Projektmanagement. Mit dem Lean PM wird ein Ordnungsrahmen geschaffen, der auf eine wertschöpfende Anwendung und Kombination der Methoden abzielt – unabhängig davon, ob diese nun »klassisch« oder »agil« sind. Dabei werden die grundlegenden Prinzipien des Lean Thinking auf Projekte übertragen, aber auch konkrete Praktiken zu deren Umsetzung vorgestellt. Wertvolle Anleitungen zur Wahl der passenden Projektvorgehensweise liefern insbesondere die systematischen Kriterienkataloge zur Charakterisierung des vorliegenden Projekts und seiner Umfeldbedingungen. Damit werden den Anwendern eine Vielzahl fundierter Hilfestellungen zur zielgerichteten Ausgestaltung hybrider Methoden an die Hand gegeben – und so die Leserinnen und Leser unterstützt, den nächsten Schritt in der Weiterentwicklung des Projektmanagements zu vollziehen.

Prof. Dr. Ayelt Komus, Hochschule Koblenz

[9]Vorwort

Mein erstes Projekt in einem professionellen Umfeld war Mitte der 1990er-Jahre die Entwicklung eines Umweltinformationssystems in einer integrierten SAP-Umgebung. Kurz nach meinem Studium durfte ich dieses Projekt als Primus inter pares eines vierköpfigen Teams auch gleich leiten. Im Ergebnis entstand die erste SAP-basierte Fachanwendung einer Reihe, die in der auftraggebenden Umweltbehörde dann auch produktivgesetzt wurde. In dieser Zeit nahm die Idee der prozessorientierten Konzeption sowie auch der Standardisierung des Projektmanagements einen signifikanten Aufschwung. Meine Leidenschaft für diese Domänen war mit dem erfolgreichen Projekt entfacht.

Es folgte eine Vielzahl weiterer kleiner und großer Organisations- und IT-Projekte, die ich durchführen und auch leiten durfte. Von den beiden größten berichte ich in dem vorliegenden Buch. Sie stellen einen wesentlichen praxisbezogenen Hintergrund für die Ideen des Lean Project Managements dar. Bereits Ende der 2000er-Jahre entwickelten wir zudem in meinem Team erfahrener Projektmanager das Konzept eines hybriden Ansatzes für SAP-Einführungsprojekte zur Nutzbarmachung der jeweiligen Vorteile der sogenannten Wasserfall- bzw. agilen Vorgehensweise. In dieser Zeit verantwortete ich die Unit Project Operations & Risk Control eines weltweit agierenden TecDAX-Unternehmens. Hier bekam ich als Standardisierer, Coach, Trainer und Supervisor der A- und B-Projekte des Unternehmens weitere wertvolle Einblicke und Anregungen. Die Idee des Lean Project Managements als Rahmen für die erfolgversprechende kontextbezogene Ausgestaltung von Projektvorgehensweisen nahm erste Züge an.

Mit meinem Wechsel in die Welt der Forschung & Lehre im Jahr 2015 konnte ich nun beginnen, die Ideen zu systematisieren. Das vorliegende Buch ist das vorläufige Ergebnis dieser Arbeit. Es soll den Lesern und ihren Organisationen helfen, Denkweisen und Praktiken, die man durchaus auch mit dem vielbeschworenen gesunden Menschenverstand intuitiv umsetzen kann, einen methodischen Rahmen zu geben und sie damit in den Anwenderorganisationen und ihren Projekten zu etablieren.

Ich wünsche viel Spaß und hoffentlich einige Aha-Momente beim Lesen.

Claus Hüsselmann

Gender-Hinweis: Aufgrund der besseren Lesbarkeit wird in diesem Buch das generische Maskulinum verwendet. Wir verstehen dieses als neutrale grammatikalische Ausdrucksweise, die ausdrücklich alle Geschlechter umfasst.

[15]Abkürzungsverzeichnis

3PPartizipation, Paretoprinzip, Passung5S bzw. 5ALean-Methode zur Verbesserung der ArbeitsumgebungA/B/VAufgaben/Befugnisse/VerantwortlichkeitenALG 2Arbeitslosengeld 2ANSIAmerican National Standards InstituteAPArbeitspaketBDUFBig Design Up FrontBMBundesministeriumBPMLBusiness Process Master ListBPMNBusiness Process Model and NotationCCPMCritical Chain Project ManagementCMMICapability Maturity Model IntegrationCPM-SystemCorporate PM-SystemCRChange RequestCTQCritical-to-QualityDAXDeutscher AktienindexDBDatenbankDevOpsDevelopment and OperationsDINDeutsches Institut für NormungDMSDokumentenmanagementsystemELSEinsatzleitsystemERPEnterprise Resource PlanningEVAEarned Value AnalysisF&EForschung und EntwicklungFMEAFailure Mode and Effects AnalysisGPMDeutsche Gesellschaft für ProjektmanagementHCMHuman Capital ManagementHSHochschuleICBIPMA Competence BaselineIDIshikawa-DiagrammIFOAIntegrated Form of AgreementIPMAInternational Project Management AssociationISOInternationale Organisation für NormungITInformationstechnikJEDUFJust Enough Design Up FrontKLKKleiner LenkungskreisKMKnowledge ManagementKMUkleine und mittlere UnternehmenKPIKey Performance IndicatorKVPKontinuierlicher Verbesserungsprozess[16]LCILean Construction InstituteLeSSLarge-Scale ScrumLLLessons LearnedLRMLast Responsible MomentMaAGIEModernisierung administrativer Aufgaben durch Geschäftsprozessorientierung und IT-EinsatzMoPManagement of PortfoliosMPMMultiprojektmanagementMSMeilensteinMuSCoWMust-have, Should-have, Could-have, Won’t-haveMVPMinimal Viable ProductNECNew Engineering ContractsOEMOriginal Equipment ManufacturerOPLOffene-Punkte-ListeOPM3Organizational Project Management Maturity ModelPDCAPlan – Do – Check – ActPERTProgram Evaluation and Review TechniquePIIPrioritätsindex der InterventionPMProjektmanagementPMIProject Management InstitutePMMMProject Management Maturity ModelPMOProject Management OfficesPMSysProjektmanagementsystemPPCProject Partnering ContractPPMPPM-Labor: Prozess- und ProjektmanagementPPMProjektportfoliomanagementPVProjektvorgehenPVSPersonalverwaltungssystemRACIResponsible – Accountable – Consulted – InformedRMRisk ManagementRPZRisikoprioritätszahlRVRisikoverantwortlicheSAFeScaled Agile FrameworkSAMSolution Architecture ManagementSBDSet-based DesignSGMMSt. Galler Management-ModellSWOTStrengths, Weaknesses, Opportunities, ThreatsTH/THMTechnische Hochschule MittelhessenTPSToyota Production SystemTVDTarget Value DesignUPMFUnified Project Management FrameworkUSUser Story[17]USPUnique Selling Point/Proposition (Alleinstellungsmerkmal)VCJFValued Cheapest Job FirstVoCVoice of the CustomerVUKAVolatilität, Unsicherheit, Komplexität und AmbiguitätWBSWork Breakdown StructureWiPWork in ProgressWSJFWeighed Shortest Job FirstXBSX-Breakdown StructureZLPZentrale Leitstelle der Polizei

[19]1Hintergrund und Motivation

1.1Herausforderungen im modernen Projektmanagement

Die führende Studie der Deutschen Gesellschaft für Projektmanagement (GPM) zur makroökonomischen Vermessung der Projekttätigkeit zeigt auf, dass der Anteil der Projekttätigkeit an der Gesamtarbeitszeit 2013/2014 deutschlandweit bei knapp 35 % lag. Und die Projektifizierung der Wirtschaft, d. h. die Zunahme von Projektarbeit in Unternehmen, wird anhalten.1 Zunehmend mehr Wertschöpfung findet also in Form von Projekten statt. Betrachten wir hierbei zwei generelle Trends des Wirtschaftslebens, die einen unmittelbaren Einfluss auf den Betrachtungsgegenstand – die Projektwirtschaft – haben, einmal etwas näher: Globalisierung und Digitalisierung.

Globalisierung in der Projektwirtschaft bedeutet verstärkte internationale Kooperation und damit Zusammenarbeit unter den Rahmenbedingungen verteilter Standorte und verschiedener (Arbeits-)Kulturen. Nicht zuletzt werden Projektteams instabiler, oder anders ausgedrückt: Mehr Mitarbeiter sind involviert, werden gegebenenfalls im Laufe eines Projekts ausgetauscht, kommen später zu einem (Groß-)Projekt hinzu etc. So wurden beispielsweise in einem mehrjährigen globalen SAP-Konsolidierungs- und Roll-out-Projekt eines Pharmakonzerns mehrfach die Projektauftragnehmer aufgrund von Vergabebestimmungen ausgetauscht und ebenso nahmen eigene Mitarbeiter im Laufe der Zeit verschiedene Funktionen im Projekt und im Unternehmen wahr. Das alles liegt in der Natur der Sache von Großprojekten. Es liegt aber auf der Hand, dass dabei durch Einarbeitungszeiten und Know-how-Transferverluste Verschwendung entsteht.

Der zweite Megatrend, die Digitalisierung, scheint derzeit die Aufmerksamkeit in der Wirtschaft zu dominieren. So stellte Gartner 2018 fest, dass künstliche Intelligenz, die Digitalisierung der Geschäftsprozesse und -modelle und die Vernetzung (und die darunter zu subsumierenden Einzelentwicklungen) aktuell die technologischen Trends bestimmen.2 Digitalisierung bedeutet IT-getriebene Innovation! Und die Entwicklung der IT verläuft nicht linear und in nie dagewesener Geschwindigkeit. Nach dem Moorschen Gesetz verdoppelt sich die Kapazität digitaler integrierter Schaltkreise in einem Zeitraum von circa 18 Monaten. Gleich welche Auslegung dieses Gesetzes man wählt, bleibt doch die Erkenntnis einer nichtlinearen Steigerung der Leistungsfähigkeit von IT, die sich in den vergangenen Jahrzehnten bestätigt hat und die jedermann im täglichen Leben ja auch beobachten kann. Denke man nur einmal an die Leistungsfähigkeit (und Bedeutung) von Smartphones, die mit dem iPhone 1 ja erst im Jahr 2007 in Erscheinung traten. Zudem zeigt auch die Vernetzung von Menschen und Dingen durch die Internettechnologie eine rasante Entwicklung. 2015 waren beispielsweise ca. 25 Milliarden Dinge mit dem Internet verbunden – diese Zahl sollte sich bis 2020 auf über 50 Milliarden verdoppeln.3 Die [20]zunehmenden Möglichkeiten der IT treiben die technischen und betriebswirtschaftlichen Entwicklungen massiv an. Sie bieten vielfach relativ niederschwellige Markteintrittshürden (eine App ist schnell programmiert, siehe Uber und andere), ermöglichen eine fortwährende Weiterentwicklung der Produkte auch nach Markteinführung (siehe z. B. Updates bei Amazon im Sekundentakt)4 und legen so das Fundament für eine immer größere Geschwindigkeit, mit der Produkte und Leistungen entwickelt, bereitgestellt und weiterentwickelt werden.

Die digitale Transformation der Unternehmen bedeutet aber auch, dass Unternehmen, deren Kernkompetenz bis dato z. B. in der (konventionellen) Produktion von Maschinenbauteilen bestand, sich plötzlich mit einem weitgehenden und in der Folge geschäftskritischen Einsatz von IT konfrontiert sehen, deren Entwicklung zudem die zuvor aufgeführte Dynamik aufweist. Hat die Entwicklung der Mechatronik schon für eine signifikante Erhöhung der Produkt- und Entwicklungskomplexität gesorgt, setzt die Digitalisierung gleichsam noch eine Dimension oben drauf. Die Folge: Die Komplexität der Prozesse und Projekte im Unternehmen steigt signifikant an; der Umgang mit Unsicherheit wird zu einem zentralen Managementthema.

Ferner ist zu verzeichnen, dass die Projektlandschaft von Unternehmen durch eine außerordentliche Vielfalt von Projekten charakterisiert ist. In einer führenden Studie der TU Berlin wurden in den untersuchten Projektportfolios (n=200) beispielsweise durchschnittlich ca. 120 Projekte verwaltet.5 Eine weitere Studie der GPM belegt zudem, dass ca. zwei Drittel der Project Management Offices (PMO) Portfolios mit den unterschiedlichsten Projektarten (IT, F&E, Organisation, Investition) verwalten.6

Im Zuge dieser Entwicklungen und aus der bitteren Erkenntnis nach wie vor schlechter allgemeiner Erfolgsquoten der Projekte7 haben sich gewissermaßen Pole des Projektmanagements gebildet, gekennzeichnet durch agile versus klassische Vorgehensweisen. Klassisch meint dabei den etablierten internationalen Best Practices und Standards (von PMI, IPMA, PRINCE2, ISO/DIN etc.) folgend.8 Diese sind als plangetrieben zu charakterisieren, d. h., sie postulieren eine systematische Planung der Projekte und Projektphasen in vielerlei Hinsicht (Struktur, Ablauf, Qualitätssicherung, Risikomanagement etc.). Entgegen vielfach anzutreffender Aussagen ist damit nicht automatisch das sogenannte Wasserfall-Vorgehen impliziert. Agile Vorgehensweisen operationalisieren im Allgemeinen die Forderungen des Agilen Manifests aus dem Jahr 2001.9 Das Vorgehen ist stets iterativ und inkrementell und als fundamental und weitestgehend anpassungsfreudig gegenüber Veränderungen zur Projektlaufzeit zu charakterisieren. Vielfach wird eine vorgeschaltete Planung untergeordnet oder gar abgelehnt und die Selbstorganisation des Teams betont (vgl. Scrum). [21]Diese Polarisierung erzeugt Verwirrung und Irritation, gerade bei Organisationen, die Projektmanagement (PM) nicht im Kerngeschäft betreiben, beispielsweise kleine und mittelständische Industriebetriebe. Hier zeigt die Erfahrung vieler betreuter studentischer Arbeiten in den Unternehmen, dass die kleinen und mittleren Unternehmen (KMU) vielfach noch keinen adäquaten Reifegrad im PM erreicht haben, aber schon von der Welle der Agilität erfasst werden. Aber auch ganz allgemein ergibt sich die Schwierigkeit, die Pole des PM, die beide kontextuell ihre Berechtigung haben, in einem Managementsystem zu handhaben. Das Management multimodaler Projektlandschaften stellt auch etablierte Portfoliomanager (methodisch, organisatorisch und prozessual) vor Herausforderungen.

Wir leben also in einer VUKA-Welt: Volatilität, Unsicherheit, Komplexität und Ambiguität kennzeichnen nicht zuletzt die Anforderungen an das Management in und die Steuerung von Unternehmen. Eine Reihe nationaler und globaler Trends und Megatrends, die sich herausgebildet haben,10 charakterisiert und verursacht VUKA – siehe die Beispiele Digitalisierung und Globalisierung.

Folgende, dem Grunde nach nicht neue Anforderungen, lassen sich für ein modernes PM in der VUKA-Welt ableiten:

FlexibilitätEin modernes PM-System muss flexibel an die jeweiligen Erfordernisse der Projekte und der Organisation anpassbar sein. Je nach Projektkontext kann beispielsweise ein plangetriebener Ansatz (z. B. Erweiterung einer Produktionshalle) oder ein agiler Ansatz (z. B. Entwicklung eines neuen, internetbasierten Services) angemessen sein.LeichtgewichtigkeitKleine Projekte wollen nicht mit Kanonen auf Spatzen schießen und administrativen Overhead vermeiden. Mitarbeiter müssen sich schnell im PM-System zurechtfinden.Praktikabilität/PraxisorientierungGleichwohl ein umfassendes theoretisches Fundament für das Projektwesen einer Organisation insgesamt hilfreich ist, fordern die Praktiker, also die Projektmanager im Feld, einfache, klare und zielführende Rezepte zur Steuerung der Projekte.UniversalitätDas PM-System einer Organisation muss auf alle vorhandenen Projektarten anwendbar sein. Ein Portfoliomanagement, in dem Scrum-Projekte nach Methode X berichten und Infrastrukturprojekte nach Methode Y, ist nicht zielführend.

Die Anwendung von Lean Thinking unter Adaption der verschiedenen Ausprägungen des Lean Management für Produktion, Administration, Produkt- und nicht zuletzt IT-Entwicklung auf das Projektwesen verspricht, die Anforderungen an ein modernes PM zu erfüllen. Das Lean PM ist durch eine hohe Kunden- und Wertschöpfungsorientierung unter weitestmöglicher Vermei[22]dung von Verschwendung (insbesondere administrativer Overhead) gekennzeichnet. Dabei kommen aus dem Lean Management bekannte Methoden und Tools zum Einsatz und werden mit Blick auf die Erfordernisse des Projektwesens weiterentwickelt, beispielsweise Gemba, 5S/5A und andere (s. Kap. 4).

1.2Motivation des Lean Project Managements

Das PM unterliegt derzeit einem (vermeintlichen) Paradigmenwechsel: von einer linearen, sequenziellen Vorgehensweise (Wasserfall) hin zu einer zyklischen, inkrementellen (Agilität). Im Diskurs von Wissenschaft und vor allem Praxis bilden sich dabei zunehmend auch hybride Ansätze heraus, die das Beste aus beiden Welten vereinen sollen.11 Dabei lässt sich feststellen, dass die sich offenbar gegenüberstehenden Ansätze bei genauer Betrachtung viele Gemeinsamkeiten haben (können) – auch wenn sie ohne Zweifel unterschiedliche Planungs- und Steuerungsphilosophien betonen und hervorheben sowie entsprechende Methoden anbieten (z. B. Scrum).

War früher alles schlecht? Diese Frage muss man sich unweigerlich stellen, wenn man das aktuelle Interesse für das Thema agile Projekte verfolgt. Viele empirische Untersuchungen – allen voran der allseits zitierte CHAOS-Report der Standish Group – lassen diesen Schluss zu. Immerhin wurden dort nach eigenen Angaben seit 1994 40.000 bis 50.000 (IT-)Projekte untersucht.12 Im Report 2015 wird angegeben, dass nur 11 % der mehr als 10.000 untersuchten Projekte erfolgreich gewesen seien, der Rest läge in Sachen Termineinhaltung, Leistungserbringung und/oder Kosten nicht im Zielkorridor oder sei gar gänzlich gescheitert.13 Anders bei agilen Projekten: Dort beträgt die Erfolgsquote immerhin 39 %. Des Weiteren wird ein Zusammenhang mit der Größe der Projekte aufgezeigt: Unabhängig vom Vorgehensmodell scheitern größere Projekte öfter als kleine. Andere Leuchtturmprojekte wie der ebenfalls vielzitierte Flughafen Berlin Brandenburg zeugen auch nicht gerade von einem erfolgreichen Reifegrad der (Groß-)Projekte.

Der einfache Schluss aus dem oben Genannten wäre, dass Projekte, die nach den klassischen Modellen wie des PMI, der IPMA oder nach PRINCE2 durchgeführt werden, strukturell bedingt schlechtere Erfolgsaussichten hätten. Was aber, wenn schlichtweg die Anwendung der »alten« PM-Methoden in vielen Fällen nicht zielführend durchgeführt wurde? Immerhin zeugen ausgezeichnete Projekte in Deutschland (GPM) und weltweit (IPMA, PMI) davon, dass Projekte erfolgreich und »mit Plan« durchgeführt werden können.14

[23]Und lässt sich Agilität so einfach beispielsweise auf Bauprojekte übertragen?

Abb. 1-1: Agiler Hausbau?

Die am häufigsten im Agilen verwendete Methode ist Scrum.15 Scrum hat seine Wurzeln in IT-Entwicklungsprojekten und geht im Original von einer Teamgröße von ca. sieben Mitarbeitern aus. Ein solches Projekt gehört also generell zu den kleinen.16 Insofern haben sich in den vergangenen Jahren Versuche herausgebildet, den Scrum-Ansatz auf größere Projektkontexte, die in der Praxis großer Organisationen gang und gäbe sind, zu skalieren. Dazu gehören etwa das Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS) oder Nexus.17 Auch wird zunehmend die Übertragbarkeit auf andere Projektarten, wie etwa die Produktentwicklung untersucht.18

Sicherlich ist die Erfolgsgeschichte von Scrum auch dessen konzeptioneller Leichtgewichtigkeit verdanken. Immerhin passt das Originalskript von Schwaber und Sutherland in der aktuellen Fassung auf 17 Seiten (!).19 Andere Werke, die weniger eine konkrete Methode beschreiben, sondern vielmehr einen Body of Knowledge darstellen, kommen da auf viele Hundert bis Tausende Seiten. Dazu gehören natürlich der Project Management Body of Knowledge des PMI, aber nicht zuletzt auch das Handbuch für Praxis und Weiterbildung im Projektmanagement PM4 der GPM.20 Auch die aktuellen Zahlen der niederschwelligen PRINCE2-Zertifizierungen, die sich bis 2018 auf ca. 1,2 Millionen Zertifizierte weltweit belaufen, zeigen auf: Die Praxis verlangt nach leichtfüßigeren PM-Systemen.21

[24]Insbesondere für KMU scheinen die Flaggschiffe des PM oftmals zu schwergewichtig und finden daher lange keine flächendeckende Verbreitung.22 Da kommen die schlanken Ansätze des Agilen gerade recht, die in vielen Bereichen als konkrete Anwendung von Lean Thinking zu erkennen sind (auch wenn der Begriff bei Schwaber/Sutherland nicht auftaucht). Allerdings ist leicht festzustellen, dass die bekannten agilen Methoden, zu denen neben Scrum oftmals auch Xtreme Programming und der Einsatz von Kanban gezählt werden,23 kein vollwertiges PM-System darstellen, fehlen doch in diesen Konzepten weitgehend wesentliche Disziplinen wie unter anderem Risiko-, Stakeholder- oder Vertragsmanagement. Nicht zuletzt bezeichnen Schwaber und Sutherland Scrum als »Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten« – und nicht als PM-Methode.24

Ein zeitgemäßer PM-Ansatz sollte das Beste aus diesen Welten generalisieren und in einem universelleren – einem Lean-Project-Management-Ansatz – vereinen und operationalisieren. Lean PM schafft dabei die Synthese im Sinn eines modernen, zielgerichteten und flexiblen PMs (s. Abb. 1-2).

Abb. 1-2: Die Dialektik des Projektmanagements

[25]Der Anspruch des Lean-PM-Ansatzes – der Begriff wurde erstmalig bereits 2003 in einem Paper von Ballard erwähnt25 – ist es, ein vollwertiges PM-System zu liefern, das es Projekten ermöglicht, mit weniger Aufwand mehr Wert im Sinn des Projektnutzens zu erzielen. Beispielsweise haben Studien von Luft- und Raumfahrtprojekten ergeben, dass in den untersuchten Projekten die rein wertschöpfenden Tätigkeiten nur etwa 12–13 % der Aktivitäten ausmachten!26

Lean PM …

hilft durch den Fokus auf das Wesentliche und die Vermeidung von Unnötigem (Verschwendung) die Projekte zügig ans Ziel zu führen und die Projektbudgets einzuhalten.stellt den Kundenwunsch in den Fokus. Der Kunde definiert Wert und Wertschöpfung. Kundenwünsche werden in konkrete, messbare Critical-to-Quality-Anforderungen (CTQ) für den Projektalltag übersetzt.ist ressourcenschonend, weil Verschwendung und Unnötiges vermieden wird.stellt alle Anforderungen an Dokumentation, Formalitäten, Quality Gates etc. auf den Prüfstand und misst diese individuell daran, welchen Mehrwert sie liefern. Was keine Wertschöpfung darstellt, wird nicht gemacht.

Mit dem Lean PM wird das Ziel verfolgt, bestehende Ansätze zum modernen PM weiterzuentwickeln und einen generell einsetzbaren, leichtgewichtigen Ansatz zu formulieren, der leicht adaptierbar ist und der offen ist für eine flexible Anwendung zwischen Planungssicherheit auf der einen und Trial & Error (im positiven Sinn Inspect & Adapt) auf der anderen Seite. Einen (sinnvollen) Plan zu haben wird dabei nicht grundsätzlich als etwas Schlechtes angesehen (s. auch Abb. 1-1). Lean PM liefert ein unabhängiges, übergeordnetes Modell, das für aktuelle Anwendungen, aber auch zukünftige geeignet ist.27

1 vgl. GPM 2015, S. 19 ff.

2 vgl. Schmitz 2018.

3 vgl. Robinson 2015.

4 s. McKendrick 2015.

5 s. Gemünden et al. 2011.

6 s. GPM 2014.

7 vgl. z. B. PMI 2018, S. 14.

8 PMI: Project Management Institute; IPMA: International Project Management Association; PRINCE2: Projects in Controlled Environments, Vers. 2; ISO: Internationale Organisation für Normung; DIN: Deutsches Institut für Normung.

9 s. Beck et al. 2001.

10 s. Scheller 2017, S. 16 ff.

11 vgl. Komus/Kuberg 2017, S. 26.

12 vgl. The Standish Group 2018.

13 vgl. Wojewoda/Hastle 2015.

14 s. GPM o.J.; IPMA o.J.; PMI o.J.

15 vgl. Komus/Kuberg 2017, S. 13.

16 vgl. Schwaber/Sutherland 2017, S. 6.

17 s. SAFe 2020; LeSS o.J.; Schwaber/Sutherland 2018.

18 s. Komus 2018, S. 11.

19 s. Schwaber/Sutherland 2017.

20 s. PMI 2017; GPM 2019.

21 s. Brecht-Hadraschek 2014, S. 9; Anmerkung: PRINCE2 ist nicht als Body of Knowledge einzustufen, sondern vielmehr als konkret ausgestaltetes PM-Framework.

22 vgl. Vogelsang/Olberding 2007, S. 1.

23 s. Bowes 2015.

24 Schwaber/Sutherland 2017, S. 4.

25 s. Ballard 2003.

26 s. Belvedere 2019, S 411–413.

27 s. auch Erne 2019.

[27]2Grundlagen

2.1Management von Projekten

2.1.1Wertschöpfung durch Projekte

Projekte gibt es eigentlich schon immer. Schon im Alten Testament wird vom Turmbau zu Babel berichtet, der aufgrund unüberwindbarer Verständigungsschwierigkeiten zum Stillstand gekommen sei (von höherer Stelle ausgelöst). Auch der Bau der Pyramiden wird gerne als Beispiel für Ur-Projektvorhaben seit dem dritten Jahrtausend vor Christus herangezogen. Schon damals gab es erfolgreiche und weniger erfolgreiche Vorhaben. So entstand, erkennbar durch Bauprobleme verursacht, die bekannte Knickpyramide des Pharaos Snofur – die offenbar abweichend von der eigentlichen Vorstellung fertiggestellt, aber immerhin als Kultstätte in Betrieb genommen wurde. Parallelen zu heutigen Bauprojekten können hier schnell gezogen werden. Natürlich ist davon auszugehen, dass die Methoden der Planung und Steuerung der antiken Vorhaben nicht vergleichbar mit denen heutiger Projekte waren. Allein mit der Ressource Arbeitskraft dürfte in den altertümlichen Projekten anders umgegangen worden sein – auch wenn heutzutage noch mancher von Projektsklaven reden mag. Im weiteren Verlauf der Geschichte gab es stets große, komplexe Vorhaben einmaliger Art, wie der Bau der Chinesischen Mauer, des Panama- und des Suezkanals, des Eiffelturms, der Aufstellung von Kriegsflotten, um nur einige zu nennen. All diese Vorhaben erforderten ohne Zweifel umfangreiche Planungen sowie logistische und steuernde Maßnahmen – kurzum ein wirkungsvolles Management.28

Auch wenn Gantt bereits im frühen 20. Jahrhundert sein berühmtes Balkendiagramm entwickelte, womit erstmals eine dokumentierte PM-Methode in Erscheinung trat, wird im Allgemeinen die systematische Entwicklung des PMs vor allem mit den militärischen und zivilen Luft- und Raumfahrtprogrammen nach dem zweiten Weltkrieg in Verbindung gebracht. Dazu gehören vor allem die Realisierung des Polaris-Programms der US NAVY, die Großprogramme der US-Luftwaffe und das Apollo-Programm der NASA, also allesamt in den USA beheimatete Projekte, die umfassendere (Projekt-)Managementsysteme wie Phased Project Planning (NASA) oder das System Program Management (USAF) hervorbrachten. Mit den ebenfalls in den USA entwickelten Methoden Program Appraisal & Review Technique (PERT) sowie die Critical Path Method (CPM) prägte die Netzplantechnik anschließend viele Jahre in Deutschland geradezu als Synonym das PM.29

[28]Nicht zuletzt im Zuge der Verbreitung dieser Ansätze in anderen Industriezweigen, insbesondere auch der Automobilindustrie, gründeten sich seit den späten 1960er-Jahren die auch heute noch weltweit führenden Organisationen für das PM: das Project Management Institute (PMI) 1969 in den USA, die International Project Management Association (IPMA) 1965 mit Hauptsitz zunächst in Zürich oder für Deutschland die Deutsche Gesellschaft für Projektmanagement (GPM) 1979 als IPMA-Landesgesellschaft. Damit verbunden war dann auch die Weiterentwicklung von PM als ganzheitlicher Managementansatz – ergänzend zu den eher technokratischen Sichtweisen hin zu einer angemesseneren Betonung sozialer Kompetenzen, wie sie z. B. in der IPMA Competence Baseline (ICB) zum Ausdruck kommen.

Die PM-Organisationen waren es auch, die die Standardisierungsbemühungen für das PM durch die Veröffentlichung jeweils eigener Best Practices vorantrieben. Als Normen entstanden so auch die US-amerikanische ANSI-Norm 99-001 aus dem PM Body of Knowledge Guide (PMBoK Guide) des PMI,30 die DIN 69 900 ff. als deutsche Norm für PM sowie die ISO 21 500 als internationale Norm – leider allesamt untereinander nicht konsistent.

Alle geschilderten Institutionen und Werke (und darüber hinaus noch weitere, wie etwa das britische Office of Government Commerce, das PRINCE2 veröffentlichte) haben jeweils eigene Definitionen für Projekte und das PM entwickelt, deren Auflistung an dieser Stelle nicht erfolgen soll. Vielmehr wird gleichsam als Synthese dieser Beschreibung folgendes Verständnis der Begriffe diesem Buch zugrunde gelegt.

DEFINITION PROJEKT

Ein Projekt ist ein Vorhaben mit einem beschränkten Zeit- und Kostenrahmen zur Erbringung einer Reihe gewünschter Ergebnisse, die – unter Einhaltung bestimmter Qualitätsanforderungen – dazu dienen, die definierten Projektziele zu erreichen. Es ist somit eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, bestimmte Ergebnisse bzw. Produkte in Übereinstimmung mit einem übergeordneten Nutzenziel zu erbringen. Ein Projekt ist im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet.31

Aus der Projektdefinition ergeben sich die in Abb. 2-1 dargestellten typischen Charakteristiken von Projekten.

[29]

Abb. 2-1: Typische Charakteristiken von Projekten

Jedes dieser Merkmale tritt weniger oder stärker ausgeprägt auf – aber nie gleich Null. Damit sind Projekte genuin als (mehr oder weniger) komplexe Vorhaben gekennzeichnet (s. Abschnitt 2.5). Als (temporäre) betriebliche Organisation kommen in Projekten somit die bekannten Funktionen des Managements zur Anwendung. Zu diesen gehören die Festlegung von Zielen, die Entwicklung einer Strategie zur Zielerreichung, die Organisation und Koordination der Produktionsfaktoren und die Führung der Mitarbeiter.32 Für Projekte können wir definieren:

DEFINITION PROJEKTMANAGEMENT

Projektmanagement ist die Anwendung von Wissen, Fertigkeiten, Werkzeugen und Methoden auf Projektvorgänge, um die Projektanforderungen zu erfüllen.33 Es ist ein disziplinierter Prozess zur Identifikation, Koordination und kontinuierlichen Bündelung von Ressourcen (Personen, Material, Fähigkeiten etc.) zur Erfüllung von Projekt-/Vertragszielen innerhalb von Zeit-, Kosten-, Ressourcen- und Qualitätsbeschränkungen.

Mintzberg hat die verschiedenen Rollen, die ein Manager generell einnimmt, empirisch untersucht und beschrieben. Diese treffen auch auf das Management von Projekten zu und können in diesem Kontext ebenso beobachtet werden. Ein (Projekt-)Manager ist demnach Repräsentant, Führer, Koordinator, Informationssammler, Informationsverteiler, Informant externer Gruppen, Unternehmer, Krisenmanager, Ressourcenverteiler und Verhandlungsführer.34 Je nach Auslegung der Rolle – durch den Projektleiter oder die basierende Organisation – ergeben sich unterschiedliche Erscheinungsformen bei der Ausübung des PMs. In Anlehnung an die von Schäfer passend formulierte Charakterisierung können bei der Anwendung von PM-Methoden [30]Pole zu schwacher oder ausgeprägter Ausgestaltung identifiziert werden, wobei der Mittelweg der erfolgversprechende ist (s. Tab. 2-1).35 Diesen gilt es bei der Ausübung eines wirksamen PMs zu treffen.

Ausgestaltung des Projektmanagementszu geringadäquatzu hochRolle Projektleiterfachlicher Treiber, Fachexpertemethodischer Treiber mit fachlichem Verständnis, Unternehmer, Change Agentausführendes Organ, ErfüllungsgehilfeErforderliche Kompetenz des ProjektleitersFachkompetenz wird überbetont, Methodenkompetenz vernachlässigtMethodenkompetenz im Projekt- und Change- management, fachliche Urteilsfähigkeitmethodische Kompetenzen werden überbetont, striktes Befolgen von Regelungen und Standards eines FrameworkPositionierung des Projekts in der Organisationschwach, sehr hohe Dominanz der Linienorganisationausgeglichene Matrixorganisationstark, Vermischung durch Projektarbeit in der LinienarbeitZielfokus(Über-)Erfüllung der fachlich-inhaltlichen Anforderungen, Zeit und Kosten spielen eine untergeordnete Rolleausgewogenes Verhältnis der Dimensionen (Ziele) des Magischen DreiecksZeit und Kosten werden überbetont, formale Anforderungen dominierenGrad der FormalisierungProjektstandards werden als (notwendiges) Übel angesehenProjektstandards sind erforderlich, aber kein Selbstzweck, differenzierende, nutzenstiftende AnwendungÜberbetonung formaler Prozesse und standardisierter Ergebnisse, Effizienz sinktRisikenIntransparenz, hohe (unentdeckte) Zielerreichungsrisikenübliche Projektrisiken werden als normaler Bestandteil betrachtet und systematisch gemanagt.Lähmung, Demotivation, Aufbau von Puffern, Verlagerung der Risiken

Tab. 2-1: Auslegung des Projektmanagements – Pole und Passgenauigkeit

Das diesem Buch zugrunde gelegte Verständnis von Projekten betrachtet diese in den Ebenen PM-Prozesse (PM) und fachlich-fortschreitende Projektbearbeitung (Projektvorgehen (PV), s. Abb. 2-2). Ergänzt werden diese durch eine übergeordnete, den Rahmen vorgebende Ebene des Projektportfoliomanagements (PPM), die aber in diesem Buch nur am Rande mitbetrachtet werden soll (s. Kap. 7).

[31]

Abb. 2-2: Projektebenen (PS: Projektstart, PE: Projektende)

Das fachlich-progressive Vorgehen in einem Projekt (PV) ist abhängig vom Projektgegenstand und letztlich vom konkreten Projektkontext. So hat ein Bauprojekt naturgemäß ein anderes zugrunde liegendes Vorgehensmodell als ein IT-Projekt etc. Insofern ist die PM-Ebene als universeller einzuordnen als die PV-Ebene, was ja auch in den bereits erwähnten Standards zum Ausdruck kommt, die in der Regel unabhängig vom Projektgegenstand zu betrachten sind (auch wenn das oftmals aufgrund der Herkunft der jeweiligen Ansätze, z. B. PRINCE2 aus dem IT-Kontext, anders interpretiert wird).

Gleichwohl haben sich auch für die PM-Ebene unterschiedliche generische Modelle gebildet. Allen voran bekannt geworden ist das sogenannte Wasserfallmodell. In diesem wird ein Projekt in Projektphasen eingeteilt, welche die grundsätzlich fachliche Folge der Leistungserstellung widerspiegeln. Es wird sodann angenommen, dass diese Folge auch sequenziell abgearbeitet wird, sodass der Fluss der Entstehung der Leistung einem Wasserfall gleicht, der stufenweise von oben nach unten fließt. Das Modell wird allgemein Royce zugesprochen, der allerdings bereits betonte, dass es iterative Rückkopplungen zwischen den einzelnen Phasen gebe, die »unglücklicherweise« sogar in der Praxis über mehrere Stufen hinweg durchzuführen seien.36 Der Kerngedanke von Royce und damit des Wasserfallmodells ist, dass es eine logische Folge der Aktivitäten zur Entwicklung eines Produkts gibt, bei der einzelne fachliche Schritte planmäßig aufeinander folgen müssen (Konzeption, Entwicklung, Testen etc.), die nicht übersprungen werden dürfen, wenn das Ergebnis nutzbar sein soll.

Auch in solchen sequenziellen, plangetriebenen Vorgehensmodellen ist Adaptivität Voraussetzung für Stabilität. Dies lässt sich anhand des Beispiels des Kybernetikers Ashby für das Management plakativ veranschaulichen: das Befahren einer geraden Linie mit einem Fahrrad. Würde man in diesem Fall den Lenker des Fahrrads fixieren, fiele man unausweichlich rasch um, weil die permanenten kleinen Störungen (Schwankungen im Gleichgewicht) nicht ausgeglichen [32]werden könnten. Ein erfolgreiches PM muss daher – schon immer – gleichermaßen durch die Schaffung von Stabilität und die Bewahrung von Flexibilität geprägt sein.37 Ohne Flexibilität kann man den besten Plan nicht abfahren!

Abwandlungen des sequenziellen Wasserfallmodells liegen beispielsweise durch das parallele oder vorgezogene Bearbeiten fachlicher Phasen oder das sogenannte Spiralmodell vor. Das parallele Bearbeiten wird möglich, wenn fachliche Arbeiten logisch voneinander zu trennen sind oder das Vorliegen von Teilergebnissen bereits zum Start der nächsten sachlogisch folgenden Arbeit führt. Das hat den Vorteil, dass schneller mit der Arbeit begonnen werden kann, allerdings zum Preis einer höheren Komplexität der Projektabfolge (inkl. Risiken der Nacharbeit), die es zu managen gilt. Das Spiralmodell auf der anderen Seite hält grundsätzlich an der sequenziellen Abfolge der Phasen fest, durchläuft diese aber mehrfach im Sinn einer sukzessiven Weiterentwicklung der Lösung. Die Anzahl der Durchläufe ist dabei von vornherein definiert, womit das Spiralmodell einen Mittelweg zwischen rein agilen Vorgehensweisen und dem Wasserfallmodell beschreibt. Die rein agilen Vorgehensmodelle definieren demgegenüber a priori nicht die Anzahl der Durchläufe zur Erstellung eines zuvor klar definierten Produkts, sondern sind diesbezüglich grundsätzlich offen – lediglich durch Zeit- und Budgetbedingungen begrenzt.

Welches Projektvorgehen bzw. welcher PM-Ansatz letztlich in einem Projekt zum Einsatz kommen sollte, ist Gegenstand der weiteren Ausführungen zum Lean PM in diesem Buch, insbesondere der Adaption des PM-Systems in Abschnitt 5.3.

2.1.2Unified Project Management Framework – der Ordnungsrahmen für PM

Im Bereich des (Einzel-)PMs haben sich eine Reihe von Normen und Best Practices (im Folgenden vereinfachend Standards) etabliert. Dazu gehören insbesondere der PMBoK Guide (PMI), die ICB (IPMA), Projects in Controlled Environments, PRINCE2 (AXELOS), das Kompendium zum kompetenzbasierten Projektmanagement, PM4 (GPM), die DIN 69 900 ff. sowie die ISO 21 500, das Vorgehensmodell für IT-Entwicklungsprojekte der Bundesrepublik Deutschland oder auch das V-Modell XT.38 Aufgrund seiner in der Praxis der Projekte erlangten Bedeutung schließen wir an dieser Stelle auch Scrum mit ein.

Die genannten Standards haben alle einen in wesentlichen Bereichen gemeinsamen Betrachtungsgegenstand – nämlich das Managen von Projekten bzw. Produktentwicklungsprozessen (Scrum) – und unterscheiden sich unter anderem in der fachlichen Schwerpunktsetzung, im Wording, im Grad der Operationalisierung oder in der Managementphilosophie.

[33]Aufgrund der Universalität der Aufgabe PM kann man wohl sagen: Es ist immer derselbe Wein in unterschiedlichen Schläuchen. Gleichwohl lassen sich die Standards grundsätzlich einteilen in sogenannte Bodies of Knowledge (PMBoK Guide, ICB etc.) bzw. operative PM-Methoden/Projektvorgehensweisen (PRINCE2, Scrum etc.).39Tab. 2-2 zeigt eine grobe Analyse der verschiedenen erwähnten Ansätze.40

PMBoKGuideoBody-of-Knowledge-AnsatzoBetonung des Verhaltens des PLodefinierte Wissensgebiete+prozessorientiertKompetenzen–kein Phasenmodell–keine expliziten Artefakte…ICBoBody-of-Knowledge-Ansatz+Betonung der (definierten) Kompetenzen des PL+Einbeziehung fachlicher und kontextbezogener–keine konkreten Prozessmodelle–keine konkreten Artefakte…PM3oBody-of-Knowledge-Ansatzo(nur) beispielhafte Artefakte–extrem umfangreich+extrem umfassend…PRINCE2oPM-Methoden-Ansatzoformulierte Prinzipien+Betonung der Phasenorientierung (aber kein Phasenmodell)+konkrete Artefakte+Business-Case-Orientierung+Lessons-Learned-Betonung+ausgeprägtes Rollenmodell–kein vollumfänglicher Kanon…DIN, ISOoPM-Methoden-Ansatz+klare Definitionen–keine Konsistenz zwischen DIN und ISO–keine konkreten Artefakte…ScrumoPM-Methoden-Ansatz (Vorgehensmodell)oOperationalisierung agiler Prinzipien+konkrete Artefakte–starker IT-Bezug (vgl. z. B. User Storys)–kein umfassendes PM-Konzept…[34]V-Modell XToPM-Methoden-Ansatz (Vorgehensmodell)oOperationalisierung wasserfallorientierter Prinzipien (in erster Linie)oumfangreich, Anforderung zum Tailoring+konkrete Artefakte–starker IT-Bezug…

Tab. 2-2: PM-Ansätze im Vergleich (ausgewählte Aspekte)

Die PM-Standards werden teilweise spezifisch kritisiert (»zu wenig konkret«, »nur bei IT-Projekten einsetzbar«, »zu umfangreich« etc.) und teilen die PM-Community vielfach in entsprechende Lager.

Aufgrund der Universalität der Aufgabenstellung PM sowie des Bedürfnisses, im Sinn eines Lean PM Methoden jeweils auch projektspezifisch ausprägen zu können (sogenanntes Tailoring), bietet es sich an, ein allgemein einsetzbares, wissenschaftlich fundiertes und praktikables Rahmenwerk zu nutzen bzw. zu schaffen. Mit einem solchen Unified Project Management Framework (UPMF, s. Abb. 2-3)41 kann es sodann gelingen, Lean PM systematisch und universell zu operationalisieren. Ziel ist die Entwicklung eines universellen PM-Ordnungsrahmens (Framework) mit folgenden Merkmalen:

einfache Darstellungeinfache Anwendbarkeit und konkrete Operationalisierbarkeituniverselle, projekttyp-unabhängige GültigkeitBest-in-Class-Content, d. h. Vereinigung aus den vorhandenen PM-StandardsÜberwindung des (vermeintlichen) Gegensatzes traditioneller und agiler MethodenMöglichkeit der Anpassung an den jeweiligen Projektkontext

[35]

Abb. 2-3: Big Picture des Unified Project Management Framework

Kern des Unified Project Management Framework ist ein prozessorientierter Ansatz, in dem die Aktivitäten des PM im Verlauf des Projekts im Allgemeinen wiederkehrend beschrieben werden. Dazu gehören …

einmalig die Prozesse der Initialisierung & Vorbereitung des Projekts mit dem zentralen Output des Projektauftrags im Vorlauf eines Projekts sowiewiederkehrend während des Projektablaufs die Prozesse der Ausplanung & Operationalisierung undbegleitend zur Ausführung der fachlichen Arbeiten der Überwachung & Steuerung sowie schließlichdie Überleitung & der Abschluss, welche die Phasenübergänge innerhalb der fortschreitenden Projektbearbeitung sowie auch den Betriebsübergang fokussiert.Komplementär zu den PM-Prozessen erfolgt die Ausführung der fachlich fortschreitenden Projektarbeiten, die unmittelbar dem Projektzweck dienen und damit von den PM-Prozessen abzugrenzen sind.

Den Betrachtungsfokus für die oben genannten Prozesse und Prozessgruppen geben die PM-Disziplinen, zu denen beispielsweise das Management der Risiken, der Stakeholder, des Projektumfangs etc. gehören. Diese PM-Disziplinen werden in den bekannten PM-Standards unterschiedlich [36]bezeichnet (z. B. Wissensgebiete bei PMI, Themen bei PRINCE2) und strukturiert. Gleichsam als gemeinsamer Nenner lässt sich das in Abb. 2-4 dargestellte Framework ableiten.42

Abb. 2-4: Das Unified Project Management Framework

Einer allgemeinen Systematik zur Klassifizierung von Prozessen im Unternehmen folgend, werden die PM-Prozesse unterteilt in (1) strategische Prozesse, (2) Kernprozesse und (3) Befähiger-/Enabler-Prozesse:

Managen des Auftrags und des Business Case, der Stakeholder inkl. Auftraggeber sowie der Risiken und ChancenManagen des Projekt-Scopes, der Projektarbeits- und -organisationsstruktur, des Projektablaufs und der Prozesse sowie des Teams und der KommunikationManagen der Anforderungen und der Qualität, der finanziellen und materiellen Ressourcen im operativen, dispositiven Sinn sowie der Konfiguration der Projektartefakte und der Wissenssicherung und -verwertung

In der Ausgestaltung ergibt sich damit eine Matrix (Disziplinen x Prozessgruppen), in der die Aktivitäten je nach Lage unterschiedlich intensiv bearbeitet werden. Dabei ist anzumerken, dass die Prozesse in Abb. 2-4 selbstverständlich auch parallel und wiederkehrend – nicht zuletzt im Sinn eines »Plan – Do – Check – Act«-Zyklus (Deming-Kreis) – gehandhabt werden.43

Zur Beschreibung der Elemente des Unified Project Management Framework gehören sodann die definitorische Fassung, die zugehörigen Aktivitäten bzw. Teilprozesse, typische Methoden und Tools, Inputs und Outputs, Prozessauslöser, -zulieferer, -ausführende und -kunden sowie Erfolgsfaktoren und Kompetenzen.

[37]Wie in Abb. 2-3 ebenfalls zu sehen ist, ist das Unified Project Management Framework in die organisatorischen Rahmenbedingungen für die Projekte des Unternehmens einzubetten. Neben den infrastrukturellen Voraussetzungen (materielle und immaterielle Betriebsmittel wie Räumlichkeiten, IT, Lizenzen, Material, Informationen und andere) sind hier die Qualifikation der am Projekt Beteiligten (PM-Techniken, fachlicher, betriebswirtschaftlicher Kontext, Verhalten/Persönlichkeit)44 sowie die nicht zu die kulturellen Faktoren der Organisation (bürokratisch, agil, hierarchisch etc.) gehörenden zu nennen, die entscheidend bezüglich Ausgestaltung, Anwendbarkeit und Akzeptanz einzubeziehen sind.

Folgender Nutzen kann mit einem solchen Framework assoziiert werden:

klare, einfach nachvollziehbare StrukturOrdnungsrahmen zur systematischen Ableitung von Lean-Potenzialen und Zuordnung von Lean-Elementen (Prinzipien, Methoden, Tools)alle wichtigen Aspekte zusammen, z. B. Prozessorientierung, agile Elemente, Wissensgebiete, Business-Orientierung etc. – durch Vermeidung der Schwächen einzelner Standardsoperativer Leitfaden und »Werkzeugkoffer« – ohne Vernachlässigung des übergeordneten Gesamtbildesuniversell einsetzbar und verfügbar – ein Framework für alle Projekte im Unternehmen, z. B. ohne Richtungsstreit »klassisch vs. agil«

2.2Grundlagen des Lean Managements

Lean Management hat seinen Ursprung im Toyota Production System, das maßgeblich von dem Ingenieur und Manager Taiichi Ohno gestaltet wurde. Womack und Jones haben die Erkenntnisse aufgegriffen, durch eine Vielzahl anderer Unternehmensanalysen erweitert und daraus den Lean-Production- und schließlich den generellen Lean-Thinking-Ansatz entwickelt. Aufgrund der mittlerweile vielfältigen Literatur und anderer Quellen zu dem Themenkomplex wird im Folgenden nur ein schlanker Überblick hierzu gegeben und die wesentlichen Elemente vorgestellt, die für die Vermittlung der Idee und das Verständnis der späteren Übertragung auf Projekte wichtig sind.

2.2.1Herkunft aus der Produktion

Lean Management ist eine Erweiterung des Lean-Production-Ansatzes auf die komplementären Prozesse der Produktion. Lean Production wiederum fußt im Kern auf dem Toyota Production System. Seine Wurzel reichen damit in die 1940er-Jahre zurück, in denen Ohno damit begann, das Produktionssystem bei Toyota durch seine innovativen Ideen zu verändern. In den [38]nächsten Jahrzehnten wurde das Toyota Production System unter seiner Führung sukzessive um verschiedene Techniken erweitert, die heute allgemein zum Lean-Management-Konzept gezählt werden. Toyota konnte in dieser Zeit zum weltmarktführenden Automobilkonzern aufsteigen und dient seither als Beispiel für die Konkurrenz in Asien, Europa und den USA.

Kerngedanke des Toyota Production System war und ist die Vermeidung von Muda – Verschwendung – jeglicher Art. Im Toyota Production System wurden dazu insbesondere folgende Techniken entwickelt, eingesetzt und optimiert, die auch heutzutage zu den Kernelementen des Lean Managements gehören:

Jidokaautomatischer Band- und Maschinenstillstand, wenn ein Fehler auftrittAutorisierung der Mitarbeiter, Maschinen unverzüglich zu stoppen, wenn ein Fehler auftrittTrennung der menschlichen und von der maschinellen Arbeit, sodass ein Mitarbeiter mehrere Maschinen oder Prozesse bedienen kannAndoneinfaches visuelles Signal, das auf den Zustand einer Maschine oder eines Prozesses aufmerksam machtKanbanverbrauchsorientierte Just-in-Time Materialbereitstellung mithilfe eines Kartensystemsselbststeuernd nach dem Pull-PrinzipWertstromorientierungKonzentration auf die Fertigungsabläufe bei der Anordnung der Maschinen (anstatt nach Bearbeitungsart)Target Costingrückwärts getriebenes Design to Cost, bei dem der Original Equipment Manufacturer (OEM, Erstausrüster) den Wert einer Komponente für den Endkunden vorgibtKaizenProzess der kontinuierlichen Verbesserung im Bestreben nach Perfektion5 Whywiederholtes Fragen nach dem Warum zur Aufdeckung von Ursachen von Problemen

Ohnos übergeordnetes Ziel war es letztlich, die geforderte Qualität zu minimalen Gesamtkosten und kürzestmöglichen Durchlaufzeiten zu liefern. Auf diesen Aspekten liegt im Toyota Production System der Fokus. Dabei ist zu betonen, dass die Domäne des Toyota Production System als Serienproduktion charakterisiert ist, d. h. mit häufig wiederkehrenden, gleichförmigen Prozessen der Leistungserstellung. Dies begründet auch das Bestreben nach Standardisierung der Prozesse auf immer höherem Performance- und Stabilitätsniveau im Toyota Production System und diesem Lean-Management-Ansatz. Hierin liegt ein besonderer Unterschied zur Domäne des PMs, den es beim Transfer der Ideen und Methoden zu berücksichtigen gilt. Projekte zeichnen sich per Definition durch Einmaligkeit, zumindest aber keine gleichförmige Wiederholung von Dagewesenem aus. Diesem Aspekt wird bei der Ausgestaltung des [39]Lean PM entsprechende Aufmerksamkeit gewidmet (s. Abschnitt 5.3). Doch zunächst zurück zu den Lean-Management-Wurzeln.

Womack und Jones integrierten das Toyota Production System durchaus exponiert in ihre in den 1980er-Jahren weltweit durchgeführte Studie zur »schlanken« Produktion in der Automobilindustrie.45 Sie leiteten aus dieser Studie mithilfe der damit vorliegenden Benchmarks später die generellen Prinzipien ab, die sie als Lean-Thinking-Elemente erstmalig 1996 veröffentlichten.46 Die Idee war, aus den Erkenntnissen eines erfolgreichen Managements der Produktion (insbesondere bei Toyota) einen Ansatz zu entwickeln, der den Managern einen übergeordneten, aber auch pragmatischen Leitfaden in die Hand gibt, wie die vielseitigen einzelnen Techniken anzuwenden sind. Dabei formulierten sie insbesondere die fünf Kernprinzipien des Lean Managements, auf die wir uns im weiteren Verlauf des Buches beziehen. Des Weiteren wurde eine Reihe zusätzlicher Lean-Elemente beschrieben, die im Laufe der Jahre durch Wissenschaft und Praxis immer weiter ergänzt wurden. Dies liegt in der Natur der Sache dieses Konzepts, wie wir im weiteren Verlauf erkennen werden, und erzeugt gewissermaßen eine Never-Ending-Story der Entwicklung des Lean Managements.

Teil dieser Geschichte ist die Übertragung des Lean Managements auf weitere Bereiche des Unternehmens. Hiermit hatten bereits Womack und Jones begonnen, indem sie das Lean Enterprise definierten, bei dem über die Produktion und schließlich auch über die Unternehmensgrenzen hinaus in der gesamten Wertschöpfungskette, insbesondere der logistischen Supply Chain, Lean Management umgesetzt wird. In der Folge wurde der Lean-Gedanke auf andere Branchen und weitere Unternehmensfunktionen, die aus Sicht der Produktion als indirekte Bereiche bezeichnet werden, explizit übertragen: Lean Procurement, Lean Sales, Lean Administration, Lean Innovation sowie Lean Construction, Lean (Software) Development, aber auch Lean Start-up. Besonders hervorzuheben ist hierbei das Bauwesen, in dem vor allem die Baukrisen in den USA in den 1980er-Jahren zur Entwicklung erster Übertragungen auf das Projektwesen führten – dem Lean Project Delivery, das im Lean Construction Institute der University of California etwa seit dem Jahr 2000 von Glenn Ballard federführend entwickelt wurde.47 Im Bereich der Software-Entwicklung, der zweiten großen Quelle der Inspiration zur Entwicklung des vorliegenden Lean-PM-Konzepts, sind vor allem die Poppendiecks zu erwähnen, die zeitgleich ebenfalls in den USA ihren Ansatz des Lean Software Development vorgestellt haben.48 Sie nennen den Ansatz auch agilen Werkzeugkasten (agile toolkit), was die Nähe der Konzepte des agilen Managements zum Lean Managements verdeutlicht. Auf die meiner Ansicht nach bestehenden Unterschiede gehe ich im weiteren Verlauf noch ausführlicher ein.

[40]Doch schauen wir uns zunächst einmal die zentralen Elemente des Lean Managements kurz systematisch an.

2.2.2Identifikation von Verschwendung

Das primäre Postulat des Lean Managements ist die Vermeidung von Verschwendung (Muda) jeglicher Art im Unternehmen.49 Als Verschwendung sind allgemein alle Aktivitäten und Prozesse zu bezeichnen, die zwar Kosten verursachen, aber keinen Wert (für den Kunden) erzeugen. Dabei sind grundsätzlich folgende Arten der Verschwendung zu unterscheiden:50

Prozessbedingte Verschwendung:

Dazu gehören Aktivitäten, die für den Prozesskunden nicht direkt wertschöpfend, aber für die Durchführung des Leistungserstellungsprozesses (aktuell) notwendig sind. Beispiele sind Planungsaktivitäten oder Rüstvorgänge. Es gilt, diese auf das Notwendige zu minimieren, bis hin zur möglicherweise vollständigen Eliminierung.

Geschäftsbedingte Verschwendung:

Darunter werden (Sekundär-)Prozesse verstanden, die nicht unmittelbar wertschöpfend für den Kunden sind, aber für den Betrieb insgesamt notwendig. Beispiele sind Finanzierungsprozesse oder die Personaladministration. Es gilt, diese hinsichtlich ihrer Effizienz und gegebenenfalls ihrer Elimination zu überprüfen.

Reine Verschwendung:

Gemeint sind weder direkt wertschöpfende noch die Wertschöpfung unterstützende oder ermöglichende Prozesse. Beispiele sind eine unnötige Papierflut oder Ausgaben. Diese sind unmittelbar zu eliminieren.