Lean Delivery Management. Einsatz leichtgewichtiger Methoden und Techniken bei der Lieferung von Produkten


Fachbuch, 2017
899 Seiten

Leseprobe

Inhaltsverzeichnis

1.0 Lean Thinking

2.0 Methoden
2.1 Scrum
2.1.1 Release Planning
2.1.2 Iteration Planning
2.1.3 Stand-up Meeting
2.1.4 Review
2.1.5 Retrospektive
2.1.6 Leichtgewichtige Rollen
2.1.6.1 Rolle des Projektmanagers
2.1.6.2 Rolle des Scrum Master
2.1.6.3 Rolle des Product Owner
2.1.6.4 Rolle des Application Owner
2.1.6.5 Rolle des Releasemanagers
2.1.6.6 Rolle des Betriebs
2.1.6.7 Rolle des Architekten
2.1.7 Modell- und Konzeptlernen
2.1.7.1 Alles-oder-Nichts-Modell
2.1.7.2 Konzeptlernen
2.2 Kanban
2.2.1 Pull-Prinzip
2.2.2 Serviceklassen
2.2.3 Kanban in der Softwareentwicklung
2.3 Scrumban
2.3.1 Kombination von Scrum und Kanban
2.3.2 Kombination von Projekt- und Tagesgeschäft
2.4 Drum-Buffer-Rope
2.4.1 DBR in Scrum-basierten Vorgehensmodellen
2.4.2 DBR in Kanban-basierten Vorgehensmodellen
2.5 Testgetriebene Entwicklung
2.5.1 Extreme Programming und Test
2.5.2 Testgetriebene Entwicklung mit Akzeptanztests
2.6 Feature-driven Development
2.6.1 Rollen
2.6.2 Prozesse
2.7 Scaled Agile Framework
2.7.1 Rollen
2.7.2 Prozesse
2.8 Dynamic Systems Development Method
2.9 Leichtgewichtiges V-Modell XT
2.10 Leichtgewichtiges Wasserfallmodell

3.0 Techniken
3.1 Nutzwertbasierte Produktplanung
3.1.1 Gossensche Gesetze
3.1.2 Optimaler Verbrauchsplan
3.1.3 Grenzrate der Substitution
3.1.4 Kano-Modell
3.1.5 Netzeffekte
3.1.6 Diffusionstheorie für Netzeffektgüter
3.1.7 Nutzwertbestimmung
3.2 Anforderungsmanagement
3.2.1 Leichtgewichtiges Anforderungsmanagement
3.2.1.1 Use Cases
3.2.1.2 User Stories
3.2.2 Szenarien
3.2.2.1 Szenarien als Grundlage für Architekturentscheidungen
3.2.2.2 Szenarien als Grundlage für Akzeptanztests
3.2.3 Anforderungsentwicklung
3.2.3.1 Anforderungsermittlung
3.2.3.2 Checklisten für Anforderungen
3.2.3.3 Qualitätskriterien für Anforderungen
3.2.3.4 Anforderungen an Akzeptanzkriterien
3.2.4 Änderungssteuerung
3.2.4.1 Product Roadmap
3.2.4.2 Product Backlog
3.3 Konfigurationsmanagement
3.3.1 Leichtgewichtiges Konfigurationsmanagement
3.3.2 Continuous Integration
3.3.3 Continuous Deployment
3.3.4 Continuous Delivery
3.4 Leichtgewichtige Qualitätssicherung
3.4.1 Leichtgewichtige Testprinzipien
3.4.2 Definition of Done
3.4.3 Chancen und Risiken in leichtgewichtigen Testprojekten
3.4.4 V++ Entwicklungs- und Testmodell
3.4.5 Testautomatisierung
3.4.6 Systematic Test and Evaluation Process
3.4.7 Test Process Improvement
3.4.8 Lean Test Process Improvement
3.5 Projektkoordination
3.5.1 Earned-Value-Analyse
3.5.2 Earned Schedule
3.5.3 Balanced Scorecard
3.5.4 Prozesskostenrechnung
3.5.5 Prozesscontrolling
3.6 Kontrolle und Steuerung des Fortschritts
3.6.1 Beispiele für Projekt- und Prozesskennzahlen
3.6.2 Quantitative Assessment
3.6.3 Qualitative Assessment
3.6.4 Checkliste für Scrum Master
3.7 Risikomanagement
3.7.1 SWOT-Analyse
3.7.2 FME-Analyse
3.7.3 ABC-Analyse
3.7.4 SCARF-Modell
3.8 Leichtgewichtiges Lastenheft
3.8.1 Probleme konventioneller Festpreisverträge
3.8.2 Konventioneller Festpreisvertrag aus Sicht des Kunden
3.8.3 Konventioneller Festpreisvertrag aus Sicht des Lieferanten
3.8.4 Probleme von Time & Material -Verträgen
3.8.5 Time & Material -Vertrag aus Sicht des Kunden
3.8.6 Time & Material -Vertrag aus Sicht des Lieferanten
3.8.7 Leichtgewichtiger Festpreisvertrag
3.8.8 Funktionsmethode des Target Costing
3.9 Leichtgewichtige Prozessverbesserung
3.9.1 Standards für Qualitätsmanagement und -sicherung
3.9.2 Prozessverbesserung und leichtgewichtige Methoden
3.9.3 Leichtgewichtige Methoden und das EFQM-Modell
3.9.4 Lean Capatibility Maturity Model Integration
3.9.4.1 CMMI-DEV
3.9.4.2 CMMI und leichtgewichtige Methoden
3.9.5 Software Process Improvement and Capability dEtermination
3.10 Leichtgewichtige Architekturentwicklung
3.10.1 Lean Architectural Thinking
3.10.2 Sieben Prinzipien leichtgewichtiger Architektur
3.10.3 Leichtgewichtige Architekturen durch Microservices
3.10.3.1 Domain Driven Design für Microservices
3.10.3.2 Architecture Patterns für Microservices
3.10.4 Architekturbewertung
3.10.4.1 Software Architecture Analysis Method
3.10.4.2 Architecture Tradeoff Analysis Method

4.0 Literaturverzeichnis

5.0 Linkliste

1.0 Lean Thinking

Unternehmen müssen heute flexibel und schnell in der Lage sein, auf neue Marktanforderungen bzw. Wünsche der Kunden und Benutzer zu reagieren und dabei eine hohe Qualität bei niedrigen Preisen sicherstellen. Um langfristig einen Geschäftserfolg zu erzielen, müssen sie zum einen neue Marktsegmente effektiv und effizient zufriedenstellen, indem sie mit kurzer Vorlaufzeit innovative, qualitativ hochwertige Produkte anbieten (Stichwort: Time to Market). Zum anderen müssen sie bestehende Beziehungen vertiefen, d.h. die Loyalität alter Kunden und Benutzer erhalten. Um diese Ziele zu erreichen müssen Unternehmen sowohl die Motivation und Fähigkeiten der Akteure mobilisieren, als auch ein produktives Umfeld schaffen, in dem durch eine kontinuierliche Prozessverbesserung (<engl.> Continuous Process Improvement) eine hohe Flexibilität und Qualität gewährleistet sind. Die Referenzgröße für Qualität bildet in erster Linie die Zufriedenheit der Kunden und Benutzer, die als Bedingung für einen langfristigen Geschäftserfolg zu verstehen ist. Dem Kunden, welcher das Produkt erwirbt und es ggf. anpassen lässt, kann an einer Produktivitätssteigerung, den Gesamtkosten des Produkts einschließlich Betrieb und Wartung gelegen sein. Die Benutzer können hingegen eine intuitive Bedienung des Produkts erwarten. Sowohl für den Kunden, als auch für die Benutzer können Sicherheitsaspekte eine wichtige Rolle spielen. Die Erfüllung der jeweiligen Bedürfnisse hat einen erheblichen Einfluss auf die Zufriedenheit mit dem Produkt.[1]

Um die Bedürfnisse der Kunden und Benutzer zu erfüllen und am Markt zu bestehen, bedarf es sowohl einerseits leicht anpassbarer, flexibler Entwicklungsprozesse, als auch andererseits nahtlos integrierter Test- und Unterstützungsprozesse. Die Entwicklungs-, Test- und Unterstützungsprozesse müssen einer ständigen Optimierung unterliegen. Hervorzuheben ist, dass bereits eine Verbesserung der Entwicklungsprozesse zu einer höheren Qualität führt. Im Umkehrschluss ist jeder Entwicklungsprozess so gut, wie die Qualität des resultierenden Produkts. Ferner führt eine Verbesserung der Entwicklungsprozesse zu einer genaueren Projektplanung, d.h. einer effektiven Zeitplanung und dem effizienten Einsatz von Ressourcen.

Mit Leichtgewichtigkeit (<engl.> lightweight oder lean für flexibel, schnell) sind die zeitabhängige Entwicklung eines Unternehmens, seiner Produkte und Prozesse angesprochen. Der leichtgewichtige Ansatz (Stichwort: Lean Delivery Management) hat sich als probates Gegenmittel für viele Hauptgründe des Scheiterns von Projekten erwiesen:[2]

– Große Projekte und langfristige Planungen gehen häufiger schief als überschaubare Vorhaben. Darum planen die Protagonisten des leichtgewichtigen Ansatzes nur für wenige Wochen, häufig zwei bis vier Wochen, voraus. In dieser Zeitspanne, auch Iteration oder Sprint bei Scrum genannt, erstellt das Team eine überschaubare Anzahl neuer Features (<engl.> für Funktion, Funktionalität, Eigenschaft).
– Da der Kunde zu Beginn des Projekts oft selbst nicht genau weiß, was er möchte, gibt man ihm wiederholt die Möglichkeit zum Test und für Feedback. So bekommt der Kunde immer klarere Vorstellungen von seinen Anforderungen (und das Team ebenso).
– Fehlendes Wissen gibt es auch auf der Seite der Auftragnehmer, z.B. wenn das Projekt eine neue Technik einsetzt oder die vorhandenen Regeln durch neue Regeln ersetzt. Manchmal fehlt es dem Team auch schlicht an Erfahrung. In solchen Konstellationen werden Aufwandsschätzungen zum Glücksspiel. Der iterative Ansatz gibt dem Team Gelegenheit zum Lernen. Da es nach jeder Iteration neu entscheiden muss, was die nächste hervorbringen soll, können die Mitglieder neue Erkenntnisse stets in die Planung einbeziehen.
– Komplexe Prozesse lenken von der produktiven Arbeit ab und erzeugen unproduktiven Organisationsaufwand. Da verteilte Teams und Abstimmungsprozesse Reibungsverlust erzeugen, arbeitet man als kleine Gruppe am selben Ort und es gibt nur wenige Rollen. In Scrum z.B. gibt es die Rollen Scrum Master (Prozessverantwortlicher), Product Owner (Vertreter des Kunden) und das Team.
– Lean Development (<engl.> für Leichtgewichtige Entwicklung) versetzt die Teams in die Lage, zu einem vorab definierten Zeitpunkt (auch kurzfristig) lauffähige und qualitativ hochwertige Produkte zu liefern, und zwar zu einem vorhersehbaren Preis. Die Menge der Features können die Teams allerdings nicht zuverlässig im Voraus planen. Im Gegensatz dazu legt bei einem konventionellen Ansatz ein Werkvertrag den Umfang an Features und den Preis fest. Leider verschiebt sich der Liefertermin bei Projekten, die mit einem konventionellen Vorgehensmodell arbeiten, häufig und die Qualität der Produkte leidet unter zu vielen Kompromissen.

Korn[3] zufolge können im Kontext der Produktentwicklung und des Projektmanagements sowie des Managements und der Gestaltung des Unternehmens vier Ausprägungen eines leichtgewichtigen Ansatzes unterschieden werden:

1. Leichtgewichtiger Ansatz = Flexibilität und Adaptivität sichern mit sogenannter „Empirical Process Control“ in Form eines Ansatzes in kontinuierlichen kleinen Schritten ausgehend von einem möglichst leichtgewichtigen sogenannten „Just Enough Design Up Front“. Jeder Schritt liefert ein, wenn immer möglich bereits praktisch nutzbares, Teilergebnis, das Grundlage für das Lernen und für Feedback zur Gestaltung der nächsten Schritte ist.
2. Leichtgewichtiger Ansatz = Flexibilität und Adaptivität plus „Lean Management Principles“. Zusätzlich zur obigen Bedeutung werden die Prinzipien des „Lean Managements“ als eigentliche Basis eines iterativ-inkrementellen Ansatzes angesehen. Diese werden oft dargestellt als sogenanntes „Lean Thinking House“. Das Ziel „Wert schaffen“ als Dach des Lean Thinking House ist gekennzeichnet durch sogenannte „Sustainable shortest lead time / Best quality and value (to people and society) / Most customer delight, lowest cost, high morale, safety“ und getragen von den beiden Säulen „Respect for People“ und „Continuous Improvement“. Erreicht wird das Ziel durch spezifische Entwicklungsmethoden basierend auf den sogenannten „14 Toyota Way Principles“.
3. Leichtgewichtiger Ansatz = Flexibilität und Adaptivität plus „Lean Management Principles“ verbunden mit einer Sammlung „post-tayloristischer“, hierarchie- und autoritätsfreier, partizipativer, selbststeuernd-kollaborativer, kommunikationsbasierter, systemischer Praktiken und „Glaubenssätze“. Die vier Werte und zwölf Prinzipien des sogenannten „Agilen Manifests“ sind als Appell zu verstehen und nicht als „verifizierte Arbeitsregeln“. Sie dogmatisch als Handlungsanweisungen für die Produktentwicklung in unterschiedlichsten Situationen zu betrachten wäre eine Fehlnutzung.
4. Leichtgewichtiger Ansatz = Aspekte zur Sicherung der Überlebens- und Entwicklungsfähigkeit, d.h. eine ganz andere, nicht auf die Produktentwicklung sondern die Führung sozialer Systeme in risikoreichen und komplexen Missionen ausgerichtete Sicht von „leichtgewichtig“. Dies umfasst die Aspekte Robustheit (die Fähigkeit, aufgaben-, situations- und bedingungsübergreifend effektiv zu bleiben), Belastbarkeit (die Fähigkeit, sich von Unglücksfällen, Schäden oder einer destabilisierenden Störung der Umgebung zu erholen oder sich darauf einzustellen), Reaktionsfähigkeit (die Fähigkeit, auf eine Veränderung der Umgebung rechtzeitig zu reagieren), Flexibilität (die Fähigkeit, mehrere Lösungsmöglichkeiten einzusetzen und nahtlos von einer zur anderen überzugehen), Innovationsfähigkeit (die Fähigkeit, neue Dinge zu tun und die Fähigkeit, alte Dinge auf eine neue Art und Weise zu tun) und Anpassungsfähigkeit (die Fähigkeit, Arbeitsprozesse zu ändern und die Fähigkeit, die Organisation zu ändern). Diese Definition versteht unter „Flexibilität“ im Gegensatz zu allen anderen Sichtweisen von „leichtgewichtig“ nicht nur ein inkrementell-adaptives Vorgehen in kleinen Schritten, sondern lässt auch ein stark plangetriebenes Vorgehen dann zu, wenn es für die aktuelle Situation passender und effizienter ist.

Eine Umfrage hat Herrmann[4] zufolge gezeigt, dass leichtgewichtige Projekte deutlich öfter zur Zufriedenheit aller enden als konventionelle. Aber auch konventionelle Projekte, die leichtgewichtige Techniken anwenden, haben eine höhere Erfolgsquote. Folgende Techniken führen ihm zufolge am wahrscheinlichsten zum Erfolg:

– Iterativ-inkrementeller Ansatz mit der Einhaltung von Zeitfenstern bzw. zeitlichen Beschränkung von Tasks (<engl.> Timeboxing), Ergebnisreviews und Retrospektiven (<engl.> Retrospectives).
– Das gemeinsame Planen von Management und Projektteam.
– Die intensive Zusammenarbeit mit dem Kunden (mindestens einmal wöchentlich bis täglich).

Das Konzept eines leichtgewichtigen Ansatzes in der Produktion stammt aus Japan, wo es von Taiichi Ohno für die Fa. „Toyota“ in den 1950er Jahren aufgrund sich ändernder wirtschaftlicher Gegebenheiten entwickelt wurde. Die Herausforderung war, die vorhandenen Ressourcen optimal einzusetzen um die Wettbewerbsfähigkeit in einer zunehmend globalisierten Wirtschaft zu verbessern und neue Märkte zu erschließen. Das Grundkonzept wurde seitdem kontinuierlich weiterentwickelt. Experten betrachten diesen ursprünglich als Produktionssystem entwickelten Ansatz als die Grundlage für den Aufstieg der Fa. „Toyota“ zu einem führenden Automobilhersteller. Ab den 1990er Jahren wurde das sogenannte „Toyota-Produktionssystem“ (TPS) auch als sogenannte „Lean Production“ (<engl.> für Leichtgewichtige Produktion) bekannt. Verschiedene Unternehmen haben seither den Einsatz erprobt. Die Prinzipien der leichtgewichtigen Produktion wurden anfangs auf einzelne Produktentwicklungen angewendet. Dabei wurde schnell festgestellt, dass das Gesamtvorgehen optimiert bzw. erweitert werden muss, d.h. der Prozess muss auf die Zulieferer ausgedehnt sein. Später wurden die Prinzipien der leichtgewichtigen Produktion auch auf die gesamte Wertschöpfungskette angewendet.

Die Ziele eines leichtgewichtigen Ansatzes beziehen sich auf die Optimierung der Produktivität der Produktionsfaktoren und der Qualität der Produkte sowie die Flexibilität des Produktionsapparates. In seinem Buch „Toyota Production System“ bezeichnet Ohno[5] das Produktionssystem der Fa. „Toyota“ als „ a system for the absolute elimination of waste “. Das Konzept des leichtgewichtigen Ansatzes umfasst eine systematische Identifikation und Eliminierung der Verschwendung im Unternehmen. D.h., dass durch die Minimierung der Verschwendung die Prozesse verschlankt werden, was primär wiederum zu sinkenden Durchlaufzeiten führt. Verschwendung liegt üblicherweise in insgesamt sieben Formen vor:[6]

1. Überproduktion: Frühere, schnellere und größere Menge an Produkten, als vom Kunden verlangt.
2. Wartezeit: Zeit, in der keine wertschöpfenden Tasks abgearbeitet werden.
3. Prozessübererfüllung: Tasks, die weder vom Kunden verlangt werden, noch zur Wertschöpfung beitragen.
4. Transport: Überflüssige Materialbewegung.
5. Nacharbeit: Wiederholung bzw. Korrektur eines Prozesses.
6. Bestand: Lagerung von Teilen bzw. Material über die für den Kunden erforderliche Menge hinaus.
7. Bewegung: Überflüssige Bewegungen von Akteuren oder Material innerhalb eines Prozesses.

Leichtgewichtigkeit ist der sparsame und zeiteffiziente Einsatz der Produktionsfaktoren, d.h. unter anderem des Personals sowie der Werkstoffe und Betriebsmittel bei allen Tasks (<engl.> für Arbeitsaufträge). Das Konzept zeichnet sich dadurch aus, dass es jede Form von überflüssigen Tasks eliminiert. Seine zwei Stützen sind „Just-in-Time Flow“ und „Stop-the-Line“.[7]

– Just-in-Time Flow: Projekte bzw. ganze Unternehmen sollen nicht mehr auf Vorrat produzieren. Alle Komponenten werden in kleinen Häppchen durch die Wertschöpfungskette geleitet. Einzelne Knoten, organisatorische Stellen, in denen das Produkt erstellt wird, können sehr schnell umfunktioniert werden und auch andere Tasks übernehmen. Bei Just-in-Time wird die lokale Effizienz in den einzelnen Arbeitsschritten nicht mehr maximiert (für sich betrachtet könnte jeder Knoten ohne Just-in-Time mehr produzieren). Durch Just-in-Time wird aber der Gesamtausstoß maximiert.
– Stop-the-Line: Der gesamte Produktionsprozess wird kontinuierlich implizit auf Fehler überprüft. Es existiert keine dedizierte Qualitätsstelle, die zu vorbestimmten Zeitpunkten die Qualität der erstellten Produkte überprüft. Ein kontinuierlich auf Fehler überprüfter Produktionsprozess benötigt keine expliziten Qualitätskontrollen. Alle Akteure sind jederzeit in die Fehlerfindung bzw. Überprüfung der Qualität involviert. Wird irgendwo im Gesamtprozess ein Fehler gefunden, wird „die ganze Linie angehalten“ und der Fehler direkt behoben. D.h., es wird keine Produktion mehr durchgeführt, bis der Fehler behoben ist.

Durch Verschwendung entstehen Kosten, denen keine Wertschöpfung gegenüber steht. Diese sogenannten „Blindleistungen“ werden in der Praxis in den wenigsten Unternehmen aussagefähig oder ganzheitlich erfasst. In den meisten Fällen werden sie als „notwendiger“ oder „unvermeidlicher“ Teil von Prozessen eingeordnet. Wenn man Verschwendungskosten jedoch nicht transparent macht, können sie auch nicht beeinflusst und beseitigt werden.

Abbildung in dieser Leseprobe nicht enthalten

[Abb. 1: Verschwendung entlang einer möglichen Wertschöpfungskette (angepasste Darstellung)[8] ]

- Abb. 1: Die Wertschöpfung selbst ist nur ein Teil der gesamten Aufwände. Traditionell fokussieren Initiativen zur Senkung der Kosten die Bereiche, in denen die Wertschöpfung unmittelbar stattfindet. Lean Thinking fokussiert demgegenüber den Wertstrom als Ganzes und versucht nicht nur wertschöpfende Tasks zu optimieren, sondern auch nicht wertschöpfende Tasks zu minimieren.

Eine Antwort auf die Frage, welche Tasks in welchen Prozessen als wertschöpfend betrachtet werden können, erhält man durch die Überlegung, ob der Kunde dafür bereit ist zu bezahlen. Kunden, die bspw. eine Standardsoftware kaufen, sind sicherlich dafür bereit zu zahlen, dass etwa ihre Geschäftsprozesse analysiert werden. Die im Unternehmen notwendigen Tasks zur Steuerung des Projekts, wie etwa die Akquise von geeigneten Akteuren und / oder die Befähigung von Akteuren, sind aus Sicht des Kunden hingegen mit keinem Nutzwert verbunden. Insofern ist der Kunde nicht dafür bereit zu zahlen, d.h. sämtliche internen Tasks des Lieferanten sind für den Kunden nicht wertschöpfend. Verschwendung bzw. nicht wertschöpfende Tasks umfasst bzw. umfassen demnach alle Prozesse, die Ressourcen kosten, aber nicht unmittelbar zur Umsetzung der Anforderungen beitragen.[9] Neben der Verschwendung sind zwei weitere Störfaktoren, welche die Leistung in der Produktion hemmen zu minimieren:[10]

1. Zum einen ist dies die Variabilität, die jede Abweichung von den Standardabweichungen bezeichnet.
2. Zum andern ist dies die Inflexibilität, die eine schnelle Reaktion auf veränderte Nachfrage verhindert.

Das TPS bildet den Rahmen, um die drei Hemmfaktoren Verschwendung, Variabilität und Inflexibilität zu minimieren. Das TPS lässt sich mit den folgenden 14 Prinzipien beschreiben, die sich dadurch auszeichnen, dass sie kaum Aussagen zu konkreten Methoden, Modellen, Techniken und Werkzeugen machen. Die Prinzipien sind eher grundsätzlicher Natur. Die „14 Toyota Way Principles“ der Lean Product Development fasst Liker[11] wie folgt zusammen (ähnlich Töpfer[12] ):

1. Managemententscheidungen sind auf die langfristigen finanziellen Ziele, auch auf Kosten der kurzfristigen finanziellen Ziele, des Unternehmens ausgerichtet.

– Die Vision beeinflusst die (kurzfristige) Entscheidungsfindung maßgeblich. Das Unternehmen muss primär über das Tagesgeschäft wachsen, aber auf langfristige Ziele ausgerichtet sein, um in der Zukunft noch profitabler zu werden. Jedes Projekt muss sich die Historie des Unternehmens vor Augen führen und seinen Beitrag zur Erreichung der langfristigen Ziele verstehen. Diese visionäre Perspektive ist die Grundlage aller „14 Toyota Way Principles“.
– Ein Projekt generiert Nutzwert für den Kunden und im optimalen Fall für die Volkswirtschaft und / oder die Gesellschaft. Jeder Prozess und jeder Akteur wird hinsichtlich seiner Fähigkeit bewertet, einen Beitrag zum angestrebten Nutzwert zu leisten.
– Jeder Akteur muss Verantwortung zeigen und sich in Bezug auf die Vision des Unternehmens einordnen, ausrichten und weiterentwickeln. Die Akteure strahlen Selbstvertrauen aus, denn sie verfügen über ausgeprägte soziale und fachliche Kompetenzen. Die Akteure übernehmen die Verantwortung für ihr Handeln und verbessern kontinuierlich ihre Kompetenzen, um einen höheren Beitrag zur Zielerreichung bzw. zum Nutzwert zu leisten.

2. Etablierung standardisierter Prozesse, um Probleme sichtbar bzw. fassbar zu machen.

– Analyse und Anpassung der Prozesse, um den Nutzwert zu optimieren. Das Vorgehen hat zum Ziel die Leerlaufzeiten der Akteure zu minimieren.
– Die Optimierung des Materialflusses und des Flusses an Hintergrundwissen (<engl.> Background Knowledge) sowie die Verknüpfung von Prozessen und Akteuren machen Probleme schnell sichtbar.
– Der Schlüssel zu einer wirklichen kontinuierlichen Verbesserung und zur gezielten Weiterentwicklung der Akteure ist die transparente Einbindung des Flusses an Material und Hintergrundwissen in die Kultur des Unternehmens.

3. Einsatz von Pull-Systemen, um eine Überproduktion zu vermeiden.

– Direkte Einbindung der Kunden in den Produktionsprozess, um zur richtigen Zeit die benötigte Menge zu liefern. Ein durch den aktuellen Verbrauch gesteuerter Materialfluss ist das Grundprinzip des Just-in-Time-Gedankens.
– Minimierung der Fertigung und Lagerbestände eines Produkts anhand von Erfahrungswerten hinsichtlich des Verbrauchs.
– Flexible Reaktion auf Veränderung der Nachfrage, anstatt Planung anhand starrer Verbrauchs- bzw. Produktionspläne.

4. Ausbalancierung der Arbeitsbelastung (<jap.> Heijunka); „Arbeiten wie die Schildkröte, nicht wie der Hase“.

– Die Beseitigung von „Müll“ ist nur ein Drittel der Gleichung für den Erfolg der leichtgewichtigen Produktionsmethode. Die Beseitigung von Abraum hinsichtlich Menschen und Material und die Beseitigung von Unebenheiten im Produktionsprozess sind ebenso wichtig. (Was in der Regel aber von Unternehmen nicht sofort verstanden wird, welche die leichtgewichtige Produktionsmethode einführen.)
– Erst einmal machen und dann die Arbeitsbelastung auszubalancieren als Alternative zum Stopp-Start-Ansatz (<engl.> Stop Planning, Start Finishing) des Wasserfallmodells, ist in den meisten Unternehmen ein typischer Fehler bei der Einführung eines leichtgewichtigen Ansatzes.

5. Etablierung einer „Stopp-Kultur“, um Probleme unmittelbar zu beheben und die geforderte Qualität bereits beim ersten Durchlauf sicherzustellen.

– Qualität ist der treibende Faktor bei der Generierung von Nutzwert für den Kunden.
– Einsatz aller verfügbaren, modernen Methoden zur Qualitätssicherung (<engl.> Quality Assurance).
– Erweiterung der Prozesse um ein integriertes Monitoring, so dass der Prozess bei Problemen automatisch stoppt. Dies umfasst die Einführung eines visuellen Systems, welches das Team oder die Projektleitung alarmiert, wenn ein Problem in einem Prozess auftritt. In diesem Zusammenhang ist der Einsatz künstlicher Intelligenz förderlich.
– Einsatz organisationaler Unterstützungssysteme um Probleme schnell lösen bzw. Gegenmaßnahmen einzuleiten zu können.
– Erweiterung der Kultur des Unternehmens, hin zu einer Stopp-Kultur bzw. zu einer Kultur der Verlangsamung um bereits beim ersten Durchlauf die geforderte Qualität sicherzustellen und langfristig die Produktivität zu erhöhen.

6. Standardisierte Tasks sind die Grundlage für die kontinuierliche Prozessverbesserung und die Befähigung der Mitarbeiter (<engl.> Empowerment).

– Einsatz stabiler, wiederholbarer Prozesse im gesamten Unternehmen, um die Berechenbarkeit der Tasks sicherzustellen. Dies ist die Grundlage für ein Pull-System.
– Erfassung des akkumulierten Hintergrundwissens über einen Prozess zu einem bestimmten Zeitpunkt durch eine Standardisierung der aktuellen Best Practices (<engl.> für bewährte Methoden, Modelle, Techniken und Werkzeuge). Es ist jedoch wichtig, individuelle Anpassungen der Prozesse in konkreten Situationen zu ermöglichen, vorgenommene Anpassungen regelmäßig zu reflektieren und bei Bedarf in einen neuen Standard zu überführen. Dies stellt sicher, dass die Prozessdokumentation aktuell ist und das benötigte Hintergrundwissen für alle Akteure verfügbar ist.

7. Einsatz visueller Kontrollen, so dass keine Probleme unentdeckt bleiben.

– Einsatz einfacher visueller Indikatoren, um den Akteuren zeitnah zu ermöglichen festzustellen, ob Abweichungen vorliegen und ob diese Abweichungen noch im Toleranzbereich liegen.
– Vermeidung des Einsatzes von Bildschirmen, wenn diese den Fokus des Akteurs zu stark vom eigentlichen Task ablenken.
– Einsatz einfacher visueller Systeme an der Stelle, an welcher die Tasks durchgeführt werden um den Einsatz von Pull-Systemen zu unterstützen.
– Wenn möglich, Reduzierung der Berichterstattung auf die Größe eines Briefpapierbogens, auch für wichtigste finanzielle Entscheidungen.

8. Einsatz zuverlässiger, ausgereifter Technologie, welche die Mitarbeiter und Prozesse unterstützt.

– Einsatz von Informationstechnologie um die Akteure zu unterstützen und nicht um sie zu ersetzen. Häufig ist es vorteilhaft zuerst einen manuellen Prozess zu etablieren und diesen dann später mit Informationstechnologie zu unterstützen.
– Neue Technologien sind häufig unzuverlässig und schwer zu standardisieren und ihr Einsatz gefährdet den Fluss von Material und Hintergrundwissen durch die Prozesse. Der Einsatz bewährter Technologien hat deshalb Vorrang vor dem Einsatz neuer, unerprobter Technologien.
– Es besteht die Notwendigkeit zur Durchführung von umfassenden Tests neuer Technologie vor deren Integration in Prozesse und / oder Produkte.
– Ablehnung oder Änderung von Technologien, die in Konflikt zur Kultur des Unternehmens stehen oder die Stabilität, Zuverlässigkeit und Berechenbarkeit des Produkts gefährden.
– Trotz der oben genannten Vorbehalte, Ermutigung der Akteure neue Technologien auszuprobieren bzw. neue Lösungsansätze zu entwickeln.

9. Aufbau starker Persönlichkeiten, die ihre Arbeit wirklich verstehen, die Vision des Unternehmens leben und die Vision des Unternehmens anderen Akteuren vermitteln.

– Entwicklung von Akteuren zu Führungspersönlichkeiten anstatt diese am Markt einzukaufen.
– Eine Führungskraft darf nicht nur als mehr oder minder kompetenter Akteur bei der Ausführung von Tasks mit Menschenkenntnis gesehen werden.
– Eine kompetente Führungskraft muss das Tagesgeschäft im Detail verstehen und die Vision des Unternehmens anderen Akteuren vermitteln können.

10. Entwicklung außergewöhnlicher Akteure und Teams, welche der Vision des Unternehmens folgen.

– Etablierung einer starken, stabilen Kultur, in der Unternehmenswerte und Überzeugungen weitgehend geteilt und über einen Zeitraum von vielen Jahren gelebt werden.
– Vermittlung der Vision des Unternehmens an außergewöhnlicher Akteure und Teams, um außergewöhnliche Ergebnisse zu erzielen.
– Einsatz interdisziplinärer Teams, um die Qualität und die Produktivität zu erhöhen und die Beschleunigung des Flusses von Material und Hintergrundwissen, durch die Lösung schwerwiegender Probleme, zu erreichen. Die Befähigung der Akteure ergibt sich, wenn die Akteure die Methoden, Modelle, Techniken und Werkzeuge des Unternehmens nutzen um eine Verbesserung zu erreichen.
– Es bedarf kontinuierlicher Bemühungen Akteuren beizubringen, wie man als Team auf gemeinsame Ziele zuarbeitet. Arbeit im Team ist etwas, was man lernen muss.

11. Würdigung des erweiterten Netzwerks aus Partnern und Lieferanten durch das Stellen und Annehmen von Herausforderung und die Unterstützung bei der kontinuierlichen Prozessverbesserung.

– Respekt gegenüber allen Akteuren. Dies beinhaltet die konsequente Einbindung externer Stakeholder in die internen Strukturen des Unternehmens bzw. Projekts.
– Ermutigung externer Stakeholder zu Wachstum und Weiterentwicklung sowie Unterstützung dieser bei der Erreichung anspruchsvoller Ziele. Dies zeigt die Wertschätzung des Unternehmens bzw. Projekts gegenüber den externen Stakeholdern.

12. Eigeninitiative, um die jeweilige Situation wirklich zu verstehen (<jap.> Genchi Genbutsu).

– Lösung von Problemen und Prozessverbesserung durch die Analyse der Ursachen an der Quelle. Dies beinhaltet die persönliche Beobachtung und Überprüfung von Daten anstatt der Analyse anhand der Aussagen anderer oder generierter Berichte.
– Die Kommunikation und Entscheidungsfindung erfolgt anhand persönlich überprüfter Sachverhalte.
– Das Topmanagement sollt sich, wie die anderen Führungskräfte, selbst ein Bild der Dinge machen, um ein besseres Verständnis der jeweiligen Situation zu bekommen.

13. Sorgfältige Entscheidungsfindung im Konsens mit allen Stakeholdern unter Berücksichtigung aller Optionen und die schnelle Umsetzung der getroffenen Entscheidungen (<jap.> Nemawashi).

– Sorgfältige Überprüfung aller Alternativen im Vorfeld der Entscheidungsfindung. Wurde eine Entscheidung getroffen, setzt ein kontinuierlicher Prozess der Reflexion bereits während der Umsetzung ein und die Entscheidung wird bei Bedarf revidiert.
– Probleme und potentielle Lösungen werden mit allen Stakeholdern diskutiert, um ein gemeinsames Verständnis und eine einvernehmliche Lösung zu erreichen. Der Prozess einen Konsens zu schaffen ist zeitaufwändig, hilft aber den Lösungsbereich zu erweitern und sobald eine Entscheidung getroffen ist, kann diese zügig umgesetzt werden.

14. Etablierung eines lernenden Unternehmens und lernender Projekte durch kontinuierliche Reflektion (<jap.> Hansei) und kontinuierliche Verbesserung (<jap.> Kaizen).

– Wurden stabile Prozesse etabliert, kommen Techniken zur kontinuierlichen Verbesserung zum Einsatz, um ineffiziente Prozessschritte zu identifizieren und wirksame Gegenmaßnahmen einzuleiten.
– Etablierung von Prozessen, die nahezu keine Vorratshaltung bedürfen. Leichtgewichtige Prozesse machen die möglicherweise gegebene Verschwendung von Ressourcen noch sichtbarer. Sobald unnötiger Ballast in Prozessen sichtbar wird, sorgen die Techniken der kontinuierlichen Verbesserung dafür, dass der „Müll“ beseitigt wird.
– Schutz der organisationalen Wissensbasis (<engl.> Knowledge Base) durch die gezielte Weiterentwicklung der Akteure und das Aufzeigen von Karrierepfaden.
– Reflektion der Prozesse und projektspezifischen Tasks zu den wichtigsten Meilensteinen, Identifikation aller Schwachstellen und zumindest zum Ende eines Projekts Aufarbeitung der Schwachstellen in den sogenannten „Lessons Learned“ (<engl.> für gewonnene Erkenntnisse).
– Zumindest zum Ende eines Projekts Überarbeitung der Best Practices um das Rad nicht bei jedem Projekt neu erfinden zu müssen.

Ausgehend von den Prinzipien des TPS lassen sich in Anlehnung an Töpfer,[13] der sich im Rahmen der betrieblichen Wertschöpfung auf Womack und Jones[14] sowie Weidinger[15] bezieht, auf übergeordneter Ebene fünf Prinzipien herausstellen, deren konsequente Anwendung zum sogenannten „Lean Thinking“ führt.

1. Das Prinzip der Definition des Nutzwerts ist der entscheidende Ansatz des Lean Thinking. Der Nutzwert wird durch den Kunden definiert und bezieht sich auf eine spezifische Leistung zur Befriedigung der Bedürfnisse, für die er zu bezahlen bereit ist. Die Analyse und Gestaltung der Wertschöpfung bedarf demnach einerseits einer umfassenden Orientierung an den Bedürfnissen des Kunden, welche die völlige Klarheit über Ziele, Probleme und Absichten des Kunden voraussetzt. Über die exakte Definition der vom Kunden geforderten Leistungen werden andererseits (im Idealfall) die Erstellung aller nicht-wertschöpfenden Ergebnistypen und die Durchführung der damit zusammenhängenden Tasks vermieden.
2. Das Prinzip der Identifikation des Wertschöpfungsstroms unterstreicht die Notwendigkeit, alle Bearbeitungsschritte entlang der Wertschöpfungskette (d.h. der Prozesse, die mit der Herstellung und Qualitätssicherung des Produkts bzw. der Erstellung und Absicherung der Leistung selbst, der Lieferung (<engl.> Delivery) an den Kunden, den Dienstleistungen nach dem Kauf usw. zu tun haben) einer umfassenden Analyse zu unterziehen. In der Analyse werden die Tasks in Nutz-, Stütz-, Blind- und Fehlleistung untergliedert. Das Ziel besteht in der Maximierung der Nutz- und Stützleistung auf der einen Seite sowie in der Minimierung bzw. Vermeidung der Blind- und Fehlleistung und deren Ursachen auf der anderen Seite.
3. Nach der Analyse des Wertes und der Eliminierung nicht-wertschöpfender Tasks setzt das Prinzip des Flow (<engl.> für Fluss) die kontinuierliche Flussorientierung der wertschöpfenden Prozessschritte um. Die Optimierung der Prozesse fördert die Möglichkeit des schnellen Wechsels zu beliebigen Varianten bzw. Konfigurationen eines Produkts, um die Anforderungen der Kunden schneller und flexibler, bei geringeren Kosten und einer niedrigeren Fehlerrate zu erfüllen.
4. Die Flussorientierung der Leistungserstellung bildet die Grundlage zum Einsatz des Pull-Prinzips. Hinsichtlich eines real vorhandenen Bedarfs werden nur direkt nachgefragte Ergebnistypen produziert bzw. Anforderungen erfüllt und zu einem vereinbarten Zeitpunkt bereitgestellt.
5. Die gegenseitige Stimulation der bisher beschriebenen vier Prinzipien führt im Rahmen des Prinzips der Perfektion zu einer kontinuierlichen Optimierung des Prozessflusses, wodurch die Annäherung an die Perfektion (stufenweise) realisierbar ist. Verbesserungen können kontinuierlich und inkrementell (Stichwort: Kaizen) oder radikal und sprunghaft (Stichwort: Kaikaku) sein. Die schnelle Identifikation von Verbesserungsmöglichkeiten bedarf einer hohen Transparenz im gesamten Unternehmen. Zu diesem Zweck müssen die erreichten Qualitätsniveaus abgesichert werden, d.h. adäquate Methoden, Modelle, Techniken und Werkzeuge festgelegt und im Rahmen standardisierter Arbeitsabläufe unterstützend eingesetzt werden.

Im Gegensatz zu konkreten, in der Praxis anwendbaren Methoden, welche die Prinzipien in bestimmten Situationen anwenden, ändern sich Prinzipien über die Zeit nicht. Es ist elementar, die Prinzipien zu verstehen, um adäquate Methoden, Modelle, Techniken und Werkzeuge bereitstellen und anwenden zu können.[16]

In der Softwareentwicklung wurde die Anwendung der Prinzipien unter dem Begriff „Lean Development“ (<engl.> für Leichtgewichtige Entwicklung) bekannt. Der Begriff wurde durch das gleichnamige Buch von Mary und Tom Poppendieck[17] ab dem Jahr 2003 populär. Ausgehend von den fünf Prinzipien des Lean Thinking lassen sich die Gemeinsamkeiten von Lean Production, Lean Development und Lean Quality Management ableiten, die in der Tab. 1 gegenübergestellt sind.

Abbildung in dieser Leseprobe nicht enthalten

[Tab. 1: Gemeinsamkeiten zwischen Lean Production, Lean Development und Lean Quality Management (angepasste Darstellung)[18] ]

- Tab. 1: Ausgehend von den fünf Prinzipien des Lean Thinking (siehe oben) lassen sich die Gemeinsamkeiten von Lean Production, Lean Development und Lean Quality Management ableiten.

Ein auf Lean Thinking fokussierter Projektmanager stellt den Mehrwert eines Projekts in den Vordergrund. Der Mehrwert kann in Bezug auf Produkte (materielle Werte als Projektergebnis) und Dienstleistungen (immaterielle Werte als Projektergebnis) generiert werden (ein Wert ist ein vom Kunden gewünschtes Produkt, eine gewünschte Dienstleistung oder ein gewünschter Zustand). In anderen Worten heißt das, dass im Projektkontext der Begriff „Wert“ in Abhängigkeit des Inhalts und Umfangs sowie des Projektverlaufs definiert wird. Ein Projekt lässt sich nur rechtfertigen, wenn es erforderlich ist, einen definierten Mehrwert, d.h. einen monetären geschäftlichen Nutzen (Nutzwert) zu schaffen. Da der Nutzwert eines Projekts häufig erst vollständig realisiert werden kann, nachdem das Projekt bereits abgeschlossen ist, laufen Projekte Gefahr, sich ausschließlich auf die Lieferung des Outputs zu konzentrieren. Die Verbindung zwischen dem Output und dem Nutzwert eines Projekts muss im Business Case klar definiert und für alle Akteure deutlich erkennbar sein, da es sonst geschehen kann, dass der eigentliche Zweck des Projekts aus den Augen verloren wird. Die Sicht des Unternehmens ist in diesem Zusammenhang klar: Das Projekt ist nur von Nutzen, wenn es greifbare Ergebnisse liefert, d.h. ein valider Business Case vorliegt. Lean Thinking stellt sicher, dass jede Mehrwertstufe (Entwicklung des Business Case, Planung der Projektergebnisse, Erstellung der Produkte, Realisierung des Mehrwerts), jeder Task oder jede Entscheidung in einem direkten Bezug zum Projektergebnis steht und somit zum geplanten monetären geschäftlichen Nutzen (Nutzwert) beiträgt. Deshalb sollten die Prinzipien des Lean Thinking auf das gesamte Projekt, d.h. das Projektmanagement, die Entwicklung und den Test angewendet werden. Es ist somit ein wichtiger Task des Projektmanagers der Verschwendung vorzubeugen, d.h. die Identifikation und Beseitigung jeglicher Form von Verschwendung aus dem Projekt um den höchstmöglichen Nutzwert zu generieren. Wenn bspw. ein Feature keinen Nutzwert aufweist, wird es entfernt. Ein Projekt, das dem Konzept des Lean Thinking nicht entspricht:

– ist unnötig,
– wird zu spät, mit überzogenem Budget oder im falschen Umfang (Qualität, Umfang an Features und Quantität) fertiggestellt,
– kann den angestrebten Nutzwert nicht erzielen.

In vielen Projektschritten kann die Verschwendung in der Art reduziert werden, dass bspw. die Kunden optimal in das Projekt einbezogen werden oder die Planung und Erstellung der Produkte optimiert wird. Um jedoch wirklich leichtgewichtig zu sein, muss das Projektmanagement die Organisation, Verwaltung und Überwachung von Akteuren, Prozessen und Techniken, die in einem Projekt zusammenwirken, koordinieren und in robusten Geschäftsprozessen zusammenführen, um letztendlich den Nutzwert des Projektergebnisses zu gewährleisten. Dem Teilbereich „Qualitätsmanagement“ kommt dabei die Aufgabe zu sicherzustellen, dass das Projekt im geplanten Umfang (Qualität, Umfang an Features und Quantität) geliefert wird. Ein Projekt- bzw. Testmanager der das Konzept des Lean Thinking bzw. einen iterativ-inkrementellen Ansatz verfolgt, kann dazu die verbreiteten und bewährten, leichtgewichtigen Methoden, Modelle, Techniken und Werkzeuge nutzen.

In Projekten stellt häufig der Umfang (Qualität, Umfang an Features und Quantität) die Variable zur Steuerung dar, um die zeitlichen Vorgaben einzuhalten. Dabei sind die Qualität und der Umfang an Features die Größen, mittels derer insb. bei zeitlichem Verzug in Projekten vorzugsweise eine Anpassung vorgenommen wird. Dies ist natürlich ein Ansatz ohne Nachhaltigkeit.

Abbildung in dieser Leseprobe nicht enthalten

[Abb. 2: Leichtgewichtige Projekte schätzen den möglichen Umfang (Qualität, Umfang an Features und Quantität) bei gegebenen Ressourcen in gegebener Zeit (angepasste Darstellung)[19] ]

- Abb. 2: Leichtgewichtiges Vorgehen bedeutet, sich vom sogenannten „eisernen Dreieck“ zu lösen und stattdessen die erreichbaren Projektergebnisse davon abhängig zu machen, was bei festen Terminen, Kosten und definierter Qualität, definiertem Umfang an Features und definierter Quantität machbar ist.

Konsequent umgesetzt, lässt sich Lean Thinking als eine Denkhaltung beschreiben, die alles am Nutzwert für den Kunden ausrichtet. Dies beginnt bei der Beziehungsgestaltung zwischen der Fachseite und dem Projekt. Wo früher ein starres Verhalten vorlag, hält in einem leichtgewichtigen Umfeld eine auf Flexibilität beruhende Beziehung Einzug. Die Akteure versuchen weniger, sich abzusichern. Sie arbeiten vielmehr daran, sich wechselseitig immer besser einschätzen zu lernen. Für die Fachseite bedeutet dies, ein Verständnis für Möglichkeiten der Entwicklungsmethode, der eingesetzten Techniken und der Technologie zu entwickeln. Für die Entwicklung bedeutet dies, sich so tief in die fachlichen Abläufe und Bedürfnisse einzuarbeiten, dass sie ein Gefühl dafür bekommt, was für die Fachseite des Kunden wirklich wichtig ist und was nicht.

Die Teams werden in einem leichtgewichtigen Umfeld bedarfsorientiert anstatt nach fachlichen Disziplinen wie Entwicklung, Test und Dokumentation organisiert. Bedarfsorientierte Teams reden möglichst direkt mit den jeweiligen Kunden. Sie sind so aufgestellt, dass sie ein Ergebnis mit direktem Nutzwert für den Kunden produzieren. In Projekten bedeutet dies, dass Analytiker, Architekten, Designer, Entwickler und Tester ein Team bilden. Das Vorgehen setzt insb. auf kurze Durchlaufzeiten. Ein Entwicklungsprojekt das mittels leichtgewichtiger Prinzipien arbeitet produziert regelmäßig (typischerweise nach zwei bis acht Wochen) lauffähige, qualitätsgesicherte Produkte, die an den Kunden ausgeliefert werden. Dies ermöglicht ein Rapid Feedback (<engl.> für zeitnahe Rückmeldung), ein kontinuierliches Lernen und eine ständige Verbesserung der Ergebnisse. Das Vorgehen stellt somit folgende Perspektiven in den Vordergrund.

– Kurze Iterationen (Zyklen). Um möglichst häufig Feedback der Benutzer zur aktuellen Version des Produkts zu erhalten, werden kurze Iterationszyklen von wenigen Wochen oder Monaten angestrebt.
– Orientierung am Nutzwert für den Kunden: Die während einer Iteration umzusetzenden neuen Features stellen aus der Sicht des Kunden bzw. Benutzers einen erkennbaren Nutzwert dar.
– Adaptive Zeitplanung: Die Zeitplanung erfolgt nicht für das Gesamtprodukt, sondern bezieht sich nur auf einzelne Features. Sie orientiert sich an der sogenannten „Velocity“ (<engl.> für Entwicklungs geschwindigkeit) des Teams in vorangegangenen Iterationen.
– Teamorientierung: Die Vorteile erfolgreicher Teamarbeit, hohe Motivation der Teammitglieder, gezieltere Nutzung von individuellen Stärken, stabilere Zeitplanung bei krankheitsbedingten Ausfällen, werden gezielt genutzt.

Statt Entscheidungen zentral zu treffen, setzt das Projektmanagement alles daran, dass jedes Teammitglied weiß, welche Ziele der Kunde mit dem Projekt verfolgt. Damit befähigt das Projektmanagement jeden Einzelnen, im Sinne dieser Ziele zu entscheiden – und entlastet sich von der Bürde, alles steuern und kontrollieren zu müssen. Wenn sich Projektmanager diese Grundprinzipien zu Nutze machen, setzt leichtgewichtiges Vorgehen das gesamte Potential des Projekts im Sinne der Ziele des Kunden frei. Ein Schwerpunkt liegt deshalb darauf, hierfür die erforderlichen Kommunikationsmöglichkeiten einzurichten.

Überflüssiges eliminieren: Um Überflüssiges (<engl.> Waste) eliminieren zu können, ist der erste Schritt, das Überflüssige lokalisieren und identifizieren zu können. Dazu muss bekannt sein, was den eigentlichen Nutzwert ausmacht. Alle Tasks, die keinen Nutzwert für den Kunden mit sich bringen, sind überflüssig. Oft ist bspw. halbfertige Arbeit Verschwendung. Auch Anforderungen können zu unnützem Aufwand werden. Werden Anforderungen bspw. lange vor der Umsetzung erfasst, werden sie sich bis zur Umsetzung ändern. Der anfangs betriebene Aufwand ist verschwendet. Die größten Verschwendungen können in folgende Bereiche unterteilt werden:[20]

– Unfertige Arbeit: Unfertige Arbeit kann die Form von Spezifikationen und anderen Ergebnistypen vorliegen, zu denen es keinen Quelltext gibt oder den Quelltext selbst betreffen. Nur „fertiger“ Quelltext hat tatsächlich einen Nutzwert! Ferner hat nicht mit dem zentralen Repository synchronisierter Quelltext keinen großen Nutzwert: Verschiedene Entwicklungszweige (<engl.> Branches) werden parallel entwickelt, oder der Entwickler führt seine Änderungen nicht regelmäßig dem zentralen Repository zu. Je länger der Quelltext nicht synchronisiert wird, desto schwieriger ist die Synchronisierung. Weiter ist nicht getesteter Quelltext überflüssig: Nur getesteter und integrierter Quelltext steigert den Nutzwert. Quelltext soll direkt bei der Entwicklung getestet werden, nicht in einem späteren Schritt. Quelltext, der dem Kunden ungetestet bereitgestellt wird, ist nutzlos.
– Überflüssige Features: Lean-Projekte zeichnen sich dadurch aus, dass nur das Feature entwickelt wird, das zu einem bestimmten Zeitpunkt benötigt wird und Nutzwert schafft. Features auf Vorrat zu entwickeln schafft keinen Nutzwert, sondern steigert nur die Komplexität und Fehleranfälligkeit. Hält man sich vor Augen, dass gewöhnlich nur rd. 20 % der Features eines Produkts (häufig) genutzt werden, kann bei nicht (zwingend) benötigten aber entwickelten Features ebenfalls von einer Verschwendung gesprochen werden. Die überflüssigen Features werden mitgeschleift, erhöhen die Komplexität des Produkts unnötig, verursachen Fehler, müssen gewartet werden usw.
– Erneutes Lernen: Sich erneut in Situationen hineinzuversetzen und sich Erkenntnisse erneut anzueignen, ist eine große Verschwendung. Das betrifft den Kunden, der eine Entscheidung möglicherweise bereits vor langer Zeit gefällt hat und nun nochmal vor ihr steht. Es betrifft genauso interne Entscheider und faktisch jeden Entwickler, der sich etwas aneignen muss oder sich in einen Sachverhalt neu einarbeiten muss. Verschwenderisch ist es auch, wenn Tasks den falschen Akteuren aufgetragen oder qualifizierte Akteure nicht gefragt und gehört werden. Lean-Projekte verhindern das durch ihren gemeinschaftlichen, vorausschauenden Umgang mit den Tasks.
– Übergaben: Unnötige Übergaben sind Verschwendung von Wissen. Der Akteur, an den etwas übergeben wird, wird durch die Übergabe nie die Erkenntnisse und Erfahrungen des Übergebenden erhalten. Nur Entwickler z.B., die wirklich an einem speziellen Quelltextabschnitt gearbeitet haben, besitzen 100 % Wissen über diese Passage. Gibt man das Wissen mündlich an jemanden weiter, der wiederum selbst das Wissen weitergibt, ist das Wissen beim endgültigen Empfänger faktisch auf null reduziert.
– Taskwechsel: Lean-Projekte konzentrieren sich auf einen Task zu einer Zeit. Ein Akteur arbeitet immer nur an einem Task auf einmal. Es wird nicht gleichzeitig an mehreren Tasks oder gar mehreren Projekten gearbeitet. Eine Abarbeitung von mehreren Tasks gleichzeitig dauert durch die Kontextwechsel länger als eine lineare Abarbeitung. Eine Ausnahme kann sein, wenn es bei der Abarbeitung eines Tasks zu Wartezeiten kommt und der Akteur auf den zweiten Task wechseln kann. In der Praxis zeugt das allerdings davon, dass der Task (welcher die Wartezeit verursacht) zu groß ist. Er könnte in mehrere kleinere Tasks unterteilt werden.
– Verzögerungen: Jede Art von Verzögerung mindert den Nutzwert und ist Verschwendung. Ein Team arbeitet räumlich eng zusammen und tauscht sich kontinuierlich aus. Auf diese Weise werden kontinuierlich Entscheidungen gefällt, ohne dass es zu Verzögerungen kommt. Jeder im Team kann Entscheidungen fällen. Innerhalb des Teams existiert kein Flaschenhals, welcher das Tempo vermindert (z.B. ein disziplinarischer Vorgesetzter, der bei allen Entscheidungen des Teams mitreden will). Ein weiteres Beispiel für Verschwendung liegt bei einer verzögerten Integration vor.
– Defekte: Defekte werden nicht nur gefunden, sie werden durch umfangreiches Testen verhindert. Unit Tests (<engl.> für Komponententests) und Acceptance Tests (<engl.> für Akzeptanztests) sind Spezifikationen und treiben die eigentliche Entwicklung vor sich her. Mit einem Test-First-Ansatz und häufigen Integrationen werden gegen Ende des Projekts keine Fehler mehr gefunden. Konventionelle Projekte haben gegen Ende die meisten Probleme und Fehler, leichtgewichtige Projekte haben gegen Ende ein lauffähiges, qualitätsgesichertes Produkt.
– Abfolge: Ein weiterer Fall von Verschwendung sind suboptimale Abfolgen, wie z.B. eine Testphase nach Abschluss der eigentlichen Entwicklung. Zum einen wird der nicht unwesentliche Beitrag von Tests als treibender Kraft, welche die Architektur, den Entwurf, den Quelltext, die Benutzbarkeit usw. verbessert, nicht realisiert. Zum anderen führt die Durchführung von Tests nach der Entwicklung zu einem weiteren Zeitbedarf vor der Lieferung des Produkts an den Kunden. Eine derartige Praktik führt dabei zu kostspieligen Nacharbeiten und in der Konsequenz letztendlich zu einer langsameren sogenannten „Velocity“ (<engl.> für Entwicklungs geschwindigkeit).

Qualität implizit machen: Befassen sich nur bestimmte Akteure mit qualitätssichernden Tasks, ist das ein sicheres Zeichen dafür, dass die Qualität nicht ausreichend im Gesamtprozess verankert ist. Sie wurde nicht implizit gemacht.

– Inspektionen im Quelltext werden z.B. besser nicht nach der Lokalisierung von Fehlern durchgeführt, sondern bereits vorher, um genau diese Fehler zu verhindern. Wenn das in größeren Abständen nicht immer gelingt, muss nach jedem noch so kleinen Schritt inspiziert werden. Auf diesem Weg werden Defekte zeitnah zu ihrem Auftreten identifiziert und können direkt behoben werden. Beim Auftreten von Fehlern wird zunächst kein neues Feature erstellt, sondern es wird die gesamte Linie gestoppt (siehe oben).

- In einer extremen Form sind sogar Trackingsysteme, welche der Verwaltung von Fehlern dienen, überflüssig. Jeder Fehler wird sofort behoben und somit ist ein Trackingsystem in diesem Sinne Verschwendung.
- Daneben erspart sich das Projekt zu einem späteren Zeitpunkt ein unproduktives, langes Suchen von Fehlern und Debugging. Das Durchlaufen von Quelltext, um Fehler zu finden, ist insb. in späten Iterationen extrem zeit- und kostenintensiv.

– Werden viele Fehler spät gefunden, so lässt das häufig auf einen Fehler im Gesamtprozess schließen. Der Entwicklungs- und Testprozess scheint falsch abzulaufen. Es wurden offenbar keine Tests geschrieben, welche die spät aufgetretenen Fehler früher hätten finden bzw. ganz vermeiden können. Test-driven Development (<engl.> für Testgetriebene Entwicklung) und Continuous Integration (<engl.> für Kontinuierliche Integration) sorgen von Anfang an dafür, dass es richtig gemacht wird und die Verschwendung minimiert wird. Entwickler schreiben Unit Tests und Akzeptanztests, bevor sie den eigentlichen fachlichen Quelltext schreiben. Nachdem der neue Quelltext in das Produkt integriert ist, werden alle Tests, auch die aus früheren Iterationen, durchlaufen. Wird ein Fehler festgestellt, wird erst der existente, fehlerhafte Quelltext angepasst, bevor ein weiteres Feature entwickelt wird. Ist der Quelltext fehlerfrei, werden nach dem gleichen Prinzip so lange weitere Features ergänzt, bis der Nutzen die Kosten nicht mehr rechtfertigt.

Wissen generieren: Die Erstellung von Produkten ist ein Wissen schaffender Prozess. Konstant Änderungen zu akzeptieren bedeutet, sich veränderten Situationen zu stellen, diese zeitnah zu verstehen und darauf einzugehen. Es ist notwendig, dem Kunden früh einige wenige Features bereitzustellen um Feedback zu erhalten und eine Auswertung zu ermöglichen. Nur so kann gelernt und neues Wissen über Anforderungen, Methoden, Techniken und Prozesse generiert werden. Um Hintergrundwissen zu sammeln sind ferner tägliche Builds und Rapid Feedback aus den Integrationstests notwendig. Der gesamte Prozess muss kontinuierlich überwacht, überdacht und optimiert werden. Probleme sind ganz normal, sie müssen aktiv angegangen und die ursprüngliche Ursache lokalisiert werden. Retrospektiven helfen dabei, Wissen zu erlangen und für zukünftige Iterationen anwendbar zu machen.

– Vorhersagen, die lange im Voraus erstellt wurden, sind nicht aussagekräftig. Ist das Produkt komplex, die vorherzusehende Zeit zu weit in der Zukunft und existieren zu viele unsichere Details in einer komplexen Umgebung, können keine verlässlichen Aussagen getroffen werden. Lean Development kehrt ab von Vorhersagen und reduziert stattdessen die Antwortzeit, um auf neue Erkenntnisse und Rahmenbedingungen direkt eingehen zu können und aktuelles Wissen zu schaffen.

Spätmöglichste Entscheidungen: Es existiert immer, insb. auch in Entwicklungsprojekten, ein Zeithorizont, innerhalb dessen eine Entscheidung getroffen werden muss. Wird die nötige Entscheidung erst im letzten Augenblick gefällt, ist der Entscheider auf dem aktuellsten Wissensstand (<engl.> Level of Knowledge). Der letzte Moment ist der letzte zu verantwortende Moment, bevor die Entscheidung zu spät gefallen ist. Für die Entwicklung bedeutet dies, in frühen Iterationen keine unnötigen Entscheidungen zu treffen, die nicht mehr umkehrbar sind. Wird zu Beginn eines Projekts bspw. eine Architektur erstellt, so wird der Architekt sich nicht gleich anfangs unwiderruflich auf eine bestimmte starre Architektur fixieren. Er wird die Architektur flexibel halten bis zu dem Moment, in dem konkrete Anforderungen eine Festlegung erfordern. Planung heißt dabei, die Architektur flexibel zu halten und keine einschränkenden Entscheidungen zu treffen.

Liefern so schnell es geht: Ein Produkt (in Inkrementen) schnell zu liefern hat zahlreiche Vorteile. Allen voran wird der Kunde zufrieden gestellt. Der Kunde kann das Produkt bereits in der jeweiligen Ausbaustufe einsetzen. Auch frühes Bereitstellen in der Umgebung für Integration oder Test ist für den Kunden sehr hilfreich. Nach einem täglichen Deployment (<engl.> für Bereitstellung, Verteilung bzw. Installation) kann der Kunde zeitnah und sehr „nah an der Entwicklung“ Feedback geben und Verbesserungsvorschläge machen bzw. Änderungen einbringen. Neue Anforderungen werden in kommenden Iterationen umgesetzt und sind wiederum schnell verfügbar. Wenn der Benutzer eine umgesetzte Anforderung am Rechner sieht, fallen ihm möglicherweise noch Punkte ein, die einer Verbesserung bzw. Änderung bedürfen. So können fachliche Defekte früher identifiziert werden.

Akteure respektieren: Alle Teammitglieder müssen das volle Vertrauen und den Respekt des Projekt- bzw. Teammanagers genießen. Zum Beispiel gibt ein Teammanager einem hochqualifizierten Entwickler einen Task. Nach einer Woche ist der Task fast gelöst, aber aufgrund ihrer Komplexität ergeben sich weitere Tasks, welche vorher nicht absehbar waren. Der Teammanager versteht die bei der Umsetzung entstandenen Schwierigkeiten auch nicht im Detail, da er ja ganz andere Aufgaben als der Entwickler hat. Weil er mit dem Mehraufwand (im Vergleich zu seiner ursprünglichen Abschätzung) nicht einverstanden ist, fragt er den Entwickler nicht nach den Gründen, sondern setzt ihn unter Druck. Er fragt ihn, warum die Arbeiten so „lange“ dauern. Solche Aussagen sind häufig polemisch und suggerieren dem Entwickler, seine Arbeit sei nicht gut genug. Dies ist ein Negativbeispiel und darf nicht vorkommen.

– Häufig gibt es verschiedene Lösungen für ein Problem. Es kann also davon ausgegangen werden, dass sich der Entwickler bei dem von ihm eingeschlagenen Weg etwas gedacht hat. Kann darüber nicht sachlich diskutiert werden, muss sich der Entwickler ständig rechtfertigen (offensichtlich mangelt es an Vertrauen). Der Entwickler fühlt sich als „nicht respektiert“. Negative Folgen derartiger Szenarien sind das Einstellen von Eigeninitiative, Demotivation und ein zeitlich verzögerter Entwicklungsprozess. Werden die Akteure hingegen offensichtlich respektiert, werden Persönlichkeiten gefördert, die sich Problemen stellen (aktive, hochmotivierte Akteure, gute Führungspersönlichkeiten, die exzellente Produkte erstellen). Respekt bedeutet aber auch, dass die Akteure sich weitestgehend selbst organisieren und selbstständig ein gegebenes Ziel erreichen können. Nur frei denkende Akteure finden in einem Prozess Optimierungspotenzial, das es ja immer gibt. Den Akteuren Freiraum zu geben, Fehler zu tolerieren, zu erlauben, Entscheidungen selbst zu treffen, das alles zeugt von Respekt.
– Respekt hat schließlich auch etwas mit Expertise zu tun. Respekt fördert sogenanntes „Knowledge Buildung“ (<engl.> für Wissensaufbau). Möchte ein Unternehmen oder das Projekt gegen die Konkurrenz bestehen, müssen die Akteure hoch qualifiziert bzw. motiviert sein, neues Wissen aufzubauen. Unternehmen benötigen Wissen, das sie von Wettbewerbern unterscheidet. Wird Wissen nur gekauft, so kann es jedes andere Unternehmen auch kaufen.

Ganzheitlich optimieren: Lean Development fokussiert die Optimierung von Entwicklungsprozessen. Im gesamten Entwicklungsprozess muss die Atmosphäre existieren, dass immer noch etwas verbessert werden kann. (Ständige Verbesserungen sind auch unter dem Begriff „Kaizen“ bekannt.) Lean Development setzt sich dabei immer zum Ziel, ganzheitlich zu optimieren, d.h. es existieren keine Mikrooptimierungen.

– Damit die Integration von Lean Thinking in den Entwicklungs- bzw. Testprozess erfolgreich ist, müssen verschiedene (Management-)Themenbereiche aufgearbeitet werden. Dazu gehören insb. die Bereiche Programm- und Projektmanagement, Organisation und Struktur sowie Methoden, Modelle, Techniken und Werkzeuge.

Bei Lean Development geht es im Kern um Rapid-Feedback-Mechanismen sowie iteratives (zyklisches) und inkrementelles Vorgehen auf möglichst allen Ebenen. Leichtgewichtige Methoden können lediglich die Entwicklungs- und Testprozesse, aber auch das Unternehmen als Ganzes umfassen. Lean Development zeichnet sich durch einen geringen bürokratischen Aufwand aus und basiert auf wenigen flexiblen Regeln. Den meisten leichtgewichtigen Methoden liegt zu Grunde, dass sie versuchen, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den konventionellen Methoden der Fall ist. Ein Modell wird als Referenzmodell bezeichnet, wenn es zur Unterstützung der Konstruktion anderer unternehmungsspezifischer Modelle dient. Referenzmodelle formulieren Sollempfehlungen für eine Klasse von Unternehmungen. Insofern geht der Konstruktion spezifischer Modelle immer die Konstruktion eines generischen Referenzmodells voraus.[21] Mit einem Referenzmodell erhält die Unternehmung eine Ausgangslösung für ihre Geschäftsprozessgestaltung, an der sie sich bezüglich Detaillierungsgrad der Modellierung und fachlichem Inhalt bei der Beschreibung eines Wertebereichs orientieren kann. Die Referenzmodelle beinhalten Dokumentationen über Prozesswissen, das bei der Modellierung genutzt werden kann. Sie können nach dem Konzept von Scheer[22] aus Anwendungsfällen oder theoretischen Überlegungen entwickelt werden. Es wird dabei zwischen Vorgehensmodellen, etwa zur Durchführung eines (Re-)Engineering-Projekts, und Fachmodellen, etwa für die Auftragsabwicklung oder Produkteinführung, unterschieden. Vorgehensmodelle stellen eine besondere Art von Referenzmodellen dar. Generell verstehen wir unter einem Vorgehensmodell eine modellhafte, abstrahierende Beschreibung von Vorgehensweisen, Richtlinien oder Prozessen, die für einen abgegrenzten Problembereich Gültigkeit besitzen.[23] Modelle gehen häufig mit Methoden einher und beschreiben neben den zugehörigen Prozessen den Einsatz von Techniken und Werkzeugen (Stichwort: Rational Unified Process [RUP]).

2.0 Methoden

Nach der Freigabe des Projekts durch den Lenkungsausschuss beginnen der Projektmanager und das Projektmanagementteam mit der Durchführung des Projekts. Allzu oft startet ein Projekt jedoch mehr oder weniger unkoordiniert. Das Ergebnis einer unkoordinierten bzw. frühzeitigen und / oder nicht autorisierten „Weichenstellung“ durch einzelne Teammitglieder ist zum einen eine weniger effiziente Projektdurchführung und zum anderen eine weniger effektive Zielerreichung in Bezug auf den Business Case. Ggf. müssen die getroffenen Fehlentscheidungen im Laufe des Projekts aufwändig korrigiert werden. Deshalb ist es ein Task (<engl.> für Arbeitsauftrag) des Projektmanagers in einem frühen Projektstadium unter anderem die Akteure zu „bremsen“, d.h. eine robuste Planung der Mehrwertstufen durchzuführen und für einen geordneten Projektstart zu sorgen (Stichwort: Kick-off). Ein Projekt durchläuft einen Lebenszyklus, der sich vom Start- bis zum Endpunkt des Projekts durch vier generische sogenannte „Mehrwertstufen“ charakterisieren lässt. Jede Stufe bzw. Phase, die wiederum als eigenes kleines Projekt verstanden werden kann, hat ein bestimmtes Ziel und umfasst wiederum einen eigenen Start- und Endpunkt.[24]

1. Entwicklung des Business Case: Der Startpunkt eines Projekts ist in der Regel eine Notwendigkeit oder eine Idee innerhalb des Unternehmens, z.B. eine gesetzliche Vorgabe die es umzusetzen gilt oder eine Geschäftsidee, d.h. eine Veränderung des Status-quo. In dieser Phase sind die Projektmanagementprozesse darauf ausgerichtet festzustellen, „ob“ das Projekt das „Richtige“ erreichen kann bzw. ein valider Business Case vorliegt.
2. Planung der Projektergebnisse: In dieser Phase geht es um die Planung der Projektmanagementprozesse zur Durchführung der Umsetzungsphasen und die Planung der Umsetzungsphasen selbst, d.h. darum festzulegen, „wie“ das Projekt das „Richtige“ liefern wird.
3. Erstellung der Ergebnistypen: In dieser Phase erfolgt die effektive und effiziente Erstellung der geplanten Projektergebnisse. Das Projekt „richtig“ umzusetzen bedeutet, dass sich die Projektmanagementprozesse auf die kontrollierte Erstellung der Ergebnistypen konzentrieren (Stichwort: Managing Product Delivery). Die Phase beinhaltet neben dem operativen Projektgeschäft unter anderem die Maßnahmen zur kontinuierlichen Verbesserung sowohl der Projektprozesse, als auch der Leistungserstellung (Stichwort: Controlled Environments).
4. Realisierung des Mehrwerts: Die letzte Phase beinhaltet die Integration der Projektergebnisse in das Tagesgeschäft, so dass diese zu einem Teil der normalen Geschäftsprozesse werden.

Die Planung der Mehrwertstufen wird im sogenannten „Projektleitdokument“ (Stichwort: Project Delivery Plan [PDP]) festgehalten. Das Projektleitdokument beinhaltet die Darstellung der wichtigsten Projektphasen und des geplanten Zeitrahmens, d.h. die Meilensteine ​​und den identifizierten kritischen Pfad. Um zu verstehen, warum ein Projektleitdokument notwendig ist, muss man verstehen, warum Projektmanagement notwendig ist. Die Planung, Kontrolle und Steuerung (Koordination) des Projekts zielt darauf ab, den Erfolg zu maximieren, indem alle Bereiche die mit Unsicherheitsfaktoren belastet sind im Laufe des Projekts explizit gemanagt werden. Die zu koordinierenden Themenbereiche werden in den folgenden Managementergebnistypen angesprochen, die jeweils Teil des Projektleitdokuments sind.[25]

– Geschäftsplan (<engl.> Business Plan): Spricht den Nutzwert und organisatorischen Wandel an. Der Geschäftsplan besteht aus mehreren Teilplänen, darunter dem Beschaffungs-, Produktions-, Personal-, Forschungs-, Vertriebs- und Marketingplan. Hinzu kommt der Finanzplan, der eine Schätzung der notwendigen finanziellen und personellen Ressourcen (Kosten) und der erwarteten Umsatzerlöse enthält, um die Wirtschaftlichkeit der Investition in ein Projekt beurteilen zu können.
– Projektlösungsansatz (<engl.> Project Set-up Plan): Spricht die gewählte Methode sowie die Modelle, Techniken und Werkzeuge mit welchen das Projektergebnis geliefert werden soll an. Der Projektlösungsansatz spricht dabei die Rahmenbedingungen für die Projektdurchführung und die Einsatzbedingungen des zu erstellenden Produkts an. Er bezieht sich auf die im Business Case gewählte Handlungsoption. Der Projektlösungsansatz gibt z.B. bei der Entwicklung an, welche Komponenten selbst entwickelt und welche zugekauft werden. Bei einem organisationalen Entwicklungsprojekt definiert der Lösungsansatz z.B., ob das Projekt in allen Abteilungen gleichzeitig oder in einer Abteilung nach der anderen durchgeführt wird. Der Projektlösungsansatz ist jedoch kein Projektplan, sondern definiert lediglich die grundlegende Herangehensweise.
– Projektkontrollplan (<engl.> Project Control Plan): Spricht die Projektrisiken, Verträge, Projektkontrolle und -steuerung (Projektkoordination) sowie Projektreviews an. Der Projektkontrollplan legt fest, wann welche Resultate vorliegen müssen, wann Kontrollen durchgeführt werden (z.B. periodische Statusmeetings bzw. Statusberichte zu festgelegten Zeitpunkten) und wie steuernd eingegriffen werden kann bzw. soll. Er dient sowohl der internen, als auch der externen Kontrollplanung und fokussiert dabei zum einen die Projektdurchführung (die plan- und fachgerechte Durchführung des Projekts) und zum anderen die Produktgestaltung (das Projektergebnis, d.h. das neue Produkt).

Das Projektleitdokument ist ein speziell für die Abwicklung eines spezifischen Projekts entwickelter Managementergebnistyp. Ziel ist es sicherzustellen, dass die im Sinne eines Best-Practice-Ansatzes entwickelten, eigeführten und kommunizierten Vorschriften, Strategien, Methoden, Modelle, Techniken und Werkzeuge auf die Bedürfnisse des Projekts abgestimmt sind. Das Projektleitdokument:[26]

– definiert den Zweck und das Ziel des Projekts, beschreibt die Teamorganisation (Stichwort: Rollen).
– beinhaltet die Vorschriften, Strategien, Methoden, Modelle, Techniken und die Festlegung von Werkzeugen, die für die erfolgreiche Umsetzung bzw. den erfolgreichen Abschluss des Projekts erforderlich sind.
– dient dazu sicherzustellen, dass das Projektergebnis die geschäftlichen Anforderungen erfüllt (Stichwort: Business Case).
– ist wichtig für die Kommunikation des Teams und aller anderen Stakeholder.

Das Projektleitdokument ist ein „lebendiger“ Ergebnistyp, der in regelmäßigen Abständen aktualisiert wird. Es ist notwendig sicherzustellen, dass die entwickelten Vorschriften, Strategien, Methoden, Modelle, Techniken und Werkzeuge kontinuierlich überarbeitet und verfeinert werden, damit die Projektziele über den gesamten Projektverlauf hinweg auf den Nutzwert ausgerichtet bleiben. Der Nutzen eines Projekts ist nichts anderes als der (monetär bewertete) Beitrag dieses zur Wertschöpfung eines Unternehmens (wir sprechen vom Nutzwert eines Projekts). Als Möglichkeit zur Bestimmung des monetären geschäftlichen Nutzens (Nutzwerts) eines Projekts bietet sich an, die Frage zu beantworten, ob es lohnend ist, ein Projekt durchzuführen oder nicht. Es handelt sich hierbei um ein Ex-ante-Kalkül, das vor der Durchführung aufgestellt wird. Die Abschätzung des Nutzwerts geschieht einmal unter der Annahme, dass das Projekt nicht durchgeführt wird und einmal unter der Annahme, dass das Projekt durchgeführt wird. So lassen sich sowohl die Opportunitätskosten der verworfenen Alternative ermitteln, indem der Ertrag bzw. Gewinnerwartungswert einer Entscheidung vor der Durchführung mit dem nach der Durchführung verglichen wird, als auch der Nutzwert des Projekts quantifizieren, da die Differenz zwischen dem Gewinnerwartungswert des „Unternehmens mit dem Projekt“ und dem Gewinnerwartungswert des „Unternehmens ohne das Projekt“ letztendlich das Kosten-Nutzen-Verhältnis bei der Durchführung der Alternative zum Ausdruck bringt.[27]

Das initiale Projektleitdokument wird durch den Projektmanager etabliert, vor dem Projektstart durch den Lenkungsausschuss genehmigt und im Laufe des Projekts durch den Projektmanager und andere wichtige Stakeholder weiterentwickelt. Änderungen werden wiederum je nach Inhalt und Umfang (Stichwort: Management by Exception) durch den Lenkungsausschuss genehmigt. Das Projektleitdokument ist als Projekthandbuch zu verstehen, welches alle relevanten Managementergebnistypen des Projekts enthält, das Team bei der Entscheidungsfindung unterstützt und den Austausch von Wissen optimiert.

Nach der Genehmigung des Projekts durch den Lenkungsausschuss, sind der Projektmanager und die Akteure in die Lage versetzt bzw. berechtigt, mit der geordneten Projektdurchführung zu beginnen. Entscheidend ist jedoch, dass das Team den Vorgaben im Projektleitdokument folgt. Die Anwendung der darin enthaltenen Vorschriften, Strategien, Methoden, Modelle, Techniken und festgelegten Werkzeuge minimiert bzw. reduziert die Risiken und erhöht die Wahrscheinlichkeit eines erfolgreichen Projektabschlusses. Es gilt generell, Chaos in den einzelnen Phasen des Projektlebenszyklus zu verhindern. Chaos wird oft als „Verwirrung“ empfunden und die Symptome, die wir normalerweise sehen, können wie folgt klassifiziert werden:

– Projekte werden verspätet oder außerhalb des vereinbarten Verbrauchs an Ressourcen geliefert.
– Projekte werden nicht im vereinbarten Umfang (Qualität, Umfang an Features und Quantität) geliefert.
– Projekte genügen nicht den geschäftlichen Anforderungen (der erwartete Nutzwert kann nicht erreicht werden).

Messungen des Projektfortschritts dienen dazu, den Umfang an Abweichungen vom ursprünglichen Projektplan zu ermitteln. Wichtig ist, neben dem Umfang auch die Ursache einer Abweichung vom Projektplan festzustellen und eine Entscheidung zu treffen, ob eine korrigierende oder vorbeugende Maßnahme notwendig ist. Die Analyse einer Abweichung kann zusammen mit der Überprüfung der Fortschrittsberichte zu notwendigen Änderungen am Projektplan und zu weiteren Änderungsanträgen sowohl für andere Management-, als auch Expertenergebnistypen führen.

Der für die Durchführung, Kontrolle und Steuerung des Projekts verantwortliche Akteur ist der Projektmanager. Die Rolle des konventionellen Projektmanagers hat sich in den letzten Jahren zunehmend verändert. Projektmanagement beschränkt sich nicht mehr ausschließlich darauf sicherzustellen, dass das gewünschte Projektergebnis erreicht wird. In diesem Zusammenhang steht das sogenannte „Project Delivery Management“ für einen weiter gefassten Projektmanagementbegriff. Die folgende Liste enthält einen Überblick der von einem Projekt zu bearbeitenden Themenbereiche:

– Kommunikationsmanagement (<engl.> Communication Management): Umfasst die erforderlichen Prozesse um rechtzeitig und angemessen zu informieren, d.h. die Erzeugung, Sammlung, Verbreitung, Speicherung und ggf. spätere endgültige Löschung des für die Durchführung des Projekts notwendigen Hintergrundwissens zu gewährleisten.
– Führungskompetenz (<engl.> Managerial Competence): Stellt eine möglichst effektive Einbindung aller am Projekt beteiligten Stakeholder sicher. Die Mitarbeiterführung umfasst mehr als die Steuerung des Verhaltens und die Einflussnahme auf das Verhalten der Akteure im Tagesgeschäft. Die Mitarbeiterführung umfasst ebenfalls sowohl die Sicherstellung der Work-Life-Balance, als auch die Weiterbildung und Aufstiegsmöglichkeiten.
– Leitungskompetenz (<engl.> Leading Competence): Beinhaltet die Motivation, d.h. die Initiierung, Richtungsgebung und Aufrechterhaltung von Aktivitäten, die ein Team zum erfolgreichen Abschluss eines Projekts benötigt. Hierzu gehören die angemessene Delegation von Verantwortung und die Stärkung einzelner Teammitglieder.
– Zufriedenheitsmanagement (<engl.> Satisfaction Management): Misst durch einen Evaluierungsprozess zum einen die Zufriedenheit der Kunden mit dem Projektendprodukt. Zum anderen muss die Qualität der Teilprodukte über den Projektverlauf hinweg sichergestellt werden.
– Inhalts- und Umfangsmanagement (<engl.> Scope Management): Das Management des Leistungsumfangs umfasst in erster Linie die Definition und Steuerung dessen, „was“ und „was nicht“ zum Projektumfang gehört. Dies beinhaltet die erforderlichen Prozesse um sicherzustellen, dass das Projekt alle erforderlichen Arbeiten, und nur die erforderlichen Arbeiten, ausführt, damit das Projekt erfolgreich abgeschlossen werden kann.
– Erwartungsmanagement (<engl.> Expectation Management): Beinhaltet die Abstimmung mit den verschiedenen Stakeholdern um die Bedürfnisse und Erwartungen dieser zu erfüllen bzw. zu übertreffen. Der Projektmanager begleitet diesen Prozess über den gesamten Projektverlauf hinweg.
– Infrastrukturmanagement (<engl.> Infrastructure Management): Definiert alle notwendigen Komponenten der Infrastruktur die zur (informationellen) Absicherung der Akteure, der Prozesse, der Technologie und des Wissens notwendig sind. Dazu gehören Bereiche wie der Desktop Support, der Help Desk, die Netzwerk-, die Betriebs- und die Sicherheitspolitik.
– Risikomanagement (<engl.> Risk Management): Die Prozesse sowohl der Identifikation und Analyse, als auch der Reaktion auf Projektrisiken, so dass die Chance, dass ein Risiko auftritt sinkt und / oder seine Auswirkungen minimiert bzw. reduziert werden.
– Wissensmanagement (<engl.> Knowledge Management): Der Prozess der Erfassung, Speicherung und Indizierung des für die Durchführung des Projekts notwendigen Hintergrundwissens. Das Vorgehen umfasst Mechanismen, welche die Verteilung des Know-how und des Empirical Knowledge (<engl.> für Erfahrungswissen) unter den Stakeholdern fördern.
– Geschäftsprozessmanagement (<engl.> Business Process Management): Umfasst sowohl den Prozess der Bewertung und Gestaltung der Geschäftsbeziehungen, als auch der Struktur der Geschäftsprozesse zwischen dem Kunden und dem Lieferanten. Die Tasks umfassen die Beschreibung, wie das Geschäft strukturiert, organisiert und ausgeführt wird.
– Kostenmanagement (<engl.> Cost Management): Umfasst die Tasks, bei denen insb. die Kosten analysiert und zielgerichtet beeinflusst werden. Des Weiteren sollen die Prozesse des Kostenmanagements die Einhaltung des Budgets sicherstellen, d.h. das Kostenmanagement umfasst die erforderlichen Prozesse um sicherzustellen, dass das Projekt innerhalb des genehmigten Budgets abgeschlossen wird.
– Zeitmanagement (<engl.> Time Management): Die Prozesse um die termingerechte Fertigstellung des Projekts zu gewährleisten.
– Management der Kennzahlen (<engl.> Ratio Management): Die definierten Kennzahlen werden von der Planung, über die Ist-Analyse bis zum Ende der Umsetzungsphase erhoben und verglichen. Die Kennzahlen dienen der Erfassung von Indikatoren über Ressourcen (Betriebsmittel, Finanzmittel, Boden, Rohstoffe, Energie, Akteure und [Arbeits-]Zeit).
– Qualitätsmanagement (<engl.> Quality Management): Die Prozesse um sicherzustellen, dass das Projekt die Bedürfnisse, für die es entwickelt wurde, befriedigt.
– Beschaffungsmanagement (<engl.> Procurement Management): Die Prozesse um Waren und Dienstleistungen von außerhalb des Unternehmens zu beantragen und zu erwerben.
– Wertemanagement (<engl.> Value Management): Die Adressierung wertorientierter Ziele auf allen Managementebenen (strategisch, taktisch und operativ) und die Erarbeitung geeigneter Lösungen (Strukturen, Tasks und Verhalten) für das Projekt.

Die Koordination eines Projekts umfasst viel mehr als die Kontrolle und Steuerung der Projektleistung. Deshalb beinhaltet das „Project Delivery Management“ neben dem Management der sogenannten „harten Faktoren“, d.h. der greifbaren Elemente in einem Projekt (Zeit, Ressourcen, Umfang [Qualität, Umfang an Features und Quantität] und Risiken), auch das Management der sogenannten „weichen Faktoren“, d.h. die Verwaltung und Überwachung von Akteuren, Prozessen und Techniken, die in einem Projekt koordiniert werden müssen, um die Projektziele zu erreichen (Stichwort: Capability). Dem Teilbereich „Quality Delivery Management“ kommt dabei die Aufgabe zu sicherzustellen, dass das Projekt im geplanten Umfang (Qualität, Umfang an Features und Quantität) geliefert wird.

Noch bis Ende der 1990er-Jahre waren Projekte von Methoden geprägt, die großen Wert auf definierte Prozesse und umfangreiche Dokumentation legten. Diese Methoden wollten den Ablauf eines Projekts im Vorhinein detailliert planen und sich bei der anschließenden Umsetzung streng daran halten. Fast alle diese Methoden basieren auf dem klassischen Wasserfallmodell, das den Entwicklungsprozess in verschiedene Phasen unterteilt (Grobspezifikation, Feinspezifikation, Design, Umsetzung, Test und Lieferung), die typischerweise streng sequenziell durchlaufen werden. Dokumentation spielt insofern eine große Rolle, als die Ergebnisse einer Phase in der Regel gründlich dokumentiert werden und die Dokumentation als Input für die nächste Phase bereitgestellt wird. Typische Vertreter dieser Wasserfall-basierten Methoden sind:[28]

– Das allgemeine V-Modell, dessen Ursprünge ins Jahr 1979 zurückgehen, ist ein Vorgehensmodell zur Planung und Durchführung von Entwicklungsprojekten. Das allgemeine V-Modell erweitert das traditionelle Wasserfallmodell, indem es jeder der ursprünglichen Phasen eine Test- oder Abnahmephase gegenüberstellt. Während das allgemeine V-Modell durch relativ starre Prozesse gekennzeichnet ist, lässt die im Jahr 2005 in Deutschland für Projekte des Bundes und der Länder eingeführte Variante „V-Modell XT“ bereits eine gewisse Anpassung der Prozesse an spezifische Gegebenheiten zu.
– Das im Jahr 1986 erstmals vorgestellte Spiralmodell ist ein Vorgehensmodell, das ebenfalls auf dem Wasserfallmodell beruht, es aber bereits um die Idee der iterativ-inkrementellen Entwicklung erweitert. Es sieht vor, typische Phasen wie Analyse, Entwurf, Realisierung und Test immer wieder zu durchlaufen und sich so schrittweise dem Projektziel zu nähern.
– Der im Jahr 1998 von der Firma „IBM“ veröffentlichte sogenannte „Rational Unified Process“ (RUP) umfasst ein Vorgehensmodell, das zur Modellierung die sogenannte „Unified Modeling Language“ (UML) einsetzt. Auch der RUP weicht bereits deutlich vom klassischen Wasserfallmodell ab und empfiehlt stattdessen ein iterativ-inkrementelles Vorgehen.

Ebenso prägend für die 1990er-Jahre waren Bemühungen, durch die Verbesserung der zugrunde liegenden Prozesse die Qualität von Software zu erhöhen. Als Resultat dieser Bemühungen entstanden verschiedene Prozessframeworks, die zwar kein spezielles Verfahren vorschreiben, aber doch darauf abzielen, innerhalb eines bestimmten Rahmens verbindliche Prozesse zu definieren und diese im Projektverlauf einzuhalten. Zu den oben genannten Methoden sind diese Prozessframeworks in dem Sinne orthogonal, dass sie unterschiedliche Schwerpunkte setzen und sich mit den verschiedensten Methoden kombinieren lassen. Beispiele für bekannte Prozessframeworks sind:[29]

– Das sogenannte „Capability Maturity Model Integration“ (CMMI) ist ein Modell zur Beurteilung des Reifegrads sämtlicher Prozesse einer Organisation im Zusammenhang mit der Entwicklung und dem Betrieb von Produkten. Ziele sind die Definition, Planung, Implementierung und Qualitätssicherung dieser Prozesse. Das relativ starre ursprüngliche Modell (CMM) wurde im Jahr 2003 durch den flexibleren Nachfolger (CMMI) abgelöst.
– Die Normenreihe DIN EN ISO 9000ff legt Mindestanforderungen für die Qualitätssicherung fest. Die Normen beziehen sich auf Produktherstellung und Dienstleistungen generell und werden gelegentlich auch auf die Softwareentwicklung angewendet. Seit Mitte der 1990er-Jahre sind manche Organisationen bestrebt, sich in Bezug auf ihre Qualitätsstandards nach DIN EN ISO 9000 zertifizieren zu lassen.

Daneben haben sich im Laufe der Zeit eine Reihe leichtgewichtiger Methoden etabliert, die in ihrer konkreten Ausgestaltung unterschiedliche Akzente setzen und unterschiedlich verbreitet sind.[30]

– Eine der frühen leichtgewichtigen Methoden ist das sogenannte „Extreme Programming“ (<engl.> für Extremprogrammierung), häufig einfach auch mit der Abkürzung „XP“ bezeichnet. Seit dem Jahr 2000 hat die Methode einige Popularität erreicht. Sie basiert auf einer Reihe bewährter Praktiken, zu denen z.B. iterativ-inkrementeller Entwurf, „Test-driven Development“ (<engl.> für Testgetriebene Entwicklung) sowie Continuous Integration (<engl.> für Kontinuierliche Integration) gehören. Bekannt geworden ist XP vor allem für die Einführung des sogenannten „Pair Programming“ (<engl.> für Paarweise Programmierung).
– Scrum ist mittlerweile die bekannteste leichtgewichtige Methode, zumindest im deutschsprachigen Raum. Kennzeichen von Scrum ist ein iterativ-inkrementelles Vorgehen, das sich in regelmäßigen Iterationen, den sogenannten „Sprints“, ausdrückt. Darin werden jeweils Inkremente des Produkts entwickelt und ausgeliefert. Am Ende jeder Iteration steht unter anderem eine Retrospektive zur Überprüfung des eigenen Vorgehens.
– Eine weitere leichtgewichtige Methode ist Kanban, das seinen Ursprung in den Prinzipien des sogenannten „Lean Development“ hat. Kanban versucht, durch die Reduktion paralleler Arbeit den gesamten Fluss aller Projekttätigkeiten zu verbessern bzw. den Durchsatz zu erhöhen.
– Das sogenannte „Feature-driven Development“ (<engl.> für Funktionsgetriebene Entwicklung [FDD]) ist ein leichtgewichtiges Verfahren, das ausgehend von einem Gesamtmodell eine Liste einzelner Features entwickelt und die gesamte Entwicklung dann in die Implementierung der einzelnen Features herunterbricht. FDD ist vielleicht weniger „revolutionär“ als z.B. XP oder Scrum, befindet sich aber durchaus im Einklang mit den Prinzipien der leichtgewichtigen Entwicklung.
– Beim sogenannten „Test-driven Development“ (<engl.> für Testgetriebene Entwicklung [TDD]) handelt es sich um eine Strategie, die das Testen eines Produkts in den Vordergrund stellt (nachdem es über lange Zeit hinweg in vielen Projekten nur ein Schattendasein gefristet hatte). Das Prinzip ist dabei, der Entwicklung bestimmter Features immer die Entwicklung entsprechender Tests vorausgehen zu lassen. TDD ist als Einzeltechnik Bestandteil vieler leichtgewichtiger Methoden.
– Das sogenannte „Agile Modeling“ (<engl.> für Agile Modellierung) ist ein Verfahren, das sich auf die Modellierungsaspekte in Projekten konzentriert und dafür leichtgewichtige und durch starke Interaktion geprägte Prozesse empfiehlt.
– Das DevOps-Konzept (der Begriff „DevOps“ setzt sich aus „Dev“ für Entwicklung [ <engl.> Development ] und „Ops“ für den Betrieb der Informationstechnologie [ <engl.> Operations ] zusammen) ist ein Ansatz der das Ziel verfolgt, ein leichtgewichtiges Vorgehen auf den Betrieb von Produkten auszudehnen. Schwerpunkt ist dabei die enge Kooperation zwischen den Entwicklern und der Betriebsabteilung. Durch die regelmäßige Auslieferung von lauffähigen Produkten geht deren Inbetriebnahme in einen einfachen, erprobten und reproduzierbaren Prozess über.

Seit Anfang der 2010er-Jahre werden mehrheitlich leichtgewichtige Vorgehensmodelle zur Umsetzung von Projekten herangezogen bzw. die konventionellen Vorgehensmodelle haben eine Durchdringung mit leichtgewichtigen Methoden zur Planung und Koordination der anfallenden Arbeiten bzw. zu erstellenden Produkte und der Qualitätssicherung erfahren. D.h., die konventionellen Vorgehensmodelle haben im Laufe der Zeit an Flexibilität gewonnen und tragen mittlerweile der Tatsache Rechnung, dass Projekte individuell geprägt sind und dass Prozesse an die individuellen Gegebenheiten angepasst werden müssen. Inhalt und Umfang eines Projekts werden nicht mehr wie bei schwergewichtigen, konventionellen Projektmanagement-Frameworks initial abschließend festgelegt sowie sukzessive umgesetzt. Die Umsetzung erfolgt iterativ und inkrementell (leichtgewichtig). Die Möglichkeit zur Integration leichtgewichtiger Methoden in konventionelle Vorgehensmodelle ist grundsätzlich an der Schnittstelle zwischen Beauftragung der Umsetzung und der Umsetzung selbst gegeben. Wichtig ist eine kontrollierte Trennung der Steuerung und der Umsetzung. Sobald die Entscheidung zur Erstellung eines Produkts gefallen ist, wird der Planungsprozess angestoßen. Die Planung und folgende Umsetzung bezieht sich auf die drei Ebenen „Executive, Management und Delivery“ (vgl. Abb. 3).

Abbildung in dieser Leseprobe nicht enthalten

[Abb. 3: Delivery Management der geplanten Ergebnistypen einer Iteration (angepasste Darstellung)[31] ]

- Abb. 3: Leichtgewichtige Methoden können beim Einsatz konventioneller Vorgehensmodelle zum Delivery Management der geplanten Ergebnistypen einer Iteration eingesetzt werden.

Während der Business Case auf der Executive-Ebene gepflegt und geprüft wird, lösen die Tasks des Projektmanagers auf der Ebene des Managements das wiederholte Durchlaufen des Entwicklungszyklus aus. Auf der Ebene „Delivery“ (<engl.> für Lieferung) ist das wichtigste Ziel, die Arbeit des Entwicklungsteams zu steuern. Die Entwicklung hat ihrerseits dafür Sorge zu tragen, dass die geplante Ergebnistypen vom Team erstellt und an das Projekt geliefert werden.

Arbeitet das Unternehmen bei der Programm- bzw. Projektsteuerung generell nach einem konventionellen Ansatz, wirkt sich das nur mittelbar auf die Ebenen Management und Delivery aus. Auf allen Ebenen können im Extremfall unterschiedliche Vorgehensmodelle eingesetzt werden. So kann etwa in einem konventionellen Programmumfeld die Projektumsetzung leichtgewichtig durchgeführt werden. Oder in einem konventionellen Projekt können die Tasks zur Lieferung der geplanten Ergebnistypen wiederum mit einem leichtgewichtigen Vorgehensmodell geplant und gesteuert werden. Wesentlich ist primär, dass die jeweils beauftragten Ergebnistypen (Management- und Expertenergebnistypen) geliefert werden.

[...]


[1] Vgl. Corsten, D.; Gabriel, C. - Supply Chain Management erfolgreich einsetzen: Grundlagen, Realisierung und Fallstudien - Springer 2002 S.8

[2] Vgl. Herrmann, A. - Leichte Dellen: Wenn Agil nicht geht; Feature Driven Development in: iX 9/2014 S.110f

[3] Vgl. Korn, H.-P. - Die „agile“ Organisation: Vom Hype zum Daily Business 2014 - http://korn.ch/archiv/Agile-Organisation.pdf S.6 ff.

[4] Vgl. Herrmann, A. - Leichte Dellen: Wenn Agil nicht geht; Feature Driven Development in: iX 9/2014 S.111

[5] Ohno, T. - Toyota Production System: Beyond Large-scale Production - Productivity Press 1988

[6] Vgl. Töpfer, A. - Lean Six Sigma: Erfolgreiche Kombination von Lean Management, Six Sigma und Design for Six Sigma - Springer 2009 S.28

[7] Vgl. Hüttermann, M. - Agile Java-Entwicklung in der Praxis - O‘Reilly 2008 S.37

[8] Vgl. Liker, J. - The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer - McGraw-Hill 2004 S.30

[9] Vgl. Bergmann L., Lacker M. - Denken in Wertschöpfung und Verschwendung in: Dombrowski U., Herrmann C., Lacker T. et al. - Modernisierung kleiner und mittlerer Unternehmen; Ein ganzheitliches Konzept - Springer 2009 S.161

[10] Vgl. Töpfer, A. - Lean Six Sigma: Erfolgreiche Kombination von Lean Management, Six Sigma und Design for Six Sigma - Springer 2009 S.28f

[11] Vgl. Liker, J. - The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer - McGraw-Hill 2004 S.38ff

[12] Vgl. Töpfer, A. - Lean Six Sigma: Erfolgreiche Kombination von Lean Management, Six Sigma und Design for Six Sigma - Springer 2009 S.29

[13] Vgl. Töpfer, A. - Lean Six Sigma: Erfolgreiche Kombination von Lean Management, Six Sigma und Design for Six Sigma - Springer 2009 S.30ff

[14] Vgl. Womack, J.P.; Jones, D.T. - Lean Thinking: Ballast abwerfen, Unternehmensgewinne steigern - Campus 2004 S.24ff

[15] Weidinger, C. für den Lehrstuhl für Marktorientierte Unternehmensführung der TU Dresden - Ganzheitliche Bewertung und Verbesserung der externen Wertschöpfungskette hinsichtlich Lean Management und Business Excellence im Rahmen eines aktiven Lieferantenmanagements - Diplomarbeit 2007 (unveröffentlicht)

[16] Vgl. Hüttermann, M. - Agile Java-Entwicklung in der Praxis - O‘Reilly 2008 S.37f

[17] Poppendieck, M.; Poppendieck, T. - Lean Software Development: An Agile Toolkit - Addison Wesley 2003

[18] Vgl. Poppendieck, M.; Poppendieck, T. - Implementing Lean Software Development: From Concept to Cash - Addison Wesley 2010 S.37ff

[19] Vgl. Leffingwell, D. - Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise - Addison-Wesley 2011 S.17

[20] Vgl. Hüttermann, M. - Agile Java-Entwicklung in der Praxis - O‘Reilly 2008 S.38ff und S.79f

[21] Vgl. Thomas, O.; Scheer, A.-W. - Business Engineering mit Referenzmodellen; Konzeption und informationstechnische Umsetzung - IM 1/2006 S.65f

[22] Vgl. Scheer, A.-W. - ARIS: Vom Geschäftsprozess zum Anwendungssystem - Springer Verlag Berlin Heidelberg NewYork 1998 S.61ff

[23] Vgl. Stahlknecht, P.; Hasenkamp, U. - Einführung in die Wirtschaftsinformatik - Springer Verlag Berlin Heidelberg NewYork 1997 S.253

[24] Vgl. Melton, T. - Real Project Planning: Developing a Project Delivery Strategy - Butterworth Heinemann 2007 S.1ff

[25] Vgl. Melton, T. - Real Project Planning: Developing a Project Delivery Strategy - Butterworth Heinemann 2007 S.11ff

[26] Vgl. Melton, T. - Real Project Planning: Developing a Project Delivery Strategy - Butterworth Heinemann 2007 S.226f

[27] Boehm, B.W. - Value-Based Software Engineering - Software Engineering Notes Vol. 28 No. 2 - ACM SIGSOFT 2003: http://facweb.cs.depaul.edu/jhuang/se681/ValueBasedSoftwareEngineering2.pdf

[28] Vgl. Rüping, A. - Historie der Agilen Entwicklung: Evolutionstheorie - iX Special 2017 - IT-Projektmanagement S.74

[29] Vgl. Rüping, A. - Historie der Agilen Entwicklung: Evolutionstheorie - iX Special 2017 - IT-Projektmanagement S.74f

[30] Vgl. Rüping, A. - Historie der Agilen Entwicklung: Evolutionstheorie - iX Special 2017 - IT-Projektmanagement S.76

[31] Vgl. Tudor, D.J. - Agile Project and Service Management: Delivering IT Services using ITIL, PRINCE2 and DSDM Atern - TSO 2010 S.47

Ende der Leseprobe aus 899 Seiten

Details

Titel
Lean Delivery Management. Einsatz leichtgewichtiger Methoden und Techniken bei der Lieferung von Produkten
Autor
Jahr
2017
Seiten
899
Katalognummer
V465042
ISBN (eBook)
9783668937017
Sprache
Deutsch
Schlagworte
lean, delivery, management, einsatz, methoden, techniken, lieferung, produkten
Arbeit zitieren
Dr. Gernot J. Schwed (Autor), 2017, Lean Delivery Management. Einsatz leichtgewichtiger Methoden und Techniken bei der Lieferung von Produkten, München, GRIN Verlag, https://www.grin.com/document/465042

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Lean Delivery Management. Einsatz leichtgewichtiger Methoden und Techniken bei der Lieferung von Produkten


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden