Vorlesung. Projektmanagement. Sommersemester Wolfgang Kowarschick. Hochschule Augsburg

Größe: px
Ab Seite anzeigen:

Download "Vorlesung. Projektmanagement. Sommersemester 2015. Wolfgang Kowarschick. Hochschule Augsburg"

Transkript

1 Vorlesung Projektmanagement Sommersemester 2015 Wolfgang Kowarschick Hochschule Augsburg

2 Draft (13. März 2015) 2

3 Inhalt 1 Definitionen Projekte Definition (von W. Kowarschick) Ziele Funktionalität und Qualität sowie strategische Ziele Zeit Kosten Ressourcen Projektmanagement Definition Aufgaben des Projektmanagements Theory of Constraints Zusammenfassung Projekterfolg Risikomanagement Wie vermeidet man einen Misserfolg? Vorgehensweise Typische Risiken und Vorsorgemaßnahmen Vergleich von Projekten mittels Euro-Tagen Projektverlauf Verschiedene Phasenmodelle Die Spezifikationsphase: Was soll gemacht werden? Designphase (Entwurfsphase) Fertigungsphase (Entwicklung) Einführungsphase Review Die Nutzungs- und Aufarbeitungsphase Wasserfall- und Spiralmodell V-Modell XT Draft (13. März 2015)

4 3 Schätzung Die Schätzgrößen Voraussetzunggen für gute Schätzungen Divide et Impera Projektphasen und -vorgänge Akzeptierbare Abweichungen Schneller oder billiger als geplant ist erlaubt! Schätzungen von Phasen und Vorgängen Erwartungswert und Standardabweichung Zentraler Grenzwertsatz der Statistik Weitere Verteilungen für Mehrpunktschätzungen Delphi-Methode Planning Poker Die Function-Point-Methode COCOMO Die Güte von Schätzverfahren Was ist ein Personenmonat? Planung Projektpläne Grobplanung Projektstrukturplan Feinplanung, insb. Ressourcenplanung Netzpläne Vorwärts- und Rückwärtsrechnung Balkendiagramme (Gantt-Diagramme) Feinplanung Personalplanung Bedarfsplanung der Betriebsmittel Kapazitätsausgleich, Resource Leveling Kostenplanung Kalender Methode der kritischen Kette Draft (13. März 2015) 4

5 4.5.1 Integrierter Puffer Die kritische Kette Zubringerpuffer (Feeding Buffer) Ressourcenpuffer Kritischer Pfad und kritische Kette: Ein Vergleich Beispiele für den erfolgreichen Einsatz von CCPM Multiprojektmanagement Projektkontrolle (Controlling) Dringlichkeitslisten Tätigkeitsberichte Zeitdiagramme Gesamtpufferverbrauch als Risikoindikator Earned-Value-Analyse Menschenführung und Teamarbeit Management Führungsstile Druck Folgen von übermäßigem Druck Wie übt man Druck aus? Teamarbeit Motivation Wie kann man Motivation erkennen? Motivationstheorien Individualpsychologischer Ansatz Die Wechselbeziehungen im Verhalten von Chef und Mitarbeiter Dokumentation Einführung Welche Arten von Dokumentation sind brauchbar? Regeln für gute Kommentare Draft (13. März 2015)

6 Draft (13. März 2015) 6

7 Kapitel 1 Definitionen Fremdwörterduden [2001]: Projekt: Plan, Unternehmung, Entwurf, Vorhaben managen: leiten, zustande bringen, geschickt bewerkstelligen, organisieren Brockhaus [1991b]: Projekt (lat. proiectum das nach vorn Geworfene ): geplante oder bereits begonnene Unternehmung, Vorhaben Projektmanagement: Gesamtheit der Planungs-, Leitungs- und Kontrollaktivitäten, die bei zeitlich befristeten Vorhaben (d. h. Projekten) anfallen. Kellner, Hedwig (Kellner [2001]): Merkmale eines Projektes: es ist ein einmaliges Vorhaben es ist zeitlich begrenzt es ist ein komplexes Vorhaben es macht die Zusammenarbeit von Menschen aus unterschiedlichen Fachgebieten notwendig es sind neuartige und unbekannte Probleme zu lösen es steht unter besonderem Risiko es hat ein eigenes Budget während der Projektarbeit stehen die Mitarbeiter und der Leiter unter besonderem Druck Projektmanagement: alle Tätigkeiten, die das ausführende Arbeiten im Projekt erst ermöglichen DIN 69901: Projekt: Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe zeitliche, finanzielle oder andere Bedingungen Abgrenzung gegenüber anderen Vorhaben projektspezifische Organisation 7 Draft (13. März 2015)

8 Projektmanagement (PM): Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projektes. 1.1 Projekte Definition (von W. Kowarschick) Ein Projekt (englisch: Project) ist ein zeitlich begrenztes, eigenständiges, komplexes und riskantes Vorhaben mit klaren Vorgaben bezüglich Funktionalität und Qualität und mit eigenem, fast immer begrenztem Budget. Die Realisierung eines Projektes wird von einem Auftraggeber finanziert und einem Auftragnehmer übertragen. Der Auftragnehmer nimmt dazu ein Projektteam und (andere) geeignete Ressourcen zu Hilfe. Das Projektergebnis wird nach erfolgreichem Projektende von Benutzern eingesetzt. Es kann überdies Auswirkungen auf weitere Personen haben: die Betroffenen. Auftraggeber, Auftragnehmer, Projektteam und Benutzer sind die so genannten Projektbeteiligten. Im weiteren Sinne zählen auch die Betroffenen dazu. Beispiele für Projekte Asterix und Kleopatra: Bau eines Palastes für Cäsar (Goscinny und Uderzo [1968]) Ich baue ein Haus Falls erfolgreich: Folgeprojekt: Ich ziehe um Entwicklung eines elektronischen Aufsatzdienstes für mehrere bayerische Hochschulen Erstellung einer Multimediapräsentation für ein Unternehmen Gegenbeispiele (Tagesgeschäfte) Asterix kämpft gegen die Römer Ich bereite das Frühstück, ich kaufe Lebensmittel ein Elektronische Lieferung von Aufsätzen Pressen von Multimedia-CD-ROMs Draft (13. März 2015) 8

9 Anmerkungen Ein Projekt ist ein eigenständiges, komplexes und riskantes Vorhaben. Neuartige, unbekannte Probleme sind zu lösen. Verschiedene Techniken, Methoden und Spezialisten müssen eingesetzt und koordiniert werden. Menschenführung ist diewichtigste Aufgabe des Projektleiters. Großes Risiko im Vergleich zum Tagesgeschäft. Risikomanagement ist die zweitwichtigste Aufgabe des Projektleiters. Hin und wieder wird auch die Einmaligkeit von Projekten gefordert (vgl. Kellner [2001]), um sauber zwischen Projekt und Tagesgeschäft zu unterscheiden. Ich verzichte ganz bewusst auf diese Forderung, da ein Hausbau oder die Realisierung eines Web-Auftrittes auch dann als Projekt angesehen werden sollte, wenn das Unternehmen schon Dutzende von Häusern gebaut bzw. Web-Auftritten realisiert hat. Als Auftraggeber kann ich dann allerdings viel präzisere Schätzungen hinsichtlich Zeit und Kosten einfordern. Ein Projekt hat klare Vorgaben bzgl. Funktionalität und Qualität. Der Auftraggeber entscheidet darüber was das Projektergebnis einmal leisten soll (Funktionalität) und welche Güte es haben soll (Qualität); der Auftragnehmer akzeptiert oder lehnt ab. Am Ende ist entscheidbar, ob die Ziele erreicht oder verfehlt wurden. Ein Projekt ist zeitlich begrenzt. Daraus leiten Projektleiter häufig folgende Konsequenzen ab: Der Auftraggeber legt die Dauer fest; der Auftragnehmer akzeptiert oder lehnt ab. Es gibt definierte Start-, Zwischen- und Endtermine; diese werden vom Auftragnehmer festgelegt; Meilensteine werden mit dem Auftraggeber abgesprochen. Dies ist aber grundfalsch. Da ein Projekt eine riskante Unternehmung ist, können keine genauen Termine abgegeben werden, sondern nur Zeitspannen, in denen ein Projekt voraussichtlich beendet ist. Diese Zeitspannen sind umso größer, je weniger Erfahrung mit vergleichbaren Projekten vorliegt. Dieser Punkt wird im Abschnitt sowie im Abschnitt ausführlich diskutiert. Besser ist daher: Auftraggeber und Auftragnehmer einigen sich über einen Zeitraum oder einen variablen Funktionskatalog. Das heißt, es gibt einen Zeitrahmen für das erwartete Projektende oder es gibt einen festen Termin zusammen mit einem Katalog von Funktionen, die im Zweifelsfall nicht realisiert werden. Es gibt für Meilensteine keine fixen Termine. 9 Draft (13. März 2015)

10 Ein Projekt hat ein eigenes, (fast immer) begrenztes Budget. Der Auftraggeber trägt die Kosten; Auftraggeber und Auftragsnehmer einigen sich über einen Kostenrahmen. Kosten und Nutzen müssen gegeneinander aufgewogen werden. (Dies gilt sowohl für Auftraggeber als auch für Auftragnehmer und Benutzer auch sollte das Projektergebnis nicht auf Kosten Unbeteiligter gehen). Wer zahlt, schafft an. Falsch! Die Ziele müssen vorher schriftlich vereinbart werden; Änderungen an den Zielen müssen ebenfalls schriftlich vereinbart werden. Von Anfang an sollte bei der Finanzierung ein finanzieller Puffer für spätere Änderungswünsche eingeplant werden. Für die Schätzung der Kosten gilt dieselbe Aussage wie für die Schätzung der Dauer. Je seltener ein vergleichbares Projekt durchgeführt wurde, desto größer ist der Rahmen, in dem sich die Kosten bewegen werden. Genauere Zahlen gibt es nur, wenn viele Vergleichsprojekte vorliegen. Ein Projekt hat einen Auftraggeber und einen Auftragnehmer Auftraggeber und Auftragnehmer einigen sich, unter Berücksichtigung der Wünsche der späteren Benutzer, über realistische Projektziele (Funktionalität, Qualität, Projektdauer und Projektkosten) Vorgaben vom Auftraggeber; Vorschläge, Annahme oder Ablehnung durch den Auftragnehmer. Ein Projekt wird von einem Projektteam realisiert. Der Auftragnehmer wählt geeignete (und nicht etwa nur möglichst billige) Mitarbeiter und insbesondere einen geeigneten Projektleiter. Dieser sollte möglichst früh (in den allerersten Projektphasen) an der Projektdefinition beteiligt werden (am Besten auch an der Auswahl des Teams). Ein großes Projekt kann in mehrere Teilprojekte mit eigenen Teams und Teilprojektleitern untergliedert werden. Einen Gesamtprojektleiter (Projektmanager) gibt es dennoch. Draft (13. März 2015) 10

11 Ein Projekt verbraucht Ressourcen (Material, Lizenzen etc.). 1 Der Auftragnehmer wählt geeignetes Material, Lizenzen, etc., um das Projektziel, d. h. die Realisierung der Funktionalitäten in der geforderten Qualität unter Berücksichtigung der Zeit- und Kostenvorgaben, zu erreichen. Die Ressourcen müssen stets zur rechten Zeit in der richtigen Menge am richtigen Ort sein. Das Projektergebnis wird nach Projektende von Benutzern eingesetzt. Die Wünsche des Benutzers müssen bei der Projektplanung berücksichtigt werden. Ein Projektergebnis, das nicht akzeptiert wird, ist selten für den Auftraggeber von großem Nutzen. Das Projektergebnis eines erfolgreichen Projektes sollte für alle Beteiligten von Nutzen sein: Auftraggeber, Auftragnehmer und Benutzer und es sollte Betroffenen nicht schaden. Zitat aus InformationWeek (Neumann [1999]): Unterschätzte Anwender: IT-Abteilungen wissen, daß die Zufriedenheit der internen Anwender und der Kunden für die Beurteilung ihrer Leistung wichtig sind; die Hersteller halten die Meinung der User für unerheblich. Auf S. 40 im selben Artikel bewerten 350 Anwender die Benutzerfreundlichkeit der IT-Systeme (Rang 2, Vorjahr Rang 3) und den Feedback der Anwender im eigenen Betrieb (Rang 6, Vorjahr Rang 9) als sehr wichtige Technikaspekte. Die Hersteller sind ganz anderer Meinung: Rang 11 und Rang 15. Das Projektergebnis hat Auswirkungen auf Betroffene (z. B. Anwohner an einem neuen Flughafen). Die negativen Auswirkungen auf Betroffene müssen so minimal wie möglich gehalten werden. Prozesskosten, durch Prozesse entstehende Verzögerungen, Entschädigungszahlungen etc. müssen berücksichtigt werden. Projekte können an Betroffenen scheitern! 1 Von einem rein funktionalen Standpunkt aus gesehen, ist ein Mitarbeiter auch nur eine Ressource, die vom Projekt verbraucht wird (immerhin geht ein Teil seiner gesamten Lebenszeit für das Projekt drauf). Gegenüber den Mitarbeitern sollte man zwischen Ressource und Personal allerdings tunlichst unterscheiden. Deshalb wurde zuvor der Punkt Projektteam auch separat behandelt. Beachten Sie aber, dass die nachfolgenden Aussagen eins zu eins auch für Projektteams gelten! 11 Draft (13. März 2015)

12 1.1.2 Ziele Ein Projekt verfolgt neben den vier vertraglich festgelegten Zielen Funktionalität, Qualität, Kosten und Zeit normalerweise auch strategische Ziele, wie Verbesserung des Arbeitsablaufs, Steigerung der Mitarbeitermotivation oder der Kundenzufriedenheit, mehr Marktmacht etc. Diese Ziele können allerdings häufig weder präzise definiert werden, noch ist es am Ende möglich, definitiv zu entscheiden, in welchem Maße sie erreicht wurden. Das wesentliche strategische Ziel dürfte jedoch immer sein, dass das Projektergebnis für alle Beteiligten in irgendeiner Form von Nutzen ist. Jedes Projekt basiert auf zwei Ecksäulen: Ziele (Was?) und Ressourcen (Wie?). Die formalen Ziele legt der Auftraggeber (in Abstimmung mit den Auftragnehmer) fest und die Ressourcen der Auftragnehmer (oft macht der Auftraggeber allerdings auch bezüglich der Ressourcen Vorgaben). Beide Vertragsparteien verfolgen, wie auch die späteren Benutzer und evtl. die Betroffenen, i. Allg. auch noch strategische Ziele mit einem Projekt. Projektziele Funktionalität Qualität Auftraggeber Was? Zeit Kosten strategische Ziele Auftragnehmer Wie? Ressourcen strategische Ziele Benutzer strategische Ziele Betroffene strategische Ziele Projekte basieren i. Allg. nicht auf dem Prinzip Hoffnung: Fangen wir mal an und sehen dann, ob was dabei rauskommt. (Ausnahme: Grundlagenforschungsprojekte) Am Anfang müssen klare und erreichbare Ziele formuliert werden (Analyse, Spezifikation, Pflichtenheft, evtl. Vorprojekte). Am Ende muss entschieden werden können, inwieweit diese Ziele erreicht wurden, d. h., inwieweit das Projekt erfolgreich war. Draft (13. März 2015) 12

13 Die Ziele sollten einen konkreten Nutzen für alle Beteiligten mit sich bringen (das gilt selbst für die Grundlagenforschung: das Menschheitswissen, das als Basis für alle anderen Projekte dient, wird vermehrt). Funktionalität und Qualität sowie strategische Ziele Spezifikation Was soll im Projekt erreicht werden (Funktionalität), und von welcher Güte soll das Ergebnis sein (Qualität). Strategische Ziele werden i. Allg. in der Spezifikation nicht formuliert. Asterix und Kleopatra Funktionalität: prunkvoller Palast für Cäsar Qualität: rechtwinklige Stufen, Steine fallen nicht von der Decke, Türen klemmen nicht (Gegenbeispiel: Das Haus von Numerobis) strategische Ziele: Nachweis, dass Ägypter nicht dekadent sind; Gewinn einer Wette Der Auftraggeber, der Auftragnehmer und vor allem die Benutzer erwarten sich vom Projektergebnis einen Gewinn oder anderen Nutzen: Kleopatra (Auftraggeber): Will Wette gewinnen. Numerobis (Auftragnehmer): Will mit Gold überschüttet werden und Folgeaufträge haben. Miraculix (Teammitglied): Will einem alten Freund helfen und bedeutende Schriften aus der alexandrinischen Bibliothek lesen. Asterix, Obelix, Idefix (Teammitglieder): Wollen Miraculix helfen, wollen außerdem Spaß (Römer verprügeln), Action und Abenteuer. Sekretaris, Arbeiter (Teammitglieder): Wollen Geld verdienen und im Falle der Arbeiter (die ausdrücklich keine Sklaven sind) möglichst wenige Peitschenhiebe. Cäsar (Nutzer des Palastes): Will Wette gewinnen (und nicht etwa den Palast nutzen!). Pyradonis (Betroffener Konkurrent von Numerobis, der leer ausging): Will das Projekt selbst durchführen oder besser noch die Hälfte des Gewinns (Gold) ohne das Risiko zu tragen (von Krokodilen gefressen zu werden). Man beachte: Es handelt sich durchwegs um strategische Ziele. Keiner der Beteiligten interessiert sich für das eigentliche Projektergebnis: den Palast. 13 Draft (13. März 2015)

14 Das Projektergebnis sollte die gewünschte Funktionalität (und nur diese!) in der gewünschten Qualität aufweisen. Dies gilt sogar dann, wenn der Benutzer (wie Cäsar) gar nicht das Projektergebnis nutzen will. ständige Überwachung des Funktionsumfangs geeignete Qualitätstests Um wirklich von Nutzen zu sein (d. h. i. Allg. Gewinn abzuwerfen), sollte das Projekt nicht nur funktionierende, sondern auch qualitativ hochwertige Ergebnisse liefern. Gegenbeispiel Windows-Software: häufig viel Funktionalität in schlechter Qualität. Gutes Marketing oder Monopol trotzdem Gewinn. Es gilt leider nicht hohe Qualität hoher Gewinn. Oftmals wird der Gewinn mit der Verminderung der Qualität vergrößert (z. B. gibt es heute keine DVD-/CD-ROM-Laufwerke mehr mit Staub- und Kratzschutz in Form von Cartridges Wikipedia [2006c]). Bei der Festlegung der Ziele müssen Auftraggeber und Auftragnehmer die Wünsche der späteren Benutzer berücksichtigen. Ein Produkt, das am Benutzer vorbeientwickelt wurde, wird sicherlich kein Erfolg. Das heißt, von Anfang an sollte der Benutzer in die Projektplanung mit einbezogen werden! Zeit Spezifikation: Zeitplan Auftraggeber: möchte nur begrenzte Zeit warten (Asterix: genau 3 Monate) Zeitplan und zur Verfügung stehende Zeit müssen in Einklang gebracht werden: eventuelle Abstriche an Funktionalität/Qualität oder mehr Ressourcen höhere Kosten Reale Zeiten und Zeitplan müssen im Einklang gehalten werden: ständige Überwachung des Zeitplanes Auch geringe Zeitüberschreitungen können evtl. Katastrophen zur Folge haben, z. B., wenn der Konkurrent schneller war oder wenn ein multimedialer Ausstellungskatalog erst nach der zugehörigen Ausstellung fertiggestellt wird oder wenn der Projektleiter von Krokodilen gefressen wird. Kosten Spezifikation: Kostenschätzung Auftraggeber: stellt i. Allg. nur begrenzte Mittel zur Verfügung Draft (13. März 2015) 14

15 Kostenschätzung und zur Verfügung stehende Mittel müssen in Einklang gebracht werden ständige Überwachung des Budgets (Budgetüberschreitung hat evtl. Katastrophe wie z. B. Konkurs zur Folge) Anmerkung Nicht alle Auftraggeber erwarten die vollständige Erfüllung aller Projektziele. Special-Effects-Firmen (SFX-Firmen) wie z. B. Digital Domain (Titanic, 25 Mio. Dollar, Nachverhandlungen 40 Mio Dollar 4 Mio Dollar + 31 Mitarbeiter Verlust), müssen auf Verlangen der Hollywood Filmstudios manchmal nur entweder on time (d. h. im vorgegebenen Zeitraum) oder on budget (d. h. im Rahmen des vorgegebenen Budgets) arbeiten, aber am Besten natürlich Beides. (QUELLE FEHLT [????]) Ressourcen Wesentlicher Projektbestandteil von Anfang an: der Ressourcenplan. Es muss insbesondere abgeschätzt werden können, ob die Projektziele überhaupt erreichbar sind. Funktionalität/Qualität, Zeitplan und Kostenplan müssen mit dem Ressourcenplan in Einklang gebracht werden. Ressource Mensch : Welche und wie viele Spezialisten werden benötigt? Achtung: Jede Person ist für Ihr Arbeitsgebiet ein Spezialist, das gilt beispielsweise auch für einfache Schreibkräfte, Sklaven (Asterix) und minderqualifizierte Mitarbeiter in einem guten Team erbringt jede Person die maximale Leistung entsprechend ihren Fähigkeiten. Ein Witz eines unbekannten Autors bringt das sehr schön zum Ausdruck: Bei einer Firma werden fünf Kannibalen als Sekretäre angestellt. Bei der Begrüßung der Kannibalen sagt der Chef: Ihr könnt jetzt hier arbeiten, verdient gutes Geld und könnt zum Essen in unsere Kantine gehen. Also lasst die anderen Mitarbeiter in Ruhe. Die Kannibalen geloben, keine Kollegen zu belästigen. Nach vier Wochen kommt der Chef wieder und sagt: Ihr arbeitet sehr gut. Nur uns fehlt seit gestern eine Putzfrau, wisst Ihr was aus der geworden ist? Die Kannibalen antworten alle mit nein und schwören mit der Sache nichts zu tun haben. Als der Chef wieder weg ist, fragt der Boss 15 Draft (13. März 2015)

16 der Kannibalen: Wer von euch Affen hat die Putzfrau gefressen? Meldet sich hinten der letzte ganz kleinlaut: Ich war es. Sagt der Boss: Du Idiot, wir ernähren uns seit vier Wochen von Teamleitern, Abteilungsleitern und Projektmanagern, damit keiner etwas merkt, und du Depp musst die Putzfrau fressen...!!! Die Mitarbeiterführung ist und bleibt die wesentliche Aufgabe eines jeden Projektleiters/-managers. Ressource Hardware : Was für Maschinen, Geräte, Rechner, Steine (Asterix) etc. werden benötigt? Ressource Software : Was für Programme werden benötigt? Ressource Wartung und Instandhaltung : Hard- und Software muss in der Regel auch gewartet werden. Das heißt, zu den reinen Anschaffungskosten kommen auch noch Instandhaltungs- oder (regelmäßige) Wartungskosten hinzu. Ressource Informationen : Was für Informationsquellen (Bücher, Internet, Hotline, Archive) werden benötigt? Ressource Infrastruktur : Was für Räumlichkeiten, welcher Verwaltungsapparat, welche Wartungsverträge, welche Telekommunikationsmöglichkeiten (Video Conferencing!) etc. werden benötigt? Ressource Rechte : Für viele Medien (Bild, Audio, Video etc.) müssen Lizenzgebühren gezahlt, d. h. Verwertungsrechte oder andere Rechte erworben werden. Ressource Vorsorge : Risikomanagement (Versicherungen, Wartung etc.) ist unverzichtbar, kostet aber Geld! Ressource Lagerhaltung : Die Lagerung von Hardware kostet Platz und damit Geld. Allerdings können Bauteile etc., die nicht rechtzeitig zur Verfügung stehen, ebenfalls Geld kosten (Just-in-time senkt die Kosten, erhöht aber das Risiko). Ressource Schulung : Die Teammitglieder sollten optimal auf die Projekt-Anforderungen vorbereitet sein. Die Schulung von Mitarbeiter kostet zwar Zeit und Geld, allerdings kann sich der Gesamt-Zeitgewinn, der sich durch sinnvolle Schulungen ergibt, positiv auf die Gesamtkosten auswirken. Draft (13. März 2015) 16

17 Ressource Unterauftragnehmer : Fremdfirmen, andere Abteilungen, Consultants etc. können als externe Unterauftragnehmer zur Erfüllung der Projektziele beitragen. Ressource Verbrauchsmaterial Steht benötigtes Büromaterial bereit? Gibt es eine Kaffeekasse für die Verpflegung von Gästen? (Mitarbeiter verwalten ihre eigene Kaffeekasse). Und so weiter. Wenn irgendwelche Ressourcen zu den geplanten Kosten oder während des geplanten Zeitraums nicht zur Verfügung stehen, müssen eventuell Abstriche an den formalen Zielen (Funktionalität, Qualität, Zeit und/oder Kosten) gemacht werden (an den strategischen Zielen werden i. Allg. keine Abstriche gemacht). Ressourcenplan und realer Ressourcenverbrauch müssen stets im Einklang gehalten werden. Achtung: Besonders günstige Ressourcen zu beschaffen ist ein typisches Beispiel für das Prinzip: Wir sparen, koste es was es wolle! Da wird eine Maschine von einem Lieferanten beschafft, der diese Euro billiger verkauft als ein Konkurrent. Allerdings hätte der Konkurrent vier Wochen eher liefern können. Projektleiter übersehen gerne, dass Mitarbeiter, die wegen eines fehlenden Bauteils vier Wochen lang nicht weiterarbeiten können, wesentlich mehr kosten als Euro. Sehr viele Manager optimieren lokal (hier: Euro bei einem Bauteil gespart); sie übersehen dabei allerdings dass viele lokale Optima i. Allg. kein globales Optimum (hier: Gesamtkosten möglichst gering) zur Folge haben. 1.2 Projektmanagement Definition Unter Projektmanagement verstehe ich, ein Projekt hinsichtlich der Ecksäulen formale Ziele ( Qualität und Funktionalität, Kosten, Zeit ) und Ressourcen zu planen, zu organisieren und zu kontrollieren, das Risiko des Scheiterns zu minimieren sowie das zugehörige Projektteam zu führen. Zu diesem Zweck werden i. Allg. ein verantwortlicher (Gesamt-)Projektleiter und eventuell mehrere Teilprojektleiter (d. h. Leiter von Teilprojekten) bestimmt Aufgaben des Projektmanagements Die Aufgaben des Projektleiters sind also neben der Menschenführung die Projektplanung, -organisation und -kontrolle sowie das Risikomanagement: 17 Draft (13. März 2015)

18 Projektziele sind unter Beteiligung des (zukünftigen) Projektleiters frühzeitig zwischen Auftraggeber und Auftragnehmer abzustimmen und schriftlich in verbindlicher Form (Vertrag) präzise festzuhalten. Änderung an den Projektzielen müssen ebenfalls stets schriftlich in verbindlicher Form festgelegt werden. Der Projektleiter muss die Spezifikation durch genaue Projektpläne (Kostenpläne, Zeitpläne, Ressourcenpläne, Aufgabenaufteilung, Risikoindikatoren etc.) absichern! Risiken sind frühzeitig zu identifizieren. Es muss Vorsorge getroffen werden, für den Fall, dass ein Risiko, d. h. ein potentielles zukünftiges Problem zu einem echten Problem wird (DeMarco und Lister [2003]). Nach der Menschenführung ist die zweitwichtigste Aufgabe des Projektleiters, Vorkehrungen für rechtzeitige und richtige Reaktionen bei Planabweichungen zu treffen und bei allen Abweichungen dann auch rechtzeitig und richtig steuernd einzugreifen (Risikomanagement). Gäbe es mit Sicherheit keine Abweichungen, bräuchte man keinen Projektleiter, sondern nur einen Projektplaner. Im laufenden Projekt muss also die Einhaltung dieser Pläne fortwährend kontrolliert werden, um frühzeitig Risiken zu erkennen, die zu echten Problemen werden: Werden die vereinbarten Funktionen (und nur diese!) von den Entwicklern in der vereinbarten Qualität erstellt (Qualitätstests)? Werden die Zeitpläne eingehalten? Sind Zwischenergebnisse innerhalb der erwarteten Zeitfenster (Meilensteine) fertig? Werden die Kostenpläne eingehalten? Entwickelt sich der Ressourcenverbrauch wie geplant; werden die Ressourcen optimal eingesetzt? Rechtzeitige Lieferungen der benötigten Hard- und Software, keine Überschreitungen der gesetzten Limits, wie z. B. Rechenkontingente, zufriedene Mitarbeiter (unzufriedene Mitarbeiter sind sehr teuer!) etc. Ein Projektleiter sollte sich aber hüten, alles kontrollieren zu wollen. Es reicht, wenn er sich auf diejenigen Aspekte seines Projektes konzentriert, deren Nicht-Erfüllung eine Nicht-Erfüllung einzelner Projektziele zur Folgen haben. Wenn beispielsweise ein so genannter nicht-kritischer Vorgang um zwei Wochen hinter der Zeit herhinkt, das Ergebnis aber trotzdem noch immer rechtzeitig zur Verfügung stehen wird, besteht für den Projektleiter keinerlei Handlungsbedarf! Draft (13. März 2015) 18

19 Leider managen die meisten Manager zum größten Teil Probleme, deren Lösung für sie gar keinen Gewinn bedeutet. (90%, Quelle: irgendwo bei Goldratt: QUELLE FEHLT [????]) Überarbeitete Manager beschäftigen sich mit Dingen, mit denen Sie sich nicht beschäftigen sollten. (DeMarco [2001], S. 71) Laut dpa-meldung räumt z.b. mehr als die Hälfte von 1400 Geschäftsreisenden ein, dass ein Teil ihrer Reisen verzichtbar sei (dpa [2006]). Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Projektabnahme nach, dass: das Produkt alle geforderten Funktionen der Spezifikation enthält das Produkt in der vereinbarten Qualität erstellt wurde das Budget innerhalb des vereinbarten Finanzierungsrahmens liegt die Termine innerhalb des vereinbarten Zeitfensters liegen Der Projektleiter muss über das nötige Wissen, die nötigen Kompetenzen und die nötigen Menschenkenntnisse verfügen, um angemessene Entscheidungen treffen zu können. Der Projektleiter muss allerdings nicht über so viel Fachwissen verfügen, um selbst aktiv an der Entwicklung mitwirken zu können. Bei den allermeisten Projekten ist er bereits mit der Projekt-Leitung (d. h. Führung, Organisation, Problemlösungen etc.) zu mehr als 100% ausgelastet (siehe z. B. Hoffmeyer [2006]). Murphys Gesetz Wenn etwas schiefgehen kann, dann geht es schief. If there s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way. (Diese Aussage geht auf Edward A. Murphy, jr. zurück. Den genauen Wortlaut seiner ursprünglichen Aussage, die er nach einem missglücktem Experiment gemacht haben soll, kenne ich allerdings nicht, dazu kursieren im Netz zu viele unbelegte Versionen.) Anders gesagt: Alles dauert länger als geplant, kostet mehr als geplant und leistet weniger als geplant. Grund meist menschliches Versagen Deshalb Nach Abschluss des Projektes: Erfahrung reflektieren, um dieselben Fehler nicht ein zweites Mal zu machen (Fehleranalyse). 19 Draft (13. März 2015)

20 Frei nach Konfuzius: Wer einen Fehler macht und nichts daraus lernt, macht einen zweiten Theory of Constraints (vgl. Goldratt und Cox [2002], Goldratt [2003]) Die Theory of Constraints und später das Critical-Chain-Projektmanagement wurden von Dr. Eliyahu Moshe Goldratt (31. März Juni 2011) begründet. (Todesnachricht: Techt [2011]) Welche Entscheidungen muss ein Manager treffen, und welche Entscheidungen sind überflüssig oder gar schädlich, da sie nichts zum Erfolg des Unternehmens oder des Projektes beitragen oder diesen sogar behindern? Goldratt geht davon aus, dass bis zu 90 % aller Management-Entscheidungen in die zweite Kategorie fallen. Abbildung 1.1: Konvoi Engpass und Puffermanagement Um den Unterschied zwischen sinnvollen und nutzlosen oder gar fehlerhaften Entscheidungen zu veranschaulichen, schlägt Goldratt ein einfaches Gedankenexperiment vor: Die Aufgabe ist es, einen Konvoi von Fahrzeugen (oder auch eine Gruppe von Wanderern/Schülern, die auf einem schmalen Pfad hintereinander gehen) so schnell wie möglich vom Start (Abbildung 1.1 a) vollständig ins Ziel (Abbildung 1.1 b) zu bringen. Dabei können sich die Fahrzeuge nicht überholen. Wodurch ist die Fahrtdauer des Konvois begrenzt? Durch die Geschwindigkeit des langsamsten Fahrzeugs (Abbildung 1.1 c, das langsamste Fahrzeug ist mit einem Draft (13. März 2015) 20

21 x gekennzeichnet). Die vor diesem Fahrzeug fahrenden Fahrzeuge können beliebig schnell fahren. Das hat aber keine Auswirkung auf die Ankunft des letzten Fahrzeugs, der entweder selbst das langsamste ist oder hinter diesem festhängt. Wie sollte ein Manager vorgehen, um den Konvoi zu beschleunigen? Die sinnvollste Vorgehensweise wäre, zunächst das langsamste Fahrzeug (= den Engpass, engl. constraint ) zu ermitteln und dann dieses Fahrzeug schneller zu machen (z.b. indem es von unnützem Ballast befreit wird oder einen stärkeren Motor erhält). Falls der Konvoi weiter beschleunigt werden soll, wiederholt man diese beiden Schritte einfach. Der Manager kann aber auch nutzlose Entscheidungen treffen, wie z. B. die gleichzeitige Beschleunigung aller Fahrzeuge. Dies würde zwar auch das Engpass-Fahrzeug beschleunigen (was sinnvoll ist), aber eben auch alle übrigen Fahrzeuge, was in der aktuellen Situation sinnlos ist und nur Kosten verursacht, da der Konvoi dadurch nicht schneller ans Ziel kommt. Eine fehlerhafte Entscheidung wäre, das Engpass-Fahrzeug weiter zu verlangsamen, indem es z. B. mit noch mehr Transportgut beladen wird. Eine subtilere Fehlentscheidung wäre, einige oder gar alle anderen Fahrzeuge soweit in ihrer Leistungsfähigkeit zu beschränken (um Kosten zu sparen ), dass sie genauso leistungsfähig sind wie das Engpass-Fahrzeug. Diese Entscheidung hätte eine deutliche Verlangsamung des Konvois zur Folge, auch wenn das auf den ersten Blick nicht klar ist. Darauf wird im nachfolgenden Paragraphen Management der kurzfristigen Kostensenkung noch genauer eingegangen. Zunächst soll eine andere Frage diskutiert werden: Was macht man dagegen, dass die Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht auf und davon fahren? Laut Goldratt reicht es, wenn man das erste Fahrzeug an eine (virtuelle) Kette (engl. chain ) legt, die mit dem Engpassfahrzeug verbunden ist (Abbildung 1.1 d). Damit erreicht man, dass sich das erste Fahrzeug und damit auch alle anderen Fahrzeuge, die sich vor dem Engpass-Fahrzeug befinden, nicht beliebig weit entfernen können. Die Kette darf allerdings nicht zu kurz sein. Sonst bremst eine Störung bei einem vorausfahrenden Fahrzeug (z.b. ein Tankvorgang) auch das Engpass-Fahrzeug aus. Nun machen wir ein zweites Gedankenexperiment (Abbildung 1.2 a): Ein Produkt wird erstellt, indem Lieferanten L die geeigneten Rohstoffe liefern und diese der Reihe nach von verschiedenen Maschinen Mi (oder auch Arbeitern) weiterverarbeitet werden (zum Beispiel am Fließband), bis das fertige Produkt vorliegt und von Kunden K gekauft werden kann. Auch hier gibt es eine Engpass-Maschine, mit dem geringsten Durchsatz (im Diagramm ist dies die Maschine M3, die wiederum mit einem x markiert wurde). 21 Draft (13. März 2015)

22 !"# -!- $# %& %'(& ) % &!"#.-!"# - &!"# - + &, + &, + &, + &, * &!"# Abbildung 1.2: Produktion Maschinen, die in der Produktionsreihenfolge vor dieser Maschine stehen, können mehr Zwischenprodukte produzieren, die in Zwischenlagern vor der jeweils nachfolgenden Maschine gelagert werden müssen. Genauso wie Fahrzeuge, die vor dem Engpass-Fahrzeug fahren, beliebig großen Abstand gewinnen können, können Maschinen, die vor der Engpass-Maschine produzieren, beliebig große Zwischenlager erzeugen. Im Beispiel (Abbildung 1.2 a) kann M1 nicht so viele Rohstoffe verarbeiten, wie der Lieferant liefert. M2 arbeitet schneller als M1 und muss daher hin und wieder Leerlaufzeiten hinnehmen. Allerdings produziert M2 deutlich mehr Zwischenprodukte, als M3 verarbeiten kann. Alle Maschinen, die in der Produktionskette nach M3 stehen, könnten mehr Zwischenprodukte verarbeiten, hängen aber hinter M3 fest, da diese Maschine nicht genug Zwischenprodukte erstellt. Auch hier ist die beste Managementstrategie wieder: Engpass finden und be- Draft (13. März 2015) 22

23 schleunigen. Außerdem sollten die Lieferanten an die Kette genommen werden. Sie sollten stets nur so viele Rohstoffe liefern, dass das Zwischenlager vor M3 immer mit genügend vielen Zwischenprodukten gefüllt ist, d. h., dass ein kleiner Lieferengpass oder ein kurzzeitiger Produktionsstopp an einer der Maschinen M1 oder M2 die Engpass-Maschine nicht ausbremst (Abbildung 1.2 b). Da die reine Just-in-Time-Strategie, die hier verfolgt wird, bei Streiks oder anderen unvorhergesehenen Ereignissen zu Problemen führen kann, kann man theoretisch mit einer zweiten Kette auch noch ein etwas größeres Rohstofflager vor Maschine M1 einrichten (Abbildung 1.2 c). Prinzipiell könnte man aber auch das Zwischenlager vor M3 einfach entsprechend vergrößern. Wenn die Managementstrategie Engpass finden, dann Engpass beheben zyklisch immer und immer wieder durchgeführt wird, tritt irgendwann eine von folgenden zwei Extremsituationen ein: 1. Die Lieferanten sind der Engpass. 2. Die Kundennachfrage ist der Engpass. (Abbildung 1.2 d) In beiden Fällen sollte wie üblich versucht werden, den Engpass zu beheben. Im ersten Fall braucht man neue oder weitere Lieferanten oder auch Alternativ-Rohstoffe. Im zweiten Fall muss man die Nachfrage ankurbeln. Falls dies gelingt, ist wieder eine der Maschinen der Engpass, die dann wieder beschleunigt werden muss. Spätestens wenn es allerdings irgendwann nicht mehr gelingt, den Engpass Kundennachfrage zu beheben und der Leerlauf bei allen Maschinen immer größer wird, muss man ein neues, innovatives Produkt auf den Markt werfen. Das heißt, so viel ein Manager auch optimiert, nach jeder Optimierung muss ein weiterer Optimierungsschritt folgen. Das Management kommt nie an den Punkt, an dem es nichts mehr zu verbessern oder zu verändern/erneuern gibt. Goldratt geht davon aus, dass auch in einem großen Maschinenpark, in dem mehrere Maschinen teilweise parallel an verschiedenen Zwischenprodukten arbeiten (die erst später zu einem größeren Ganzen zusammengefügt werden), immer genau eine Engpass-Maschine existiert, die den Gesamtdurchsatz bestimmt. Dies ist der Engpass, der den Durchsatz bestimmt und auf den sich der zuständige Manager konzentrieren muss. Das Vorgehen, sich auf den Engpass zu konzentrieren und diesen mit einem sinnvollen Puffermanagement von engpass-externen Störungen abzuschirmen, bezeichnet Goldrat als Theory of Constraint (ToC, Engpasstheorie). Im Projektmanagement identifiziert er den kritischen Pfad als Engpass. Um Zeitund Kostenprobleme in den Griff zu bekommen, schlägt er ein explizites Puffermangement vor. Einen kritischen Pfad mit explizitem Puffer bezeichnet er in Anlehnung an die Pufferkette als kritische Kette (vgl. Goldratt [2002]). 23 Draft (13. März 2015)

24 Typische Managementfehler Obwohl die vorgestelle Management-Strategie ( immer wieder: Engpass finden und dann diesen Engpass beheben ) zumindest im Fall des Konvois sofort einleuchtet, gibt es mehrere alternative Management-Strategien, die leider weit verbreitet sind, aber dennoch falsch. Viele Manager haben ein Problem damit, wenn eine Ressource nicht zu 100 % ausgelastet ist. Damit wird der Meinung dieser Manager nach Geld verschwendet. Dies führt dann zu vollkommen falschen Management-Entscheidungen. Management by Objectives Eine mögliche Management-Strategie wäre z. B., mit jedem Fahrer des Konvois bzw. mit jedem Arbeiter an einer Maschine Ziele zu vereinbaren ( Management by Objectives, MbO, Management durch Zielvereinbarung): Ein Fahrer der 10 % schneller fährt als bisher bzw. ein Arbeiter der 10 % mehr Zwischenprodukte erzeugt als bisher, erhält eine Bonuszahlung. Dies hat folgende Effekte: Die Fahrer, die vor dem Engpass fahren, vergrößern den Abstand zum Engpass noch schneller als bisher; die Zwischenlager vor dem Engpass wachsen noch schneller als bisher. Die Fahrer hinter dem Engpass-Fahrzeug bzw. die Arbeiter hinter der Engpass-Maschine sind sauer auf den Engpass-Verantwortlichen, da sie durch diesen ausgebremst werden. Vielleicht wird auch der Engpass etwas beschleunigt, so dass die Produktion tatsächlich etwas erhöht wird. Aber zu welchem Preis? Ich habe in meinem Bekanntenkreis einen derartigen Fall miterlebt. Es geht um eine Firma, die PCs am Fließband montiert (Endmontage). Neben angelernten Arbeitern jobben vor allem während der Ferienzeit regelmäßig auch Schüler und Studenten für ein paar Wochen bei dieser Firma. Die Anzahl der PCs, die pro Stunde montiert werden können, hängt davon ab, wie lange der langsamste Arbeiter für seinen Montage-Vorgang braucht. Und der langsamste Arbeiter d. h. der Engpass ist fast immer ein Schüler oder Student, der die notwendigen Griffe noch nicht so routiniert beherrscht, wie ein festangestellter Arbeiter. Dies wäre nicht weiter problematisch gewesen, wenn die Firma nicht eine Gruppen-Leistungsprämie ausgelobt hätte: Für jeweils soundso viele PCs, die vom Team am Fließband über das Soll hinaus montiert wurden, gab es eine kleine Extraprämie in Form eines etwas besseren Stundenlohns. Und so wurde der Engpassarbeiter regelmäßig das Ziel von Mobbingattacken. Insbesondere Schüler und Studenten hatten zu leiden, wenn sie besonders langsam waren. (Den Fließband-Arbeitern war natürlich nicht klar, dass es für den optimalen Durchsatz einen und nur einen Engpass geben muss. Dieser Punkt wird im Paragraph Management der kurzfristigen Kostensenkung diskutiert.) Draft (13. März 2015) 24

25 Größere Zwischenlager und unzufriedene Mitarbeiter, die irgendwann innerlich kündigen, kosten i. Allg. deutlich mehr, als durch eine Zielvereinbarung hinzugewonnen werden kann. Diese Management-Strategie geht davon aus, dass viele lokale Optimierungen (jeder Fahrer, jede Maschine wird beschleunigt) auch eine globale Optimierung (= einen größeren Gewinn) zur Folge haben. Dies ist laut Tom DeMarco (DeMarco [2001]) ein nicht auszurottender Trugschluss, der die Firmen Geld ohne Ende kostet. MbO wurde in der Mitte des vorigen Jahrhunderts erfunden und hat sich seitdem unausrottbar in die Köpfe der meisten Manager eingenistet, obwohl heute bekannt ist, dass dieses Management-Prinzip fast nur Nachteile mit sich bringt. (Weitere Nachteile, werden im Kapitel 5 diskutiert.) Management ohne Kenntnis des Engpasses Eine weitere Management-Entscheidung könnte sein, irgendwelche Maschinen, die schon alt und klapprig aussehen, durch schnellere Maschinen zu ersetzen. Hier wird genausowenig wie bei MbO analysiert, wo eigentlich die Probleme liegen, sondern aus dem Bauch heraus irgend etwas optimiert. Auch dies führt nur in den seltenen Fällen, bei denen zufällig der Engpass optimiert wird, zum Erfolg. Im Genesatz zu MbO ist diese Art der Entscheidung nur nutzlos (falls nicht zufällig gerade die Engpass-Maschine optimiert wird), aber immerhin nicht schädlich (wenn man von den derzeit sinnlosen Investionen absieht). Management der kurzfristigen Kostensenkung Eine letzte Entscheidung könnte sein, die Kosten zu senken, indem die Leerlaufzeiten von Maschinen reduziert werden. Teure Maschinen werden durch billigere, nicht ganz so leistungsfähige Maschinen ersetzt. Teure Mitarbeiter werden durch weniger qualifizierte und dadurch billigere Arbeiter ersetzt oder gleich ganz entlassen. Et cetera. Solchen Managern schwebt ein optimales System vor: Alle Maschinen sind exakt gleich leistungsfähig. Insbesondere am Fließband wird dieses Ziel angestrebt: Alle Arbeitsschritte müssen exakt im vorgegebenen Takt erfolgen. Doch auch diese Strategie ist vollkommen widersinnig. Wenn alle Maschinen exakt gleich schnell sind, hat jede Störung einer dieser Maschine Auswirkungen auf den Gesamtdurchsatz. Am Beispiel des Konvois sieht man das sehr schön: Wenn ein Auto tankt, müssen die Nachfolger warten (da das Überholen nicht möglich ist). Wenn das Engpass-Fahrzeug tankt, hat dies Auswirkungen auf die Durchschnittsgeschwindigkeit des Konvois (und damit auch auf die Gesamtdauer der Fahrt), da dieses Fahrzeug die verlorene Zeit nie wieder einholen kann. Wenn dagegen ein anderes Auto tankt, hat dies keine Auswirkungen auf die Durchschnittsgeschwindigkeit des Konvois. Fahrzeuge, die hinter dem Engpass-Fahrzeug fahren, können wieder zum Engpass-Fahrzeug aufschließen, indem sie kurzzeitig schneller fahren. Und Fahrzeuge, die vor den Engpass-Fahrzeug fahren, behindern dieses nicht, wenn der Abstand (Puffer) groß genug ist. Nach dem Tankvorgang 25 Draft (13. März 2015)

26 fahren diese Fahrzeuge ebenfalls ein Zeitlang etwas schneller als zuvor, um den alten Abstand wieder herzustellen. Wenn hingegen alle Fahrzeuge gleichschnell sind, ist jedes Fahrzeug ein Engpass. Das heißt, jeder Tankvorgang und jede sonstige Verzögerung eines beliebigen Fahrzeugs hat negative Auswirkungen auf die Durchschnittsgeschwindigkeit des Konvois, da kein Fahrzeug eine Verzögerung mehr aufholen kann. Es ist daher zwingend notwendig, dass es ein und nur ein Engpassfahrzeug gibt, sonst schaukeln sich die Störungen beliebig auf. Die Erkenntnis, dass man genügen Puffer benötigt, um Schwankungen aufzufangen, ist von zentraler Bedeutung. Ein ausgefeiltes Puffermangement ist viel wichtiger, als man gemeinhin annimmt Zusammenfassung Die wichtigste Erkenntnis, die man aus den Ergebnissen von Goldratt ziehen muss, ist, dass man sich als Manager nicht um alles zu kümmern braucht, sondern dass man nur die wirklich relevanten Risiken und Probleme in den Griff bekommen muss. Wer die Engpässe in seinem Unternehmen oder Projekt nicht kennt und auf s Geratewohl irgendwelche lokalen Optimierungen mit der Gießkanne vornimmt, ist kein Manager, sondern ein Versager. Die andere wichtige Erkenntnis ist, dass es ohne gutes Puffermangement nicht geht. Man erinnere sich: Goldratt vermutet, dass bis zu 90 % aller Management-Entscheidungen entweder keine Auswirkungen oder sogar negative Auswirkungen haben! Die wesentlichen Aufgaben eines Projektleiters sind: 1. Menschenführung (Zwischenmenschliche und persönliche Probleme erkennen und und nach Möglichkeit mindern) 2. Risikomanagement (Probleme frühzeitig erkennen und vermeiden), hierzu zählt insbesondere das Puffermanagement 3. Planung und Kontrolle (gute Planung = Problemvermeidung, Kontrolle = Probleme frühzeitig erkennen) In allen drei Fällen gilt: Konzentration auf die wirklich relevanten Problemgebiete. Nur diejenigen Risiken und Probleme sind von Interesse, die das Erreichen der Problemziele gefährden. Eine Mediation, nur weil ein Mitarbeiter mal schlecht gelaunt ist, das Managen von unbedeutenden Risiken (Kaffee geht aus) oder extrem unwahrscheinlichen Risiken, die Planung jedes kleinsten Details oder von Draft (13. März 2015) 26

27 Komponenten, die vielleicht gar nicht realisiert werden, sind überflüssig und lenken nur von den wirklichen Managementaufgaben ab. 1.3 Projekterfolg Wann ist ein Projekt erfolgreich? Wenn man Projektleiter fragt: Misserfolge gibt es nicht! Es gibt höchstens verwickelte Erklärungen, warum die ganze Sache als durchaus erfolgreich anzusehen ist (Kellner [2001]). Also braucht man ein paar gute Definitionen. Projekterfolg aus neutraler Sicht (juristische Sicht) Die neutrale Sichtweise kann nur die schriftlichen Vereinbarungen zwischen Auftraggeber und -nehmer zur Grundlage haben. erfolgreich: Ein Projekt ist erfolgreich, wenn alle vertraglich festgelegten Ziele erfüllt wurden: Spätestens zu den vorgegebenen Terminen und im Rahmen des vorgegebenen Budgets wird die geforderte Funktionalität in der geforderten Qualität geliefert. sehr erfolgreich: Ein erfolgreiches Projekt ist sehr erfolgreich, wenn die Anforderungen (Erwartungen) teilweise übertroffen wurden, d. h., wenn die gewünschten Ergebnisse früher geliefert werden können und/oder wenn die Kosten geringer waren als geplant und/oder wenn die geplante Funktionalität in höherer Qualität realisiert werden konnte und/oder in Absprache mit den Auftraggebern wenn ein erweiterter Funktionsumfang in mindestens der geforderten Qualität realisiert werden konnte. gescheitert: Ein Projekt ist gescheitert, wenn ein oder mehrere vertraglich vereinbarte Projektziele nicht erreicht wurden. Vertraglich können auch andere Erfolgsmodelle definiert werden: Zum Beispiel Hollywood Filmstudios: on time oder on budget. In diesem Fall ist ein Projekt erst dann gescheitert, wenn es sowohl den Zeit-, als auch den Finanzrahmen überzieht. Projekterfolg aus Sicht eines Projektbeteiligen (Auftraggeber, -nehmer, Benutzer, Projektleiter...) erfolgreich: Ein Projekt ist erfolgreich, wenn das Ergebnis für den jeweiligen Projektbeteiligten von Nutzen ist, d. h., wenn z. B. der Nutzen (z. B. der spätere Gewinn) 27 Draft (13. März 2015)

28 die Kosten wie geplant deutlich übersteigt oder allgemeiner, wenn die strategischen Ziele des Projektbeteiligten erfüllt wurden. Dies gilt selbst dann, wenn einzelne Projektziele verfehlt worden sind. sehr erfolgreich: Ein erfolgreiches Projekt ist sehr erfolgreich, wenn der Nutzen die Erwartungen deutlich übersteigt. weniger erfolgreich: Ein Projekt ist weniger erfolgreich, wenn das (evtl. zu spät gelieferte oder zu teurere oder zu schlechte) Projektergebnis immer noch von Nutzen ist, d. h., wenn die strategischen Ziele nur teilweise, nicht aber im gewünschten Maß erreicht werden. gescheitert (erfolglos): Ein Projekt ist gescheitert, wenn das (evtl. gar nicht vorhandene) Ergebnis nutzlos für den Projektbeteiligten ist. Dies gilt selbst dann, wenn das Projekt im juristischen Sinne erfolgreich war! katastrophal gescheitert: Ein Projekt ist katastrophal gescheitert, wenn das Ergebnis den Projektbeteiligten ruiniert. Projekterfolg aus Sicht der Betroffenen erfolgreich: Ein Projekt ist erfolgreich, wenn das Ergebnis den Betroffenen nicht ernstlich schadet. Wie wir gesehen haben, unterscheiden sich die Definitionen von Projekterfolg aus juristischer Sicht und aus Sicht der Projektbeteiligten fundamental. Die erste Definition basiert auf den vertraglich vereinbarten Zielen Funktionalität, Qualität, Kosten und Zeit, der zweiten Definition liegen dagegen die strategischen Ziele der jeweiligen Projektbeteiligten zugrunde. Fazit: Wirklicher Projekterfolg (aus nicht-juristischer Sicht) erfolgreich: Ein Projekt ist für einen Beteiligten (Auftraggeber, Auftragnehmer, Benutzer) erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis erzielt wird (Dieses Verhältnis muss natürlich kleiner als 1 sein.) sehr erfolgreich: Ein Projekt ist für einen Beteiligten sehr erfolgreich, wenn das geplante Kosten/Nutzen-Verhältnis deutlich übertroffen wurde (d. h. deutlich kleiner als geplant ist). weniger erfolgreich: Draft (13. März 2015) 28

29 Ein Projekt ist für einen Beteiligten weniger erfolgreich, wenn das echte Kosten/Nutzen-Verhältnis zwar nicht erzielt wurde, aber zumindest kleiner als 1 ist. gescheitert: Ein Projekt ist für einen Beteiligten gescheitert, wenn das echte Kosten/Nutzen-Verhältnis größer 1 ist, aber keinen Ruin für den Beteiligten bedeutet. katastrophal gescheitert: Ein Projekt ist für einen Beteiligten katastrophal gescheitert, wenn es ihn ruiniert. Ein (sehr) erfolgreiches Projekt, das Betroffenen einen größeren Schaden zufügt, ist aus Sicht der Betroffenen gescheitert oder sogar katastrophal gescheitert. Beispiel 1 Zum Beispiel war der Bau der ersten Atombombe aus Sicht der Projektbeteiligten erfolgreich. Aus Sicht der Bewohner von Hiroshima und Nagasaki und eigentlich auch aus Sicht der gesamten Weltbevölkerung ist dieses Projekt katastrophal gescheitert. Beispiel 2 Abwasser auf Kosten der Allgemeinheit ungeklärt in Flüsse ablassen. Wenn Betroffene mit ihren Klagen Erfolg haben, kann sich das Blatt auch für ein zunächst erfolgreiches Projekt später in das Gegenteil umkehren (Schadensersatzzahlungen etc.). Kosten/Nutzen-Planung Wie man an diesen Definitionen sieht, kann man den wirklichen Projekterfolg nur dann bestimmen, wenn man Kosten und Nutzen gleichermaßen geplant hat (vgl. hierzu Teil IV in DeMarco und Lister [2003]). Häufig sieht die Planung jedoch so aus: Kosten: ,13 Euro Nutzen: Das müssen wir haben. 29 Draft (13. März 2015)

30 Strategische Ziele eines gewinnorientierten Unternehmens Goldratt definiert die strategischen Ziele eines gewinnorientierten Unternehmens folgendermaßen (Goldratt [2003]): 1. Gewinn erzielen bzw. steigern (heute und in Zukunft) 2. sicheres und befriedigendes Umfeld für Belegschaft schaffen (heute und in Zukunft) 3. Markt zufrieden stellen (heute und in Zukunft) Was heißt Gewinn erzielen/steigern? 1. Nettogewinn erzielen/steigern Nettogewinn = Einnahmen Ausgaben > 0 (unter Berücksichtigung der Inflation) 2. Rendite erzielen/steigern Rendite = Gewinn/Investition 3. Cashflow erzeugen/steigern Cashflow = Einzahlungen Auszahlungen Eine Einzahlung muss keine Einnahme sein und eine Auszahlung keine Ausgabe. Wenn beispielsweise ein Kunde seine Rechnung bezahlt, steigt die Menge des verfügbaren ( flüssigen ) Geldes. Aber das Geldvermögen erhöht sich nicht, da gleichzeitig die zugehörige Forderung erlischt. Umgekehrt sinkt die Menge des verfügbaren Geldes, wenn man eine Rechnung bezahlt. Dies ändert aber ebenfalls nichts am Geldvermögen, da die zugehörige Verbindlichkeit erlischt. Ein positiver Cashflow, d. h. der Geldzufluss ist höher als der Geldabfluss, beschreibt also die Menge des verfügbaren ( flüssigen ) Geldes. Dieses Geld notwendig, um Lohn und Gehalt, Material, Steuern, Zinsaufwendungen etc. fristgerecht zahlen zu können. Geldmittel werden dem Cashflow insbesondere entzogen durch: Lagerbestände Infrastruktur (Gebäude etc.) laufende Projekte Achtung: Ein länger andauernder negativer Cashflow, d. h. der Geldzufluss ist geringer als der Geldabfluss, führt zur Insolvenz, auch wenn der Gewinn und Rendite stimmen, da die frei verfügbaren Finanzmittel immer weiter bis auf Null abnehmen (vgl. Flash-Animation Biz/ed [2006]). Wenn Sie zum Beispiel Handyschalen vertreiben, nützt es Ihnen gar nicht, wenn Sie viele Kunden haben, solange ein Großteil der Kunden die Rechnung nicht bezahlt. Jede einzele der offenen Rechnungen per Rechtsstreit einzutrei- Draft (13. März 2015) 30

31 ben, ist bei dem jeweils sehr geringen Streitwert nicht möglich. Um eine positiven Cashflow zu erzielen, müssen Sie bei so einem Geschäftsmodell besser auf Zahlung per Rechnung verzichten und mit Vorkasse oder Ähnlichem arbeiten. Beispiele Titanic, der Film (QUELLE FEHLT [????]): sehr erfolgreich für den Auftraggeber, trotz Kosten von 200 Mio Dollar (100 Mio geplant) sowie 6 Monate Verzug. Aus Sicht von Digital Domain: erfolgreich, wenn man den Prestigegewinn durch den Film berücksichtigt, oder gescheitert, wenn man die Verluste berücksichtigt (trotz Nachverhandlungen: 4 Millionen Dollar Verlust; außerdem haben 31 Mitarbeiter ihren Job verloren, da für sie keine geeigneten Projekte akquiriert werden konnten). Projekt: Bau des Bahnhofs Canfranc (Scheytt [1998]) Gebäude: 241m langer Palast, 1853 Planungsbeginn, 1882 Bewilligung (6 Jahre Bauzeit, Pesetas Subvention/km, Steuerfreiheit auf Baumaterialien), 1928 Einweihung (46 Jahre reale Bauzeit), wegen unterschiedlicher Spurbreiten und fehlender Elektrifizierung auf spanischer Seite: für Auftraggeber ein Flop, d. h. gescheitert! (Allerdings nicht katastrophal gescheitert, da die beteiligten Staaten Spanien und Frankreich daran nicht Konkurs gegangen sind.) Projekt: Bau der ersten Atombombe Manhattan Project (Brockhaus [1991a], Schattenmacher [2004]) Projektleiter: Oppenheimer, Robert ( ; Krebs) Juli 1943: Direktor der Forschungslaboratorien in Los Alamos (New Mexiko) Budget: unbegrenzt; zum Schluss mehr als 2 Milliarden Dollar Zeit: genau 19 Monate Team: die besten Physiker Amerikas Das Projekt wurde erfolgreich abgeschlossen: funktionierendes Ergebnis genau zum angestrebten Termin ( Tag X ). 21 und 24 Tage nach Projektende wurde das Ergebnis in Hiroshima und Nagasaki eingesetzt. Für das amerikanische Militär war das Projektergebnis ein voller Erfolg; für die Betroffenen die Bewohner von Hiroshima und Nagasaki und später für die ganze Menschheit (Wettrüsten) war das Projekt katastrophal gescheitert (gerade weil es formal erfolgreich war). Oppenheimer war kurze Zeit ein Nationalheld. Während des Projektes hat er allerdings einen Mitarbeiter bei einem Atomunfall verloren (das erste Opfer einer Atombombe). Später widersetzte sich Oppenheimer dem Bau der 31 Draft (13. März 2015)

32 Wasserstoffbombe Untersuchungsverfahren wegen angeblicher kommunistischer Gesinnung, 1954 Ausschluss von allen Staatsgeheimnissen und öffentlichen Ämtern, 1963 Rehabilitation. Aussagen von Oppenheimer (im Spielfilm): Wir entwickeln das Ding nur, für ihren Einsatz tragen andere die Verantwortung. Manchmal glaube ich, dass wir trotz aller unserer Intelligenz vom Raubtier abstammen. Projekt: Untersuchung über Heilungswirkung verschiedener Varianten des synthetischen Hormons Levothyroxin bei Schilddrüsenerkrankungen (Rubner [1990]) Projektleiterin: Betty Dong, Pharmazeutin an der Universität von Kalifornien in San Franzisko Projektergebnis: alle vier untersuchten Präparate wirken bei den meisten Patienten gleich gut. Einer der Auftraggeber, die Firma Boots, erklärte die Studie für fehlerhaft (d. h. als Misserfolg) und verbot die Veröffentlichung. Boots stellte das teuerste und meistverschriebene der vier untersuchten Präparate her. Gutachter des Journals of the American Medical Association konnten keine Fehler in der Studie finden. Das Ergebnis wurde erst später, als die Geschichte publik wurde, veröffentlicht. Kosten für Versicherungen und Kranke: 365 Millionen Dollar. Bemerkung Für das Scheitern eines Projektes aus der Sicht des Auftraggebers ist nicht notwendigerweise der Projektleiter verantwortlich. Wenn dieser zu den gegebenen Terminen und im Rahmen des vorgegebenen Budgets die geforderte Funktionalität liefert, das Ergebnis aber trotzdem für den Auftraggeber nutzlos ist, lag bereits ein Planungsfehler vor (z. B. Eisenbahnbrücke ohne Eisenbahn: Die Soda-Brücke von Rödental; dpa [2005], Wikipedia [2011b], Wikipedia [2006b]). Allerdings sollte der Projektleiter schon von Anfang an, d. h. auch während der Planungsphase, verantwortlich am Projekt beteiligt sein. In diesem Fall wäre er auch mitverantwortlich für das Scheitern des Projektes. Draft (13. März 2015) 32

33 1.4 Risikomanagement Wie vermeidet man einen Misserfolg? Ein erfolgreiches Projekt zu leiten, sollte das Ziel eines jeden Projektleiters sein. Erfolgreich heißt dabei: erfolgreich aus juristischer Sicht, aus Sicht des Projektleiters, aus Sicht des Auftragnehmers, aus Sicht des Auftraggebers, aus Sicht des Benutzers und sofern ein ethisches Verantwortungsbewusstsein besteht aus Sicht der Betroffenen. Aber auch weniger erfolgreiche oder nur relativ kurzzeitig erfolgreiche Projekte werden eventuell noch akzeptiert. Darum: Wie vermeidet man Misserfolge und erst recht Katastrophen? 1. Regel Es gibt kein Patentrezept! ( There are no Silver Bullets : Brooks [1986], Wikipedia [2006a]) 2. Regel Der Projektleiter muss einfach für jedes (managebare) Risiko, das für sein Projekt zum Problem werden kann, rechtzeitig Strategien zur Minderung der Auswirkungen und/oder Strategien zur Reaktion entwickeln. Falls ein Risiko zum echten Problem wird, muss er rechtzeitig und richtig reagieren. Numerobis: In Ägypten haben wir gegen die Zeit, gegen den Personalmangel und gegen die Römer zu kämpfen. Vor allem gegen den Architekten Pyradonis, meinen Konkurrenten. Leider lassen sich nicht alle möglichen Probleme vorhersagen oder gar beseitigen. Man sollte sich die tückischen Fallen aber von vorne herein klar machen, um wenigstens möglichst viele dieser Risiken zu vermeiden oder zumindest deren Auswirkungen abzumildern. Für das Management heißt das im Wesentlichen einen fähigen Projektleiter wie Numerobis? einzusetzen und glasklare Projektziele zu formulieren, die nachträglich wenn überhaupt nur kontrolliert geändert werden können. Der Projektleiter sollte sich möglichst auf die Erfüllung der Projektziele konzentrieren (können), d. h., dem Begriff erfolgreich sollte die neutrale Sicht zugrunde gelegt werden (auch wenn das nicht immer zu vertreten ist siehe Oppenheimer). 33 Draft (13. März 2015)

34 1.4.2 Vorgehensweise (vgl. DeMarco und Lister [2003]) 1. Risiken identifizieren 2. Risiken bewerten Ist das Risko managebar? Risiko-Eintrittswahrscheinlichkeit abschätzen Risikofolgen abschätzen 3. Vorbeugemaßnahmen, Gegenmaßnahmen überlegen Kosten der Risikovorsorge abschätzen 4. managebare Risiken nach Priorität sortieren; hohe Eintrittswahrscheinlichkeit + schlimme Folgen hohe Priorität; mögliche Formel, um Risiken zu gewichten: Eintrittswahrscheinlichkeit ( Problemkosten Risikovorsorgekosten ) 5. gute und tragfähige Problemindikatoren finden Frühwarnsystem 6. Risiken managen Wenn Vorsorge sinnvoll: Vorsorge treffen Problemindikatoren überwachen rechtzeitig Gegenmaßnahmen einleiten Achtung: Nicht jeder Indikator ist sinnvoll. Krebsvorsorge ist z. B. nur dann sinnvoll, wenn die Vorsorge auch einen positiven Effekt für die Patienten hat: höhere Lebenserwartung und/oder höhere Lebensqualität. PSA-Tests zur Prostata-Vorsorgeuntersuchungen bieten diese Vorteile derzeit mit hoher Wahrscheinlichkeit nicht (Albin [2010]), auch der Sinn von Mammographie-Reihenuntersuchungen ist umstritten (Nekolla et al. [2005], Dubben und Beck-Bornholdt [2010]). In der New York Times schreibt Richard Albin, der PSA vor 40 Jahren entdeckt hat: PSA sollte keinesfalls genutzt werden, um alle Männer über 50 regelmäßig zu testen, wie es jene wollen, die wahrscheinlich davon profitieren. Ich hätte mir nie träumen lassen, dass meine Entdeckung vor 40 Jahren in eine derartige profitgetriebene Katastrophe für das Gesundheitswesen führen würde. Die Medizin sollte sich der Realität stellen und den unangemessenen Einsatz von PSA-Tests stoppen. Das würde Milliarden Dollar sparen und Millionen Männer vor unnötigen und beeinträchtigenden Behandlungen bewahren. (Albin [2010], Übersetzung in der SZ) Draft (13. März 2015) 34

35 Im Oktober 2011 empfahl die U.S. Preventive Services Task Force, ein Gremium des US-Gesundheitsministerium, die Abschaffungen des PSA-Tests in der USA. (Briseño [2011]) Typische Risiken und Vorsorgemaßnahmen Im Folgenden werden Beispiele für Risiken angegeben, die ein Projekt scheitern lassen können, wenn sie nicht rechtzeitig bedacht werden. Für viele Risiken werden zusätzlich mögliche Vorsorgemaßnahmen angegeben. falsche Funktionalität funtioniert nicht (Vorsorgemaßnahme: Integration von Entwicklung und Tests testdriven development, z. B. Spiralmodell) Benutzer akzeptieren das System nicht (Vorsorgemaßnahme: Benutzer frühzeitig mit ins Boot holen, leider auch weit verbreitet (z.b. bei Smartphones oder studentischen Arbeiten): Plagiatieren; Gegenmaßnahme: nachträgliche Anpassung des Systems) überzogene oder nicht-realisierbare Funktionalität Der Auftraggeber möchte eine eierlegende Wollmilchsau (Vorsorgemaßnahme: Anforderungen frühzeitig vertraglich fixieren) neue Techniken sollen eingesetzt werden, die noch gar nicht das Stadium der Forschung hinter sich gelassen haben (Solche Projekte sollten nur als Forschungsprojekte durchgeführt werden.) Inflation der Anforderungen = ausufernde Änderungswünsche während der Projektlaufzeit (Vorsorgemaßnahme: explizites Änderungsmanagement etablieren) Qualitätsprobleme schlechte Qualität (Vorsorgemaßnahmen: Qualitätsanforderungen in Lasten-/Pflichtenheft einbauen, Qualitätssicherung, Qualitätsmanagement) überzogene oder nicht-realisierbare Qualität z. B.: Ein System mit 100 % Ausfallsicherheit kann nicht erstellt werden. Forderungen wie Ausfallzeit unter 30 Min/Jahr sind dagegen, bei entsprechenden Kosten, schon realisierbar: 99,99 % Ausfallsicherheit ˆ= max. 53 Min Ausfall/Jahr 99,999 % Ausfallsicherheit ˆ= max. 5 Min Ausfall/Jahr 35 Draft (13. März 2015)

36 kritisches bzw. falsches Zeitmanagement Mitarbeiter fehlen unerwartet, werden krank, heiraten, haben Urlaub 2 etc.(vorsorgemaßnahme: Puffermanagement, Gegenmaßnahme: evtl. Hilfskraft einstellen, aber keinen Ersatz-Mitarbeiter) Lieferschwierigkeiten, Systemausfall etc.; Pyradonis behindert Steinnachschub (Vorsorgemaßnahme: Puffermanagement) Achtung: Die Puffer, die für einzelne Vorgänge ermittelt werden, sollten zu größeren Einheiten zusammengefasst werden (Zubringerpuffer, Gesamtpuffer etc.; siehe Abschnitt 4.5.) Mitarbeiter verlassen den Betrieb (Mitarbeiterfluktuation). Vor allem gute Mitarbeiter gehen, andere kündigen innerlich, wenn sie unzufrieden sind. (Vorsorgemaßnahme: gute Menschenführung) Arbeitseifer Oh, jetzt wird s aber knapp! anfängliche Begeisterung Ist ja noch Zeit! Start 2/3 Zeit 1/3 Arbeit Ende 1/3 Zeit 2/3 Arbeit Zeit Verspätung Abbildung 1.3: Studentensyndrom, vgl. Goldratt [2002] Die Mitarbeiter erliegen dem Studentensyndrom (Goldratt [2002], Fachbezeichnung: Prokrastination). (Vorsorgemaßnahmen: Meilensteine, kurze Vorgänge, keine Parallelarbeit eines Mitarbeiters an mehreren Vorgängen, realistische Schätzungen (Vertrauen!)) 2 Mir ist ein Fall bekannt, bei dem für alle Entwickler eine langfristige Urlaubssperre verhängt wurde, damit ein Produkt rechtzeitig zur CeBit fertiggestellt werden konnte. Im März, d. h. in der Endphase des Projektes bemerkte der Betriebsrat, dass der Urlaub des Teams zu verfallen drohte. Also wurde das gesamte Entwicklerteam im März in Zwangsurlaub geschickt... Draft (13. März 2015) 36

37 Ein guter Mitarbeiter/Projektleiter arbeitet in normalen Zeiten höchstens 4 Tage à 6 Stunden (= 24 Stunden) pro Woche aktiv für das Projekt, wenn sie nicht von Routine-Aufgaben entlastet werden. Asterix: Arbeiter arbeiten zu langsam. (Vorsorgemaßnahmen: Zaubertrank; Falls man diesen nicht zur Hand hat: Zeiten realistisch schätzen, Mitarbeiter an kritischen Vorgängen von anderen Arbeiten entlasten, Resource Leveling (siehe Abschnitt 4.4.3)) Sinnlose Wartezeiten kosten Zeit (Microsoft-Lösung: Win95-Buttons für bevorzugte Abfertigung in der Kantine (Cusumano und Selby [1997]). Telekommunikation kostet Zeit: Jedes Telefonat, jede reißt einen Wissensarbeiter aus seiner Denkarbeit, durchschnittlich passiert dies alle 11 Minuten (Pilgram [2011]) es dauert danach jeweils ca. 10 Minuten seine Gedanken danach wieder auf die eigentliche Arbeit zu konzentrieren, d. h., sich zu vertiefen (DeMarco [2001]). (Vorsorgemaßnahme: Störungen von Mitarbeitern möglichst fernhalten) Projektexterne Tätigkeiten kosten Zeit. Der Zeitplan ist inhärent falsch ( politischer Zeitplan, agressive Zeitplanung ; Vorsorgemaßnahme: gute Schätzmethoden einsetzen). Die Konkurrenz ist schneller (evtl. mit weniger Funktionalität oder Qualität). kritische Kostenplanung (bei Asterix nicht gegeben, Geld ist reichlich da) Das wesentliche Risiko lautet: Das Projekt kostet zum Schluss (deutlich) mehr als geplant. Wenn es dann aber auch deutlich mehr Gewinn abwirft als geplant, ist das Risiko eigentlich gar nicht zum Problem geworden. Dennoch: In den meisten Fällen steigen zwar die Kosten, aber leider nicht der Gewinn. Geeignetes Ressourcen (Hard-/Software, Lizenzen etc.) kosten Geld. (Vorsorgemaßnahme: Bei der Planung nicht(s) übersehen.) Spezialisten kosten Geld. (Es kann allerdings billiger sein, einen Profi zu Euro/Tag zu holen, als einen Amateur zu 100 Euro/Tag.) Inflation kostet Geld. (Vorsorgemaßnahme: Bei langfristigen Projekten die Infaltion bei der Planung berücksichtigen.) Der Kostenplan ist inhärent falsch: politischer Zeitplan, agressive Zeitplanung. (Vorsorgemaßnahme: realistische Schätzungen anstelle von politischen Vorgaben) Ausfallzeiten kosten Geld. (Vorsorgemaßnahme: Puffermanagement) 37 Draft (13. März 2015)

38 Ressourcen Risikomanagement (wie z.b. Einplanung von Pufferzeiten) kostet Geld. Aber: Risiken, die zu Problemen werden, können deutlich mehr Geld kosten! (Vorsorgemaßnahme: nur sinnvolle Risiken managen; insbesondere Puffermanagement ist sinnvoll!) Die Konkurrenz ist billiger, evtl. mit weniger Funktionalität oder schlechterer Qualität. (Vorsorgemaßnahme: Dieses Risiko ist nur schwer zu managen. Von Methoden wie Spionage oder Sabotage rate ich dringend ab.) Der Projektleiter hat i. Allg. keinen oder nur wenig Einfluss auf die Projektziele Kosten, Zeit, Funktionalität und Qualität. Was er beeinflussen kann, sind die von ihm eingesetzten Ressourcen zur Erfüllung dieser Ziele. Unzufriedene Mitarbeiter können jedes Projekt zu Fall bringen: Mobbing, zuviel Kontrolle, zu wenig Kontrolle etc. (Vorsorgemaßnahme: gute Menschenführung; Asterix: Arbeiter wollen weniger Peitschenhiebe) Kommunikationsprobleme (Vorsorgemaßnahme: gute Menschenführung) geringe Produktivität der (falschen oder auch unmotivierten) Mitarbeiter (Vorsorgemaßnahme: gute Menschenführung) Ressourcenklau zwischen rivalisierenden Projekten (Vorsorgemaßnahme: gute Menschenführung durch höhere Führungsebenen) zu knappe Ressourcen (Rechnerzeiten, Kopierkontingente, Raumnot etc., Asterix: zu wenig Sklaven; Lösung: Zaubertrank) unwirtschaftlicher Einsatz von Ressourcen (Mensch, Material, Infrastrukturen, Information) Verfügbarkeit von Ressourcen ist nicht sichergestellt, z.b. weil Auftraggeber oder Lieferant benötigte Ressourcen zu spät liefert (Asterix: Steine fehlen Problem trotz Zaubertank) falsche Ressourcen (unfähige Mitarbeiter, die für das Tagesgeschäft nicht geeignet und daher verfügbar sind; nicht-erweiterbare Multimedia-Rechner ohne Soundkarten, unausgereifte Entwicklungswerkzeuge etc.) Sabotage Draft (13. März 2015) 38

39 Spezifikationskollaps Ein sehr großes Risiko ist jedoch auch, dass der Projektleiter gar nicht weiß, welche Ziele er eigentlich verfolgen soll. In der Spezifikation werden zu Projektbeginn, da sich die beteiligten Parteien nicht einigen können, keine konkreten Angaben zu Anforderungen gemacht (nur Luftblasen). Wolkige Spezifikation ist möglich, wolkige Entwicklung nicht irgendwann kommt es zum Crash. Dieses Risiko wird sofort zum Problem, sobald ein derartig schwammiger Vertrag formal geschlossen wird. Das heißt, die Risikovorsorge muss sehr frühzeitig erfolgen, evtl. noch, bevor überhaupt ein Projektteam eingesetzt wird. Hier sind auch wieder höhere Führungsebenen gefragt, die über dem Projektteam liegen. Probleme von außen Neben den tyischen Managementfehlern gibt es noch Risiken, deren Problemwerdung vom Projektteam nur schwer abgewendet werden können: höhere Gewalt (Konkurs des Auftraggebers, Streik, Umweltkatastrophen) Spionage Konkurrenz hat mehr Marktmacht Menschen Projekte scheitern dennoch meist an Menschen: Management ( Managementfehler häufigste Insolvenzursache, AZ [2006]) Projektteam (Projektleiter und Projektmitarbeiter) Auftraggeber externe Partner Benutzer (akzeptieren das Projektergebnis nicht) Betroffene (klagen erfolgreich gegen Projektergebnis) Man beachte, dass es schwierig ist, Risiken zu finden, die nicht auf Managementfehler zurück zu führen sind, und diese beeinflussen meist auch nur die Projektziele Dauer und Kosten : Krankheit der Mitarbeiter (Dauer) Konkurs eines Sub-Unternehmers (Dauer, Kosten) Ressourcenknappheit wg. Streik, Lieferengpässen etc. (Dauer, Kosten) Hardware fällt aus (Dauer, Kosten) 39 Draft (13. März 2015)

40 Steigende Preise (Kosten) geeignete Hardware/Software steht nicht zur Verfügung (Funktionalität, Qualität, Dauer, Kosten) Bei den meisten Problemen, die auftreten, handelt es sich jedoch um Managementfehler: keine Konzentration des Managements auf wesentliche Aufgaben Manager kümmern sich nicht um Projektinterna, treffen aber Entscheidungen Ausüben von negativem Druck Ausüben von positivem Druck, wie z.b. Management by Objectives Angst vor Versagen zuviel Kontrolle Angst vor Sympathieverlust zu wenig Kontrolle kein Risikomanagement Kommunikationsoverhead Spezifikationskollaps Inflation der Anforderungen falsche Zeitplanung, wie z.b. fixe Termine oder Parallelarbeit durch Mitarbeiter, falsche Kostenplanung, falsche Ressourcenplanung etc. Weitere typische zwischenmenschliche Probleme: nutzlose Meetings aufgrund von Profilierungssucht irreale Kosten-/Zeitschätzungen, weil Auftragnehmer das Projekt unbedingt oder überhaupt nicht haben will Pläne werden über die Köpfe der Betroffenen hinweg erstellt DV-Spezialisten ignorieren Belange von Normalbenutzern ( Diese Idioten verstehen sowieso nichts davon ) Mitarbeiter, Partner etc. verstehen sich nicht (wahllos zusammengewürfelte Teams) Neid ( Eigentlich wäre ich an der Reihe gewesen, Projektleiter zu sein etc.) Mobbing Sabotage durch unzufriedene Mitarbeiter, Projektleiter, Konkurrenten (Pyradonis) oder Benutzer etc. pp. Draft (13. März 2015) 40

41 Kernrisiken Projektrisiken gibt es viele. Am Besten ist es natürlich, alle managebare Risiken auch zu managen, sofern diese eine gewisse Relevanz haben. Ein Risiko wie z. B. Ein Asteroid vernichtet einen Großteil der Menschheit ist nicht managebar und kann daher ignoriert werden. Genauso kann ein Risiko wie z. B. Der Kaffee ist aus ignoriert werden; hier finden die Projektmitarbeiter i. Allg. eine eigene tragfähige Lösung (z. B. einen Kaffeebeauftragten, der rechtzeitig für Nachschub sorgt). Es ist schon viel gewonnen, wenn wesentliche Kernrisiken berücksichtigt werden. Kernrisiken zeichnen sich durch hohe Eintrittswahrscheinlichkeit und hohe Kosten aus, wenn sie wirklich eintreten. DeMarco und Lister [2003] geben folgende fünf Kernrisiken an: inhärent fehlerhafter Zeitplan Inflation der Anforderungen (ausufernde Anforderungen) Mitarbeiterfluktuation Spezifikationskollaps geringe Produktivität Urs Gulba [2004] nennt folgende Top-Risiken in Softwareprojekten: Dynamische Anforderungen (= andauernde Veränderung der Anforderungen) schlechte Projektplanung und -schätzung mangelhafte Kommunikation fehlende oder unzureichende Qualitätssicherung unreife Softwaretechniken sowie unzulängliche Entwicklungsmethoden und -werkzeuge Es fällt auf, das in beiden Quellen jeweils nur ein Problem genannt wird, das die Arbeitsleistung betrifft und dies auch noch als letztes. Die anderen Risiken können durch harte Arbeit des Teams kaum gemindert werden. Sie als Projektleiter können allerdings gegen die meisten Risiken ankämpfen. Bei Problemen wie einem inhärenten Zeitplan oder einem Spezifikationskollaps können allerdings auch Sie (nachträglich!) nicht mehr viel ausrichten. Wesentliche Kernprobleme bestehen schon frühzeitig. Das heißt, viele Kernrisiken müssen schon sehr früh berücksichtigt werden, da sie sonst schon früh zu echten Problemen werden (auch wenn das häufig erst spät, viel zu spät erkannt wird). 41 Draft (13. März 2015)

42 Ein klassisches Beispiel ist der erste Versuch des Toll-Collect-Projektes. Um den Auftrag zu erhalten, hat das Konsortium eine Projektlaufzeit von weniger als einem Jahr veranschlagt. Im Vorfeld anstehender Bundestagswahlen einigte man sich auf publikumswirksame elf Monate bis zum Starttermin plus vier Monate Erprobungszeit... Im Detail ist der ausgehandelte Vertrag bis heute so geheim, dass nicht einmal das Parlament Einblick bekommt. Mit der Geheimhaltung solle die Vertraulichkeit wichtiger Patente und Verfahrensweisen gesichert werden, sagte Verkehrsminister Stolpe.... (Borchers [2004]). Dass diese Zeitspanne für ein derart komplexes Projekt viel zu kurz war, dürfte selbst jedem Laien klar sein. Durch... juristische[n] Hickhack blieben... elf Monate Entwicklungszeit übrig: DaimlerChrysler, das mindestens 30 Monate für die Entwicklung eines LKW benötigt, unterschrieb als Partner von Toll Collect im September 2002 einen Vertrag für ein System, das weitaus komplexer ist als ein LKW. (Borchers [2004]) Nachdem die veranschlagten elf Monate vorbei waren, wurde eine realistische Schätzung von mehreren Jahren Projektdauer vorgenommen und in einem zweiten Versuch wurde das Projekt erfolgreich abgeschlossen. 1.5 Vergleich von Projekten mittels Euro-Tagen Ein billiges Projekt mit langer Laufzeit bindet eventuell mehr Kapital, als ein teures Projekt mit kurzer Laufzeit. Um den Wert eines Projektes abschätzen zu können, reicht es daher nicht, den später erwarteten Gewinn zu berücksichtigen. Man sollte auch den Effekt auf den Cashflow betrachten. Goldratt schlägt vor, dies mit Hilfe des künstlichen Maßes Euro-Tage zu tun (Goldratt [2002], TOC Times [2005]). Wenn ein Projekt Euro einen Monat lang bindet, entspricht dies laut Goldratt einer Investition von Euro-Tagen = Euro 30 Tage. Verschiedene Euro-Tag-Investitionen werden einfach aufaddiert. Nehmen wir an, unser Projekt hätte eine Laufzeit von 3 Monaten. Jeder Monat koste uns Euro, anschließend verdienen wir monatlich 500 Euro mit dem Projektergebnis. Das heißt, wir investieren Euro und müssen insgesamt 9 Monate (= 3 Monate Projektlaufzeit + 6 Monate Verdienst am Projektergebnis) warten, bis wir die Investition wieder herein geholt haben. Nach 9 Monaten haben wir also genauso viel Geld zur Verfügung als davor. Erst jetzt verdienen wir mit dem Projekt Geld. Wir hatten allerdings neun Monate lang Geld gebunden (dem Cashflow entzogen), welches wir anderweitig für evtl. bessere Investitionen hätten verwenden können. Wie groß war nun die Auswirkung auf den Cashflow? Draft (13. März 2015) 42

43 Unsere Investition betrug Euro, nach 9 Monaten hatten wir das Geld wieder. Das entspricht einer Investition von Euro 9 30 Tage = Eurotage, man spricht auch von Investitions-Euro-Tagen. Diese Rechnung ist allerdings etwas grob, da wir die Euro ja nicht sofort am ersten Tag investiert hatten und auch nicht 9 Monate lang auf jeden Cent verzichten mussten. Bei genauerer Rechnung ergibt sich folgende Investitionssumme: 1. Monat: Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 2. Monat: weitere Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 3. Monat: weitere Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 4. Monat: 500 Euro verdient noch Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 5. Monat: 500 Euro verdient noch Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 6. Monat: 500 Euro verdient noch Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 7. Monat: 500 Euro verdient noch Euro investiert 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 8. Monat: 500 Euro verdient noch 500 Euro investiert 30 Tage 500 Euro = Euro-Tage, Summe: Euro-Tage 9. Monat: 500 Euro verdient noch 0 Euro investiert 30 Tage 0 Euro = 0 Euro-Tage, Summe: Euro-Tage 10. Monat: 500 Euro verdient 500 Euro Gewinn Das heißt, wir verdienen erst ab dem 10. Monat Geld, haben dafür aber 9 Monate lang auf Investitionsmittel in Höhe von Euro-Tagen verzichtet. Wenn wir das Geld für diese Zeit anders (besser) angelegt hätten, hätten wir evtl. früher mehr Geld verdient. Das heißt, wir können erst dann von einem echten Reingewinn sprechen, wenn wir mir dem Projekt nicht nur das Geld, sondern auch die verlorenen Euro-Tage wieder verdient haben. Die Rechnung der so genannten Durchsatz-Euro-Tage, d. h. der Euro-Tage, die wir durch das Projekt gewinnen, beginnt ab dem Zeitpunkt, ab dem wir erstmals einen echten Gewinn einfahren. Bei unserem Projekt ist das der 10. Monat. Die Durchsatz-Euro-Tage werden geanuso wie die Investitions-Euro-Tage berechnet: 10. Monat: 500 Euro Gewinn 30 Tage 500 Euro = Euro-Tage, Summe: Euro-Tage 11. Monat: weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 43 Draft (13. März 2015)

44 12. Monat: weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 13. Mona:t weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 14. Monat: weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 15. Monat: weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage 16. Monat: weitere 500 Euro Gewinn 30 Tage Euro = Euro-Tage, Summe: Euro-Tage (26 Tage Euro = Euro-Tage, Summe: Euro-Tage) Das heißt, am Ende des 16. Monats (genauer: 4 Tage zuvor) haben wir so viele Durchsatz-Euro-Tage verdient, wie wir Investitions-Euro-Tage zuvor verloren hatten. Bis dahin haben wir außerdem Euro mit unserem Projekt verdient. Über den Zeitraum von 7 Monaten entspricht das einer Investitionskraft von Euro-Tagen. Diese Investitionskraft hätten wir auch gehabt und das auch noch früher, wenn wir das Projekt gar nicht gestartet hätten. (Inflationsbereinigt hätten wir sogar noch ein paar Tage länger warten müssen, bis wir unsere ursprüngliche Investitionskraft wieder hergestellt hätten). Welche Bedeutung hat also der 17. Monat für unser Projekt? Das ist der Zeitpunkt, ab dem wir wirklich neues Geld verdienen, das wir zusätzlich investieren oder verleben können. Im Magazin TOC Times steht:... the project Flushes we really return the investment in both money and opportunity lost (TOC Times [2005]). In einem Internetforum (Zultner [2009]) wird von Richard Zultner der Sinn der Investiontions- und der Durchsatz-Euro-Tage mit einem sehr einfachen Gegenbeispiel in Frage gestellt. Das Argument lautete wie folgt: Wenn jemand 10 Euro auf zwei Arten anlegen könne, einmal für einen Tag, um dann 20 Euro zurückzubekommen (= 10 Euro Gewinn) 3 und einmal für 10 Tage, um dann 100 Euro zurückzubekommen (= 90 Euro Gewinn), dann sei es auf jeden Fall besser, es für 10 Tage anzulegen, weil dann der Gewinn deutlich größer sei. Dies widerspräche aber dem Ergebnis der Berechnung der Investitions-Euro-Tage, die im ersten Fall nur 10 1 = 10 Euro-Tage betrügen, im zweiten dagegen = 100 Euro-Tage. Dieses Ergebnis würde ja bedeuten, dass man die 10 Euro besser nur einen Tag anlegen sollte, weil der Flush dann wesentlich früher einträte. In jedem Lehrbuch stünde dagegen, dass die andere Variante die bessere Wahl sei. Hat er Recht? Ja, er hat Recht, aber nur, wenn eine Reinvestition wie von Zultner 3 Richard Zultner wählt ein etwas komplexeres Beispiel: Nach zwei und nach 5 Tage erhalte ich jeweils 20 Euro Gewinn. Draft (13. März 2015) 44

45 gefordert nicht möglich ist. Sehen wir uns dieses Beispiel (mit diesen fantastischen Gewinnmöglichkeiten) mal etwas genauer an. Angenommen, ich wäre im Besitz von genau 10 Euro und legte sie so an, dass ich nach 10 Tagen 90 Euro Gewinn machte. Bis ich diesen Gewinn einstreichen könnte, wären meine 10 Euro gebunden und ich könnte sie nicht anderweitig verwenden. Dies drückt sich im Wert 100 Investitions-Euro-Tage aus. Wenn ich dagegen die 10 Euro nur ein Tag lang anlegte, hätte ich am nächsten Tag 20 Euro zur Verfügung, die ich gleich wieder investieren könnte. Die 20 Euro legte ich natürlich bereits am zweiten Tag wieder zu den Super-Bedingungen Verdopplung in einem Tag an. Das heißt, nach zwei Tagen (am dritten Tag) hätte ich 40 Euro, nach drei Tagen 80, nach 4 Tagen 160 und so weiter. Auf diese Weise hätte ich nach 10 Tagen einen Gewinn von Euro erwirtschaftet. Der wesentliche Punkt bei dem Maß Euro-Tag ist, dass er nur dann Sinn macht, wenn ich mein Geld regelmäßig möglichst sinnvoll investieren will und kann. Dieses Maß hilft einem dabei, zu entscheiden, welche Investitionen wirklich sinnvoll sind. Wenn ich zwischen diesen fantastischen Investionsmöglichkeiten Verdopplung in einem Tag und Verzehnfachung in 10 Tagen nur ein einziges Mal wählen kann und es keine anderen Reinvestitionmöglichkeiten gibt, dann sollte ich natürlich die Verzehnfachung wählen. Wenn mir aber nach einem oder auch zwei Tagen wieder eine Super-Investionsmöglichkeit angeboten wird, dann ist die Verdopplung der Verzehnfachung i. Allg. vorzuziehen, da diese die Investitionsmittel nicht so lange bindet. Allerdings nützen die ganzen schönen Berechnungen von Euro-Tagen nichts, wenn die Schätzungen der Projektdauer, der Kostenverläufe und der erwarteten Gewinne schlecht oder gar vollkommen unseriös sind. Andererseits macht einem die Berücksichtigung der Euro-Tage erst klar, welche Kosten eine große Zeitverzögerung wirklich verursacht. Es wird nicht nur der Reingewinn geschmälert (wenn sich das neue Handy beispielsweise nur noch ein halbes Jahr verkaufen lässt und nicht, wie geplant, ein ganzes Jahr, da es zu spät auf den Markt gekommen ist). Es wird auch die Investitionskraft, d. h. der Cashflow, empfindlich geschmälert. Fazit Wenn man die Auswahl zwischen mehreren Projekten hat, sollte man bei der Entscheidung, welche davon realisiert werden sollten, nicht nur die Kosten und den später erhofften Gewinn, sondern auch die Auswirkungen auf die Investitionskraft, d. h. die Investitions- und die Durchsatz-Euro-Tage berücksichtigen. 45 Draft (13. März 2015)

46 Draft (13. März 2015) 46

47 Kapitel 2 Projektverlauf Ein Fußmarsch von 1000 Meilen beginnt mit dem ersten Schritt. (chinesisches Sprichwort) Jede menschliche Tätigkeit lässt sich in Phasen einteilen (aufstehen, waschen, anziehen, frühstücken, zur Arbeit fahren etc.) Ebenso lässt sich jedes Projekt in Phasen unterteilen (Spezifikationsphase, Designphase, Fertigungsphase, Einführungsphase etc.) Prinzipiell ist es möglich, zwei Phasen überlappen zu lassen (Nahrungsaufnahmephase + Informationsphase = frühstücken + Zeitung lesen) Auch in Projekten könnte man mehrere Phasen einander überlappen lassen. Zum Beispiel könnte man mit der Einführungsphase (Aufstellen von Hardware beim Benutzer, Installation von Basissoftware etc.) begonnen werden, bevor die Fertigungsphase vollständig abgeschlossen ist. Im Falle von Terminproblemen wird man manchmal auch so vorgehen. Allerdings ist es sicherer, eine Phase vollständig abzuschließen und dann erst mit der nächsten zu beginnen. Ein sehr schönes Beispiel lieferte im Sommersemester 2005 der Bau des neuen Schülegebäudes der Hochschule Augsburg. Die erste Planungsfirma hatte das Handtuch geworfen, eine zweite Planungsfirma übernahm den Job. Während diese Firma die Anschlüsse von Steckdosen, Netzwerken etc. plante, wurden bereits die zugehörigen Leerrohre auf der Baustelle einbetoniert. Den Mitarbeitern des Fachbereichs Informatik, die an der Planung beteiligt waren, standen veraltete Pläne zur Verfügung, in denen sich z. B. Türen an anderen Stellen als aktuell geplant befanden. Aber das war sowieso egal, da ja auf der Baustelle bereits Fakten geschaffen wurden. Besser ist es i. Allg. jede Phase vollständig abzuschließen, bevor die nächste begonnen wird. Während einer Phase können allerdings verschiedene Aufgaben (Vorgänge) parallel bearbeitet werden. Das Ende einer Phase wird auch als Meilenstein bezeichnet. Dabei unterscheidet man zwischen internen Meilensteinen, die nur innerhalb des Projektteams von Bedeutung sind, und den externen Meilensteinen, bei denen die Teilergebnisse dem 47 Draft (13. März 2015)

48 Auftraggeber präsentiert werden und mit ihm das weitere Vorgehen abgestimmt wird. Phase 1 Phase 2 Phase 3 Projektstart Meilenstein 1 Meilenstein 2 Projektende Prinzipielles Vorgehen Ein Projekt wird in n Phasen unterteilt. Es sei i 1, 2,..., n. Phase i: Dauer i Budget i Funktionalität und Qualität i Pläne i Ressourcen i Vorgänge i Produkt i (Meilenstein am Ende der Phase i) Review i mit Entscheidung: weiter: Phase i + 1 wird gestartet (bzw. Projektende, wenn Phase i + 1 nicht existiert, d. h., wenn i = n), weiter mit Ziel- oder Planänderung: Phase i + 1 wird nach Änderung der Ziele oder Pläne gestartet zurück: Phase i (oder sogar eine frühere Phase) wird wiederholt zurück mit Ziel- oder Planänderung: Phase i (oder sogar eine frühere Phase) wird nach Änderung der Ziele oder Pläne wiederholt Projektabbruch (da sinnvolle Ziele nicht mehr erreicht werden können) Bei einem Review können auch Projektziele (Kosten, Zeit, Funktionalität, Qualität) geändert werden. Dies sollte jedoch stets schriftlich mit Zustimmung aller Beteiligten erfolgen (Änderungsmanagement). Dieses Vorgehen garantiert, dass die Phase n zur Zufriedenheit aller (oder zumindest der Mehrheit) abgeschlossen wird oder dass das Projekt wegen unüberwindbaren Problemen, Unwirtschaftlichkeit oder Ähnlichem vollkommen gestoppt wird. Draft (13. März 2015) 48

49 Vorteile des Phasenmodells Schätzungen sind, wenn man ein Projekt in mehrere Teile wie z. B. einzelne Phasen unterteilt und diese einzeln schätzt, viel besser, als wenn man ein Projekt im Ganzen schätzt. (siehe Abschnitt 3.2.2) Das Projekt dümpelt nicht vor sich hin, da man immer erreichbare Ziele vor Augen hat. Die Zeit, Budget- und Zielplanung kann schrittweise erfolgen. Man stattet beispielsweise das Projekt zunächst nur mit einem Budget für die ersten ein, zwei Phasen aus und entscheidet dann, ob man mit dem eigentlichen Projekt starten will. Zu jedem Meilenstein/Review-Zeitpunkt wissen alle Beteiligten, wo das Projekt steht. Allerdings zaubern Projektleiter und -mitarbeiter bei Reviews oft ganz schön. Bei jedem Review kann eine formale Änderung alter Projektziele erfolgen (Änderungsmanagement, Change Management). Schlimmstenfalls kann entschieden werden, mehrere Phasen zu wiederholen (z. B. weil der Hardwarehersteller der Zielplattform Pleite gegangen ist in derart krassen Fällen sollte allerdings nicht erst eine Review-Phase abgewartet werden). Das Risikomanagement wird deutlich einfacher. 2.1 Verschiedene Phasenmodelle Es gibt kein einzig richtiges Phasenmodell! Welche Phasen notwendig sind, welche Meilensteine gesetzt werden sollten, hängt immer vom aktuellen Projekt ab. Prinzipiell gibt es bei Softwareprojekten fünf große Abschnitte (aber keine normierten Begriffe dafür), die allerdings auch verschränkt ablaufen können (Spiralmodell; siehe Abschnitt 2.2): 1. Spezifikationsphase (Projektziele: Was soll erreicht werden?) 2. Designphase (Wie werden die Projektziele erreicht?) 3. Fertigungsphase (Realisierung der Projektziele) 4. Einführungsphase (Übergabe der Projektergebnisse an den Auftraggeber/die Benutzer) 5. Aufarbeitungsphase (+ Nutzungsphase) Nach Abschluss der Einführungsphase ist das Projekt eigentlich abgeschlossen. Allerdings sollte man die Erfahrungen, Erfolge und Fehler in einer abschließenden 49 Draft (13. März 2015)

50 Aufarbeitungsphase reflektieren, um daraus für ein nächstes Projekt zu lernen. Die Nutzungsphase ist nicht mehr Bestandteil des Projektes. In dieser Phase anfallende Arbeiten, wie z. B. Wartungstätigkeiten, gehören zum Tagesgeschäft (obwohl viele Projektarbeiten leider oft in die Wartung verlegt werden, um den Termin formal einhalten zu können; Bananenprodukt: Das Produkt reift beim Kunden). Ein erfolgreiches Projekt kann ein oder mehrere Folgeprojekte initiieren. Das heißt, in die Nutzungsphase (eventuell sogar schon in frühere Projektphasen) können die Planungsphasen der Nachfolgeprojekte fallen. Diese fünf Grobphasen können je nach Projekt unterschiedlich umfangreich und in unterschiedliche Teilphasen gegliedert sein Die Spezifikationsphase: Was soll gemacht werden? Ziel dieser Phase ist es festzulegen, was gemacht werden soll. Zunächst startet ein Projekt meist ohne konkrete Vorstellungen, ohne Projektleiter und Projektmanagement. Typische Phasen während der Spezifikationsphase: Initialisierungsphase, Planungsphase, Bedarfsermittlung, Vorstudie Zunächst muss die Projektidee geboren werden. Das kann ganz spontan im Schlaf passieren, oder man sucht gezielt nach neuen Projektideen mit Hilfe einer Vorstudie oder Bedarfsermittlung (Brainstorming etc.). Am Anfang ist die Idee! Orientierung (Informationsphase) Welche Bedürfnisse bestehen (z. B. Benutzerbefragungen)? Welche Probleme oder Engpässe bestehen (Problemanalyse)? Wo ist eine Marktnische (Übersichtsanalyse)? Untersuchung Gibt es Lösungsmöglichkeiten für die erkannten Probleme? Ist zumindest eine Lösung realisierbar (Konzeptanalyse)? Nutzt die Lösung dem Auftraggeber (grobe Kosten-/Nutzenschätzung)? Ist eine Lösung der Probleme wirtschaftlich notwendig? Eine Bedarfsermittlung wird normalerweise vom Auftraggeber alleine durchgeführt, eine Vorstudie wird dagegen oft als Auftragsarbeit an eine andere Firma Draft (13. März 2015) 50

51 (z. B. Beraterfirma) vergeben. Es ist von Vorteil, wenn der zukünftige Projektleiter in dieser Phase schon aktiv beteiligt ist. Eventuell wird während einer Bedarfsermittlung auch schon ein Rahmenkonzept erstellt (z. B. Orientierung an unternehmensweitem Datenmodell, Zusammenstellung potentieller Anwendungen). Es ist sogar möglich, schon Rahmenpläne zu erstellen (Teilprojekte mit Zielen, einzusetzende Ressourcen etc.). Vorstudien sind eigentlich selbst wieder Projekte mit dem Ziel, die Machbarkeit eines größeren Projektes zu analysieren und ein Rahmenkonzept sowie Rahmenpläne zu erstellen: Während der Designphase des Vorprojektes kann eine so genannte Systemanalyse durchgeführt werden, während der Fertigungsphase sollten ein oder mehrere Konzepte erstellt werden, und während der Einführungsphase sollte ein Konzept ausgewählt und eine Entscheidung für das eigentliche Projekt getroffen werden. Review Genehmigung einer Anforderungsliste von Ausschreibungsunterlagen eines Lastenheftes, welches die wesentlichen Projektziele beschreibt (d. h. Funktionalität, Qualität, grobe Kostenvorstellung, grobe Dauer) eines Rahmenkonzeptes von Rahmenplänen sowie Beschluss, die nächste Phase zu beginnen Akquisitionsphase Diese Phase erfolgt, sobald Sie wissen, dass Sie ein Projekt durchführen wollen, Ihnen aber die Mittel dafür fehlen (vor allem, wenn Sie nicht selbst der Auftraggeber sind). Die Phase kann sich direkt an die Informationsphase anschließen oder auch erst nach Verabschiedung irgendeiner Grobspezifikation erfolgen. Wenn Sie zuwenig Geld haben, müssen Sie Projektpartner und/oder Geldgeber finden. Typische Projektpartner: andere Abteilungen, externe Unternehmen anderer Branchen, europäische Unternehmen derselben Branche etc. Typische Geldgeber: der Aufsichtsrat, der Abteilungsleiter, ein anderes Unternehmen (wenn Sie z. B. einer Technologietransferstelle angehören), der bayerische Staat (Existenzgründerdarlehen etc.), die EU (Esprit etc.). 51 Draft (13. März 2015)

52 Probleme Die Akquisitionsphase kann sehr lange dauern (manchmal ein Jahr und mehr, Canfranc: 30 Jahre). Die ursprünglichen Projektziele können dabei völlig über den Haufen geworfen werden. Die zugeteilten Geld- und Zeitmittel können oft rein politischer Natur sein ( Hier haben Sie eine Million, lösen Sie das Problem in 15 Monaten! ). Als potentieller Projektleiter sollten Sie von Anfang an bei der Akquise beteiligt sein. Es gibt nichts Schlimmeres, als zum Projektleiter eines undurchführbaren Projektes ernannt zu werden (völlig überzogene Ziele bezüglich Funktionalität, Qualität, Zeit und/oder Kosten, z. B. Toll Collect in elf Monaten (Projektstart: 20. September 2000, Buchholz [2003]; Projektende: 31. August 2003, manager-magazin [2003]). Während der Akquisitionsphase werden oftmals mehr oder weniger detaillierte Pläne ausgearbeitet (Phasenpläne mit Meilensteinen, Kostenpläne, Ressourcenpläne etc.). Doch Vorsicht! Die Pläne der Akquisitionsphase sind oft politischer Natur. Es gibt Projekte, bei denen heißt es am Ende der Akquisitionsphase: Jetzt haben wir die Fördergelder. Was machen wir damit? Review Genehmigung der Finanzierung. Jetzt kann oft schon mit gutem Gewissen ein Projektvertrag zwischen Auftragsnehmer und -geber geschlossen werden (wenn bereits belastbare Rahmenkonzepte, ein Lastenheft o. Ä. vorliegen). Definitionphase (Konzeptphase) Spätestens in dieser Phase muss ein verantwortlicher Projektleiter bestimmt werden. In den ersten Teilphasen der Spezifikationsphase werden normalerweise nur grobe Zielvorstellungen formuliert und zwar vom Auftraggeber (Lastenheft). Spätestens wenn klar ist, dass ein Projekt gestartet werden soll, müssen die Ziele genau definiert und verbindlich festgelegt werden. Ein Pflichtenheft oder eine Spezifikation muss gemeinsam von Autraggeber und Auftragnehmer geschrieben werden. Hier muss genau spezifiziert werden, was zu tun ist, welche Normen einzuhalten sind, wer für was verantwortlich ist (auch der Auftraggeber hat Pflichten!), wie Probleme kommuniziert werden etc. Zunächst sollten Funktionalität und Qualität festgelegt werden. Dabei müssen messbare Erfolgskriterien festgelegt werden. Draft (13. März 2015) 52

53 Beispiel Aufsatzdienst Elektra Der Aufsatzdienst Elektra soll druckbare Aufsätze in einer Qualität besser als Fax per Internet ausliefern. Die Bearbeitung einer Bestellung durch eine Fachkraft dauert am Rechner nicht mehr als 20 Sek/Seite. Und so weiter. Beispiel Internetauftritt läuft auf allen Browsern insbesondere kann jede Seite mit jedem HTML-5-konformen Browser betrachtet werden (auch Lynx, Braille-Zeilen etc.) Barrierefreiheit läuft auch ohne JavaScript (wird wegen Sicherheitsproblemen oft sogar via Proxy herausgefiltert) und so weiter Auch strategische Ziele können formuliert werden. Die Erfüllung derartiger Ziele kann allerdings meist nicht nachgewiesen werden dann muss man auf die Aufnahme in das Pflichtenheft verzichten. Anschließend sollten Kosten und Zeit geschätzt und die anderen Ziele eventuell angepasst werden. Bei größeren Projekten werden teilweise Kosten- und Zeitpläne nur für die nächsten Schritte genauer spezifiziert und für spätere Schritte dagegen zunächst nur grob festgelegt (höhere Fehlertoleranz). Anmerkung 1 Eine Schätzung basiert auf vielen Unbekannten und macht daher keine exakten Angaben über die echten Kosten und den echten Zeitbedarf. Ein guter Projektleiter zeichnet sich dadurch aus, dass seine Schätzungen im Mittel, d. h., wenn man viele von ihm geleitete Projekt in Betracht zieht, richtig sind. Einzelne Projekte kosten mal mehr, mal weniger als geschätzt, und sie dauern mal länger und mal kürzer als geschätzt. Die Abweichungen von den realen Werten sollten umso kleiner sein, je häufiger ein Projektleiter ein Projekt derselben Art durchgeführt hat. Die Unsicherheiten hinsichtlich der Kosten und der Dauer des ersten Marsfluges sind wesentlich zahlreicher, als bei einem Architekten, der sein hundertstes Haus baut. Im ersten Fall sind Schwankungen von vielen 100 % zu erwarten, im zweiten Fall sollten sich die Abweichungen im einstelligen Prozentbereich bewegen. 53 Draft (13. März 2015)

54 Anmerkung 2 Im Pflichtenheft sollte nicht stehen, wie etwas zu realisieren ist. (Grobe) Vorgaben bezüglich der Ressourcen können allerdings über die Ziele gemacht werden (z. B.: Software muss mit vorhandener Software kompatibel sein Das ist Bestandteil der Funktionalität. Das Projekt hat 3 Mitarbeiter Das ist Bestandteil der Kostenvorgabe: Es wird Geld für 3 Mitarbeiter und 2 Rechner zur Verfügung gestellt. Das heißt aber nicht, dass nicht 6 Halbtagskräfte eingestellt werden dürften. Und so weiter.) Der Auftragnehmer sollte über die Ressourcenplanung selbstständig entscheiden können. Bei Inhouse-Ressourcen kommt es dabei allerdings häufig zu Problemen, wenn die Ressourcen auch von anderen Projekten oder Gruppen benötigt werden (z. B. Netzspezialisten, Hardware etc.). Die Lösung dieses Problems sollte allerdings nicht heißen: Jedes Projektteam versucht möglichst viele der benötigten Ressourcen zu ergattern. In seinen Vorlesungen pflegte Prof. Ulrich Güntzer zu sagen: Wer knappe Ressourcen hortet, verknappt die Ressourcen weiter. Die Lösung des Problems heißt Multiprojektmanagement (siehe Abschnitt 4.7). Review Genehmigung des Pflichtenheftes und Beschluss, die Designphase zu starten. Spätestens jetzt sollte ein Projektvertrag zwischen Auftraggeber und -nehmer geschlossen werden. Die Spezifikationphase kann sich in mehrere Teilphasen untergliedern. Dabei kann es, muss es aber nicht zu Zwischenreviews kommen. Die Definitionsphase sollte allerdings immer mit einem Review beendet werden. Dort werden sich Auftraggeber und Auftragnehmer spätestens einig, ob das Projekt gestartet wird und was dabei genau herauskommen soll. Spätestens jetzt liegt ein offizieller Starttermin für das Projekt fest. Vorbereitungsphase Nun d. h. bis zum offiziellen Starttermin ist der Projektleiter spätestens gefordert, detaillierte Pläne zu erstellen sowie sich nach geeigneten Mitarbeitern und anderen Ressourcen umzuschauen: Er weiß jetzt genau (oder sollte es zumindest wissen), was zu tun ist. Im Allgemeinen sollten die Pläne zumindest in groben Zügen bereits vorliegen. Auch ist oft schon ein Teil der zukünftigen Mitarbeiter bekannt und ein Teil der benötigten Ressourcen vorhanden. An der Feinarbeit kommt der Projektleiter allerdings nicht vorbei. Und zwar schon bevor die Designphase beginnt. Draft (13. März 2015) 54

55 Bei der Erstellung von Plänen kann ihm ein PM-Tool von Nutzen sein. Die Arbeit abnehmen kann ihm ein derartiges Werkzeug allerdings nicht, denken er (oder sie) selbst! Typische Pläne Terminpläne mit Meilensteinen Kostenpläne (Wann fallen welche Kosten an?) Ressourcenpläne (Wann werden welche Ressourcen benötigt?) Aufgabenpläne (Wer ist mit welchen Aufgaben betreut?) Qualitätssicherung (Qualitätsmanagement) Risikovorsorge (Risikomanagement) Verfahren bei nachträglichen Änderungen (Änderungsmanagement) Benutzerschulung Man beachte, dass Planung (im obigen Sinne) eigentlich ständig stattfindet. Es gibt es oft keine dedizierte Feinplanungsphase daher spreche ich auch von Vorbereitungsphase. Die Grobplanung kann schon im Rahmen der früheren Teilphasen erfolgt und genehmigt worden sein. Oder die Feinplanung liegt vollkommen in der Verantwortung des Projektleiters und bedarf deshalb überhaupt keines formalen Reviews, sondern nur eines internen Reviews durch den Projektleiter. Falls er dabei jedoch gravierende Zielkonflikte entdeckt, muss er vor Beginn der Designphase den Auftraggeber informieren, um eventuell die Ziele neu zu definieren oder das Projekt abzubrechen. Review Eine Vorbereitungsphase zwischen Zielformulierung und echtem Projektstart gibt es dennoch fast immer. Diese Phase bedarf da sie sich meist nur mit Planung und Ressourcenbeschaffung befasst nicht unbedingt eines formalen Reviews, da es den Auftraggeber nicht interessieren sollte und meist auch nicht interessiert, mit welche Ressourcen das Projekt durchgeführt wird. Auch hier gilt aber, dass zumindest der Projektleiter oder ein Projektverantwortlicher (der nicht notwendigerweise auch der Projektleiter sein muss, sondern auch eine ranghöhere Person des Auftraggebers sein kann) am Ende der Vorbereitungsphase Bilanz ziehen muss: Kann das Projekt starten oder nicht? Wenn nein, wird wiederum der Auftraggeber informiert. Fazit: Meist handelt es sich beim Vorbereitunsphasen-Review um ein projektinternes Review. 55 Draft (13. März 2015)

56 2.1.2 Designphase (Entwurfsphase) Spätestens jetzt startet das Projekt offiziell. Es sollte einen griffigen Namen und am besten ein griffiges Logo bekommen. Die Designphase ist die wesentlichste Phase, da sie das Fundament für das spätere Produkt legt. Gravierende Fehler aus der Designphase können später kaum noch ausgebügelt werden, außer wenn das Projekt im Sinne des Spiralmodells (siehe Abschnitt 2.2) realisiert wird. Wesentlich Ziel der Designphase: Festzulegen wie das Pflichtenheft realisiert wird? (Dort steht nur was realisiert werden soll.) Typische Aufgaben in der Designphase Entwicklung von Datenmodellen, Schnittstellendefinitionen, Ablaufplänen, Schaltplänen, Storyboards etc. (grobes) Mediendesign (Screendesign, Audiodesign etc. ) Erstellung von Funktionsmodellen, Simulation etc. Rapid Prototyping (evtl. schon in Vorstudie) Basteln von 3D-Modellen aus Holz, Pappe, Kunststoff (3D-Drucker!) Tests: Auswahl von geeigneter Zielhardware, -software, Programmiersprachen, Datenbanksysteme etc. Beginn der Dokumentation!!!! (Auch Lasten- und Pflichtenheft sind Bestandteil der Dokumentation Die Dokumentation sollte eigentlich schon in vollem Gange sein.) Verfahren für Wartung, Versionspflege Backup und Recovery Qualitätssicherung und Tests Datenschutz, Datensicherheit Urheberrechte, Lizenzvereinbarungen Installation in Zielumgebung Umstellung von bisherigem Verfahren auf neues (Bayerische Vereinsbank: Multimediaschulung für Windows NT) Schulung Der Projektleiter muss entscheiden, welche Designmethoden und Designwerkzeuge eingesetzt werden (z. B. objektorientierte Modellierung gemäß UML), wer welche Designaufgaben übernimmt, bis wann das Design steht etc. Außerdem muss er mit der Soll-Ist-Überwachung beginnen: Wie weit weicht das Draft (13. März 2015) 56

57 Projekt vom Plan ab? Gegebenfalls muss er gegensteuern. Darüberhinaus muss er die Schätzungen für die Folgephasen verfeinern. Hausbau ohne zentimetergenaue Baupläne: undenkbar! Softwareentwicklung ohne Datenmodell und Design: der Regelfall! (siehe S. 98 Kellner [2001]). Wunschziel: Das Design beschreibt das Produkt so konkret, dass es nur noch realisiert (= kodiert zusammengebaut, -geschraubt,... ) werden muss. Heute wird ein Projekt meist agiler gemäß einem so genannten Spiralmodell (siehe Abschnitt 2.2) durchgeführt. Hier sieht das Wunschziel etwas anders aus: Das Design beschreibt die nächste Projektversion so konkret, dass diese nur noch realisiert werden muss. Probleme Man kann keine Lines of Code vorweisen. Die Projektdauer wird in Augen des Auftraggebers künstlich verlängert. Der Auftraggeber will Ergebnisse sehen. Es blinkt und blitzt nichts. Denken ist keine Arbeit. Der Hacker unter den Entwicklern will endlich richtig programmieren. Er weiß eh, wie s geht. Schlechte Projektleitung. Mangelhafte Kompetenz/Kreativität der Beteiligten. Sich an ein Design zu halten. Zeit drängt lieber anfangen Bei vielen Firmen ist Hacking verboten (wird trotzdem gemacht). Grund: Firmen machen sich sonst von Hackern abhängig. Unwartbarer Code kann nur weggeworfen und neu geschrieben werden. Design wir oft nicht ernst genommen. Es gehört halt zu einem Projekt dazu (Kellner: Höflichkeitsakt). Man hält sich aber nicht das Design, sondern fügt es der Projektdokumentation bei. Kellner: Da ist alles sauber abgeheftet und stört nicht bei der Arbeit. Designfehler sind verdammt teuer. Beispiel: Y2K-Problem (Year-2000 problem) Zweistellige Darstellung: = = 1900 Hauptproblem: Finden von Problemcode in vielen Millionen Zeilen von Code (LOC). 57 Draft (13. März 2015)

58 Hilfsprogramme zur automatischen Umsetzung: teuer Erfolgsgarantie < 100 % oftmals wurden mehrere verschiedene Tools parallel eingesetzt Vervielfachung der Kosten Dennoch kamen die Unternehmen nicht an der Handarbeit vorbei. Bemerkung Das Argument Die Speicherplatzvorteile einer Zwei-Byte-Lösung waren vor 30 Jahren wesentlich, da Speicher knapp war. Deshalb war das Y2K-Problem unvermeidbar. zieht nicht. In zwei Byte passen mehr als Jahre. Selbst in einem Byte bringt man 256 Jahre unter. Das heißt: Zwei Byte für 100 Jahre bedeutet Speicherplatzverschnitt. Fazit: Es handelt sich ausschließlich um ein schlechtes Design. Es wurde gewählt, weil diese Art der Datumsdarstellung allgemein üblich war und ist, und sich niemand Gedanken über die Konsequenzen gemacht hat. Die Zwei-Byte-Codierung ist soweit vorbereitet, dass auch in den ersten zehn Jahren des neuen Jahrtausends die meisten Menschen die Jahre mit 00(?), 01, 02, 03,... abkürzen, anstelle von 0, 1, 2, 3,... Kaum einer schreibt , sondern oder Warum? Aus reiner gesellschaftlicher Konvention! Weitere Datums-Probleme: Unix: sec = , 3:14:08 Uhr (vgl. Wikipedia [2011d]) DOS: (vgl Tannenbaum [2002], Garantie bis 2035 Danach ist laut Redmont DOS tot) Windows95 (ohne Patch): 2000 (z. B = C3, eigene leidvolle Erfahrung; vgl. Microsoft [1999a]) Windows95 (mit Patch): Garantie bis (vgl. Microsoft [1999b]) weitere 4-Byte-Speicherplatz-Datums-Normen: ISO, Europa etc. Problemlösung: 8 Byte ˆ= sec = Jahre Wenn die Menschheit nicht länger als die Dinosaurier leben (200 Mio Jahre) reichen 7 Byte für eine sekundengenaue Darstellung. :-) Anmerkung Es gibt viele verwandte Probleme wie z. B. das 49,7-Tage-Problem (4-Byte-Zähler für millisekundengenaue Timer beginnen nach Millisekunden = 49,7 Tagen wieder bei Null), Dow-Jones-Index > etc. Beispiel Kuka Roboter GmbH: Bei einem Praktikantenbesuch erzählte mir ein Mitarbeiter, dass bestimmte Roboter alle 49,7 Tage für mehrere Stunden ausfielen. Der Fehler wurde allerdings meist erst nach 99,4 Tagen entdeckt, da Roboter normalerweise immer Samstags installiert werden, um den Arbeitsablauf nicht zu behindern (49,7 Tage später ist ein Sonntag). Draft (13. März 2015) 58

59 Geschätzte Kosten der Designfehler für das Y2K-Problem (vgl. Berghel [1998]) USA: Personenmonate, $ Kosten für Y2K-spezifische Softwareprobleme (eine derartige präzise Schätzung halte ich allerdings für Humbug) Weitere $125 Milliarden um Datenbanken und Data Warehouses zu reparieren. Weitere Schätzungen (vgl. Jansen und Neumann [1997]) Juli 1997, konkrete Aktionen von deutschen Unternehmen zur Behebung des Y2K-Problems: 4 % Planungsphase 13 % mit Korrekturen begonnen 21 % sehen keine Probleme 28 % sind unentschlossen 34 % noch keine Aktion geplant Viele Unternehmen und Behörden behandelten das Y2K-Problem lange Zeit als Randproblem, das sich irgendwie von selbst lösen sollte. Eine Mehrheit der Unternehmen hatte kein Budget für die Umstellung eingeplant. Rund 30% alle Computersysteme waren nicht Jahr-2000-kompatibel. Giga Information Group: Viele Firmen werden das Jahr 2001 nicht mehr erleben. So schlimm ist es dann doch nicht gekommen. Erfahrungsgemäß werden nur 14 % aller größeren Entwicklungsvorhaben fristgerecht fertiggestellt. Kosten (vgl. Jansen und Neumann [1997]) Spezialisten kosten 1000 DM/Tag, Tendenz steigend (Großbritannien 3000 DM/Tag) Umstellungsdauer je Programm: 20 % benötigen 35 h, 50 % benötigen 20h, 30 % benötigen 10 h 20 h/programm Personenjahr: 1600 h, DM (Anmerkung von WK: zu billig geschätzt) Kosten: $600 Milliarden weltweit (Schätzung der Gartner Group laut Jansen und Neumann [1997]) Hohe Reenineering-Kosten IT-Ersatzinvestitionen werden in den kommenden Jahren reduziert. 59 Draft (13. März 2015)

60 Beispiel ARAG (vgl. Biskamp und Kunisch-Holtz [1998], Kunisch-Holtz [1998]) 1989 provisorische Umstellung (da 10-Jahres-Policen ab 1990 nicht mehr erfasst werden konnten). Ab 1996 Analyse einer dauerhaften Umstellung. Abschluss des Projektes: 2005 bis dahin konnte man mit den Provisorien von 1989 leben. Externer Betreuer der Umstellung: Alldata, IT-Tochter der ARAG Lösung, um 3800 Datenbanken nicht auch noch neu aufbauen zu müssen: Vierstellige Jahreszahlen werden in zweistellige Felder gepackt. Saubere Lösungen werden später angestrebt. Die Alldata benötigt etwa 20 PJ um 4,6 Millionen Zeilen Code zu prüfen. Kosten: 5,6 Millionen Mark ˆ= 1,20 DM/LOC. Diese Umstellungskosten sind sehr günstig, da neuere Schätzungen von $1,50/LOC = 2,70 DM/LOC ausgehen. Grund: Nur Zeilen Problemcode. Der Rest konnte automatisch umgestellt werden. Projektleiter: Je älter ein Programm, desto spannender wird s. Die Alldata gibt keine vertragliche Garantie auf 100 % richtige Umstellung. Die Tests geschehen nicht in Simulationen, sondern in der Praxis. BHF-Bank (vgl. Biskamp und Kunisch-Holtz [1998],Biskamp [1998]) Umstellung von 6000 individuell entwickelte Anwendungen (obige Kostenschätzung: h = 80 PJ) Umstellung durch verschiedene Dienstleiter + eigene Mannschaft Probleme: Suche nach Datumsfeldern in 10 Millionen LOC Abnahmetests bei Projektende Filetransfer von und zu Partnerunternehmen (Schnittstellendefinitionen) Kosten: ca. 15 Millionen Mark (grobe Schätzung; exaktes Volumen ist unbekannt; die Bank muss auf jedem Fall zahlen) Projektleiter Moses: Wenn wir als Bank zwei Tage nicht am elektronischen Zahlungsverkehr hängen, dann sind wir aus dem Geschäft. Notfallpläne: zusätzliche Mitarbeiter werden von anderen Projekten abgezogen Draft (13. März 2015) 60

61 Vorbeugung gegen Notfälle: Cleanmanagement Das heißt, dass ein Programm, das den Jahr-2000-Abnahme-Test bestanden hat, bis zum Ende des Tests nicht mehr verändert werden darf (Ausnahme: neue Jahr-2000-Probleme). In Einzelfällen können andere Bugs monatelang nicht behoben werden. Phase I (1996): Phase II (1996/97): Strategie und Bestandserfassung Detail-Analyse und Planung Phase III (1997/98): Implementierung Phase IV (1998/99): Gesamtintegrationstests Beispiel einer typischen Design-Entscheidung Sortierverfahren: Welches ist für mein Problem geeignet? Beispiel Bubblesort (Knuth [1997]): Führe Folgendes solange durch, bis keine Vertauschung mehr stattgefunden hat: Gehe die ganze Objektliste mit Ausnahme des letzten Elements durch: Wenn das aktuelle Objekt und sein rechter Nachbar in der falschen Reihenfolge stehen, vertausche sie. Beobachtung Dieser Algorithmus hängt von keiner Programmiersprache ab. Die zu verwendende Sprache kann (relativ) unabhängig von den zu verwendenden Algorithmen gewählt werden. Der Algorithmus legt sich noch nicht auf eine Datenstruktur fest (Array, verkettete Liste, SQL-Tabelle etc.). Der Algorithmus legt sich noch nicht auf einen Elementtyp fest (Integer, String, Record etc.). Der Algorithmus legt sich noch nicht auf einen Vergleichsoperator fest (Integervergleich, Stringvergleich etc.) Der Algorithmus hat eine mathematisch bestimmbare Komplexität, nur abhängig von der Anzahl n der zu sortierenden Elemente (sofern die zugrundeliegende Datenstruktur es erlaubt, die Objektliste in linearer Zeit zu durchlaufen und zwei Elemente in konstanter Zeit zu vertauschen): im besten Fall n 1 Vergleiche, im schlechtesten Fall n (n 1) Vergleiche, im Mittel O(n 2 ) Vergleiche. Es gibt noch viele weitere Sortierverfahren (siehe beispielsweise Knuth [1997])): 61 Draft (13. März 2015)

62 Quicksort Hauptspeicherverfahren, im Mittel O(n log n), im schlechtesten Fall O(n 2 ) (oft bei bereits sortierten Mengen) Mergesort auch für Datenmengen, die nicht in den Hauptspeicher passen geeignet, im Mittel sowie im schlechtesten Fall O(n log n), im Mittel um einen konstanten Faktor langsamer als Quicksort. parallele Sortierverfahren noch Forschungsgegenstand; das theoretische Optimum liegt bei O(log n); Richard Cole hat z. B. zwei Algorithmen vorgestellt, die ein Menge von Objekten mit dieser Zeitkomplexität sortieren können, allerdings werden dafür n Prozessoren benötigt (Cole [1988]); wenn die Anzahl der Elemente auf ein paar Milliarden beschränkt ist (= alle praktischen Fälle) sind effiziente parallele Sortierverfahren mit einer fixen Anzahl von Prozessoren mit der Komplexität O(n) bekannt (Obermaier [1993]). Quicksort ist im Mittel um einen konstanten Faktor schneller als Mergesort, kann diese Geschwindigkeit aber nicht garantieren. Bubblesort ist für sehr kleine Datenmengen (< 100 Elemente) das schnellste Verfahren. Quicksort und Bubblesort sortieren in place, d. h. ohne Zusatzspeicher. Im Laufe der Designphase muss eine Entscheidung getroffen werden, welches Verfahren verwendet wird. Einflussfaktoren: Anzahl der zu sortierenden Elemente, verfügbare Datenstrukturen, verfügbare Software (Wiederverwendung), garantierte Antwortzeiten etc. Beispiel: Elemente zu sortieren, Vergleiche pro Sekunde. O(n 2 ): Vergleiche 10 6 Sekunden const 1 = 11, 6 Tage const 1 O(n log n): Vergleiche 20 Sekunden const 2 O(n): 10 6 Vergleiche pro CPU 1 Sekunde const 3 O(log n): 20 Vergleiche pro CPU 20 Mikrosekunden const 4 Quicksort kann wegen Worst-case-Komplexität keine Antwortzeiten garantieren, Mergesort schon! Aufgrund solcher and ähnlicher Probleme müssen Entscheidungen vor dem Programmieren getroffen werden. Während der Entwicklung wird oft nur mit geringen Datenmengen gearbeitet da funktioniert auch der Bubblesort die böse Überraschung kommt dann im Realbetrieb. Rucksack-Programmierung Ohne sauberes Design kommt es während der Entwicklung und noch mehr während des laufenden Betriebs im Rahmen der Wartung zur so genannten Ruck- Draft (13. März 2015) 62

63 sack-programmierung. Wenn ein im Design übersehener Sonderfall zu Problemen führt, wird ein Rucksack zum Code hinzugefügt: if <Sonderfall> then <Rucksack> else <alter Code> Viele Rucksäcke machen ein Programm unwartbar. Diese Technik kennen übrigens auch E-Techniker. Wenn sich im Platinen-Layout ein Fehler befindet, wird manchmal eine Rucksack-Platine angefertigt, die auf die ursprüngliche Platine montiert wird und die fehlerhaften Teilelemente ersetzt. Teilphasen Auch die Designphase kann in mehrere Teilphasen (mit Reviews) unterteilt werden: Entwicklung von Basiskonzepten Auswahl geeigneter Hardware, Software-Tools, Algorithmen etc. (Vergleich von 20 objektorientierten Datenbanksystemen, Vergleich von verschiedenen Präsentationstools, Leistungsmessungen verschiedener Kompressions-Algorithmen, Bestimmung der Qualität verschiedener Druckformate etc.) Implementierung eines Prototypen (rapid Prototyping) Erstellung des endgültigen Designs (Datenmodelle, Storyboards etc.) usw. Review Am Ende der Designphase muss ein Review erfolgen. Die Ergebnisse des Designs müssen dem Auftraggeber vorgestellt werden, insbesondere, wenn diese ernsthafte Änderungen an einen oder mehreren Projektzielen zur Folge haben. Die Entscheidung, die dann getroffen wird lautet wie immer: weiter (mit oder ohne Zieländerung): Das Projekt wird gemäß Design realisiert. zurück (mit oder ohne Zieländerung): Das Design wird überarbeitet. stopp: Das Projekt wird ergebnislos beendet. Es muss allen Beteiligten klar sein, dass im nächsten Schritt Designänderungen nur noch schwer durchzuführen sind und sehr teuer werden können sofern das Projekt gemäß dem Wasserfallmodell (Abschnitt 2.2) entwickelt wurde. 63 Draft (13. März 2015)

64 Jetzt ist jede Struktur, jede Oberfläche, jedes Modul, jeder Datentransfer definiert. Es darf nicht sein, dass während der Fertigungsphase neue Module und Datenstrukturen entstehen (Ausnahme: Es wurde eine explizites Änderungsmanagement etabliert). Eine bessere Alternative ist es, Design- und Fertigungsphase zyklisch abzuwechseln, um die Kosten von Designfehlern in den Griff zu bekommen (vgl. Abschnitt 2.2). Beispiel Hausbau Solange nur Architektenpläne gezeichnet werden, kann eine Wand ganz einfach verschoben oder ein zusätzliches Leerrohr eingezogen werden. Wenn die Wände aber mal stehen, sind Veränderungen nur mit zusätzlichen Kosten möglich Fertigungsphase (Entwicklung) In dieser Phase wird das Produkt realisiert. Funktionsbeschreibungen und Design liegen vor, Kreativität ist nicht mehr gefragt, gute Ideen schaden meist mehr, als dass sie nützen. Es kommt allerdings immer wieder zu Überraschungen: Probleme treten auf, die im Design nicht berücksichtigt wurden. Der Auftraggeber hat neue Wünsche (hier sind Diplomatie und starke Nerven vom Projektleiter gefordert). Auch hier gilt wieder: Ein gut durchdachtes Änderungsmanagement sollte auf keinen fehlen. Das Team folgt nicht dem Design (schlechtes Design?, schlechte Menschenführung?, Design nur Show für Management?). Typische Aktivitäten in der Entwicklungsphase: Einrichten der Entwicklungsumgebung Entwicklung von Software Erstellung von Medien-Objekten (Audio, Video, Bild, Text) Erstellung des Gesamtsystems Testen des Produktes (Funktionalität + Qualität) Realisierung von Datensicherheit, Datenschutz, Backup und Recovery etc. Schreiben des Benutzerhandbuches und anderer Dokumentationen wie Schulungsunterlagen, Systemhandbuch, Installationsanleitung etc. Draft (13. März 2015) 64

65 Vorbereitung der Projektübergabe (Systemumstellung, Abnahme durch den Auftraggeber etc.) Auch hier kann es wieder viele Teilphasen geben: Erstellung von Medien-Objekten und Systemkomponenten Integrations- und Dokumentationsphase Qualitätssicherung α-testphase β-testphase γ-testphase Reviews Am Ende einer Fertigungsphase liegt Folgendes vor: Das fertige Produkt bzw. das fertige Teilprodukt Die fertige Dokumentation bzw. die fertige Teildokumentation (Benutzerhandbuch, Systemhandbuch etc.) Nachweise über Projekterfolg in Hinblick auf die Ziele Funktionalität, Qualität, Termine und Kosten Es gibt zahlreiche weitere Produkte, die am Ende einer Fertigungsphase vorliegen können: Ausgebildete Betreuer und/oder Benutzer Anweisungen für: Installation Wartung + Versionspflege Datenschutz + Datensicherheit Backup + Recovery etc. Detailpläne für Einführung und Umstellung Der Review dient dazu, aufgrund dieser Unterlagen zu entscheiden, ob das Produkt eingesetzt bzw. das Teilprodukt als Basis weiterer Entwicklungen dient und ab wann Einführungsphase Typische Aktivitäten (evtl. auch Teilphasen): Installation in der Zielumgebung 65 Draft (13. März 2015)

66 Testen und Pilotläufe im realen Umfeld (Systemtests) Inbetriebnahme Tuningmaßnahmen Erstellung von Mängellisten (Mängel gibt es jetzt immer noch) Übergabe an die Benutzer, das Rechenzentrum, die Systembetreuer Umstellung (inklusive Unterstützung durch Projektteam bis zum erfolgreichen Abschluss der Umstellung) Analyse während des Realbetriebs Wird das Produkt korrekt genutzt? Wird es akzeptiert? Wird der erwartete Nutzen (voraussichtlich) erreicht? Greifen die Maßnahmen zu Benutzerunterstützung (Online-Hilfe!!!) Datenschutz und Sicherheit Qualitätssicherung etc. Schulung Daneben müssen Projektabschlussarbeiten durchgeführt werden: Abnahmeprotokoll Abschlussbericht + Erfahrungsbericht Testbericht Nachweis des Projekterfolges Nachkalkulation (abschließender Soll/Ist-Vergleich) Analyse von Planabweichungen (Ursachen?) Auflösung des Projektteams oder Einsatz des Teams in einem anderen Projekt Review Im Review findet die Abnahme durch den Auftraggeber statt. Achtung: Die Abnahmekriterien müssen bereits vorher schriftlich vereinbart worden sein. Insbesondere muss klar sein, welche Testergebnisse vorliegen müssen. Draft (13. März 2015) 66

67 2.1.6 Die Nutzungs- und Aufarbeitungsphase Während der Nutzungsphase müssen Wartungs- und/oder Pflegearbeiten durchgeführt werden. Wartung: Beseitigung von Problemen Pflege: Grady [1992]: Weiterentwicklung Auf 10 Fehler, die vor der Produktfreigabe durch Testen gefunden wurden, kommt ein Fehler, der nach der Freigabe gefunden wird (z. B.: Zeitsprung -Fehler wie Y2K) Es dauert die 4- bis 10-fache Zeit, um in einem umfangreichen, im Einsatz befindlichen Software-Produkt einen Fehler zu finden und zu beheben, als in einem Produkt kurz vor oder kurz nach der Freigabe. Schlechte Entwicklungsarbeit Fehlerkorrekturen während der Wartung (korrigierende Aktivitäten) Sehr schlechte Entwicklungsarbeit Neu- oder Umentwicklungen während der Wartung (sehr schlecht, aber leider weit verbreitet) Software, die erstmals freigegeben wurde, arbeitet normalerweise ineffizient, da sie noch nicht optimiert wurde. Optimierung während der Wartung (perfektionierende Aktivitäten) Änderungen in der technischen Umgebung (z. B. neue HW), der Funktionen (z. B. durch Gesetzesänderungen), der Oberflächen etc. Anpassung während der Pflege (anpassende Aktivitäten) Achtung: Wartung und Pflege machen einen Großteil des Aufwands während des Lebenszyklusses eines Produktes aus: 2/3 4/5 (67 % 80 %) des Gesamtaufwands (QUELLE FEHLT [????]). Aufarbeitungsphase Für den Projektleiter ist das Projekt beendet. Für Pflege und Wartung ist meist jemand anders zuständig. Allerdings sollten er oder besser noch das ehemalige Team das Projekt noch einmal aufarbeiten. Es gibt drei wesentliche Fragen, die beantwortet werden sollten: 1. Was leistet das Produkt, und was sollte es leisten? 2. Wie wurde im Projekt geschätzt und geplant? Wie wurden Termine und Budget eingehalten? 67 Draft (13. März 2015)

68 3. Wie war und ist die Zufriedenheit von Benutzern, Auftraggeber, Management, Team, Projektleiter und externen Partnern? Achtung: Es geht nicht um Anschuldigungen und Rechtfertigungen. Neubewertung Nach längerer Zeit (sechs bis zwölf Monaten) kann das Projektergebnis noch einmal neu bewertet werden. Hat sich der erwartete Nutzen eingestellt? Wenn nein, warum nicht? Allerdings wird dies meist nicht gemacht: Es seien keine Kapazitäten frei (Personal und Zeit). Es sei viel zukunftsorientierter nach vorne zu blicken. Ändern kann man es sowieso nichts mehr. Ja! Aber man kann viele Problemen in zukünftigen Projekten vermeiden. In seinem Roman Der Termin (DeMarco [1998]) erfindet Tom DeMarco den Job Manager der Software-Metrik-Gruppe, einen Software-Archäologen. Dessen Aufgabe ist es, alle möglichen Informationen über alte Projekte auszugraben, um damit die Schätzungen für aktuelle und zukünftige Projekte deutlich zu verbessern. Der Projektmanager Tomkins verliert dadurch seinen persönlichen Assistenten, weil dieser die besten Beziehungen zu den meisten Mitarbeitern im Unternehmen hat. Der Berater des Projektmanagers gibt einen triftigen Grund dafür an, diesen Verlust zu akzeptieren: Wir verlieren ihn nicht, wir geben ihm nur einen Job, bei dem er alle seine Talente einsetzen kann. Das ist unsere Aufgabe als Manager. Mitarbeiter dort einzusetzen, wo sie ihre Fähigkeiten und Talente am wirkungsvollsten einbringen können. Das ist es, was Management wirklich bedeutet. 2.2 Wasserfall- und Spiralmodell Das im letzten Abschnitt vorgestellte Modell wird in der Fachliteratur Wasserfallmodell genannt. Dieser Begriff geht auf W. W. Royce [1970] zurück (vgl. Wasserfall-Modell [2005]). Er verwendet zwar nicht den Begriff waterfall model, die von ihm verwendete Grafik erinnert aber an einen Wasserfall. Royce definiert dabei die Phasen: System Requirements, Software Requirements, Analysis, Program Design, Coding, Testing and Operations. Draft (13. März 2015) 68

69 Das von mir im letzten Abschnitt vorgestellte Wasserfallmodell ist im Prinzip wie folgt aufgebaut (graphisch angelehnt an Royce): Phase 1 Review 1 weiter zurück Phase 2 Review 2 weiter stop zurück Phase 3 Review 3 weiter stop zurück Phase 4 Review 4 weiter stop zurück Das Wasserfallmodell hat einen prinzipiellen Nachteil. Wenn am Ende einer großen und damit langen und teuren Phase im Review ein Problem entdeckt wird, kosten ein oder gar mehrere Schritte zurück viel Zeit und Geld. Schon Royce hatte gefordert, den Schritt von einer Phase zur nächsten (heute Review genannt) mindestens zweimal zu durchlaufen. Er schlug auch vor, einzelne Phasen je nach Komplexität mehrfach zu durchlaufen. Später hat Barry Boehm den Gedanken, einzelne Phasen mehrfach zu durchlaufen, weiterentwickelt (Boehm [1988]). Sein Modell wird durch eine Spirale visualisiert, in der bestimmte Phasen immer wieder durchlaufen werden und dabei auf die Ergebnisse des letzten Zykluses zurückgreifen. Barry Boehm nennt das Modell daher auch Spiralmodell. Er schlägt folgende vier Phasen vor, die zyklisch mehrmals durchlaufen werden: 1. Klärung der Ziele, Anforderungen und Randbedingungen 2. Risikoanalyse, Erstellung eines Prototypen 3. Implementierung und Test 4. Review (Auswertung des aktuellen Zykluses, Planung des nächsten Zykluses oder Projektende/-abbruch) stop 69 Draft (13. März 2015)

70 Ph. 1d Ph. 1c Ph. 1b Ph. 4d Ph. 4c Ph. 4b Ph. 4a Ph. 3a Ph. 1a Ph. 2a Ph. Ph. Ph. 2b 2c 2d Ph. 3b Ph. 3c Ph. 3d Am Modell von Boehm fällt auf, dass er ein großer Verfechter von Risikomanagement und Prototyping ist. Prinzipiell lässt sich jedoch sein Vorschlag auf jedes Wasserfallmodell anwenden. Die Vorteile liegen auf der Hand: Ein Rückschritt um eine oder gar mehrere Phasen ist wesentlich billiger und weniger zeitintensiv als beim Wasserfallmodell. Design-Entscheidungen werden schrittweise getroffen und anschließend gleich überprüft. Auftretende Probleme werden frühzeitig erkannt. Ich schlage daher folgendes Modell vor: Nach Abschluss der Spezifikationsphase (d. h., wenn eine Spezifikation vorliegt), werden Design und Fertigungsphase im Sinne des Spiralmodells zyklisch durchgeführt. In jedem Zyklus werden folgende Schritte durchgeführt: 1. Design 2. Implementierung 3. Test (evtl. mit Implementierung verschränkt) 4. Review/Freigabe Nach jedem Schritt wird ein internes Review durchgeführt, nach jedem Zyklus oder einer gewissen Anzahl von Zyklen wird jeweils ein großes Review mit dem Auftraggeber durchgeführt (Meilenstein). Heutzutage hat sich im Projekt-Management ein neues Modewort etabliert: agil. Man spricht von agilem Projekt-Management, agilen Prozessen etc. Das Wort agil steht dabei für leicht, flexibel. (siehe z. B. Oestreich und Weiss [2008]) Der erste Vertreter des agilen Software-Entwicklungsprozesses war das Extreme Programming von Kent Beck (Beck [2000]). Weitere Modelle, wie z. B. der Ratio- Draft (13. März 2015) 70

71 nal Unified Process (Jacobson et al. [1999], IBM [2011]) oder Scrum (Schwaber [2004]), folgten. Allen gemeinsam ist es, kurze Iterationszyklen einzusetzen. Also kann mit Fug und Recht behauptet werden, dass Boehm mit dem Spiralmodell eine der wesentlichen Grundlagen des agilen Projektmanagements eingeführt hat. 2.3 V-Modell XT (geschützte Marke der Bundesrepublik Deutschland) Dieses Kapitel basiert auf dem Aufsatz: Bundesrepublik Deutschland [2004]. Das V-Modell definiert einen Leitfaden zum Planen und Durchführen von Entwicklungsprozessen unter Berücksichtigung des gesamten System-Lebenszykluses: Es definiert die zu erstellenden Projektergebnisse. Es legt Verantwortlichkeiten eines jeden Projektbeteligten fest (Auftragnehmer + Auftraggeber). Es regelt detailliert Wer Wann Was in einem Projekt zu tun hat (auch die Kooperation zwischen Auftraggebern und -nehmern). Andere Richtlinien (ISO-Standards, Verfahrensanweisung CPM der Bundeswehr, Vorgänger V-Modell 97) sind weniger konkret, aber noch im Gebrauch. Für Projekte in Unternehmen und Einrichtungen des öffentlichen und militärischen Bereichs gedacht sowie für Behörden und Dienststellen des Bundes und der Bundeswehr. Auch für kleine mittelständische Unternehmen geeignet. Vertragsgrundlage, Arbeitsanleitung, Kommunikationsbasis Anwendbar auf möglichst viele Projektkonstellationen (Anpassung an konkretes Projekt heißt Tailoring). Zweistufiges Verfahren für Pflege und Erweiterung des V-Modells selbst; Innovationszyklen in vergleichsweise kurzen Abständen. (Fast) jedes Projekt, das gemäß dem V-Modell durchgeführt wird, besteht aus zwei Projekten: einem Projekt aus Sicht des Auftraggebers (AG) und einem Projekt aus Sicht des Auftragnehmers (AN). Für Projektphasen, die von beiden gemeinsam beendet werden, müssen jeweils bestimmte, während der Projektphase vom AN oder AG erstellte Dokumente von beiden akzeptiert werden. 71 Draft (13. März 2015)

72 AG AN AG AN AG AG Lastenheft AN Projekt 1 Projekt 2 Anforderungen3 Projekt 4 Angebot 5 genehmigt definiert festgelegt ausgeschrieben abgegeben AG AN Projekt 6 beauftragt Vertrag AN System 7 spezifiziert AG AN Änderungsplan festgelegt 14 Verifizierung Validierung Pflichtenheft Änderungsmanagement AG AN Abnahme erfolgt 13 AN Lieferung 12 durchgeführt AG AN Projekt 15 abgeschlossen Abschlussbericht System entworfen AN 8 System integriert AN 11 AN Feinentwurf 9 abgeschlossen AN Systemelemente realisiert 10 Spezifikation und Zerlegung Realisierung und Integration Zyklen möglich (über Änderungspläne) Dieser allgemeine Phasenplan kann durch Tailoring für ein bestimmtes Projekt konkretisiert werden. Zum Beispiel kann ein Projekt mit zwei Zyklen definiert werden: 1. Zyklus: Entwicklung eines Prototyps 2. Zyklus: Entwicklung des eigentlichen Systems Besonderheiten des V-Modell XT eine Systementwicklung = zwei V-Modell-Projekte (Systementwicklungsprojekt eines Auftraggebers + Systementwicklungsprojekt eines Auftragnehmers) Schnittstellen zwischen beiden Projekten sind genau beschrieben Ausschreibung enthält Lastenheft + Vorgaben für Projekthandbuch Draft (13. März 2015) 72

73 Projekt 1 genehmigt Projekt definiert 2 Anforderungen festgelegt 3 Projekt 4 ausgeschrieben Prototyp Projekt 6 beauftragt Abnahme erfolgt 13 Änderungsplan festgelegt 14 System Projekt 6 beauftragt Abnahme erfolgt 13 Projekt 15 abgeschlossen Abbildung 2.1: Phasenplan eines Systementwicklungs-Projektes mit Prototyp- Entwicklung aus Sicht des Auftraggebers (Tailoring-Ergebnis) Angebot enthält vertragsrelevante Teile des Projekthandbuches + Qualitätssicherungshandbuch Angebotsannahme endet mit Vertrag Pflichtenheft = Gesamtsystem-Spezifikation Projektstatusberichte: Projektfortschritt, -planung, Steuerungsmaßnahmen, Qualitätssicherung, Problem-/Änderungslisten Lenkungsausschuss + Änderungsgruppen: beide Parteien sind vertreten Zwischen- + Endprodukte werden durch Lieferung an den Auftraggeber übermittelt Validierung (Eignung des Produktes bezogen auf Einsatzzweck, Are we building the right product? ) Verifikation (Produkt stimmt mit Spezifikation überein, Are we building the product right? ) Abnahmeerklärung des Auftraggebers nach Lieferung Projektabschlussbericht des Auftragnehmers bei notwendigen Änderungen kann zu früheren Phasen zurückgesprungen werden (AG: Projekt beauftragt, Anforderungen festgelegt etc., AN: System 73 Draft (13. März 2015)

74 spezifiziert etc.) Auftragnehmer kann als Auftraggeber für Unterauftragnehmer fungieren zwei weitere Teilprojekte gemäß V-Modell große Projekte müssen in Teilprojekte unterteilt werden Tailoring: Anpassung des V-Modells an konkretes Projekt Entwicklung gemäß dem Spiralmodell ist möglich (Zyklen über das V einschließlich Änderungsmodul) AG AN AG AN AG AG AN Projekt 1 Projekt 2 Anforderungen3 Projekt 4 Angebot 5 genehmigt definiert festgelegt ausgeschrieben abgegeben AG AN Projektfortschritt überprüft 14 AG AN Projekt 6 beauftragt AG Iteration geplant AN 15 AG AN Abnahme erfolgt 13 AG AN Projekt 16 abgeschlossen AN System 7 spezifiziert System entworfen AN 8 Verifizierung Validierung AN Lieferung 12 durchgeführt System integriert AN 11 AN Feinentwurf 9 abgeschlossen AN Systemelemente realisiert 10 Spezifikation und Zerlegung Realisierung und Integration Zyklen möglich (über Änderungspläne) Abbildung 2.2: Aktualisierte Version V1.3 des V-Modell XT (V-ModellR XT Autoren [2006]) Draft (13. März 2015) 74

75 Kapitel 3 Schätzung Schätzungen (Zeit, Kosten und auch Ressourcen) werden immer schon in den ersten Projektphasen (spätestens in der Definitionsphase) erstellt und benötigt. Diese primären Schätzungen werden allerdings laufend angepasst. Hauptproblem: In den frühen Phasen eines Projektes kann der Aufwand aufgrund sehr vieler unbekannter Größen meist nicht genau abgeschätzt werden. Andererseits will der Auftraggeber wissen, was es kostet und wann es fertig ist. 1. Lösung: Man legt sich nicht fest kein Projekt 2. Lösung: Man sagt irgendein Datum und irgendeinen Preis politische Daten, die nichts mit dem Projekt zu tun haben sicherlich große Abweichungen 3. Lösung: standardisierte oder individuelle Schätzmethoden Hermann Josef Abs, Karl Valentin, Mark Twain, Winston Churchill etc.: Prognosen sind besonders dann schwierig, wenn sie sich auf die Zukunft beziehen. 1. Grundregel: Schätzungen sind keine Weissagungen, d. h. keine verbindlichen Voraussagen. 2. Grundregel: Je ferner die Zukunft, desto schwieriger sind die Schätzungen Die Schätzungen werden während des Projektes laufend überwacht und so früh wie möglich korrigiert. Also nicht erst am Ende der Projektlaufzeit (nachsehen) nachsehen, was noch zu tun ist und dann eine Verlängerung um beantragen (vgl. Toll Collect). 3.1 Die Schätzgrößen Die Zielparameter Zeit, Kosten, Funktionalität und Qualität beeinflussen die Schätzung. 75 Draft (13. März 2015)

76 Funktionalität Qualität Zeit (Dauer) - Kosten Wenn an einem Parameter gedreht wird, hat das einen Einfluss auf einen oder mehrere andere Parameter. Im Teufelsquadrat von Sneed [1987] ist die Produktivität eines Entwicklungssystems als viereckige Fläche dargestellt. Der Flächeninhalt muss (in weiten Teilen) konstant bleiben, auch wenn die Ziele geändert werden, da die Produktivität i. Allg. durch keine wie auch immer geartete Maßnahmen kurzfristig verbessert werden kann (Produktivitätsverbesserungen sind nur mit langer Vorlaufzeit möglich; DeMarco [1998]). Das heißt, wenn zum Beispiel mehr Funktionalität in weniger Zeit erstellt werden soll, leidet darunter die Qualität und die Kosten steigen (Überstunden, bessere Werkzeuge, externe Experten etc.). Noch eine Warnung: Es ist insbesondere nicht möglich, die Produktivität eines Teams durch Vergrößerung beliebig zu steigern, da der Kommunikationsaufwand wächst. Es gibt nicht nur bei Parallelrechnern keinen optimalen Speedup, sondern auch bei parallel arbeitenden Menschen. Eine Vergrößerung eines Teams hat zudem zunächst einen negativen Effekt: Neue Mitglieder müssen eingearbeitet werden, alte Mitglieder werden dadurch von ihrer eigentlichen Arbeit abgehalten. Außerdem gilt grundsätzlich: Ein überbesetztes Team leistet stets weniger als ein richtig besetztes. Das heißt aber nicht, dass sich die optimale Teamgröße im Verlauf des Projektes nicht ändern kann. Im Allgemeinen ist es gut, ein Projekt mit einem kleinen Team zu beginnen und dann, wenn alles spezifiziert ist und es nur noch um Routine-Arbeiten geht, zu vergrößern. An einem Neubau arbeiten zunächst auch nur ein paar Architekten und Bauingenieure, bevor eine große Anzahl von Bauarbeitern loslegt. Draft (13. März 2015) 76

77 Für die Schätzungen hat das folgende Auswirkungen: Bei mindestens einem Parameter sollte man einen Fehlerpuffer einplanen ( on time oder on budget evtl. auch on time and on budget mit optionalen Anteilen bei Funktionalität und/oder Qualität). 3.2 Voraussetzunggen für gute Schätzungen Für Schätzungen gelten zwei Naturgesetze : 1. Schätzungen fallen genauer aus, wenn man das zu schätzende Projekt in kleinere, voneinander möglichst unabhängige Teile unterteilt, diese einzeln schätzt und alle Schätzungen zu einer Gesamtschätzung aufsummiert. 2. Schätzungen fallen umso genauer aus, je mehr vergleichbare Projekte bekannt sind. Hausbau: Kosten für ein Einfamilienhaus können mit einer Genauigkeit von wenigen 1000 Euro ( ˆ= ca. 1 %) angegeben werden. Umzug der Bundesregierung nach Berlin: Abweichungen um mehrere 10 % sind möglich. 1. Flug zum Mond/Mars: Gesamtkosten können erst spät abgeschätzt werden Divide et Impera Das erste der beiden Naturgesetze kann man sich sehr schön an zwei einfachen Beispielen verdeutlichen. Der Pötzseil-Case (siehe Kupper [1993]) Pötzseil ist im Kölner Sprachgut das Seil, an dem der Eimer in einem Brunnen herabgelassen wird. Der Test verläuft wie folgt: Ein längeres Seil wird in zwei gleichlange Teile zerschnitten. Die eine Hälfte wird in 5-8 unterschiedlich lange Teile zerschnitten. 1. Test: Länge des halben Seils schätzen. 2. Test: Länge der Einzelstücke schätzen und Summe bilden. 3. Test: Länge der Einzelstücke nacheinander schätzen, nach jeder Schätzung wird die richtige Länge verraten. Anschließend wird wieder die Summe gebildet. 77 Draft (13. März 2015)

78 Ergebnis: Divide et Impera (teile und herrsche) führt zum Ziel. Dieser Test wurde mehrfach mit Studenten des ehemaligen Studiengangs Multimedia durchgeführt. Das Ergebnis war jedes Mal dasselbe. Die Schätzungen im zweiten und vor allem dritten Test waren deutlich besser als die Schätzungen im ersten Test. Gewicht des Eifelturms π Daumen-Schätzungen von Studenten, die die PM-Vorlesung von W. Kowarschick besuchen, streuen sehr weit (100 t bis t). (gute) Schätzung Der Eiffelturm wird in folgende Teile unterteilt: Höhe; Grundfläche eines Stahlklotzes, der entsteht, wenn die Leerräume entfernt werden; Gewicht von einem Kubikmeter Stahl: Zusammengedrückt nimmt der Eifelturm eine Fläche von ca. 2m 2m ein, die Höhe beträgt ca. 300 m, Eisen (Stahl) wiegt: 7, 8 t/m 3 (im Physikbuch nachgeschlagen: Kuchling [1976]) Gewichtsschätzung: 300 m 2m 2m 7, 8 t/m 3 = t Realität (Eiffelturm [2006]) Original-Gewicht: t ( ˆ= 4 kg/cm 2 ˆ= Erwachsener auf der Sitzfläche eines Stuhls) heutiges Gewicht: t (wg. Beton statt Stahl Rückbau geplant) Original-Höhe: heutige Höhe: 312, 27 m (mit Flagge) 324, 00 m (mit Antenne) Bei dieser Art der Schätzung kann es natürlich immer noch passieren, dass jemand die Grundfläche des Eiffelturmquaders vollkommen überschätzt, z. B. mit 10m 10m. Die daraus resultierende Schätzung (nämlich t) ist zwar deutlich besser als t, aber immer noch indiskutabel schlecht. Das heißt, bevor man über die Grundfläche des Quaders eine seriöse Aussage machen kann, muss man den Eiffelturm noch genauer analysieren, d.h. noch feingranularer unterteilen Projektphasen und -vorgänge Projektphasen Ein Projekt sollte, wie in Kapitel 2 beschrieben wurde, auf jeden Fall in einzelne Phasen unterteilt werden. Diese Einteilung kann insbesondere, wie beim Pötzseil- Case, verwendet werden, um robuste Kosten- und Zeitschätzungen zu erstellen. Draft (13. März 2015) 78

79 Die Gesamtdauer und die Gesamtkosten des Projektes lassen sich im Nachhinein ermitteln, indem man die Dauer i bzw. Kosten i der einzelnen Phasen i {1,..n} aufsummiert (wobei jeweils die Dauer bzw. Kosten des zugehörigen Reviews in den Werten Dauer i bzw. Kosten i enthalten sind): Projektdauer = n Dauer i i=1 Projektkosten = Fixkosten + n Kosten i i=1 Für Vorgänge berechnet man die Projektkosten analog. Für die Berechnung der Projektdauer dürfen jedoch nur nicht-parallel-laufende Vorgänge berücksichtig werden. Im Allgemeinen sind dies die so genannten kritischen Vorgänge (vgl. Abschnitt 4.3.1). Schätzungen zu Projektbeginn Für die Schätzung von Dauer und Kosten zu Projektbeginn hat die Einteilung in Phasen bzw. Vorgänge den Vorteil, dass Dauer und Kosten auch schon zu diesem Zeitpunkt genauer abgeschätzt werden können, als dies ohne Phaseneinteilung möglich wäre (Pötzseil-Case: Divide et Impera, teile und herrsche): Projektdauer min = n geschätzte Dauer i,min i=1 Projektdauer max = n geschätzte Dauer i,max i=1 Projektkosten min = Fixkosten + n geschätzte Kosten i,min i=1 Projektkosten max = Fixkosten + n geschätzte Kosten i,max i=1 wobei geschätzte Dauer i,min, geschätzte Dauer i,max, geschätzte Kosten i,min und geschätzte Kosten i,max Worst-Case- und Best-Case-Schätzwerte sind. Hier gilt natürlich das 2. Naturgesetz der Schätzung (Abschnitt 3.2): Je mehr vergleichbare Projekte bekannt sind, desto geringer ist die Differenz zwischen den Worst-Caseund den zugehörigen Best-Case-Schätzungen. Wie man an diesen Formeln sieht, sollte man seine Schätzungen gleich von Anfang an mit einem Unsicherheitsfaktor versehen. Im obigen Beispiel werden für jeden Projektabschnitt zwei Schätzwerte angegeben: Ein minimaler Wert (best case) und ein maximaler (worst case). In Abschnitt 3.3 werden darüber hinaus noch Dreipunkt- und Vierpunktschätzungen eingeführt: minimaler Wert, maximaler Wert, wahrscheinlichster Wert und evtl. noch die Wahrscheinlichkeit des wahrscheinlichsten Werts. Wie sagt Goldratt in jedem seiner Bücher? Murphy lebt! 79 Draft (13. März 2015)

80 Schätzungen zu im Laufe des Projektes Bei jedem Meilenstein j kann die Schätzung präzisiert werden: j Projektdauer min = Dauer i + n geschätzte Dauer i,min i=1 i=j+1 j Projektdauer max = Dauer i + n geschätzte Dauer i,max i=1 i=j+1 j Projektkosten min = Fixk. + Kosten i + n geschätzte Kosten i,min i=1 i=j+1 j Projektkosten max = Fixk. + Kosten i + n geschätzte Kosten i,max i=1 i=j+1 wobei die Schätzwerte geschätzte Dauer i,min, geschätzte Dauer i,max, geschätzte Kosten i,min und geschätzte Kosten i,max für i > j anhand der bisherigen Erkenntnisse angepasst werden können und sollten. Auf diese Weise werden die Schätzungen, d.h. die Abweichungen zwischen Minimalwerten und Maximalwerten i. Allg. immer geringer: -.+ #/% 0 #21$% "!$#&%(') *,+ # " Draft (13. März 2015) 80

81 Der Nachteil dieser Art von Schätzung ist, dass zum Zeitpunkt der Projektdefinition, wenn also ein verbindlicher Vertrag geschlossen werden soll, der u. a. die Dauer und die Kosten festlegt, i. Allg. noch keine Einteilung in Phasen vorliegt. Schätzmethoden, die zu diesem Zeitpunkt eingesetzt werden können, werden in Abschnitt 3.4, Abschnitt 3.5 und Abschnitt 3.6 vorgestellt. Projektvorgänge Die Planung und Schätzung kann sogar noch feingranularer erfolgen, wenn man eine Phase wie in Kapitel 2 beschrieben weiter in einzelne Vorgänge unterteilt. Im Gegensatz zu Phasen können Vorgänge allerdings durchaus parallel ablaufen. Für die Schätzung bzw. Ermittlung der Gesamtkosten gelten die obigen Formeln weiterhin: die (bekannten oder geschätzten) Kosten aller Vorgänge werden einfach aufsummiert (gegebenenfalls werden noch bestimmte Fixkosten hinzuaddiert). Bei der Berechnung der Gesamtdauer mit Hilfe von Vorgängen muss man allerdings berücksichtigen, dass Vorgänge i. Allg. parallel ablaufen. Hier muss man zunächst aus der Menge aller Vorgänge eine Folge von zusammenhängenden, nicht-parallel-laufenden Vorgängen wählen. Normalerweise definiert der so genannte kritische Pfad (siehe Abschnitt 4.3.1) eine derartige Folge. Allerdings ist es nicht ausgeschlossen, wenn auch nur selten der Fall, dass zwei parallele Vorgänge auf dem kritischen Pfad liegen (und es sich eigentlich um ein kritisches Vorgangsnetz handelt). Erst die kritische Kette (siehe Abschnitt 4.5) besteht mit Sicherheit aus einer zusammenhängenden Folge von nicht-parallelen Vorgängen. Gerade für die kritische Kette können die im Folgenden vorgestellten Schätzmethoden ebenfalls sehr vorteilhaft eingesetzt werden Akzeptierbare Abweichungen Schätzungen für spätere Phasen werden i. Allg. einen größeren Unsicherheitsfaktor enthalten, als Schätzungen für frühere Phasen. Dies darf allerdings nicht als Freibrief verstanden werden. Schätzungen müssen von Anfang an sorgfältig durchgeführt werden. Achtung: Die Chance, dass eine Schätzung mit einer Genauigkeit von +/- 10 % stimmt, liegt in der Spezifikationsphase bei lediglich 2/3 (Ende der Orientierungsphase) bis 4/5 (Ende der Definitionsphase). Nach dem Ende der Designphase liegt sie kontinuierlich bei ca. 9/10. (QUELLE FEHLT [????]) 81 Draft (13. März 2015)

82 Beispiel Phase 1: +/- 5 % Kostenabweichung Phase 2: +/- 7 % Kostenabweichung Phase 3: +/- 10 % Kostenabweichung. Phase n: +/- 20 % Kostenabweichung Das heißt, bei gegebenen Gesamtprojektkosten von beispielsweise Euro liegt für jede Phase eine Kostenmarge fest: Phase 1: Euro +/- 250 Euro Phase 2: Euro +/ Euro Phase 3:... Außerdem sollte der prozentuale Anteil des Aufwands der einzelnen Phasen vom Gesamtaufwand geschätzt werden. Phase 1: 5 % des Gesamtaufwands Phase 2: 30 % des Gesamtaufwands Phase 2.1: 10 % des Gesamtaufwands Phase 2.2: 20 % des Gesamtaufwands Phase 3:... Beispiele (QUELLE FEHLT [????], vermutlich InformationWeek) Bertelsmann: Hewlett-Packard: Definition: 30 % Definition: 18 % Design: 30 % Design: 19 % Codierung: % Codierung: 34 % Test: % Test: 29 % Damit können Abweichungen, die sich in einer Projektphase ergeben, auf das Gesamtprojekt fortgeschrieben werden. Solange der Projektleiter im Rahmen der vorgegebenen Zeit- und Kostenmargen bleibt, gibt es wenig Grund gegenzusteuern. Bei günstigerem Abschneiden kann er sogar einen Überschuss in die nächste Phase mitnehmen. Bei Annäherung an die Obergrenze muss er allerdings Maßnahmen ergreifen, damit er diese Grenze nicht überschreitet. Bei jedem Review sollten neue Schätzungen für die Restphasen auf Basis der bisherigen Erfahrungen stattfinden. Sind beispielsweise die Kosten bisher in jeder Phase um 3 % überschritten worden und wird der geschätzte prozentuale Zusammenhang zwischen den einzelnen Phasen nicht geändert, so heißt das, dass Draft (13. März 2015) 82

83 die Schätzkosten für die Folgephasen ebenfalls um je 3 % erhöht werden müssen (sonst müssen evtl. nur die geschätzten Gesamtkosten korrigiert werden). Andererseits können nach einem Review die Unsicherheitsintervalle i. Allg. nach unten korrigiert und die Schätzungen des prozentualen Anteils der Einzelphasen am Gesamtaufwand verbessert werden. Daraus ergeben sich neue (minimale und maximale) Gesamtkosten Schneller oder billiger als geplant ist erlaubt! Beachten Sie, dass hier für alle Schätzungen nicht ein fixer Wert, sondern ein Intervall eingeplant wurde. Oftmals wird bei Schätzungen jedoch nur ein Wert ermittelt. Viele Projektleiter interpretieren derartige Schätzungen so: Alles kostet mindestens soviel wie geschätzt und dauert mindestens so lange wie geschätzt. Das heißt, es kostet nie weniger und dauert nie kürzer als geschätzt. Höhere Kosten und längere Laufzeiten kommen dagegen sehr oft vor (und werden stillschweigend auch schon eingeplant). Die Gründe für dieses Schieflage sind meist gar nicht unseriöse Schätzungen, sondern die Angst, beim nächsten Projekt weniger Geld bzw. Zeit zu bekommen, wenn man zugibt, dass die Schätzungen (augenscheinlich) zu großzügig waren. Wenn ein Unternehmer nichts gegen dieses Angst unternimmt, dann kostet ihn das viel Geld. Ein gesundes Unternehmen weiß, dass die Realität in beiden Richtungen von einer Schätzung abweichen kann, nach oben und nach unten! Ein typisches Negativbeispiel dafür, dass diese Erkenntnis nicht immer vorhanden ist, ist das berüchtigte Dezemberfieber z. B. in Einrichtungen des öffentlichen Dienstes: Wenn zugewiesene Gelder in einem Jahr nicht vollständig aufgebraucht werden, geht der Geldgeber davon aus, dass der Bedarf prinzipiell zu hoch geschätzt wurde und kürzt die Mittelzuweisungen in den Folgejahren entsprechend. Aus diesem Grund werden spätestens im Dezember alle noch vorhandenen Geldmittel für irgendetwas ausgegeben, nur damit die Zuweisungen im nächsten Jahr nicht gekürzt werden. Aufgrund der Tatsache, dass es bei der hier vorgestellten Art der Schätzung verschiedene Schätzwerte gibt (Minimum, Erwartungswert, Maximum), sollten die Schätzungen sogar dreifach durchgeführt werden. Projektkosten/dauer unter optimalen Bedingungen Projektkosten/dauer unter normalen Bedingungen Projektkosten/dauer unter schwierigen Bedingungen (worst case ohne Katastrophen) 83 Draft (13. März 2015)

84 3.3 Schätzungen von Phasen und Vorgängen In den folgenden Beispielen beziehe ich mich stets auf Schätzungen von Zeiträumen. Für die Schätzung von Kostenspannen gelten dieselben statistische Gesetzmäßigkeiten. Mit Ausnahme von PERT (Malcolm et al. [1959], Miller [1963]) basieren die etablierten Projektmanagement-Methoden auf der so genannten Einpunkt-Schätzung: Für jede zu schätzende Dauer und jeden zu schätzenden Kostenfaktor wird ein Wert geschätzt und dann für bare Münze genommen. Das wirkliche Leben ist jedoch anders. Murphy lebt! Wenn man mich fragt, wie lange ich von zu Hause zu meinem Arbeitsplatz braucht, antworte ich 20 Minuten. Nur eigentlich sind es nie genau 20 Minuten. Mal schaffe ich es in 15 Minuten (alle Ampeln sind grün, kein Laster hält mich auf), das andere Mal stehe ich im Stau auf der B17 und komme erst nach einer Stunde an. Welche Schätzung soll ich also verwenden? 15 Minuten? (Das schaffe ich höchstens einmal in 10 Jahren habe ich dies das erste Mal seit 1998 geschafft!) 20 Minuten? (Das schaffe ich oft, selten geht es schneller, meist dauert es ein paar Minuten länger.) 60 Minuten? (Das schaffe ich so gut wie immer, meist bin ich aber viel schneller.) Wenn man einen Mitarbeiter fragt, wie lange er für einen Vorgang braucht, hängt die Antwort von seiner Erfahrung ab. Ein Anfänger würde im obigen Fall mit 15 Minuten rechnen. Er sieht die möglichen Probleme, die ihn behindern können, noch nicht und fällt mit dieser Schätzung erst einmal auf die Nase. Ein Profi antwortet 30 Minuten, wenn es sich um einen nicht so wichtigen Vorgang handelt. Bei einem wichtigen Vorgang antwortet er 60 Minuten, weil er sich sicher ist, dass er ihn in dieser Zeit auch erledigen kann. Und sein Chef und dessen Chef schlagen vorsichtshalber jeder nochmal 30 Minuten drauf, für den Fall, dass der Big-Boss das Ganze um 20 % kürzt. Und so kommt zum Schluss eine Schätzung von 96 Minuten zu Stande. Das Problem ist, das der Profi die von ihm oder seines Chefs genannte Zeit, d. h. die gesamten 96 Minuten, auch nutzen wird, da ansonsten die Schätzungen für unglaubwürdig gehalten würden (vgl. Dezemberfieber). Erschwerend kommt hinzu, dass er für die Erledigung mehr Zeit als notwendig hat und deshalb leicht dem Studentensyndrom erliegt (Abbildung 1.3). Draft (13. März 2015) 84

85 Wenn im letzten Drittel etwas schief geht, dauert die Realisierung noch länger als geschätzt, obwohl bereits sehr viel Puffer in der Schätzung enthalten war. Aus langjähriger Erfahrung kann ich Goldratts Beobachtungen bestätigen: Eine Abschlussarbeit (Bachelor, Master, Diplom) wird normalerweise erst am Stichtag, häufig sogar erst 5 Minuten vor der angegebenen Uhrzeit abgegeben oder es wird eine Verlängerung beantragt. Es kommt schon mal vor, dass eine Arbeit einige Tage zu früh abgegeben wird. Aber es passiert nur äußerst selten, dass sie einen Monat vor dem Stichtag fertig ist. Und das ist auch nur dann der Fall, wenn ein anderer triftiger Grund für diese Eile vorliegt (Student hat Zusage für Arbeitsplatz o.ä.). Wie löst man nun dieses Problem? Tom DeMarco (DeMarco und Lister [2003]) und Eliyahu Goldratt (Goldratt [2002]) schlagen vor, Unsicherheiten explizit zu managen. An Stelle eines einzigen Wertes werden für jeweils drei bis vier Schätzwerte ermittelt. bester Fall (best case) normaler Fall (normal case) evtl. zusätzlich: Wie wahrscheinlich ist dieser Fall? schlechtester Fall (worst case) Mit diesen Werten kann die Dichtefunktion einer Wahrscheinlichkeitsverteilung festgelegt werden. Goldratt und DeMarco verwenden Dichtefunktionen, die gut durch die Beta-Verteilung beschrieben werden können. Aber auch die einfachere Dreiecksverteilung leistet gute Dienste (vgl. Gartner [1999]). Dichte der Dreiecksverteilung Es seien a, b, c R mit a < b und c ]a, b[. Dann ist die Dichte f D der Dreiecksverteilung X D folgendermaßen definiert (vgl. Abbildung 3.1, Dreiecksverteilung [2006], Rinne [2003]): 2(x a) für a x c (b a)(c a) f D (x) := 2(b x) für c < x b (b a)(b c) 0 sonst Dichte der Beta-Verteilung Es seien a, b, α, β R mit a < b und α, β 1. Dann ist die Dichte f B der Beta-Verteilung X B folgendermaßen definiert (vgl. Abbildung 3.1, Beta-Verteilung [2006], Rinne [2003]): 85 Draft (13. März 2015)

86 P min Abbildung 3.1: Beta- und Dreiecksverteilung von Wolfgangs Fahrt zur HSA (x a) α 1 (b x) β 1 f B (x) := B(α β)(b a) α+β 1 für a x b 0 sonst Dabei ist die Beta-Funktion folgendermaßen definiert: 1 B(α, β) := t α 1 (1 t) β 1 dt = 0 Γ(α) Γ(β) Γ(α + β) Die Beta-Funktion kann also durch die Gammafunktion, das ist die Verallgemeinerung der Fakultätsfunktion n!, ausgedrückt werden (Bronstein und Semendjajew [1980]). Der Punkt c, an dem die Dichte jeweils ihr Maximum annimmt, heißt Modus (engl. mode). Der Wert, den sie dort annimmt wird Modalwert genannt. Unabhängig davon, welche der beiden Wahrscheinlichkeitsverteilung man verwendet, sagt diese für das Beispiel der Fahrt zur HSA aus, dass Wolfgang spätestens nach 60 Minuten mit Sicherheit am Ziel ist. Dies entspricht allerdings nicht der Realität. Wolfgang kann auch einen Unfall haben und erst Tage oder Wochen später oder auch gar nicht mehr kommen. Während man extrem lange Verzöge- Draft (13. März 2015) 86

87 rungen theoretisch auch mit extrem langgezogenen Beta-Verteilungen modellieren kann wird der Fall, dass ein Vorgang und damit evtl. das ganze Projekt nicht beendet werden kann, von den vorgestellten Verteilungsfunktionen nicht erfasst. Dies könnte man allerdings mit rechtsseitig unbegrenzten Verteilungen, wie z. B. der F-Verteilung (Rinne [2003]), der Log-Normalverteilung (Rinne [2003]) oder der Weibull-Verteilung (Rinne [2003]) modellieren. DeMarco und Lister [2003] schlagen dagegen vor, den vollständigen Projektabbruch als ein explizites Risiko zu modellieren. Im Folgenden gehen wir jedoch davon aus, dass die Dauer eines Vorgangs mit einer Dreipunktschätzung (d. h. mit einer Dreiecksverteilung oder Beta-Verteilung) oder einer Vierpunktschätzung (d. h. mit einer Beta-Verteilung, bei der auch der Modalwert, d. h. die Höhe der Dichte am Punkt c geschätzt wird) hinreichend genau beschrieben werden kann. Verteilungsfunktionen Welche Informationen hält die Dichtefunktion, die für eine Schätzung ermittelt wird, für uns bereit? Um diese Frage zu beantworten, muss man sich ein wenig genauer mit den Eigenschaften von Wahrscheinlichkeitsverteilung befassen. Zu jeder stetigen Dichte f(x) gibt es die Wahrscheinlichkeitsverteilungs-Funktion F (x): P (X x) := F (x) := x f(t) dt Für die Dreiecksverteilung X D gilt (Dreiecksverteilung [2006]): 0 für x < (x a)2 für a x c (b a)(c a) F D (x) := 1 + (b x)2 für c < x b (b a)(b c) 1 für b < x Damit kann man z. B. berechnen, wie wahrscheinlich es ist, dass Wolfgang spätestens nach 20 Minuten in der HSA ist (a = 15, b = 60, c = 20) F D (20) = 0 + (20 15) 2 (60 15)(20 15) = = 1 9 ˆ= 11, 1 % Es ist schon erstaunlich, dass ich es im Schnitt nur jede zweite Woche an einem Tag wirklich in 20 Minuten oder weniger schaffe (wenn man diese Verteilung zu Grunde legt). Man kann die Frage auch umkehren. Wie viel Fahrtzeit muss ich einplanen, damit ich in 50 % oder gar 95 % der Fälle rechtzeitig ankomme? 87 Draft (13. März 2015)

88 Dies kann mit Hilfe der Umkehrfunktion F 1 für die Verteilungsfunktion F berechnet werden: { FD 1 a + (b a) mp für p m (p) := b (b a) (1 m)(1 p) für p > m wobei m := c a b a F 1 (p) wird p-quantil oder p-perzentil genannt (wobei F eine Verteilungsfunktion ist, für die F 1 existiert). Das 50 %-Quantil und das 95 %-Quantil berechnen sich für unser Beispiel wie folgt: m = = 5 45 = 1 9 FD (1 1 (0, 5) = 60 (60 15) 1 )(1 0, 5) 9 8 = = 30 FD (1 1 (0, 95) = 60 (60 15) 1 )(1 0, 95) 9 8 = , 05 9 = 50 Um also in 50 % der Fälle rechtzeitig an die HSA zu kommen, müsste ich 30 Minuten Fahrtzeit einplanen. Und 50 Minuten Fahrzeit ergeben sich, wenn ich bei 95 % aller Fahrten rechtzeitig ankommen wollte. Die Realität sieht allerdings anders aus. Staus passieren in der Früh nur sehr selten. 50 Minuten vorher fahre ich definitiv nicht von zu Hause los. Die Beta-Verteilung X B beschreibt die reale Situation besser. Ihre Verteilungsfunktion ist folgendermaßen definiert (Statistik [2006]): F B (x) := x f β (t)dt Leider lassen sich weder die Verteilungsfunktion F B noch die zugehörige Umkehrfunktion FB 1 der Beta-Verteilung mit geschlossenen mathematischen Formeln beschreiben, sondern müssen algorithmisch (z. B. mit Fixpunktiteration) ermittelt werden. Tools wie Mathcad (PTC [2011]) stellen allerdings geeignete Funktionen zur Verfügung. Draft (13. März 2015) 88

89 4. Punkt 1. Punkt 3. Punkt 2. Punkt Abbildung 3.2: Beta-Verteilung Die obige Beta-Verteilung liefert bessere Schätzwerte als die Dreiecks-Verteilung. Folgende Parameter liegen der Grafik zu Grunde: a = 15, b = 60, c = 20, α = 1, 738, β = 6, 908. Die Parameter α und β wurden so gewählt, dass der Modalpunkt von f B bei c liegt und dort den Wert 0,075 annimmt. F B (20) = 0, 284 ˆ= 28, 4 % FB 1 (0, 5) = 23 (50 %-Quantil = Median) F B 1 (0, 95) = 35 (95 %-Quantil) Das heißt, in knapp 30 % der Fälle schaffe ich es wirklich in 20 Minuten oder weniger. Wenn ich 23 Minuten einplane, bin ich in 50 % aller Fälle pünktlich. Gehe ich sogar 35 Minuten vor einem geplanten Termin aus dem Haus, komme ich nur noch in 5 % der Fälle zu spät. Diese Zeiten treffen die Realität schon ganz gut. In Wirklichkeit komme ich nur in höchstens 2% der Fälle zu spät, wenn ich 35 Minuten Fahrzeit einplane. Das heißt, der Wert am Modalpunkt wurde mit 0,075 vermutliche etwas zu niedrig gewählt Erwartungswert und Standardabweichung Das 50 %-Quantil (der Median) kann relativ gut mit dem Erwartungswert abgeschätzt werden. 50 %-Quantil und Erwartungswert unterscheiden sich allerdings 89 Draft (13. März 2015)

90 umso mehr, je unsymmetrischer die Verteilung ist. Erwartungswert einer Dreiecksverteilung X D : µ(x D ) = a + b + c 3 Erwartungswert einer Beta-Verteilung X B : µ(x B ) = αb + βa α + β Für unser Beispiel ergibt sich: µ(x D ) = = 31, (50 %-Quantil) 1, , µ(x B ) = = 24, , , 91 (50 %-Quantil) Die Streuung um diesen Erwartungswert wird mit Hilfe der Standardabweichung berechnet: σ(x D ) = b a 2(1 m + m 6 2 ), wobei m = c a b a σ(x B ) = b a α + β αβ α + β + 1 Für unser Beispiel ergibt sich: σ(x D ) = 6 σ(x B ) = , , 91 2( (1 9 2 )) = 10, 1 1, 74 6, 91 1, , = 5, Zentraler Grenzwertsatz der Statistik Zur Abschätzung der Gesamtdauer einer Folge von Vorgängen, bei denen die jeweilige Einzeldauer mit Hilfe irgendwelchen Verteilungen (Dreieecksverteilung, Beta-Verteilung etc.) geschätzt wird, kann mit dem zentralen Grenzwertsatz der Statistik (Bronstein und Semendjajew [1980]) erfolgen. Dieser besagt, dass unter bestimmten Voraussetzungen, die Summe einer Menge von Zufallsgrößen X 1,..., X n angenähert normalverteilt ist. Der Erwartungswert, die Varianz und die Standardabweichung dieser Normalverteilung können dabei wie folgt abgeschätzt werden: Draft (13. März 2015) 90

91 ( n ) µ X i n µ(x i ) i=1 i=1 ( n ) n V ar X i V ar(x i ) i=1 i=1 und da die Standardabweichung die Wurzel aus der Varianz ist: ( n ) 1 σ X i n (1 σ(x i )) 2 i=1 i=1 ( n ) 2 σ X i n (2 σ(x i )) 2 i=1 i=1 ( n ) 3 σ X i n (3 σ(x i )) 2 etc. i=1 i=1 Der Erwartungswert der Summe ist also ungefähr gleich der Summe der Erwartungswerte und die Varianz der Summe ist ungefähr gleich der Summe der Varianzen. Besonders interessant ist, dass die Standardabweichung der Summe ungefähr gleich der Wurzel aus der Summe der Quadrate der einzelnen Standardabweichungen ist. Dieser Wert ist i. Allg. deutlich kleiner als die Summe σ(x i ) der einzelnen Standardabweichungen. Das heißt, die Streuungen der einzelnen Verteilungen heben sich zum Teil gegenseitig auf! Man kann davon ausgehen, dass jedes normale Projekt die Voraussetzungen (Bronstein und Semendjajew [1980]) des Zentralen Grenzwertsatzes erfüllt: Die Schätzungen der einzelnen Phasen oder Vorgänge sind voneinander unabhängig, die Schätzungen sind sind klein verglichen mit der Gesamtsumme (d. h. es gibt keine Phasen oder Vorgänge, die einen Großteil des Gesamtprojektes ausmachen), es gibt zahlreiche Vorgänge etc. Standardabweichung Mit Hilfe der Standardabweichung kann die Unsicherheit einer Abschätzung quantifiziert werden. Für eine Normalverteilung gilt dabei die 68/95/99,7-Regel (vgl. Jann [2005]): P (µ 1σ X µ + 1σ) 68 % P (µ 2σ X µ + 2σ) 95 % P (µ 3σ X µ + 3σ) 99, 7 % 91 Draft (13. März 2015)

92 Draft (13. März 2015) 92 Abbildung 3.3: Standardabweichungen der Normalverteilung

93 Das heißt, mit einer Wahrscheinlichkeit von 68 % liegt der Schätzwert im Intervall [µ 1σ, µ + 1σ] etc. (siehe Abbildung 3.3). Allerdings ist diese Regel für das Projektmanagement nicht sonderlich geeignet, da Projekte, die früher fertig werden als geplant, nie ein Problem darstellen (oder zumindest nie darstellen sollten). Daher propagiere ich, dass im Projektmanagement die (von mir so genannte) 84/98/99,9-Regel eingesetzt werden sollte: P (X µ + 1σ) 84 % P (X µ + 2σ) 98 % P (X µ + 3σ) 99, 9 % Das heißt, mit einer Wahrscheinlichkeit von 84 % liegt der Schätzwert im Intervall ], µ + 1σ] etc. (siehe Abbildung 3.3), wobei man im Projektmanagement getrost durch 0 ersetzen kann, da es keine negativen Projektlaufzeiten gibt. Um beispielsweise für eine Folge von Phasen oder kritischen Vorgängen abzuschätzen, bis zu welchem Zeitpunkt alle Vorgänge mit ca. 84%, 98% oder gar 99,9 % Wahrscheinlichkeit beendet sind, geht man daher folgendermaßen vor: 1. Man ermittelt für alle Phasen (oder kritischen Vorgänge) den jeweiligen Erwartungswert µ i und die Standardabweichung σ i ; 2. Man berechnet den Erwartungswert und die Standardabweichung der Summe der Vorgänge: µ = n i=1 µ i, σ = ni=1 σ 2 i ; 3. Man berechnet den Wert µ + σ, µ + 2σ oder µ + 3σ, je nach gewünschter Sicherheit. Beispiel Gegeben seien fünf Phasen. Für diese werden folgende Schätzungen ermittelt (a=minimum, b=maximum, c=erwarteter Wert, p(c)= Modalwert): a c b p(c) Verteilung µ i σ i Dreiecksverteilung 5,33 1, ,13 Beta-Verteilung 8,33 2, ,87 Beta-Verteilung 6,10 0, ,21 Beta-Verteilung 5,00 1, ,5 Beta-Verteilung 6,10 0,74 Summe 30,87 7,31 σ = σ1 2 + σ2 2 + σ2 3 + σ2 4 + σ2 5 = 3,78 < 7,31 µ + 1σ = 30, ,78 = 34,65 µ + 2σ = 30, ,78 = 38,43 µ + 3σ = 30, ,78 = 42,21 93 Draft (13. März 2015)

94 Abbildung 3.4: Simulation und Schätzung: Dauer von fünf Phasen Abbildung 3.5: Zugehöre Dichtefunktionen Die zugehörigen Dichtefunktionen sind in Abbildung 3.5 zu sehen. In Abbildung 3.4 wird die Schätzung der Gesamtdauer für die zuvor geschätzten fünf Projektphasen illustriert. Das Histogramm (durchgezogene Linie) wurde mit Hilfe einer Monte-Carlo-Simulation (Gellert und Kästner [1979]) ermittelt: Dabei wurde mal für jede Phase ein Zufallswert gemäß der geschätzten Verteilungsfunktion berechnet. Diese fünf Schätzwerte wurden jeweils zu einer Gesamtsumme addiert. Der jeweilige Histogrammwert gibt an, wie oft der jeweilige x-wert Draft (13. März 2015) 94

95 (Dauer in Tagen) erzielt wurde. Die gepunktete Linie visualisiert die Normalverteilung, die mit Hilfe des Zentralen Grenzwertsatzes aus den fünf Dichtefunktionen berechnet wurde. Sie wurde so skaliert, dass die Höhe mit der Höhe des Histogramms übereinstimmt. Für diese Verteilung wurden der Erwartungswert µ = (Tage) sowie das 2σ-Intervall [µ 2σ, µ + 2σ] = [23.31, 38.43] eingetragen. Die Schätzung gemäß dem zentralen Grenzwertsatz besagt also, dass das Projekt mit einer Wahrscheinlichkeit von 95 % innerhalb von 23 bis 38 Tagen fertig gestellt wird. Noch wichtiger ist das Ergebnis der 84/98/99,9-Regel: Das Projekt wird mit einer Wahrscheinlichkeit von 98 % in maximal 38 Tagen fertiggestellt. Wie man an der Monte-Carlo-Simulation deutlich erkennen kann, ist diese Schätzung etwas zu pessimistisch. Eigentlich liegen der Erwartungswert und das 95 %-Intervall einen Tag früher. Das kommt daher, dass lauter linkslastige Schätzungen verwendet wurden. Daran, dass selbst bei lediglich fünf Phasen die Abweichung unter 5 % liegt, sieht man, wie gut der zentrale Grenzwertsatz funktioniert. Die Ungenauigkeit, die sich durch die Verwendung des Grenzwertsatzes ergibt, beträgt lediglich einen Tag. Bei 15 Phasen (siehe Abbildung 3.6) ist die Abweichung schon nicht mehr der Rede wert (unter 1 %). Abbildung 3.6: Simulation und Schätzung: Dauer von 15 Phasen 95 Draft (13. März 2015)

96 Anmerkung 1 Die84/98/99,9-Regel besagt, dass, wenn man für jedes Projekt lediglich 1σ als Gesamtpuffer vorsieht, jedes sechste Projekt nicht rechtzeitig fertiggestellt wird (zumindest, wenn man den Puffer auch wirklich als Puffer benutzt; vgl Abschnitt 4.5). Daher ist ein 1σ-Puffer sicher ein guter Kompromiss, wenn man den Kunden kurze Projektlaufzeiten anbieten und dennoch einen Gewinn aus dem Projektergebnissen erzielen möchte. Anmerkung 2 Warum gilt eigentlich der zentrale Grenzwertsatz nicht für die Fahrt von Königsbrunn zur HS Augsburg? Dieser Weg kann ebenfalls in viele Abschnitte unterteilt werden (Weg von der Haustür zur Garage, Wohnweg, Straße 1, Straße 2,...) und für jeden dieser Abschnitte könnte eine individuelle Schätzung vorgenommen werden. Die Summe aller dieser Schätzungen sollte nach dem zentralen Grenzwertsatz eine Normalverteilung und keine Beta-Verteilung ergeben. Warum schätze ich den Fahrweg dennoch mit einer Beta-Verteilung ab? Der Satz wäre anwendbar, wenn die äußeren Bedingungen jedes Mal dieselben wären. Allerdings ändern sich diese Bedingungen von Tag zu Tag für den gesamten Weg: Sonne, Regen, Schnee, Ferienzeiten, Vorlesungsbeginn etc. wirken sich auf alle oder fast alle Teilabschnitte des Weges gleichermaßen aus. Bei schönen Wetter während der Osterferien brauche ich 15 bis 20 Minuten. Bei Schnee um 7:30 Uhr in der Früh im schönsten Berufsverkehr sind 30 Minuten Fahrzeit dagegen unrealistisch wenig. Diese Erkenntnis gilt auch für Projekte. Wenn sich die Rahmenbedingungen drastisch ändern (z.b. weil eine neuer Chef die Abteilung leitet), kann das Auswirkungen auf die Laufzeiten aller Vorgänge gleichermaßen haben. Dies wird von Schätzungen, die gemäß dem zentralgen Grenzwertsatz erfolgen, nicht berücksichtigt. Bei so einer fundamentalen Änderung müssen alle Einzelschätzungen an die neuen Gegebenheiten angepasst werden. Draft (13. März 2015) 96

97 3.3.3 Weitere Verteilungen für Mehrpunktschätzungen Es gibt zahlreiche Dichte-/Verteilungsfunktionen, die zur Ermittlung von µ- und σ-werten herangezogen werden können. Beispiele: Einpunkt-Schätzung fertig nach c Tagen Kosten in Höhe von c Geeignete Dichte- bzw. Verteilungsfunktionen sind zum Beispiel: unendlich 1 c c Sicheres Ereignis Dichte Verteilung c Normalverteilung (Standardabweichung ist fix) Zweipunkt-Schätzung frühestens fertig nach a Tagen, spätestens fertig nach b Tagen, oder an Stelle von b: vermutlich fertig nach c Tagen (höchste Wahrsch.) minimale Kosten a, maximale Kosten b, oder an Stelle von b: vermutliche Kosten c (höchste Wahrsch.) Geeignete Dichte- bzw. Verteilungsfunktionen nutzen jeweils zwei dieser Schätzwerte und definieren für andere Freiheitsgrade gegebenenfalls geeignete Defaultwerte. Beispiele: a b Rechtecksverteilung a b Normalverteilung a c F Verteilung, Log Normalverteilung... Normalverteilung: a = µ 2σ, b = µ + 2σ µ = b+a 2, σ = b a 4 97 Draft (13. März 2015)

98 Dreipunkt-Schätzung frühestens fertig nach a Tagen, spätestens fertig nach b Tagen, vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit), oder an Stelle von b: d = p(c) (Modalwert) minimale Kosten a, maximale Kosten b, vermutliche Kosten c (höchste Wahrscheinlichkeit), oder an Stelle von b: d = p(c) (Modalwert) Geeignete Dichte- bzw. Verteilungsfunktionen nutzen jeweils drei Schätzwerte und definieren für andere Freiheitsgrade gegebenenfalls geeignete Defaultwerte. Beispiele: d c b Dreiecksverteilung a Beta Verteilung a c b F Verteilung, a c Log Normalverteilung... Vierpunkt-Schätzung frühestens fertig nach a Tagen, spätestens fertig nach b Tagen, vermutlich fertig nach c Tagen (höchste Wahrscheinlichkeit), d = p(c) (Modalwert) minimale Kosten a, maximale Kosten b, vermutliche Kosten c (höchste Wahrscheinlichkeit), d = p(c) (Modalwert) Alle vier der genannten Werte werden geschätzt. Dafür eignet sich vor allem die Beta-Verteilung: d d a c b Beta Verteilung a c b Beta Verteilung Draft (13. März 2015) 98

99 PERT Für PERT wird eine so genannte Beta-Verteilung verwendet, bei der Erwartungswert und Standardabweichung folgendermaßen abgeschätzt werden: µ = a + 4c + b, σ = b a 6 6 Laut Frank Grubbs [1962] ist die Schätzung für folgende α- und β-werte korrekt: α = 3 + 2, β = 3 2 α = 3 2, β = (rechtslastig) (linkslastig) Für alle anderen Beta-Verteilungen sind diese Approximationen falsch und meist auch ziemlich schlecht. Das heißt, es handelt sich nicht um eine Beta-Verteilung, sondern um eine Pi-mal-Daumen-Regel. Im Gegensatz zur Dreiecksverteilung werden hier die drei Werte a, b und c nicht gleich gewichtet, sondern der Zeitpunkt der wahrscheinlichsten Dauer wird in Anlehnung an die Beta-Verteilung stärker gewichtet. Außerdem wird wiederum in Anlehnung an die Beta-Verteilung eine geringere Streuung als bei der Dreiecksverteilung berechnet. 3.4 Delphi-Methode Schätzungen sollten von Experten, d. h. von Personen mit Erfahrung im zu schätzenden Gebiet vorgenommen werden. Wenn man mehrere Experten unabhängig voneinander Schätzungen vornehmen lässt und die Ergebnisse dann mittelt, erhält am im Allgemeinen bessere Ergebnisse, als wenn man nur einen Experten befragt. Dieses Verfahren ist als Expertenschätzung bekannt. (Jakoby [2010]) Noch bessere Ergebnisse erhält man bei der so genannten Delphi-Methode, die von der Rand-Corporation in den 1960er-Jahren entwickelt wurde. Hier schätzen mehrere Experten zunächst unabhängig voneinander. Anschließend präsentieren sie ihre Ergebnisse den anderen Experten und begründen ihre Schätzwerte. Es ist dabei nicht notwendig, dass ein Experte den anderen überzeugt, es geht nur darum, dass sich die anderen Experten mit anderen Aspekten, die die Schätzung beeinflussen können, vertraut machen. Danach schätzt jeder Experte noch einmal. Der Mittelwert der Schätzungen wird wieder als Schätzwert genommen. (Jakoby [2010]) Die Expertenschätzung und die Delphi-Methode lassen sich natürlich problemlos so verallgemeinern, dass ein minimaler und ein maximaler Schätzwert als Ergebnis ermittelt werden. Zunächst müssen die Experten jeweils zwei Schätzwerte (Minimum und Maximum) abgeben. Und zum Schluss kann man die Minima und die Maxima entweder mitteln oder um ganz auf Nummer sicher zu gehen das 99 Draft (13. März 2015)

100 jeweils absolute Minimum und das absolute Maximum als Schätzwerte verwenden Planning Poker Eine spezielle Variante der Experten-Schätzung ist das so genannte Planning Poker, das im Jahr 2002 von James Grenning für Schätzungen in Extreme-Programming-Projekten vorgeschlagen wurde. (Grenning [2002]) Drei Jahre später machte Mike Cohn diese Methode mit seinem Buch Agile Estimating and Planning einem breiterem Publikum bekannt. (Cohn [2005]) Er hält das Markenrecht am Begriff Planning Poker und entsprechende Karten können bei ihm gekauft werden. 1 Heutzutage wird Planning Poker vor allem in Scrum-Projekten eingesetzt. Beim Planning Poker werden Schätzungen (nicht nur zu Beginn des Projektes, sondern auch regelmäßig während des Projektes) von den Teammitgliedern gemeinsam vorgenommen. Jedes Mitglied erhält einen Stapel von Karten mit Zahlwerten (z.b. 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100). Der Spielführer (Projektleiter, Scrum: Product Owner) gibt eine Story (eine Aufgabe, einen Vorgang) vor und die Teammitglieder diskutieren darüber. Anschließend schätzt jeder Spieler, wie lange die Bewältigung der Aufgabe ungefähr dauern wird (daher gibt es auch nicht für jede Zahl zwischen 1 und 100 eine eigene Karte) und legt die Karte mit der entsprechende Zahl verdeckt vor sich auf den Tisch. Auf ein Zeichen hin drehen alle Teammitglieder ihre Karten gleichzeitig um. Wenn kein Konsens vorliegt, erklären die beiden Spieler, die den niedrigsten bzw. den höchsten Wert geschätzt haben, wie sie auf diese Werte gekommen sind. Daraufhin erfolgt eine neue Schätzrunde. Dieses Verfahren führt man solange fort, bis ein Konsens erzielt wurde. Es gibt zwei spezielle Karten: Eine enthält ein Fragezeichen, mit der ein Spieler signalisieren kann, dass er keine Schätzung abgeben kann (z. B. weil ihm wichtige Informationen fehlen). Die andere enthält eine Kaffeetasse, mit der ein Spieler signalisieren kann, dass er eine Kaffee-Pause braucht. Planning Poker kann auch sehr gut verwendet werden, um Dreipunktschätzungen zu ermitteln. Man kann z. B. das Minimum, das Maximum und den Durchschnitt aller Schätzwerte der zweiten Schätzrunde als Eingabeparameter für eine Dreiecks- oder Beta-Verteilung verwenden. Oder man lässt das Team über Minimum, Maximum und realistische Dauer eines jeden Vorgangs einzeln abstimmen. 1 Tipp: Bei TNG Technology Consulting ( kann man ein oder zwei Kartendecks evtl. kostenlos erhalten. Oder man fertigt sich ein Kartenspiel mit Hilfe kleiner Karteikarten selbst an. Draft (13. März 2015) 100

101 3.5 Die Function-Point-Methode Diese Methode wurde von Alan Albrecht bei IBM in den späten 70er-Jahren entwickelt (Albrecht [1979]) und ist heute als ISO-Norm standardisiert (ISO/IEC 20926:2009 [2009]). Sie basiert auf Analogieschluss und Gewichtung. Grundidee: Ein Vorhaben wird in verschiedene Grundfunktionen zerlegt. Ursprünglich sah Alan Albrecht folgende Einteilung vor: Eingaben, Ausgaben, Abfragen, Schnittstellen, logische Datenbestände Heute kann die Function-Point-Methode jedoch für viele Projekttypen mit ganz unterschiedlichen Grundfunktionen eingesetzt werden. Dann wird für jede Grundfunktion Art (siehe oben), Umfang (z. B. LOC) und Komplexität (z. B. leicht, mittel, schwer) festgelegt. Abhängig von einer firmenspezifischen Function-Point-Funktion f(art, Umfang, Komplexität) werden jeder Grundfunktion so genannte Function Points zugeordnet. Aus der Summe der Function Points kann der Gesamtaufwand abgeschätzt werden. Abbildung 3.7: Eine mögliche Schätzfunktion für die FP-Methode 101 Draft (13. März 2015)

102 Vorteile: Nachteile: Die Kurve wird mit jedem abgeschlossenen Projekt genauer. Man hat ein robustes Schätzwerkzeug zur Verfügung. Man kann auch Dreipunkt-Schätzungen (Min, Mittel, Max) vornehmen, wenn man für jede Grundfunktion drei entsprechende Function-Point-Werte ermittelt. Die Daten vieler vergleichbarer Projekte (ähnliche Aufgaben, ähnliche Anzahl Mitarbeiter) müssen zur Verfügung stehen. Die Aufwandsschätzung (z. B. LOC) je Grundfunktion ist zu Anfang des Projektes oft problematisch. Der Function-Point-Graph ist umso nützlicher, je geringer die einzelnen Punkte von Approximationslinie abweichen. Laut DeMarco [2001] gibt es wissenschaftliche Studien, die ein hochinteressantes Ergebnis haben: Wenn man die Abschätzung des Arbeitsaufwandes nicht tagesgenau, sondern stundengenau macht (und dabei geleistete Überstunden berücksichtigt), wird die Streuung größer und nicht etwa kleiner! Fazit: Die tagesgenaue Schätzung ist viel aussagekräftiger. Der Grund dafür ist: Ein Mitarbeiter leistet jeden Tag ungefähr dasselbe unabhängig davon, ob er nur 8 Stunden arbeitet oder 12 Stunden. Überstunden haben keinerlei positiven Effekt (aber viele negative Effekte)!! Draft (13. März 2015) 102

103 3.6 COCOMO COCOMO: Constructive Cost Model COCOMO wurde in den späten Siebzigern von Barry Boehm entwickelt (Boehm [1981]) und hat sich seitdem zu einem der wichtigsten Schätzmethoden gemausert. In den Neunzigern wurde eine gründlich überarbeitete Version II vorgestellt (Boehm et al. [2000]). COCOMO wurde für das Wasserfallmodell konzipiert. COCOMO II kommt auch mit iterativen Modellen (Spiralmodell) zurecht. Alle Schätzungen von COCOMO basieren auf den so genannten Kilo Source Lines of Code (KSLOC). Man findet auch die Bezeichnung Kilo Delivered Source Instructions (KDSI). Das sind die Anzahl der ausgelieferten Befehle (Schleifen, Zuweisungen, Vergleiche), nicht einfach die Anzahl der Befehlszeilen (Lines of Code = LOC). In COCOMO II können auch Function Points, Use Cases etc. zur Schätzung herangezogen werden. Diese werden durch das so genannte Backfiring in KSLOC umgerechnet. Allerdings sind diese Werte häufig nicht sonderlich stark korreliert (Seibert [2005]). Bei COCOMO werden drei Arten von Projekten unterschieden: organic: kleines Projekt (< 50 KSLOC), kleines Team, erfahrende Programmierer, stabile Entwicklungsumgebung semi-detached: größeres Projekt ( KSLOC), Programmierer mit unterschiedlichen Erfahrungsleveln; Mittelding zwischen organic und embedded embedded: relativ groß (> 300 KSLOC), schwierige Nebenbedingungen, größere Unsicherheit, höherer Innovationsgrad Für jede Projektart können die Anzahl der benötigten Personenmonate, die Entwicklungszeit und die Teamgröße mittels einfacher Formeln aus den geschätzten KSLOC ebenfalls abgeschätzt werden. Für die Schätzmethode werden in Basic COCOMO folgende Zahlen verwendet: Personenmonate (PM) Dauer Anzahl Mitarb. organic 2, 4 KSLOC 1,05 2, 5 PM 0,38 PM/Dauer 0, 7 KSLOC 0,651 semi-detached 3, 0 KSLOC 1,12 2, 5 PM 0,35 PM/Dauer 0, 8 KSLOC 0,728 embedded 3, 6 KSLOC 1,20 2, 5 PM 0,32 PM/Dauer 0, 96 KSLOC 0,816 Bei der Schätzung gemäß Intermediate COCOMO werden neben der Anzahl der ausgelieferten Codezeilen weitere so genannte Kostentreiber berücksichtigt. Die Projektdauer wird mit folgenden Formeln ermittelt: 103 Draft (13. März 2015)

104 PM Dauer organic 3, 2 KSLOC 1,05 f 2, 5 PM 0,38 semi-detached 3, 0 KSLOC 1,12 f 2, 5 PM 0,35 embedded 2, 8 KSLOC 1,20 f 2, 5 PM 0,32 Der Effort Adjustment Factor f wird dabei durch Multiplikation von Gewichten für weitere Kostentreiber ermittelt. Für jeden von fünfzehn Kostentreiber wird der Aufwand geschätzt und gemäß der nachfolgenden Tabelle gewichtet (deutsche Übersetzung von W. Kowarschick): sehr sehr extrem Kostentreiber gering gering normal hoch hoch hoch Produktmerkmale Erforderliche 0,75 0,88 1,00 1,15 1,40 System-Zuverlässigkeit Datenbankgröße 0,94 1,00 1,08 1,16 Komplexität des Produktes 0,70 0,85 1,00 1,15 1,30 1,65 Plattformmerkmale Anforderungen an Laufzeitperformanz 1,00 1,11 1,30 1,66 Hauptspeicherbedarf 1,00 1,06 1,21 1,56 Änderungshäufigkeit der Systemumgebung 0,87 1,00 1,15 1,30 Anforderungen an Antwortzeiten 0,87 1,00 1,07 1,15 Personalmerkmale Analysefähigkeiten 1,46 1,19 1,00 0,86 0,71 SW-Entwicklungs-Fähigkeiten 1,29 1,13 1,00 0,91 0,82 Erfahrungen im Anwendungsgebiet Erfahrungen mit der Systemumgebung Erfahrungen mit der Programmiersprache Projektmerkmale Verwendung von Software- Entwicklungstools Einsatz von Software- Engineering-Methoden Anforderungen an Entwicklungsdauer Draft (13. März 2015) 104 1,42 1,17 1,00 0,86 0,70 1,21 1,10 1,00 0,90 1,14 1,07 1,00 0,95 1,24 1,10 1,00 0,91 0,82 1,24 1,10 1,00 0,91 0,83 1,23 1,08 1,00 1,04 1,10

105 Die genauesten Schätzergebnisse lassen sich mit Detailed COCOMO ermitteln. Dabei werden die Gewichte der Kostentreiber für jede Projektphase separat gemäß obiger Tabelle ermittelt. Barry Boehm teilt dabei ein Projekt in sechs Phasen ein: Analyse (Requirements) Grobentwurf (Product Design) Feinentwurf (Detailed Design) Implementierung und Modul-Test (Code and Unit Test) Integration und Test (Itegration and Test) Wartung (Maintenance) COCOMO II unterscheidet sich in einige wesentlichen Punkten von COCOMO: Function Point, UML Use Cases etc. können ebenfalls zu Schätzung herangezogen werden. Die zugehörigen Schätzwerte werden durch das so genannte Backfiring in KSLOCs umgerechnet. Allerdings sind die Umrechnungstabellen noch nicht sehr ausgereift. Bei der Entwicklung von Software kann die Wiederverwendung von Code berücksichtigt werden. Es werden drei Modelle unterschieden: Application Composition Model: für frühe Projektphasen Early Design Model: ebenfalls für frühe Projektphasen, aber vorrangig für die Evaluation von Architekturen und Entwicklungsstrategien, wenn viele Details des zu schätzenden Projektes noch unbekannt sind Post-Architecture Model: für detaillierte Schätzungen nach der Entwurfsphase Zur Abschätzung der Projektaufwandes in Personenmonaten (PM) und der Projektdauer in Monaten (M) werden in COCOMO II ähnliche Funktionen wie in COCOMO verwendet, allerdings mit anderen Parametern (die folgenden Formeln wurden vereinfacht ohne Wiederverwendung von Code und Entwicklungszeitverkürzung): wobei PM = A KSLOC E f (Projektaufwand) M = C PM F (Projektdauer) 105 Draft (13. März 2015)

106 A = 2, 94 B = 0, 91 C = 3, 67 D = 0, 28 5 E = B + 0, 01 F j j=1 F = D + 0, 2 (E B) gesetzt wird. Die fünf Faktoren F j werden projektabhängig aus den folgenden Organisationsfaktoren ermittelt: Organisationsfaktoren Erfahrungen im Produktbereich Entwicklungsflexiblität Ausgereiftheit des Entwurfs Stakeholder-Zusammenhalt Software-Prozessreife Der Effort Adjustment Factor f wird wieder durch Multiplikation von Gewichten für weitere Kostentreiber ermittelt. Dabei wurden in COCOMO II einige Kostentreiber leicht modifiziert und deren Anzahl etwas erhöht (deutsche Übersetzung gemäß Seibert [2005]). Die Gewichte wurden gegenüber COCOMO neu justiert. Produktfaktoren Erforderliche Zuverlässigkeit Datenbankgröße Produkt-/Modulkomplexität Wiederverwendbarkeit Dokumentationsumfang Plattformfaktoren Rel. Rechnerzeitnutzung Rel. Hauptspeichernutzung Plattform-Änderungsdynamik Personalfaktoren Systemanalysefähigkeit Programmierfähigkeit Draft (13. März 2015) 106

107 Anwendungserfahrung Plattformerfahrung Sprach- und Tool-Erfahrung Personelle Kontinuität Projektfaktoren Nutzung von SW-Tools Standortübergreifende Teamarbeit Verfügbare Projektzeit Für das Post-Architecture Model kommen alle siebzehn Kostentreiber zum Einsatz, für die Schätzungen der ersten Projektphasen werden nur sieben und teilweise andere Kostentreiber berücksichtigt Die Güte von Schätzverfahren Leider gibt es kein allgemeingültiges Verfahren, um präzise und verlässliche Vorhersagen zu machen. (Elzer [1994]) Faustregel: π Daumen Schätze die Größe des Codes (LOC) und teile sie durch die vom Teamleiter geschätzte Produktivität des Teams (LOC/Monat) und multipliziere dies mit dem Kosten eines Monats. Diese Regel ist nicht schlechter, als viele kompliziertere Regeln (obwohl sie nur drei Parameter berücksichtigt und nur einen linearen Zusammenhang beschreibt). Siba N. Mohanty hat 1981 ein 36-KLOC-Projekt benutzt, um die Vorhersagequalität von verschiedenen Kostenmodellen zu untersuchen. (Mohanty [1981]) Die Ergebnisse sind erschütternd (und werden im Wesentlichen von Folgeuntersuchungen bestätigt). Mohanty nimmt an, dass eine Person $ im Jahr kostet, das sind $ pro Monat. Ich schätze jetzt einfach mal, das eine Person LOC pro Jahr programmieren, testen und integrieren kann, das sind 167 LOC pro Monat oder 10 LOC pro Tag. Das Verfahren π Daumen liefert dann für das von Mohanty definierte 36-KLOC-Beispielsprojekt folgende Kostenschätzung: LOC 167 LOC/PM $/PM = $ Der Durchschnitt aller fünfzehn Schätzwerte ist ca 25 % größer: $. 107 Draft (13. März 2015)

108 Damit liegt der durch die Methode π Daumen ermittelte Schätzwert gut im Rennen. Verfahren Anzahl Kosten Dauer Einflussgrößen (Dollar) (Monate) 1 Farr und Zagorski Naval Air Dev. Center Wolverton (einfach) Wolverton (mittel) Wolverton (schwer) Kustanowitz ,6 25,8 5 Aerospace GRC SDC Price-S Walston and Felix ,77 10 Aron Schneider Doty Fazit Der höchste Schätzwert ist 7,6 mal so hoch wie der niedrigste. Das sind eigentlich keine brauchbaren Ergebnisse! Mohanty führt dieses Ergebnis darauf zurück, dass den jeweiligen Schätzmethoden firmenspezifische Schätzparameter zu Grunde liegen. Er vermutet außerdem, dass sich die einzelnen Methoden hinsichtlich der Ansprüche an die Qualität des Ergebnisses unterscheiden. Dies ist aber nur ein Spezialfall der Beobachtung, dass bei verschiedenen Unternehmen verschiedene Randbedingungen gelten. Aus der Beobachtung von Mohanty folgt, dass Schätzmethoden, die nicht auf das jeweilige Unternehmen kalibriert werden, sind nicht sonderlich aussagekräftig. Oder andersherum: Schätzmethoden, wie die Function-Point-Methode, COCO- MO etc., sind wesentlich genauer, wenn sie kalibriert werden, d. h., wenn die Schätzparameter der jeweiligen Methode durch mathematisch-statistische Analyse historischer Projektdaten an die Verhältnisse des jeweiligen Entwicklungsbereiches angepasst werden. Draft (13. März 2015) 108

109 Dieses Ergebnis wird durch eine Untersuchung von Burghardt [1995] bestätigt. Er hat 60 Projekte der Firma Siemens analysiert und COCOMO-Schätzungen mit Kalibrierung mit Standard-COCOMO-Schätzungen verglichen. Das Ergebnis dieser Untersuchung ist, dass die Vorhersagen durch die Kalibrierung wesentlich besser werden: COCOMO ohne Kalibrierung: maximaler Fehler ±20 % in 45 % der Fälle COCOMO mit Kalibrierung: maximaler Fehler ±20 % in 95 % der Fälle Prinzipiell sollte die Schätzung also phasenweise erfolgen (siehe Pötzseil-Case) und möglichst bekannte Werte aus vergleichbaren Projekten berücksichtigen (Analogieverfahren + Gewichtung, wie z. B. eine moderne Function-Point-Methode). Außerdem sollten Schätzungen nicht vom Projektleiter allein, sondern von mehreren Experten vorgenommen werden (Expertenschätzung). Deren Schätzungen sollten nicht zu weit auseinander liegen, da sonst vermutlich noch nicht alle Fakten bekannt sind und damit berücksichtigt werden (vgl. Die fünf Weisen ). Die ursprünglichen Formeln von COCOMO II wurden auf Basis von 160 Projekten ermittelt. Diese Basis ist im Laufe der Zeit auf 250 Projekte angewachsen. Für COCOMO-Varianten ist die Zahl der zugrundeliegenden Projekte dagegen teilweise noch recht gering. (Seibert [2005]) Beispiel: COCOTS zur Schätzung der Kosten für Evaluation, betriebsspezifischen Anpassung und Integration von Standardsoftware basierte im Jahr 2005 auf lediglich 20 Projekten. COCOMO II wird laut Aussage von Barry Boehm laufend weiter entwickelt. Die Umrechnungstabellen von Function Points in KSLOC sind noch großen Änderungen unterworfen. Auf die Frage, ob Backfiring bereits praktisch eingesetzt werden kann, antwortete Barry Boehm im Jahr 2005: Wir arbeiten darauf hin, haben aber ähnliche Hürden zu überwinden, wie sie die Funktionspunktleute früher hatten. (Seibert [2005]) Sechs Jahre später hat sich COCOMO zu einem wichtigen Schätzwerkzeug entwickelt. Beispielsweise bietet die Cost Xpert Tool Suite (Cost Xpert [2011a]) der Firma Cost Xpert, einem Co-Autor der COCOMO-II-Methode, COCOMO-Schätzungen an, die laut Aussage von Cost Xpert schon out of the box mit einer Genauigkeit von ±20 % aufwarten können. Bei einer Kalibrierung der Projektdatenbank auf firmenspezifische Projekte soll sogar eine Abweichung von unter ±10 % zwischen den Schätzungen und den späteren wirklichen Werten die Regel sein. (Cost Xpert [2011b]) 109 Draft (13. März 2015)

110 3.7 Was ist ein Personenmonat? Viele Zeit-Schätzverfahren liefern als Ergebnis eine Anzahl von Personenmonaten (PM). Allerdings ist der Wert nicht unproblematisch: 1. Problem Ein PJ (Personenjahr) hat nur (9 )10 PM (Personenmonate) Ein PM hat höchstens 16 PT (Personentage) und nicht etwa 20 Ein PT hat höchstens 6 Ph (Personenstunden) und nicht etwa 8 Ein PJ entspricht somit 1000 Ph effektiver Projektarbeit und nicht etwa 1600 = Das heißt, man muss sich zunächst einmal darauf verständigen, was die Begriffe PJ, PM, PW, PT und Ph eigentlich bedeuten. Balzert [1998] berechnet die Bruttoarbeitszeit wie folgt: 37-Stundenwoche 5-Tagewoche 20,8 Arbeitstage/Monat 10 Monate/Jahr (wg. Urlaub und Krankheit) 1 PT brutto = 37/5 h = 7, 4 h 1 PW brutto = 37 h 1 PM brutto = 7, 4 h 20, 8 = 154 h (153, 92 h) 1 PJ = , 9 h = 1539 h Die Nettoarbeitszeiten berechnet er einfach, indem er die 1539 h auf 12 Monate verteilt: 1 PM netto = 1539 h/12 = 128 h (128, 25 h) 1 PT netto = 128, 25 h/20, 8 = 6, 2 h 1 PW netto = 6, 2 h 5 = 31 h Dabei bleiben allerdings die Ausfallzeiten im Projekt wegen anderer Aufgaben unberücksichtigt. Draft (13. März 2015) 110

111 Ich führe daher zusätzlich den Begriff der Projektarbeitszeit ein, die nur die Arbeitszeit berücksichtigt, die ein Mitarbeiter tatsächlich für das zugehörige Projekt aufbringt (reale Projektarbeitszeit, typisch für nicht-kritische Vorgänge): 1 PT PA = 6 h 1 PW PA = 4 6 h = 24 h 1 PM PA = 17 6 h = 102 h (oder 16 6 h = 96 h) 1 PJ PA = h = 1020 h Wenn man einen Mitarbeiter von allen anderen Arbeiten entlastet, sind theoretisch auch folgende Arbeitszeiten möglich (Wunschziel zumindest für kritische Vorgänge): 1 PT PAe = 8 h 1 PW PAe = 5 8 h = 40 h 1 PM PAe = 20, 8 8 h = 166 h 1 PJ PAe = h = 1660 h Dies stimmt im Prinzip mit den von Balzert eingeführten Bruttoarbeitszeiten überein. Im Allgemeinen können jedoch nur wenige Mitarbeiter von anderen Aufgaben entlastet werden. Dies ist aber auch gar nicht notwendig. Nur die Mitarbeiter, die kritische Vorgänge bearbeiten, sollten von projektfernen Arbeiten möglichst ferngehalten werden. Vor allem im Critical-Chain-Projekt-Management (siehe Abschnitt 4.5) ist es üblich, Mitarbeiter, die an der so genannten kritischen Kette arbeiten, vollkommen von anderen Aufgaben zu entlasten. Mit welchen Begriffen man arbeitet ist letztlich egal, wenn sich alle Projektbeteiligten einig sind, was unter PJ, PM und PT zu verstehen ist. Auf eine stundengenaue Schätzung sollte man allerdings verzichten. Ein Mitarbeiter leistet an einem 12h-Tag i. Allg. weniger als an einem 8h-Tag (DeMarco [1998]). Solange nicht bekannt ist, was PJ, PM, PW und PT genau bedeutet, kann die Monatsproduktivität allerdings nicht in Jahres- oder Tagesproduktivitäten umgerechnet werden. Die Produktivität wiederum ist wichtig, um z. B. den Bedarf an Mitarbeitern für bestimmte Aufgaben zu ermitteln. Die Produktivität eines Programmierers wird häufig in LOC/PM (LOC = Lines of Code) oder NCSS/PM (NCSS = Non Commented Source Statements HP schlecht, da Kommentare nichts zählen, aber wichtig sind) gemessen. Neben dem Maß LOC gibt es natürlich noch viele weitere Maße, wie HTML-Seiten/PT, AVI-Sekunden/PW, Platinen-Bauteile/PM etc., die wesentlich von der Tätigkeit des Spezialisten abhängen. 111 Draft (13. März 2015)

112 Beispiel Aufgabe: 200 LOC-Programm erstellen (LOC = lines of code) Produktivität: 25 LOC/(d MA) Dauer: 5 d Bedarf MA = Aufwand/Dauer = (200 LOC/25( LOC/(d MA)))/5 Taged = 8 d MA/5 d = 1, 6 MA (d = Tag, MA = Mitarbeiter) Man beachte, dass die Produktivität für jede mögliche Definition von Personenmonat andere Werte hat. Wenn man davon ausgeht, dass eine Person in einem Jahr eine gewisse Leistung (z. B LOC) erbringen kann, ergibt sich folgendes Bild: 2000 LOC/PJ = 200 LOC/PM brutto = 48 LOC/PW brutto = 9, 6 LOC/PT brutto = 1, 3 LOC/Ph brutto 2000 LOC/PJ = 166, 6 LOC/PM netto = 40 LOC/PW netto = 8 LOC/PT netto = 1, 08 LOC/Ph netto 2000 LOC/PJ PA = 200 LOC/PM PA = 47 LOC/PW PA = 11, 8 LOC/PT PA = 1, 96 LOC/Ph PA 2000 LOC/PJ PAe = 200 LOC/PM PAe = 48 LOC/PW PAe = 9, 6 LOC/PT PAe = 1, 00 LOC/Ph PAe Ich mag die Messung in Bruttozeiten (= 1 Jahr hat 10 Monate) lieber, da dann die Zuordnung reale Zeit Projektzeit einfacher ist. August, Osterwoche, Pfingstwoche, 2 Wochen Weihnachten entfallen Das reale Jahr hat auch 10 Monate, in denen (voll) gearbeitet wird. Außerdem ist mir die Messung in Projektarbeitszeiten (6 h/tag, Tage/Monat) lieber, als die übliche Vollarbeitszeiten, da auch diese Werte leichter mit der Realität in Einklang zu bringen sind. Wenn ich drei Aufgaben à 6 PT PA bearbeiten lasse und erhalte nach einem realen Monat das gewünschte Ergebnis, habe ich rein rechnerisch sogar etwas Zeit gewonnen (da 18 PT PA = 1, 125 PM PA ). Ein Mitarbeiter muss im Durchschnitt etwas mehr leisten als geplant, da Krankheit und Dienstreisen den Durchschnitt drücken. Wenn man die üblichen Ferienmonate, wie oben angedeutet, intern als Nullarbeitszeiten rechnet, dann ist jede Arbeit, die die Mitarbeiter in dieser Zeit leisten, eine Mehrarbeit, die mit anderen außerplanmäßigen Fehlzeiten gegengerechnet werden kann. Draft (13. März 2015) 112

113 erstes (bereits gelöstes) Problem Alle anderen Definitionen von Personenmonaten etc. sind im laufenden Projekt schwieriger mit der Realität abzugleichen, da die vom Mitarbeiter zu leistende Mehrarbeit (gegenüber den errechneten Werten) höher ist. (größeres) zweites Problem Das Maß Ph (Personenstunde) ist unbrauchbar. Tom DeMarco (DeMarco [2001]) berichtet von wissenschaftlichen Untersuchungen (leider ohne die genaue Quelle anzugeben), die ein erstaunliche Ergebnis liefern. Eine Function-Point-Schätzfunktion wird durch Minimierung der Summe der Abstandsquadrate einer Menge von bekannten FP-Werten bereits abgeschlossener Projekte ermittelt (vgl. Abbildung 3.7). Je kleiner diese Summe der Abstandsquadrate ist, desto brauchbarer ist die Schätzfunktion. Nun sollte man vermuten, dass eine Verfeinerung der Messung auch eine Verkleinerung der Summe der Abstandsquadrate zur Folge hat. Wenn man also die Gesamtpunktzahl jedes einzelnen Projekts anhand der Personenstunden ermittelt, sollte man eine bessere Schätzfunktion erhalten, als wenn man dies Gesamtpunktzahlen anhand der Personentage ermittelt, da im ersten Fall Überstunden berücksichtigt werden und im zweiten nicht. Doch das Gegenteil ist der Fall. Wenn man die Berechnung auf Basis der Personenstunden vornimmt wird die Summe der Fehlerquadrate größer! Das heißt, dass das Maß Personentag die Produktivität der Mitarbeiter genauer beschreibt, als das Maß Personenstunde. Der Grund dafür ist, dass Überstunden so gut wie keine Auswirkung auf das Arbeitsergebnis haben: Eine Person leisten im Durchschnitt an zwei 12-Stundentagen genauso viel wie an zwei 8-Stunden- Tagen (und nicht etwa so viel wie an drei 8-Stunden-Tagen)! Fazit 1 Überstunden schaden fast immer (außer wenn man einen kurzen Endspurt hinlegt und danach eine Erholungsphase einschiebt). Laut DeMarco bringen Überstunden folgende Nachteile mit sich: Qualitätsminderung Burnout bei den Mitarbeitern Ineffiziente Nutzung der normalen Arbeitszeit Erhöhte Personalfluktuation Aus diesem Grund postuliert Kurt Beck, der Erfinder des Extreme Programming, in seinem Manifest (Beck [2000]) u. a. das Prinzip der 40-Stunden-Woche. Auch er hält Überstunden für kontraproduktiv. 113 Draft (13. März 2015)

114 Fazit 2 Schätzungen sollten immer tagesgenau und nie stundengenau vorgenommen werden. (größtes) drittes Problem Wenn eine Person in einem Monat 1 PM Arbeit leistet, heißt das nicht, dass 2 Personen in einem halben Monat auch 1 PM Arbeit leisten. Grund: Kommunikationsoverhead: Zwei Mitarbeiter müssen sich absprechen. Das heißt, wenn eine Person 8 Tage an einem Vorgang arbeitet, reichen 1,6 Personen nicht aus, um den Vorgang bereits in 5 Tagen zu erledigen (die obige Rechnung ist also fehlerhaft). Die zweite Person muss in dieser Zeit vielleicht nicht Vollzeit, aber zumindest deutlich mehr als 60 % Prozent seiner Arbeitszeit an diesem Vorgang mitarbeiten. Allgemeiner: Wenn n Personen gleichzeitig an einem Problem arbeiten, ergeben sich n (n 1)/2 2-Personen-Kommunikationskanäle, außerdem gibt es 3-Personen-Kommunikation, 4-Personen-Kommunikation... und Team-Kommunikation (Lagebesprechung etc.). Das heißt, der Kommunikationsoverhead wächst mit mindestens O(n 2 ) mit der Anzahl der an einer Aufgabe beteiligten Personen. Wenn beispielweise der Kommunikationsaufwand zwischen je zwei Teammitgliedern, die an einem Problem gemeinsam arbeiten, bei durchschnittlich 10 %, d. h. bei 4 h/woche liegt, so berechnet man die die Dauer des zugehörigen Vorgangs mittels d = 1/(MA pal), wobei pal die produktive Arbeitsleistung eines Mitarbeiters ist (die kommunikative Arbeitsleistung kal ist gleich 1 pal): 1 Person braucht 1, 0 (= 1/(1 1, 0)) Zeiteinheiten 2 Personen brauchen 0, 5 (= 1/(2 0, 9)) Zeiteinheiten 3 Personen brauchen 0, 41 (= 1/(3 0, 8)) Zeiteinheiten 4 Personen brauchen 0, 35 (= 1/(4 0, 7)) Zeiteinheiten 5 Personen brauchen 0, 33 (= 1/(5 0, 6)) Zeiteinheiten 6 Personen brauchen 0, 33 (= 1/(6 0, 5)) Zeiteinheiten 7 Personen brauchen 0, 35 (= 1/(7 0, 4)) Zeiteinheiten 8 Personen brauchen 0, 41 (= 1/(8 0, 3)) Zeiteinheiten 9 Personen brauchen 0, 5 (= 1/(9 0, 2)) Zeiteinheiten 10 Personen brauchen 1, 0 (= 1/(10 0, 1)) Zeiteinheiten 11 Personen werden gar nicht fertig :-) Oder kurz: Viele Köche verderben den Brei! Achtung: Diese Beobachtung besagt nicht, dass nicht mehrere unabhängige Vorgänge parallel ausgeführt werden können, um die Projektdauer zu beschleunigen (z. B. Tests auf verschiedenen Zielplattformen oder gleichzeitige Entwicklung von zwei unabhängigen Modulen wie Automotor und Fahrersitz). Draft (13. März 2015) 114

115 Zeit (in Tagen) kommunikative 10 Arbeitsleistung je 9 Mitarbeiter (innerhalb von 10 Tagen) 8 7 reale Arbeitszeit 6 5 theoretisches Optimum 4 3 produktive Arbeitsleistung je 2 Mitarbeiter 1 (innerhalb von 10 Tagen) Anzahl Mitarbeiter 1 MA: kostenoptimal 3 MA: bester Kompromiss aus Kosten und Zeit (evtl. 2 MA) 5 MA: zeitoptimal (theoretisch auch 6 MA) weitere Probleme Weitere Probleme bei der Bewertung, wie viele Arbeit von einer Person in einem PM geleistet werden kann, sind: 1. Verschiedene Personen leisten in derselben Zeit verschieden viel. 2. Mitarbeiter bringen nicht jeden Tag volle Leistung (Schnupfen, private Probleme, Spannungen im Team, eine versaute Präsentation etc.). 3. Neulinge, die erst später in ein Projekt integriert werden, leisten weniger, da sie sich erst einarbeiten müssen. 4. Neulinge blockieren andere Mitarbeiter, d. h., auch erfahrene Projektmitarbeiter leisten weniger, wenn sie zusätzlich einen Neuling einarbeiten müssen. wichtige Erkenntnis Hilfskräfte können Projektmitglieder von Routineaufgaben, wie Kopieren, E- Mail-Vorsortierung, Telefondienst etc. entlasten, ohne den Kommunikationsoverhead drastisch zu erhöhen. Neues Fachpersonal kann dies nicht. Ein Vier-Personen-Team plus Hilfskraft ist laut Tom DeMarco (DeMarco [2001]) nicht nur billiger, sondern auch noch effizienter als ein Fünf-Personen-Team ohne Hilfskraft. 115 Draft (13. März 2015)

116 Draft (13. März 2015) 116

117 Kapitel 4 Planung Planung ist eine der Hauptaufgaben des Projektleiters. Planung wird oft nicht sonderlich geliebt: Einfach mal loslegen ist einfacher, als vorher zu planen Planen lohne sich eh nicht, da ja doch alles anders komme. Planen behindere die Kreativität. Nein: Planung ist kreativ, planloses Herumstochern im Nebel dagegen nicht. Es gibt drei Möglichkeiten mit Planung umzugehen: Erst handeln, dann denken Es gibt viele (schlechte) Projektleiter, die Planung hassen und nur als Show für das Management veranstalten, sich im Projektverlauf aber wenig darum scheren. Fangt schon mal an, den Papierkram machen wir später. Wenn man jedoch versucht Zeit zu sparen, indem man handelt bevor man denkt, verbraucht man in der Summe viel mehr Zeit (spätere Fehlerbereinigung). Denken statt Handeln Es gibt aber auch (schlechte ) Projektleiter, die Planung zelebrieren: Alles wird geplant und analysiert (PC-Tools); Alternative über Alternative wird untersucht, nur getan wird nichts. Erst denken, dann handeln: Storming, Norming, Performing Saubere Planung besteht aus zwei Phasen, dann wird gehandelt: Storming: Norming: Ideensammlung; noch unstrukturiert (z. B. Brainstorming). Nun werden die Ideen sortiert und es wird geplant. Performing: Schließlich werden die Pläne auch durchgeführt. Brainstorming bedeutet, dass möglichst viele Ideen gesammelt werden, die nicht bewertet werden (gut/schlecht etc.). Die Stromingphase sollte lange genug dauern. 117 Draft (13. März 2015)

118 Die Planung von Projekten erfolgt normalerweise in drei Schritten: grobe Projektplanung z.b. Projektstrukturpläne feinere Projektplanung z.b. Netzpläne oder auch Balkendiagramme Detailplanung z.b. Balkendiagramme Bei kleinen, übersichtlichen Projekten werden oft keine Netzpläne, sondern nur eine einfache Grobplanung und Balkendiagramme erstellt. 4.1 Projektpläne Alles muss geplant werden viele Pläne. Diese sollten immer aktuell gehalten werden sonst sind sie nur Show und sind den Aufwand nicht wert, den man in sie investiert hat. Beispiele für Pläne Organisationsplan Verantwortlichkeiten, Kompetenzen Kommunikationsplan, Berichts- und Informationswesen Wer informiert wen wann worüber in welcher Form? Budget Wie viel, wann, von wem, wofür? Arbeitspläne Aufgaben (bzw. Vorgänge): Was, wann, wer? Personalpläne Wer, was, wann, wann nicht (Urlaub etc.)? Schulungspläne Projektteam, Anwender, Systembetreuer Ausstattungspläne Beschaffungspläne Testpläne Draft (13. März 2015) 118

119 Wartungspläne Kontrollpläne Soll/Ist-Vergleiche, Review etc. Ergebnis: stopp/zurück/weiter Änderungspläne Abbruchplan etc. Wie gesagt: Irgendwann sollte man auch etwas arbeiten. :-) 4.2 Grobplanung Bevor man Detailpläne erstellen kann, müssen erst einmal grobe Beschreibungen der Aufgaben vorliegen. Man beachte, dass die Grobplanung eine gute Basis für frühe Schätzungen darstellt Projektstrukturplan Ein Projekt sollte zunächst hierarchisch strukturiert werden: Zunächst nach Komponenten, dann nach Aktivitäten, die notwendig sind, um die Komponenten zu erstellen. Dazu dienen die sogenannten Projektstrukturpläne (PSP, engl.: work breakdown structures, WBS). In einem ersten Schritt wird der Komponenten-Projektstrukturplan (KPSP) erstellt. Bei diesem Plan handelt es sich um einen Baum, der an der Wurzel das (gewünschte) Gesamtprojekt-Ergebnis enthält. Dieses wird in Einzelkompontenten zerlegt. Und jede Einzelkomponente wird rekursiv solange in weitere Einzelkomponenten zerlegt, bis lauter Komponenten entstanden sind, deren Entwicklung jeweils in einem Arbeitspaket erfolgen kann. Dabei ist darauf zu achten, dass die Einzelkomponenten 1. möglicht unabhängig voneinander sind sowie 2. vollständig sind (also in der Summe diejenige Kompontente definieren, deren direkter Bestandteil sie sind). 119 Draft (13. März 2015)

120 Komponenten-Projektstrukturplan (KPSP) Internet Auftritt Metzgerei Meier Startseite Katalog Bestellung Fleisch Wurst Käse Sonstiges... Aktivitäten-Projektstrukturplan (APSP) Tools und Techniken auswählen Internet Auftritt der Metzgerei Meier erstellen Seitenstruktur festlegen Content beschaffen/erstellen Layout festlegen Text Fotos Videos Grafiken Web Seiten erstellen Blätter = Vorgänge Integration der erstellten Seiten Startseite erstellen Katalog programmieren Bestell komponente programmieren In einem zweiten Schritt wird der zugehörige Aktivitäten-Projektstrukturplan (APSP) erstellt. Dieser legt die Arbeitsschritte fest, die notwendig sind, um die Komponenten des KPSP zu erstellen. Der APSP enthält also im Gegensatz zum KPSP Arbeitsanweisungen. Er wird genauso wie der KPSP als Baum aufgebaut. Zunächs einmal gibt es für jede Komponente k in einem Blatt des KPSP eine zuge- Draft (13. März 2015) 120

121 Abbildung 4.1: APSP in MS Project 2010 hörige Arbeitsanweisung Komponente k erstellen. Dazu kommt für jede komplexe Komponente K, dh. für jede Komponente, die aus mehreren Einzelkompontenten besteht, die Arbeitsanweisung Alle Einzelkomponenten k der Komponente K zur Komponente K zusammenfügen. Dazu können weitere Aktivitäten kommen, die unabhängig von einzelnen Komponeten sind, wie z. B. Beschaffung von spezieller Soft- und Hardware, Vertragsverhandlungen mit Subunternehmern etc. Prerequisite-Tree (Klein et al. [2005]) fehlt noch 4.3 Feinplanung, insb. Ressourcenplanung Im Aktivitäten-Prozessstrukturplan enthalten die Blätter die so genannten Vorgänge: Definition (Vorgang) Ein Vorgang ist eine in sich abgeschlossene, genau spezifizierte Aktivität, die innerhalb einer angemessenen Zeitdauer durchgeführt werden kann. Ein Vorgang kennt genau vier Zustände: 1 noch nicht begonnen begonnen erfolgreich beendet 1 Die Angabe eines Prozentsatzes, zu dem ein Vorgang schon bearbeitet wurde, findet man zwar auch manchmal, macht aber in meinen Augen keinen Sinn. 121 Draft (13. März 2015)

122 erfolglos beendet Wenn diese Aussage für ein APSP-Blatt noch nicht zutrifft, muss der entsprechende Knoten eventuell in weitere Teilaufgaben aufgesplittet werden. Für jeden Vorgang wird Folgendes festgelegt: Name des Vorgangs Abhängigkeiten von anderen Vorgängen Zeitdauer (z. B. Mehrpunktschätzung mittels Dreiecks- oder Beta-Verteilung) Kosten (z. B. Mehrpunktschätzung mittels Dreiecks- oder Beta-Verteilung) Personal und weitere benötigte Ressourcen Ergebnis, Kosten und Zeitdauer eines Vorgangs müssen natürlich mit der Gesamtplanung und den Gesamtzielen vereinbar sein. Das heißt, die Summe der Vorgangskosten einer Projektphase sollten in etwa gleich den geschätzten Kosten für diese Phase sein. Und die Gesamtdauer aller Vorgänge sollte der geschätzten Dauer entsprechen, wobei Vorgänge durchaus parallel ablaufen können Netzpläne Netzpläne dienen dazu, Abhängigkeiten zwischen Vorgängen zu visualisieren. Darüber hinaus können sie weitere Informationen enthalten: Vorgangs- oder Ereignisnummer, frühester/spätester Starttermin/Endtermin, Dauer, Kosten, Ressourcen, Pufferzeiten etc. Es gibt mehrere Arten von Netzplänen: Vorgangspfeil-Netzpläne (VPN; Vorgänge werden als Beziehungen modelliert) Vorgang Ereignisknoten-Netzpläne (EKN; Beziehungen zwischen Ereignissen = Ergebnissen von Vorgängen werden modelliert, z. B. Vorgang Startseite erstellen ˆ= Ereignis Startseite wurde erstellt ). Ereignis Ereignis Draft (13. März 2015) 122

123 Vorgangsknoten-Netzpläne (VKN; Beziehungen zwischen Vorgängen werden modelliert; ähnlich EKN). Vorgang Vorgang Vorgangspfeil-Netzpläne (VPN) werden als historisch erste Darstellungsform der Netzplantechnik angesehen. Diese Art der Darstellung wurde 1956 für die Critical-Path-Method entwickelt. Vorgangsknoten-Netzpläne (VKN) wurden 1958 im Zusammenhang mit der Mèthode des Potentiels Metra (Metra Potential Method, MPM) eingeführt. Im selben Jahr wurden im Rahmen der Programm Evaluation und Review Technique (PERT) die Ereignisknoten-Netzpläne (EKN) erstmals vorgestellt. Heute sind VPN und EKN nur noch von geschichtlichem Interesse. Die Vorgangsknoten-Netzpläne werden allgemein verwendet. Häufig spricht man auch (eigentlich fälschlicherweise) von PERT-Diagrammen oder PERT-Netzplänen, meint damit heute aber stets VPNs und nicht die veralteten EKNs. (Kelley und Walker [1959], Miller [1963], Bouyssou und Vanderpooten [2011]) VPN: ursprünglich Critical Path Method (CPM, Kelley und Walker [1959]) EKN: ursprünglich Program Evaluation and Review Technique (PERT, Miller [1963]) VKN: ursprünglich Mèthode des Potentiels Metra (MPM, Bouyssou und Vanderpooten [2011]), heute Standard für alle Methoden Anmerkung CPM arbeitet mit Ein-Punkt-Schätzung PERT arbeitet mit Drei-Punkt-Schätzung; Beta-Verteilung (optimistisch, pessimistisch, wahrscheinlich) Bei VPNs wird die Dauer direkt beim Vorgang notiert. Die Knoten enthalten eine laufende Nummer sowie den frühesten und den spätesten Starttermin. Bei EKNs wird die Dauer ebenfalls an den Beziehungspfeilen angebracht. Laufende Nummer, frühester und spätester Termin werden in den Knoten notiert. In VKNs wird die gesamte Information (laufende Nummer, Bezeichnung, frühester und spätester Starttermin, Dauer und freie Pufferzeit, frühester und spätester Endtermin etc.) in den Vorgangsknoten notiert. An den Pfeilen wird die Art der Beziehung notiert, zumindest, wenn es sich nicht um eine Standard-Ende-Anfang- Beziehung handelt (siehe weiter unten). Die frühesten Start- und Endtermine der Vorgänge werden zunächst ausgehend vom ersten hin zu späteren Vorgängen mit Hilfe der Dauer und der Abhängigkeiten ermittelt. Dieser Vorgang wird Vorwärtsrechnung genannt. Dann können die 123 Draft (13. März 2015)

124 spätesten Start- und Endtermine ausgehend vom letzten Vorgang ermittelt werden. Dieser Vorgang heißt Rückwärtsrechnung. Ein kritischer Knoten ist ein Knoten, dessen frühester Starttermin gleich dessen spätestem Starttermin ist. Jede Verzögerung, an der dieser Knoten beteiligt ist, hat eine Verzögerung der gesamten Phase und damit des Gesamtprojektes zur Folge, wenn man die verlorene Zeit nicht anderweitig wieder hereinarbeiten kann. In einem VKN spricht man auch von kritischen Vorgängen. Ein kritischer Pfad ist eine Liste oder gar ein ganzes Netz zusammenhängender kritischer Knoten. Draft (13. März 2015) 124

125 Pufferzeiten Die Differenz zwischen frühestem und spätestem Starttermin (oder Endtermin) eines Vorgangs heißt gesamte Pufferzeit (des aktuellen Vorgangs). Um diese Zeitspanne kann ein Vorgang verzögert werden, ohne das Gesamtprojekt zu verzögern. Dabei kann es allerdings passieren, dass die Pufferzeiten nachfolgender Vorgänge verringert werden. Ein kritischer Vorgang zeichnet sich also dadurch aus, dass seine gesamte Pufferzeit gleich Null ist. Daneben kann man für die einzelnen Vorgänge auch noch die freie Pufferzeit berechnen. Das ist diejenige Zeit, um die der Start eines Vorgangs verzögert werden kann, ohne dass sich dadurch die Pufferzeit eines Nachfolgevorgangs verringert. Die freie Pufferzeit berechnet man aus dem frühestens Endtermin eines nichtkritischen Vorgangs und dem Minimum des frühesten Start-Termins aller direkten Nachfolgervorgänge. Die freie Pufferzeit eines Vorgangs ist stets kleiner oder gleich dessen gesamte Pufferzeit. Für Vorgänge kann auch ein fixer Start- oder Endtermin vorgegeben werden. In diesem Fall kann die Vorwärts- und die Rückwärtsrechnung eventuell negative Pufferzeiten und damit einen so genannten zeitinkonsistenten Netzplan liefern. Beispiel Für ein Software-Projekte werde eine geeignete Datenbank gesucht. Im Aktivitäten-Projektstrukturplan wurden folgende Vorgänge für diese Teilaufgabe ermittelt: Nr. Name Vorgänger Nachfolger Dauer 1 Phasenstart 2; 4 0 d 2 DBMS anschaffen d 3 DBMS installieren 2 5; 6 2 d 4 Testszenario entwickeln 1 5; 6 7 d 5 Testdaten einspielen 3; d 6 Testszenario implementieren 3; d 7 DBMS testen und wählen 5; d 8 Phasenende 7 0 d In der Spalte Vorgänger wird jeweils angegeben, welche Vorgänge abgeschlossen sein müssen, bevor der aktuelle Vorgang starten kann. In der Spalte Nachfolger sind diejenigen Vorgänge aufgeführt, die frühestens starten können, wenn der aktuelle Vorgang abgeschlossen ist. Die verschiedenen Visualisierungsmöglichkeiten dieser Vorgangsbeziehungen mit Hilfe Netzplänen werden in Abbildung 4.2, Abbildung 4.3 und Abbildung 4.4 gezeigt. 125 Draft (13. März 2015)

126 Anmerkung 1 Was bedeutet eigentlich Vorgang A beginnt am Tag X bzw. Vorgang A endet am Tag X? Darunter verstehe ich Folgendes: Vorgang A beginnt am Tag X = Vorgang A beginnt am Tag X um 24:00 Uhr = Vorgang A beginnt am Tag X+1 um 0:00 Uhr = Vorgang A beginnt am Tag X+1 um 8:00 Uhr (reguläre Arbeitszeit) Vorgang A endet am Tag X = Vorgang A endet am Tag X um 24:00 Uhr = Vorgang A endet am Tag X um 17:00 Uhr (reguläre Arbeitszeit) Das heißt, aus Sicht der Projektarbeitszeit gilt folgende Gleichung: Tag X, 17:00 Uhr = Tag X+1, 8:00 Uhr. Der Grund ist, dass die Mitarbeiter von 17:00 eines Tages bis 8:00 Uhr des Folgetages nicht für das Projekt arbeiten, sondern auch noch ein Privatleben haben. (Die genauen Anfangs- und Endzeiten variieren natürlich von Unternehmen zu Unternehmen.) Aufgrund dieser Konvention ist es möglich, einfach die Endzeit eines Vorgangs (Tag X um 17:00 Uhr) als Startzeit eines Folgevorgangs (= Tag X+1 um 8:00 Uhr) zu übernehmen. Anmerkung 2 Obwohl Netzdiagramme den zeitlichen Aspekt stark betonen, eignen sie sich auch zur Kosten- und Ressourcenschätzung und -planung. Draft (13. März 2015) 126

127 VPN DBMS Testlizenzen anschaffen (2) DBM Systeme installieren (3) Testdaten einspielen (5) 1 Phasenstart (1) Testszenario entwickeln (4) Testszenario implementieren (6) 3 EKN 6 Testlizenzen angeschafft DBM Systeme installiert Testdaten eingespielt Phasenstart Testszenario entwickelt Testszenario implementiert Abbildung 4.2: VPN- und EKN-Netzpläne für die Auswahl eines Datenbank-Management-Systems DBMS 6 testen und auswählen (7) DBMS getestet und ausgewählt Draft (13. März 2015)

128 VKN 1 Phasenstart nicht kritisch kritisch Meilenstein 5 DBM Systeme anschaffen DBM Systeme installieren Testdaten einspielen Testszenario entwickeln Testszenario implementieren <Nummer> Vorgangsname fs D fe ss gp se fs D fe ss gp se = = = = = = frühester Starttermin Dauer frühester Endtermin spätester Starttermin gesamte Pufferzeit spätester Endtermin Abbildung 4.3: VKN-Netzplan für die Auswahl eines Datenbank-Management-Systems 7 DBMS testen und ausgewählen Phasenende Draft (13. März 2015) 128

129 V UT K ] 9 ] ' ) ) *! $# " ; : 8 > ; : 8 > I A I A YQ U VQ Z WVX RS PQ 6> \CH I> [ A 8> ;> 9 9 KJ6 8[ B8C 6 8> 6 JJ> 6 MH 8>D 6 8[ B8C 6 8> 6 <C D>J6 ;> 9 ^8> 9 JJ> 6 MH 7> J6> 6 C9> G I> [ A 8> ^8> 9 9 >D6_[ D <H I> A 0. / &-, +' / &-, +' & ( ( & "! & % # $# $# "! ( ' & ( I> 8 >L 6 A A ;H : G6F C >D BC D >L 6 A JKG 7AG I> A ;H : =6 8;<7: G6F C >D M6 N>F =89 C D m lk k icj h e f ag JKG 7AG 7A 8> 9A 7@>?> ;> 6 : uq qds qrts k g jp c on l O> A ;F > ;> 6E G6F ;H : =7> 6 6CD I ;H A : A 8> 9A 7@>?> O> A ;F > ;> 6E G6F ;H : 79 87=6 8;<7: 8=7> 6?C 6 G6F C >D BC D ;> 6 : d bca ` a Abbildung 4.4: VKN-Netzplan für die Auswahl eines Datenbank-Management-Systems (mit MS Project 2003 erstellt) 129 Draft (13. März 2015)

130 Vorgangsbeziehungen Es werden vier Vorgangsbeziehungen unterschieden: Normalfolge: Ende-Anfang (EA) Anfangsfolge: Anfang-Anfang (AA) Endfolge: Sprungfolge: Normalfolge Ende-Ende (EE) Anfang-Ende (AE) Eine Normalfolge (EA) besagt, dass der nächste Vorgang erst begonnen werden darf, wenn der vorherige beendet wurde. Beispiel Design EA Implementierung Mit der Implementierung kann evtl. auch schon etwas früher begonnen werden, z. B. 5 Tage vor Ende des Designs. Design EA 5d Implementierung Es ist auch möglich einen etwas späteren Start als das Ende des Design festzulegen. Design EA + 3d Implementierung Anfangsfolge Eine Anfangsfolge (AA) besagt, dass ein zweiter Vorgang gleichzeitig mit dem ersten anfangen muss. Beispiel Implementierung auf der Zielplattenform AA regelm. Backup der Zielplattform oder die regelmäßigen Backups starten schon einen Tag vorher Implementierung auf der Zielplattenform AA 1d regelm. Backup der Zielplattform Draft (13. März 2015) 130

131 Beachten Sie, dass der Anfang der regelmäßigen Backups vom Anfang der Implementierung auf der Zielplattform abhängt und nicht umgekehrt. Mit Hilfe eines Balkendiagramms (Gantt-Diagramm Abschnitt 4.3.3) kann man diesen Zusammenhang besser visualisieren. Die linke Seite des Balkens wird am Start-Datum in einen Kalender eingetragen und die rechte Seite am Ende-Datum. Implementierung auf Zielplattform AA Backups auf Zielplattform... Implementierung auf Zielplattform AA 1d Backups auf Zielplattform... Endfolge Eine Endfolge (EE) besagt, dass ein zweiter Vorgang zusammen mit dem ersten beendet wird. Beispiel Netzpläne Übergabe an Kunden EE regelm. Backup auf der Zielplattform Übergabe an Kunden EE+1d regelm. Backup auf der Zielplattform 131 Draft (13. März 2015)

132 Balkendiagramme Übergabe an Kunden EE... Backups auf Zielplattform Übergabe an Kunden EE+1d... Backups auf Zielplattform Sprungfolge Eine Sprungfolge (AE) besagt, dass der zweite Vorgang erst beendet werden darf, wenn der erste begonnen wurde. Beispiel Netzpläne neue Anwendung in Betrieb AE alte Anwendung in Betrieb neue Anwendung in Betrieb AE+5d alte Anwendung in Betrieb Draft (13. März 2015) 132

133 Balkendiagramme neue Anwendung In Betrieb... AE... alte Anwendung in Betrieb neue Anwendung In Betrieb... AE+5d... alte Anwendung in Betrieb Die alte Anwendung darf erst beendet werden, wenn die neue in den Einsatz kommt. Relative Verschiebung von Start- und Endterminen Oftmals fallen Anfang und Ende von zwei Vorgängen nicht genau zusammen, sondern unterscheiden sich um einige Tage. Wie in den Beispielen gezeigt wurde, notiert man dies wie folgt: EA + 5 d: Vorgang 2 startet frühestens 5 Tage nach Ende von Vorgang 1 EA 3 d: Vorgang 2 startet frühestens 3 Tage vor Ende von Vorgang 1 AA + 2 d: Vorgang 2 startet frühestens 2 Tage nach Start von Vorgang 1 AA 1 d: Vorgang 2 startet frühestens 1 Tag vor Start von Vorgang 1 EE + 4 d: Vorgang 2 endet frühestens 4 Tage nach Ende von Vorgang 1 EE 4 d: Vorgang 2 endet frühestens 4 Tage vor Ende von Vorgang 1 AE + 6 d: Vorgang 2 endet frühestens 6 Tage nach Start von Vorgang 1 AE 2 d: Vorgang 2 endet frühestens 2 Tage vor Start von Vorgang Draft (13. März 2015)

134 Man beachte, dass mit Hilfe von Addition und Subtraktion von Zeitabständen jede Abhängigkeit zwischen zwei (endlichen) Vorgängen als Normalfolge, Anfangsfolge, Endfolge oder Sprungfolge notiert werden kann. Bei der Auswahl einer geeigneten Folge kommt es also nicht auf formale, sondern nur auf praktische Überlegungen an Vorwärts- und Rückwärtsrechnung Nachdem in einen VKN-Netzplan die Vorgänge, die jeweilige Vorgangsdauer und die Beziehungen zwischen den Vorgängen (als Pfeile) eingetragen wurden, kann man die frühesten und spätesten Start- und End-Termine mittels der so genannte Vorwärts- und Rückwärtsrechnung ermitteln. Daraus lassen sich anschließend die Pufferzeiten und der kritische Pfad ableiten. Am Beispiel der Auswahl eines DBMS (Abbildung 4.3) sollen die beiden Algorithmen für den Fall, dass es nur EA-Beziehungen gibt, erläutert werden. Algorithmus: Vorwärtsrechnung In den Dummy-Vorgang Phasenstart oder Projektstart wird als frühester Start- und Endtermin jeweils 0 eingetragen. Das heißt, das Projekt beginnt am nullten Tag um 24:00 Uhr, also am 1. Tag um 8:00 Uhr. Um welchen Tag es sich hierbei konkret handelt, muss separat (im Gantt-Diagramm; Abschnitt 4.3.3) festgelegt werden. Solange es noch Vorgänge gibt, deren frühesten Start- und Endtermine noch nicht eingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus: Wenn die spätesten Endtermine aller EA-Vorgänger-Vorgänge ermittelt wurden: Trage das Maximum dieser Endtermine als frühesten Starttermin für den aktuellen Vorgang ein. Trage als frühesten Endtermin des aktuellen Vorgangs den frühesten Starttermin plus der Dauer des aktuellen Vorgangs ein. Dieser Algorithmus endet, wenn der früheste Start- und der der früheste End-Termin in den Dummy-Vorgang Phasenende oder Projektende eingetragen wurden. Diese beiden Werte stimmen überein (da die Dauer des Dummy-Vorgangs 0 Tage beträgt). Dieser Wert sagt aus, wie lange es dauert, die Phase bzw. das Projekt zu beenden (wenn die Dauer jedes einzelnen Vorgangs richtig geschätzt wurde). Draft (13. März 2015) 134

135 Algorithmus: Rückwärtsrechnung Bei der Rückwärtsrechnung geht man davon aus, dass die Gesamtdauer der Projektphase bzw. des Projektes minimal sein soll. Man initialisiert also den spätesten Start- und den spätesten Endtermin des Dummy-Vorgangs Phasenende oder Projektende mit denjenigen Werten, die in diesem Vorgang als frühester Start- und Endtermin eingetragen sind. Solange es noch Vorgänge gibt, deren späteste Start- und Endtermine noch nicht eingetragen wurden, führe für jeden dieser Vorgänge Folgendes aus: Wenn die spätesten Starttermine aller EA-Nachfolger-Vorgänge ermittelt wurden: Trage das Minimum dieser Starttermine als spätesten Endtermin für den aktuellen Vorgang ein. Trage als spätesten Starttermin des aktuellen Vorgangs den spätesten Endtermin minus der Dauer des aktuellen Vorgangs ein. Algorithmus: Pufferzeiten und kritischer Pfad Die gesamte Pufferzeit eines einzelnen Vorgangs ermittelt man, indem man den frühestens Starttermin vom spätesten Starttermin subtrahiert. In Abbildung 4.3 hat der Vorgang 5 beispielsweise einen Puffer von zwei Tagen. Der Vorgang 4 hat einen Puffer von einem Tag. Die freie Pufferzeit eines Vorgangs ermittelt man indem man den spätesten Endtermin des Vorgangs vom Minimum der frühesten Starttermine aller Nachfolgervorgänge subtrahiert. In Abbildung 4.3 sind die freien Pufferzeiten nicht eingetragen. Sie stimmen mit den gesamten Pufferzeiten überein. In Abbildung 4.23 unterscheiden sich die Pufferzeiten von Vorgang Vc: Die gesamte Pufferzeit beträgt 3 Tage, die freie Pufferzeit ist dagegen 0 Tage. Das heißt, wenn sich dieser Vorgang verzögert, wird automatisch auch die Pufferzeit des Nachfolgevorgangs Vd reduziert. Den kritischen Pfad ermittelt man, indem man alle Vorgänge mit einer freien Pufferzeit von 0 Tagen als kritisch markiert. Man beachte, das hierbei nicht unbedingt ein Pfad enstehen muss, es kann auch ein Netz von kritischen Knoten entstehen. Komplexere Beziehungen In Abbildung 4.7 ist ein Netzplan angegeben, der relativ komplexe Beziehungsarten enthält: neben verschiedenen Normalfolgen finden sich dort eine Anfangsfolge und eine Endfolge. Nur eine Sprungfolge fehlt noch. Hier erfolgt die Vorwärtsund die Rückwärtsrechnung im Prinzip genauso, wie zuvor beschrieben. Allerdings müssen jetzt andere Werte übertragen werden. 135 Draft (13. März 2015)

136 Beispiel: Der früheste Starttermin von V3 ermittelt sich aus dem Maximum von 3 (= spätester Endetermin von V1) und 4 (= frühester Starttermin von V2 plus 4 Tage; wegen der Beziehung AA+4d). Die in Abbildung 4.7 gezeigten Diagramme unterscheidet sich in einem wichtigen Punkt von den von MS Project 2010 erstellten Diagrammen (Abbildung 4.8): Im Netzplan von MS Project enthält der Vorgang V2 keinen Puffer. Aus der Tatsache, dass der Start von V2 kritisch ist, folgert Project, dass es keinen Puffer für das Vorgangsende geben kann. Dies entspricht jedoch nicht der Faktenlage. Der andere Unterschied ist, dass MS Project 2010 im Gegensatz zu MS Project 2003 defaultmäßig den freien Puffer im Gantt-Diagramm (siehe den folgenden Abschnitt) anzeigt. MS Project 2003 hat dagegen wie dies auch in Abbildung 4.7 gemacht wird den Gesamtpuffer angezeigt. Im Gantt-Diagramm von Abbildung 4.8 werden beiden Pufferarten angezeigt: Oben der Gesamtpuffer und unten der freie Puffer Balkendiagramme (Gantt-Diagramme) Aus Netzplänen können so genannte Balken- oder Gantt-Diagramme abgeleitet werden (siehe z. B. Abbildung 4.7, Abbildung 4.8 oder auch Abbildung 4.5). Der Name geht auf Henry Gantt zurück (Gantt [1913]). Balkendiagramme betonen den Zeitaspekt mehr als Netzdiagramme, da die Balkenlänge abhängig von der Dauer des zugehörigen Vorgangs gewählt wird. Die für Netzpläne eingeführten Beziehungen (EA, AA, EE, AE) gibt es gleichermaßen für Balkendiagramme. (Die Beispiele des letzten Abschnittes wurden zusätzlich auch schon in Form von Balkendiagrammen angegeben.) Draft (13. März 2015) 136

137 !!!!! $ # & % & ' * ) - G6 D FE D C6.0. /. $ #!" $!" $ ) ( ' % $, + * % $, $ +, - )! ) - - * 1 #? >= = ;5< : > <B 5 A@ > Abbildung 4.5: Gantt-Diagramm für den Netzplan aus Abschnitt (mit MS Project 2010 erstellt) 137 Draft (13. März 2015)

138 Vorgangsknotennetz 2 Va 4 5 Vc Vd Start Ende Vb Ve Vf Gantt Diagramm (gemäß CPM, mit kritischen Pfad und freien sowie gesamten Pufferzeiten) 5. April April April April 2010 Nr. Name Dauer Vorgänger S S M D M D F S S M D M D F S S M D M D F S S M D M D F S S 1 Start 0d <Nummer> Vorgangsname fs D fe ss gp se fp 2 Va 1d 1EA 3 Vb 2d 1EA 4 Vc 3d 1EA 5 Vd 2d 4EA 6 7 Ve Vf 2d 5d 2EA 3EA, 6EA 8 Ende 0d 5EA, 7EA Abbildung 4.6: Vorgangsknotennetz und Gantt-Diagramm Vorgang kritischer Vorgang Meilenstein fs D fe ss gp se fp = frühester Starttermin = Dauer = frühester Endtermin = spätester Starttermin = gesamte Pufferzeit = spätester Endtermin = freie Pufferzeit Vorgang gesamte Pufferzeit freie Pufferzeit kritischer Vorgang Meilenstein Draft (13. März 2015) 138

139 Nr Start Name Phasenstart Vorgang 1 Vorgang 2 Vorgang 3 Vorgang 4 Vorgang 5 Vorgang 6 Phasenende 0 1 V AA+4d V EA 1d EA 1d V2 V4 V6 4 EE+1d V5 6 theoretisch auch Ende Starttermin ist kritisch Ende ist unkritisch <Nummer> Vorgangsname fs D fe ss gp se Dauer 0d Anfang Ende Mo 2.5. Mo 2.5. Vorgänger 2. Mai Mai Mai 2005 S S M D M D F S S M D M D F S S M D M D F S S 3d Mo 2.5. Di EA 3d Mo 2.5. Di EA 3d Mo 9.5. Mi EA, 3AA+4d 2d Fr 6.5. Mo EA 1d, 3EA 2d Mi Do EE+1d, 5EA 4d Mi Di EA 1d 0d Di Di EA, 7EA Abbildung 4.7: Beispiel für Netzplan- und Balkendiagramm mit komplexeren Abhängigkeiten nicht kritisch kritisch Meilenstein fs D fe ss gp se = = = = = = frühester Starttermin Dauer frühester Endtermin spätester Starttermin gesamte Pufferzeit spätester Endtermin kritischer Vorgang Vorgang (Gesamt )Puffer freier Puffer Meilenstein 139 Draft (13. März 2015)

140 Draft (13. März 2015) 140 Abbildung 4.8: Beispiel für Netzplan- und Balkendiagramm mit komplexeren Abhängigkeiten (mit MS Project 2010 erstellt)

141 4.4 Feinplanung Bislang haben wir uns im Rahmen der Planung im Wesentlichen mit den Beziehungen zwischen Vorgängen befasst. Implizit lag dabei die Annahme zu Grunde, dass jederzeit unbegrenzte Ressourcen zur Verfügung stehen. Allerdings ist dem im Allgemeinen leider nicht so. Aufgabe des Ressourcen-Management ist es, den Bedarf an Ressourcen (Einsatzmittel) vorherzusagen und eine Einsatzoptimierung zu erreichen, d. h. Engpässe und Leerläufe nach Möglichkeit zu vermeiden. Ressourcen (auch Einsatzmittel genannt) sind: Personal Betriebsmittel (Hardware, Software etc.) Man unterscheidet: termintreue Ressourcenplanung Wie viele Ressourcen brauche ich, um diese und jene Vorgänge bis zu diesen und jenen Terminen abzuschließen? kapazitätstreue Ressourcenplanung Wann kann ich frühestens diese und jene Vorgänge bei gegebenen Ressourcen abschließen? Wie in Abschnitt 3.7 gezeigt wurde, ist die termintreue Ressourcenplanung gerade hinsichtlich des Personaleinsatzes i. Allg. nicht möglich. Folgende Milchmädchenrechnung funktioniert wie wir gesehen haben sicher nicht: In zwei Tagen muss der Rohbau meiner Fabrik stehen stehen. Um dieses Ziel zu erreichen brauche ich 1278 Bauarbeiter Personalplanung Folgende Gesichtspunkte müssen beachtet werden: verfügbare Personalkapazität Qualifikation zeitliche und örtliche Verfügbarkeit organisatorische Zugehörigkeit psychologische Aspekte ( Never Change a Winning Team ; eine behinderte Person in einem neuen Team erhöht die Erfolgschancen DeMarco und Lister [1991] etc.) Ziel der Personalplanung: optimaler Personaleinsatz über die gesamte Projektlaufzeit. 141 Draft (13. März 2015)

142 Beispiel Spiel Aquaris Das Spiel Aquaris wurde im Jahr 2006 im Rahmen eines Multimedia-Semesterprojektes von einer Studentengruppe entwickelt. In diesem Spiel geht es darum, dass 6 Spieler mit Hilfe von Seilzugsteuerungen virtuelle Wasserauffangbehälter mit Wasser und Bonuselementen befüllen. Je zwei Spieler bilden ein Team: Der Sammler sammelt das Wasser und die Bonuselemente. Der Blocker versucht Maluselemente abzublocken und zum Gegner zu kicken. Das Wasser und Bonuselemente sollte er oder sie natürlich möglichst nicht abblocken. 2 Spieldesign 4 Spielsteuerung Start Ende Spiellogik 3 Animation <Nummer> Vorgangsname fs ss D gp fe se fs = D = fe = ss = gp = se = frühester Starttermin Dauer frühester Endtermin spätester Starttermin gesamte Pufferzeit spätester Endtermin nicht kritisch kritisch Meilenstein Abbildung 4.9: Netzplan des Computerspiels Aquaris Die in Abbildung 4.9 und Abbildung 4.10 angegebenen Zahlen sind fiktiv. Allerdings war neben Informatikern und Gestaltern tatsächlich erstmals auch ein Mechatroniker an einem Multimedia-Projekt beteiligt. Anhand des verfügbaren/eingeplanten Personals muss die Dauer von Vorgängen (in Personentagen etc.) ermittelt werden. Der (zeitlich variable) Bedarf an Mitarbeitern kann nach qualifikationsorientierten sowie organisationsorientierten Gesichtspunkten ermittelt werden. Wenn Mitarbeiter gleichzeitig in mehr als einem Projekt arbeiten was Sie als Projektleiter laut DeMarco [2001] tunlichst vermeiden sollten, kann die Bedarfsplanung auch projektorientiert erfolgen. Bei der qualifikationsorientierten Bedarfsplanung werden zu jedem Zeitpunkt die Draft (13. März 2015) 142

143 Personal Qualifika tion Vorgänge Informatiker Designer Mechatronik eingeplantes Personal Spieldesign Spiellogik Animation Spielsteuerung Abbildung 4.10: Personalplanung des Computerspiels Aquaris Mitarbeiter Problem: 5 Designer werden gebraucht Spieldesign Designer Spiellogik Informatiker Spielsteuerung Informatiker Mechatroniker Animation Designer Animation Informatiker Projektleiter Spielsteuerung Informatiker Mechatroniker Abbildung 4.11: Qualifikationsorientierte Bedarfsplanung Zeit Anzahl der benötigten MA mit bestimmter Qualifikation in ein Diagramm eingetragen (siehe Abbildung 4.11). Bei der organisationsorientierten Bedarfsplanung werden die Mitarbeiter nicht nach ihrer Qualifikation, sondern nach ihrer organisatorischen Zugehörigkeit (Abt. 1, Abt. 2, Partner A, Partner B etc.) in ein Bedarfsdiagramm eingetragen. Bei der projektorientierten Planung wird die Anzahl der Mitarbeiter eines jeden Projektes in ein Bedarfsdiagramm eingetragen. In allen Fällen kann man an derartigen Diagrammen Engpässe und Leerläufe ablesen (siehe Abbildung 4.12). Man beachte, dass die Anzahl vorhandener Mitarbeiter (oder Spezialisten) über die Zeit nicht notwendigerweise konstant ist. Im obigen Beispiel Spiel Aquaris ergibt sich das Problem, dass keine 5 Designer zur Verfügung stehen (siehe Abbildung 4.13). Das heißt, nach 8 Projekttage ergibt sich für zwei Tage ein Engpass an Designern. Danach folgt ein Leerlauf. Der Bedarf an Designern reduziert sich vor Projektende sogar auf Null (zumindest in unseren fiktiven Beispiel). 143 Draft (13. März 2015)

144 Mitarbeiter Engpass Leerlauf Engpass Leerlauf Leerlauf Anzahl Mitarbeiter Zeit Abbildung 4.12: Leerlauf und Engpässe Designer Anzahl Designer Zeit Abbildung 4.13: Leerlauf und Engpässe am Beispiel des Projektes Auqaris Die eigentliche Aufgabe des Ressourcen-Management ist es, die zeitliche Abfolge von Vorgängen so abzuändern, dass Engpässe (d. h. Überstunden oder Einstellungen von weiterem Personal, Zukauf weiterer Ressourcen etc.) nach Möglichkeit vermieden werden. Im Wesentlichen werden dabei vorhandene Leerlaufzeiten abgebaut. Primär sind dazu nicht-kritische Vorgänge geeignet, deren Erledigung nach hinten nach Möglichkeit in bestehende Leerlaufphasen verschoben werden kann. In Abbildung 4.14 werden fünf Vorgänge angegeben zusammen mit der jeweiligen Dauer sowie der Anzahl der Mitarbeiter, die eingeplant werden muss, um den jeweiligen Vorgang in der angegebenen Zeit erfolgreich abzuschließen. In Abbildung 4.15 ist eingetragen, wie der Personalbedarf aussieht, wenn zu jedem Zeitpunkt beliebig viele Projektarbeiter zu Verfügung stehen. Draft (13. März 2015) 144

145 EA 2d V <Nummer> Vorgangsname D MA D = Dauer MA = Anzahl Mitarbeiter V1 1 V3 3 V V Abbildung 4.14: Netzplan von fünf Vorgängen MA Termin 5 V4 Anzahl MA V2 V4 V1 V3 V Zeit Abbildung 4.15: Resultat der Vorgangsplanung Wenn das Projektteam (neben dem Projektleiter) nur sechs Mitglieder hat, die alle gleichermaßen geeignet sind, die Vorgänge zu bearbeiten, kommt es vom vierten bis zum neunten Tag zu einem Personalengpass. Ab dem neunten Tag kommt es dagegen zu einem Leerlauf. Wenn man versucht, diesen Engpass so zu beheben, dass die Arbeit an Vorgang V4 in den Tagen neun bis dreizehn erledigt wird, damit der ursprüngliche Termin gehalten wird (termintreue Planung), muss man fünf Kröten schlucken (Abbildung 4.16): 145 Draft (13. März 2015)

146 Ohne Überstunden geht es nicht. Das V4-Team ändert ständig seine Größe: 1,33 MA für 3 Tage, 3 MA für 2 Tage, 6 MA für 2 Tage, 3 MA für 2 Tage. Sechs Mitarbeiter auf einmal sind zuviel und behindern sich nur. Für V4 waren nur vier Mitarbeiter vorgesehen. Evtl. hat man gar keine sechs Experten für diesen Vorgang. Die laut Netzplan vorgegebene Abhängigkeit V4 V5 wird verletzt. MA Termin 5 Überstunden V2 V4 V4 Anzahl MA V1 V3 V Zeit Abbildung 4.16: Termintreue Personalplanung Die kapazitätstreue Personalplanung (Abbildung 4.17) vermeidet die meisten dieser Nachteile. Dafür verschiebt sich der Endtermin um drei Tage. Wenn man die sich ändernde Mitarbeiterzahl an Vorgang V4 noch weiter abmildern will, könnte man auf den Start des Vorgangs mit einem Mitarbeiter in den vier bis sechs verzichten. Dies hätte eine weitere Verschiebung des Endtermins um einen Tag nach hinten zur Folge. Dafür hätte man auch Luft, den Vorgang V4 an den Tagen 13 und 14 mit jeweils vier Mitarbeitern zu Ende zu führen (auch wenn rechnerisch nur jeweils drei Mitarbeiter nötig wären). Für das Spiel Aquaris muss beispielsweise der Start des Vorgangs 5 Animation um zwei Tage nach hinten geschoben werden (Abbildung 4.18). Diese Modifikation ist sowohl kapazitätstreu als auch termintreu. Der Puffer des Vorgangs Animation wird allerdings reduziert. Dafür gewinnt der Vorgang Spiellogik zwei Tage freien Puffer hinzu. Draft (13. März 2015) 146

147 MA Termin 5 V2 V4 Anzahl MA V1 V3 V4 V Zeit Abbildung 4.17: Kapazitätstreue Planung Bedarfsplanung der Betriebsmittel Abhängig von der Beständigkeit der Betriebsmittel unterscheidet man: verzehrbare Betriebsmittel (Büromaterial, Toner etc.) nicht-verzehrbare Betriebsmittel (Räume, Rechner, Software etc.) Eine Betriebsmittelplanung ist nur dann notwendig, wenn Engpässe sehr wahrscheinlich sind. Ansonsten rentiert sich der zusätzliche Arbeitsaufwand nicht. Für verzehrbare Betriebsmittel sollten genügend Finanzreserven vorgesehen werden, so dass fehlendes Material rechtzeitig nachbestellt werden kann. Nicht verzehrbare Betriebsmittel sollten in genügender Zahl bereitgestellt werden. Wenn eine Betriebsmittelplanung notwendig sein sollte, so läuft diese im wesentlichen wie die Personalplanung ab. Man unterscheidet dabei zwischen: vorratseingeschränkter Einsatzplanung Ein nicht-vergrößerbarer Vorrat eines Betriebsmittels muss möglichst fair auf mehrere Nutzer aufgeteilt werden Belegungspläne o. Ä. bedarfsbezogener Einsatzplanung Zunächst wird von einem unbegrenzten Vorrat eines Betriebsmittels ausgegangen. Dann wird der eigentliche Bedarf zu den verschiedenen Zeiten ermittelt. Eventuell kann der Bedarf durch termintreue oder kapazitätstreue Auslastungsoptimierung verringert werden. Schließlich können die Betriebsmittel gemäß dem errechneten Bedarf angeschafft werden. freier Einsatzplanung Wenn keine Gefahr von Engpässen besteht, kann die Planung auf die Sammlung von Benutzerbedürfnissen (oder -wünschen) beschränkt werden. 147 Draft (13. März 2015)

148 Nr. Name 1 Start Dauer 0d Vorgänger S S M D M D F S S M D M D F S S M D M D F S S M D M D F S S Spieldesign Spiellogik Spielsteuerung Animation 8d 6d 11d 9d Ende 0d 1EA 1EA 2EA 3EA 4EA, 5EA 1 Inf. + 1 Mech. 2 Des. + 1 Inf. 3 Des. 3 Inf. kritischer Vorgang Vorgang Puffer Meilenstein Nr. Name 1 Start Dauer 0d Vorgänger S S M D M D F S S M D M D F S S M D M D F S S M D M D F S S Spieldesign Spiellogik Spielsteuerung Animation 8d 6d 11d 9d Ende 0d 1EA 1EA 2EA 3EA 1 Inf. + 1 Mech. 2 Des. + 1 Inf. 3 Des. 4EA, 5EA Meilenstein 3 Inf. kritischer Vorgang Vorgang (Gesamt )Puffer freier Puffer Abbildung 4.18: Aquaris: Gantt-Diagramme mit und ohne Ressourcenengpass Draft (13. März 2015) 148

149 4.4.3 Kapazitätsausgleich, Resource Leveling Wenn man in Gantt-Diagrammen Vorgänge und deren Nachfolgervorgänge nach hinten verschiebt, um Ressourcen-Engpässe auszugleichen, spricht man von Kapazitätsausgleich oder Resource Leveling. Beispiele für Resource Leveling wurden schon im letzten Abschnitt vorgestellt (siehe Abbildung 4.17 und Abbildung 4.18). Ein wichtiger Spezialfall stellt der Kapazitätsausgleich auf Mitarbeiterebene dar. Ein Mitarbeiter sollte wann immer es sich vermeiden lässt nicht an zwei Aufgaben gleichzeitig arbeiten. Erst recht sollte ein Mitarbeiter nicht an zwei Projekten gleichzeitig arbeiten. Der Grund dafür ist ganz einfach: Die Fertigstellung aller Aufgaben verzögert sich (Abbildung 4.19)! Abbildung 4.19: Verzögerungseffekte von quasi-paralleler Arbeit 149 Draft (13. März 2015)

150 Ein Mensch kann immer nur eine Aufgabe zur selben Zeit absolvieren. Sogar die Aussage, dass Frauen multitaskingfähig seien und Männer nicht, ist laut einer Studie des Instituts für Arbeit und Gesundheit der gesetzlichen Unfallversicherung nichts als ein Märchen (DGVU [2010]). Wenn sie (oder er) mehrere Aufgaben gleichzeitig erledigen will, geht dies nur im so genannten Timesharing-Verfahren : Nach jeweils einer kurzen Zeitspanne widmet sie sich einer anderen Aufgabe. Dies hat zur Folge, dass sich das Ende aller Aufgaben mit Ausnahme der letzten verzögert (siehe Abbildung 4.19 b). Leider ist es nicht so, dass ein Mensch ohne Probleme die jeweilige Aufgabe wechseln kann. Jeder so genannte Taskwechsel hat eine zusätzliche Verzögerung zur Folge. Das heißt alle Endtermine, auch der der letzten Aufgabe, verzögert sich zusätzlich. (siehe Abbildung 4.19 c) Beispiele für diese Verzögerungseffekte gibt es viele. Es wäre z. B. viel effizienter und effektiver Lehrveranstaltungen nacheinander in Blöcken zu halten als in jeder Woche parallel diverse Lehrveranstaltungen zu besuchen, da man sich dann immer nur auf ein Thema konzentrieren müsste und das ständige Umdenken entfallen würde. Laut Aussage einer Studentin, die ein Auslandssemester in Schweden verbracht hat, wird dieses Konzept in Schweden tatsächlich umgesetzt. Ein viel schlimmeres Beispiel sind Telefon und . Ungestörtes Arbeiten ist zum Luxus geworden. Büromenschen können sich im Schnitt elf Minuten auf eine Aufgabe konzentrieren, bevor sie auf einem der vielen Kommunikationskanäle unterbrochen werden. (Pilgram [2011]) Die dauernden Unterbrechungen durch diese Medien kosten die Unternehmen jedes Jahr Milliardenbeträge. Jede Unterbrechung reißt einen Geistesarbeiter aus seinen Gedanken. Die nachfolgende Eintauchphase, um wieder voll konzentriert an der zuvor unterbrochenen Aufgabe arbeiten zu können, dauert laut Untersuchen von DeMarco und Lister (DeMarco und Lister [1985]) ca. 15 Minuten. Das heißt drei 5-Minuten-Telefonate in einer Stunde kosten die gesamte Stunde als produktive Arbeitszeit. Ein weiteres Problem ist das so genannte Matrix-Projektmanagement. Kupper [1993] hält dies für die geeignetste Form, [um] DV-Projekte durchzuführen. Projektmitarbeiter haben jeweils zwei Chefs: Einen Chef den Personalvorgesetzen der Fach- oder Stabsabteilung, der sie zugeordnet sind sowie den Projektleiter als Fachvorgesetzen. DeMarco [2001] hält das Matrix-Projektmanagement dagegen für absurd. Für vollkommen verfehlt hält er die Idee, dass der Personalvorgesetzte einen Mitarbeiter, der in einem Projekt nicht ausgelastet ist, gleichzeitig an mehreren Projekten (mit jeweils unterschiedlichen Fachvorgesetzen) mitarbeiten lässt. Hier kommt zu den üblichen Taskwechsel-Verzögerungen noch das Problem hinzu, dass der Mitarbeiter in kein Team richtig integriert ist. Dies hat Draft (13. März 2015) 150

151 wesentlich gravierendere Negativ-Effekte als die übrigen Zeitverluste durch Taskwechsel. Laut DeMarco [2001] setzt sich der durch Taskwechsel verursachte Zeitausfall insgesamt aus folgenden Komponenten zusammen: Routinearbeiten, um auf die neue Aufgabe umzuschalten Doppelarbeit, weil eine Aufgabe in einem ungünstigen Moment abgebrochen werden musste Eintauchzeit bei denkintensiven Aufgaben Frustration (emotionale Eintauchzeit) Verlust des Teambildungseffkts (bei Mitarbeit an mehreren Projekten gleichzeitig) In einer Studie (DeMarco und Lister [1985]), bei der 600 Programmierer unter realen Bedingungen Programmieraufgaben lösen mussten, wiesen Tim Lister und Tom DeMarco nach, dass jeder Taskwechsel mit einem Konzentrationsverlut von ca. 20 Minuten verbunden ist. Bei 0,4 Wechseln pro Stunde summiert sich dies zu mehr als einer Stunde Arbeitszeitverlust, was 15 % der Arbeitszeit bei einem 8-Stunden-Tag bedeutet. Fazit Resource Leveling auf Mitarbeiterebene ist bei jedem Projekt ein Muss! Resource Leveling beschleunigt ein Projekt, wenn die Ressourcen vorgegeben sind. Resource Leveling bedeutet dagegen fast immer einer Verlängerung der Projektlaufzeit gegenüber dem theoretischen Optimum, bei dem unbeschränkt viele Ressourcen zur Verfügung stehen, die sich gegenseitig nicht behindern. Nur, wann hat man das schon? Kostenplanung Die Kostenplanung erfolgt in Abhängigkeit von allen anderen Planungsaktivitäten. Das Ziel ist immer auch eine projektumfassende Vollkostenrechnung, angefangen bei der Vorplanung, endend beim Abschlussbericht. Zu den ressourcenspezifischen Kosten (Ressourcenkosten) addieren sich noch die Gemeinkosten (wie Büromiete, Löhne und Gehälter von Verwaltung und Management etc.), die sich nicht spezifischen Projekten zuordnen lassen. 151 Draft (13. März 2015)

152 Für Personal muss zwischen normalen Stundensätzen und Überstundensätzen unterschieden werden. Diese können Gemeinkosten enthalten (Personalvollkosten) oder nicht. Bei manchen Unternehmen (wie z. B. dem Staat) werden die Kosten für alle Mitarbeiter derselben Qualifikation gemittelt (Personaldurchschnittskosten). Das heißt, unterschiedliche Gehälter aufgrund von Leistungs- oder Familienzulagen o. Ä. werden projektunabhängig verrechnet. Bei Betriebsmitteln entstehen Gemeinkosten (z. B. Büros), Festkosten (z. B. Neuanschaffung nicht-verzehrbarer Betriebsmittel) und laufende Kosten (z. B. Nachkauf aufgebrauchter verzehrbarer Betriebsmittel, Zeitschriften, Wartungsverträge etc.) Anmerkung Auch Erlöse sind Kosten, und zwar negative Kosten Kalender Wesentlich für alle Planungen sind die Kalender. Der wichtigste Kalender ist der Projektkalender, in dem alle freien Tage (Samstage, Sonntage, Feiertage, Betriebsferien) eingetragen werden. Daneben kann es beliebig viele Ressourcenkalender geben, in denen die Verfügbarkeit der einzelnen Ressourcen (Personal und Betriebsmittel) eingetragen wird. Normalerweise enthalten die Ressourcenkalender lediglich mehr freie Tage als der Projektkalender (Urlaub, Rechner auf CeBIT etc.). Allerdings gibt es auch Ressourcen, die an ansonsten arbeitsfreien Tagen sinnvolle Arbeiten durchführen können (Zement kann auch am Wochenende trocknen, 3D-Animationen können auch über Weihnachten ohne Aufsicht gerendert werden etc.). Manchmal sind auch spezielle Vorgangskalender wichtig, wenn z. B. bestimmte Vorgänge im Ausland stattfinden und der betriebsspezifische Projektkalender daher keine Anwendung finden kann (sehr zum Leidwesen einiger Dienstreisender). Sollte ein PM-Tool keine Ressourcenkalender mit beliebig veränderbaren Arbeitszeiten unterstützen, so können Wochenend- und Feiertagsarbeit auch mit Vorgangskalendern modelliert werden. Draft (13. März 2015) 152

153 4.5 Methode der kritischen Kette Eliyahu Goldratt hat die Theory of Constraints (ToC, siehe Abschnitt 1.2.3) nachdem diese sehr erfolgreich war zur Methode der kritischen Kette (CCPM, Critical Chain Project Management) weiterentwickelt. Während ToC auf die Bedürfnisse der Produktionswirtschaft abgestimmt ist, ist CCPM für das Projektmanagement gedacht. In dem Roman Die Kritische Kette Das neue Konzept im Projektmanagement (Goldratt [2002]) identifiziert Goldratt den kritischen Pfad als denjenigen Engpass, auf den ein Projektleiter sein Augenmerk konzentrieren muss. Wie bei ToC ist ein explizites Puffermangement wesentlich. Im englischen Wikipedia-Artikel über PERT werden für ein Beispielsprojekt sieben Vorgänge gemäß PERT geschätzt (Abbildung 4.20). Vorgang Vorgänger Dauer: Schätzungen µ i σ i µ i + σ i best (a) normal (c) worst (b) (PERT) (PERT) (PERT) A ,00 0,67 4,67 B ,33 1,00 6,33 C A ,17 0,50 5,67 D A ,33 1,00 7,33 E B; C ,17 0,50 5,67 F D ,50 0,83 5,33 G E ,17 0,83 6,00 Abbildung 4.20: Wikipedia-Beispiel (Wikipedia [2011c]) Die Schätzwerte µ i für die Dauer der einzelnen Vorgänge sowie σ i wurden mittels der PERT-Formeln µ i = (a i + 4c i + b i )/6 und σ i = (b i a i )/6 ermittelt (siehe Abschnitt 3.3.3), wobei die σ i -Werte im Wikipedia-Artikel nicht angegeben wurden. In Abbildung 4.21 wird oben das zugehörige Gantt-Diagramm gezeigt. Eine große Frage bleibt: Ist die im Wikipedia-Artikel angewendete Art der Schätzung der Projektgesamtdauer, bei der ausschließlich die Erwartungswerte (ungerundet) aufsummiert werden, überhaupt sinnvoll? Laut zentralem Grenzwertsatz (Abschnitt 3.3.2) liefert die Summe aller Erwartungswerte der kritischen Vorgänge eine recht gute Schätzung für den Erwartungswert der Gesamtdauer: µ = 4, , , , 17 = 19, 51. (Besser noch wären tagesgenaue Schätzungen; vgl. Abschnitt 3.5) Doch was sagt der Erwartungswert µ aus? Er sagt aus, dass das Projekt mit einer Wahrscheinlichkeit von 50 % nach neunzehneinhalb Tagen fertig sein wird. 2 Insofern ist die Wikipedia-Schätzung ziemlich gewagt. 2 Für die Normalverteilung ist das 50 %-Quartil gleich dem Erwartungswert. 153 Draft (13. März 2015)

154 Draft (13. März 2015) 154 Abbildung 4.21: Gantt-Diagramme für das PERT-Beispiel; oben: µi; unten: µi + σi

Projektmanagement in der Spieleentwicklung

Projektmanagement in der Spieleentwicklung Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren

Mehr

Warum Projektmanagement?

Warum Projektmanagement? Warum Projektmanagement? Projektmanagement ist keine Software, sondern eine, die Beteiligten verpflichtende Vorgehenssystematik, ein Verhaltenskodex und Kontrollsystem für die Dauer eines Projekts. Projektmanagement

Mehr

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät

Mehr

Vorlesung. Projektmanagement. Wintersemester 2012/2013. Wolfgang Kowarschick. Hochschule Augsburg

Vorlesung. Projektmanagement. Wintersemester 2012/2013. Wolfgang Kowarschick. Hochschule Augsburg Vorlesung Projektmanagement Wintersemester 2012/2013 Wolfgang Kowarschick Hochschule Augsburg Draft (4. Oktober 2012) 2 Inhalt 1 Definitionen 7 1.1 Projekte............................... 8 1.1.1 Definition

Mehr

Projektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes:

Projektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes: Projektmanagement Link http://promana.edulearning.at/projektleitung.html Einleitung Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes: Definition des Begriffs Projekt" Kriterien

Mehr

PROJEKTCOACHING Thomas Kettner thomas@kettner-consulting.com www.kettner-consulting.com

PROJEKTCOACHING Thomas Kettner thomas@kettner-consulting.com www.kettner-consulting.com PROJEKTCOACHING Thomas Kettner thomas@kettner-consulting.com www.kettner-consulting.com AGENDA Ausgangslage Konsequenzen Lösungsansatz Projektcoaching Grundregeln des Projektcoachings Wann kommt Projektcoaching

Mehr

Papa - was ist American Dream?

Papa - was ist American Dream? Papa - was ist American Dream? Das heißt Amerikanischer Traum. Ja, das weiß ich, aber was heißt das? Der [wpseo]amerikanische Traum[/wpseo] heißt, dass jeder Mensch allein durch harte Arbeit und Willenskraft

Mehr

WollCo Wolfgang Kohl Consulting. Nachhaltige Projektumsetzung nicht nur in der Verantwortung von Geschäftsführen / Unternehmern

WollCo Wolfgang Kohl Consulting. Nachhaltige Projektumsetzung nicht nur in der Verantwortung von Geschäftsführen / Unternehmern Nachhaltige Projektumsetzung nicht nur in der Verantwortung von Geschäftsführen / Unternehmern Definitionen Ein Projekt ist ein einmaliges Vorhaben, das aus einem Satz von abgestimmten, gelenkten Tätigkeiten

Mehr

Projektmanagement PPSAP WS 03/04. Inhaltsverzeichnis : 1. Projektmanagement

Projektmanagement PPSAP WS 03/04. Inhaltsverzeichnis : 1. Projektmanagement PPSAP WS 03/04 H.Pangestu, S.Krutt 1 Inhaltsverzeichnis : 1. 1.1 Definition 1.2 Merkmale 1.3 Notwendigkeit 1.4 Dimensionen 1.5 Grafik Projekt 1.6 Projektablauf 2. Beispiel nach Prof. Isenbergs Projekt

Mehr

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Projektarbeit. 2003 Eberhard Neef - 2 - Nee Seite 1

Projektarbeit. 2003 Eberhard Neef - 2 - Nee Seite 1 Nee Seite 1 1. Projektorganisation...2 1.1. Projektdefinition...2 1.2. Projektauslösung...2 1.3. Vorstudie...2 1.3.1. Zweck der Vorstudie und Aufgaben...2 1.3.2. Problemanalyse...2 1.3.3. Ziele...3 1.3.4.

Mehr

Was sind Jahres- und Zielvereinbarungsgespräche?

Was sind Jahres- und Zielvereinbarungsgespräche? 6 Was sind Jahres- und Zielvereinbarungsgespräche? Mit dem Jahresgespräch und der Zielvereinbarung stehen Ihnen zwei sehr wirkungsvolle Instrumente zur Verfügung, um Ihre Mitarbeiter zu führen und zu motivieren

Mehr

Dokumentation des Reflexionsworkshops 1 im Projekt QA am 15. Dezember 2005 im Haus Eckstein, Nürnberg

Dokumentation des Reflexionsworkshops 1 im Projekt QA am 15. Dezember 2005 im Haus Eckstein, Nürnberg Dokumentation des Reflexionsworkshops 1 im Projekt QA am 15. Dezember 2005 im Haus Eckstein, Nürnberg 1. Begrüßung/Vorstellung der Tagesordnung In seiner Einführungspräsentation machte Moderator Dr. Klaus

Mehr

Einkaufen im Internet. Lektion 5 in Themen neu 3, nach Übung 10. Benutzen Sie die Homepage von: http://www.firstsurf.de/klietm9950_f.

Einkaufen im Internet. Lektion 5 in Themen neu 3, nach Übung 10. Benutzen Sie die Homepage von: http://www.firstsurf.de/klietm9950_f. Themen neu 3 Was lernen Sie hier? Sie formulieren Ihre Vermutungen und Meinungen. Was machen Sie? Sie erklären Wörter und Ausdrücke und beurteilen Aussagen. Einkaufen im Internet Lektion 5 in Themen neu

Mehr

Primzahlen und RSA-Verschlüsselung

Primzahlen und RSA-Verschlüsselung Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also

Mehr

Eva Douma: Die Vorteile und Nachteile der Ökonomisierung in der Sozialen Arbeit

Eva Douma: Die Vorteile und Nachteile der Ökonomisierung in der Sozialen Arbeit Eva Douma: Die Vorteile und Nachteile der Ökonomisierung in der Sozialen Arbeit Frau Dr. Eva Douma ist Organisations-Beraterin in Frankfurt am Main Das ist eine Zusammen-Fassung des Vortrages: Busines

Mehr

Wichtige Forderungen für ein Bundes-Teilhabe-Gesetz

Wichtige Forderungen für ein Bundes-Teilhabe-Gesetz Wichtige Forderungen für ein Bundes-Teilhabe-Gesetz Die Parteien CDU, die SPD und die CSU haben versprochen: Es wird ein Bundes-Teilhabe-Gesetz geben. Bis jetzt gibt es das Gesetz noch nicht. Das dauert

Mehr

6 Schulungsmodul: Probenahme im Betrieb

6 Schulungsmodul: Probenahme im Betrieb 6 Schulungsmodul: Probenahme im Betrieb WIEDNER Wie schon im Kapitel VI erwähnt, ist die Probenahme in Betrieben, die Produkte nach dem Lebensmittel- und Futtermittelgesetzbuch herstellen oder in den Verkehr

Mehr

Kulturelle Evolution 12

Kulturelle Evolution 12 3.3 Kulturelle Evolution Kulturelle Evolution Kulturelle Evolution 12 Seit die Menschen Erfindungen machen wie z.b. das Rad oder den Pflug, haben sie sich im Körperbau kaum mehr verändert. Dafür war einfach

Mehr

DER SELBST-CHECK FÜR IHR PROJEKT

DER SELBST-CHECK FÜR IHR PROJEKT DER SELBST-CHECK FÜR IHR PROJEKT In 30 Fragen und 5 Tipps zum erfolgreichen Projekt! Beantworten Sie die wichtigsten Fragen rund um Ihr Projekt für Ihren Erfolg und für Ihre Unterstützer. IHR LEITFADEN

Mehr

Professionelle Seminare im Bereich MS-Office

Professionelle Seminare im Bereich MS-Office Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion

Mehr

Wichtig ist die Originalsatzung. Nur was in der Originalsatzung steht, gilt. Denn nur die Originalsatzung wurde vom Gericht geprüft.

Wichtig ist die Originalsatzung. Nur was in der Originalsatzung steht, gilt. Denn nur die Originalsatzung wurde vom Gericht geprüft. Das ist ein Text in leichter Sprache. Hier finden Sie die wichtigsten Regeln für den Verein zur Förderung der Autonomie Behinderter e. V.. Das hier ist die Übersetzung der Originalsatzung. Es wurden nur

Mehr

IKP Uni Bonn Medienpraxis EDV II Internet Projekt

IKP Uni Bonn Medienpraxis EDV II Internet Projekt IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung

Mehr

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.

Mehr

Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU

Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU 2 DIE MEDIZINISCH-PSYCHOLOGISCHE UNTERSUCHUNG (MPU) IST HOCH ANGESEHEN Das Image der Medizinisch-Psychologischen Untersuchung (MPU) ist zwiespältig: Das ist

Mehr

Dieser PDF-Report kann und darf unverändert weitergegeben werden.

Dieser PDF-Report kann und darf unverändert weitergegeben werden. ME Finanz-Coaching Matthias Eilers Peter-Strasser-Weg 37 12101 Berlin Dieser PDF-Report kann und darf unverändert weitergegeben werden. http://www.matthiaseilers.de/ Vorwort: In diesem PDF-Report erfährst

Mehr

Was meinen die Leute eigentlich mit: Grexit?

Was meinen die Leute eigentlich mit: Grexit? Was meinen die Leute eigentlich mit: Grexit? Grexit sind eigentlich 2 Wörter. 1. Griechenland 2. Exit Exit ist ein englisches Wort. Es bedeutet: Ausgang. Aber was haben diese 2 Sachen mit-einander zu tun?

Mehr

Leseprobe. Bruno Augustoni. Professionell präsentieren. ISBN (Buch): 978-3-446-44285-6. ISBN (E-Book): 978-3-446-44335-8

Leseprobe. Bruno Augustoni. Professionell präsentieren. ISBN (Buch): 978-3-446-44285-6. ISBN (E-Book): 978-3-446-44335-8 Leseprobe Bruno Augustoni Professionell präsentieren ISBN (Buch): 978-3-446-44285-6 ISBN (E-Book): 978-3-446-44335-8 Weitere Informationen oder Bestellungen unter http://wwwhanser-fachbuchde/978-3-446-44285-6

Mehr

Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse

Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse Kundenbefragung als Vehikel zur Optimierung des Customer Service Feedback des Kunden nutzen zur Verbesserung der eigenen Prozesse Vieles wurde bereits geschrieben, über die Definition und/oder Neugestaltung

Mehr

Mobile Intranet in Unternehmen

Mobile Intranet in Unternehmen Mobile Intranet in Unternehmen Ergebnisse einer Umfrage unter Intranet Verantwortlichen aexea GmbH - communication. content. consulting Augustenstraße 15 70178 Stuttgart Tel: 0711 87035490 Mobile Intranet

Mehr

Studieren- Erklärungen und Tipps

Studieren- Erklärungen und Tipps Studieren- Erklärungen und Tipps Es gibt Berufe, die man nicht lernen kann, sondern für die man ein Studium machen muss. Das ist zum Beispiel so wenn man Arzt oder Lehrer werden möchte. Hat ihr Kind das

Mehr

a) Bis zu welchem Datum müssen sie spätestens ihre jetzigen Wohnungen gekündigt haben, wenn sie selber keine Nachmieter suchen wollen?

a) Bis zu welchem Datum müssen sie spätestens ihre jetzigen Wohnungen gekündigt haben, wenn sie selber keine Nachmieter suchen wollen? Thema Wohnen 1. Ben und Jennifer sind seit einiger Zeit ein Paar und beschliessen deshalb, eine gemeinsame Wohnung zu mieten. Sie haben Glück und finden eine geeignete Dreizimmer-Wohnung auf den 1.Oktober

Mehr

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.

Mehr

Die Invaliden-Versicherung ändert sich

Die Invaliden-Versicherung ändert sich Die Invaliden-Versicherung ändert sich 1 Erklärung Die Invaliden-Versicherung ist für invalide Personen. Invalid bedeutet: Eine Person kann einige Sachen nicht machen. Wegen einer Krankheit. Wegen einem

Mehr

Damit auch Sie den richtigen Weg nehmen können die 8 wichtigsten Punkte, die Sie bei der Beantragung Ihrer Krankenversicherung beachten sollten:

Damit auch Sie den richtigen Weg nehmen können die 8 wichtigsten Punkte, die Sie bei der Beantragung Ihrer Krankenversicherung beachten sollten: Damit auch Sie den richtigen Weg nehmen können die 8 wichtigsten Punkte, die Sie bei der Beantragung Ihrer Krankenversicherung beachten sollten: Herzlich Willkommen bei der mehr-finanz24 GmbH Mit uns haben

Mehr

Das Persönliche Budget in verständlicher Sprache

Das Persönliche Budget in verständlicher Sprache Das Persönliche Budget in verständlicher Sprache Das Persönliche Budget mehr Selbstbestimmung, mehr Selbstständigkeit, mehr Selbstbewusstsein! Dieser Text soll den behinderten Menschen in Westfalen-Lippe,

Mehr

Kapitel 3: Einführung Projektmanagement

Kapitel 3: Einführung Projektmanagement : : : : : : : : : : : : : : : : : : : : : Kapitel 3: Einführung Projektmanagement Dr.-Ing. Bastian Koller, Axel Tenschert koller@hlrs.de, tenschert@hlrs.de : : : : : : : : : : : : : : : : : : : : : Kapitel

Mehr

40-Tage-Wunder- Kurs. Umarme, was Du nicht ändern kannst.

40-Tage-Wunder- Kurs. Umarme, was Du nicht ändern kannst. 40-Tage-Wunder- Kurs Umarme, was Du nicht ändern kannst. Das sagt Wikipedia: Als Wunder (griechisch thauma) gilt umgangssprachlich ein Ereignis, dessen Zustandekommen man sich nicht erklären kann, so dass

Mehr

ratgeber Urlaub - Dein gutes Recht

ratgeber Urlaub - Dein gutes Recht Viele Arbeitgeber wollen jetzt die Urlaubsplanung für 2011 vorgelegt bekommen. Dabei kommt es immer wieder zu Streitereien unter den Kollegen. Aber auch zwischen Arbeitnehmern und Arbeitgebern kann es

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Grundlagen des Projektmanagements

Grundlagen des Projektmanagements Grundlagen des Projektmanagements Dr. Hartmut Rösch Der Einstieg 1 Was ist ein Projekt? Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet

Mehr

Stellen Sie bitte den Cursor in die Spalte B2 und rufen die Funktion Sverweis auf. Es öffnet sich folgendes Dialogfenster

Stellen Sie bitte den Cursor in die Spalte B2 und rufen die Funktion Sverweis auf. Es öffnet sich folgendes Dialogfenster Es gibt in Excel unter anderem die so genannten Suchfunktionen / Matrixfunktionen Damit können Sie Werte innerhalb eines bestimmten Bereichs suchen. Als Beispiel möchte ich die Funktion Sverweis zeigen.

Mehr

Windows 10 > Fragen über Fragen

Windows 10 > Fragen über Fragen www.computeria-olten.ch Monatstreff für Menschen ab 50 Merkblatt 103 Windows 10 > Fragen über Fragen Was ist das? Muss ich dieses Upgrade machen? Was bringt mir das neue Programm? Wie / wann muss ich es

Mehr

Alle gehören dazu. Vorwort

Alle gehören dazu. Vorwort Alle gehören dazu Alle sollen zusammen Sport machen können. In diesem Text steht: Wie wir dafür sorgen wollen. Wir sind: Der Deutsche Olympische Sport-Bund und die Deutsche Sport-Jugend. Zu uns gehören

Mehr

IWW Studienprogramm. Grundlagenstudium. Projektplanung Teil D. Lösungsmuster zur 1. Musterklausur

IWW Studienprogramm. Grundlagenstudium. Projektplanung Teil D. Lösungsmuster zur 1. Musterklausur Institut für Wirtschaftswissenschaftliche Forschung und Weiterbildung GmbH Institut an der FernUniversität in Hagen IWW Studienprogramm Grundlagenstudium Projektplanung Teil D Lösungsmuster zur 1. Musterklausur

Mehr

Fragebogen: Abschlussbefragung

Fragebogen: Abschlussbefragung Fragebogen: Abschlussbefragung Vielen Dank, dass Sie die Ameise - Schulung durchgeführt haben. Abschließend möchten wir Ihnen noch einige Fragen zu Ihrer subjektiven Einschätzung unseres Simulationssystems,

Mehr

Projektvorbereitung und Durchführung

Projektvorbereitung und Durchführung Projektvorbereitung und Durchführung Gründe für für das Scheitern vieler Reformprojekte in in Unternehmen und im im öffentlichen Bereich liegen oftmals in in der Missachtung grundlegender Prinzipien des

Mehr

Mehr Geld verdienen! Lesen Sie... Peter von Karst. Ihre Leseprobe. der schlüssel zum leben. So gehen Sie konkret vor!

Mehr Geld verdienen! Lesen Sie... Peter von Karst. Ihre Leseprobe. der schlüssel zum leben. So gehen Sie konkret vor! Peter von Karst Mehr Geld verdienen! So gehen Sie konkret vor! Ihre Leseprobe Lesen Sie...... wie Sie mit wenigen, aber effektiven Schritten Ihre gesteckten Ziele erreichen.... wie Sie die richtigen Entscheidungen

Mehr

Das Leitbild vom Verein WIR

Das Leitbild vom Verein WIR Das Leitbild vom Verein WIR Dieses Zeichen ist ein Gütesiegel. Texte mit diesem Gütesiegel sind leicht verständlich. Leicht Lesen gibt es in drei Stufen. B1: leicht verständlich A2: noch leichter verständlich

Mehr

~~ Swing Trading Strategie ~~

~~ Swing Trading Strategie ~~ ~~ Swing Trading Strategie ~~ Ebook Copyright by Thomas Kedziora www.forextrade.de Die Rechte des Buches Swing Trading Strategie liegen beim Autor und Herausgeber! -- Seite 1 -- Haftungsausschluss Der

Mehr

Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert.

Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert. Der Gutachtenstil: Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert. Das Ergebnis steht am Schluß. Charakteristikum

Mehr

infach Geld FBV Ihr Weg zum finanzellen Erfolg Florian Mock

infach Geld FBV Ihr Weg zum finanzellen Erfolg Florian Mock infach Ihr Weg zum finanzellen Erfolg Geld Florian Mock FBV Die Grundlagen für finanziellen Erfolg Denn Sie müssten anschließend wieder vom Gehaltskonto Rückzahlungen in Höhe der Entnahmen vornehmen, um

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

Manager. von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen. Spielanleitung

Manager. von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen. Spielanleitung Manager von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen Spielanleitung Manager Ein rasantes Wirtschaftsspiel für 3 bis 6 Spieler. Das Glück Ihrer Firma liegt in Ihren Händen! Bestehen Sie gegen

Mehr

Kreativ visualisieren

Kreativ visualisieren Kreativ visualisieren Haben Sie schon einmal etwas von sogenannten»sich selbst erfüllenden Prophezeiungen«gehört? Damit ist gemeint, dass ein Ereignis mit hoher Wahrscheinlichkeit eintritt, wenn wir uns

Mehr

DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG

DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG DAS PARETO PRINZIP DER SCHLÜSSEL ZUM ERFOLG von Urs Schaffer Copyright by Urs Schaffer Schaffer Consulting GmbH Basel www.schaffer-consulting.ch Info@schaffer-consulting.ch Haben Sie gewusst dass... >

Mehr

Projektmanagement. Kick-off Camp SoSe 2014. Florian Lückenbach M.Sc. Hochschulentwicklung und Qualitätssicherung

Projektmanagement. Kick-off Camp SoSe 2014. Florian Lückenbach M.Sc. Hochschulentwicklung und Qualitätssicherung Projektmanagement. Kick-off Camp SoSe 2014 1 Haben Sie schon einmal ein Projekt durchgeführt? 2 Was Sie erwartet: Teil 1. Ein wenig Theorie // Youtube // DIN 69901 Teil 2. Ein praktisches Beispiel // Projektauftrag:

Mehr

Projekt- Management. Landesverband der Mütterzentren NRW. oder warum Horst bei uns Helga heißt

Projekt- Management. Landesverband der Mütterzentren NRW. oder warum Horst bei uns Helga heißt Projekt- Management oder warum Horst bei uns Helga heißt Landesverband der Projektplanung Projektplanung gibt es, seit Menschen größere Vorhaben gemeinschaftlich durchführen. militärische Feldzüge die

Mehr

Bürgerhilfe Florstadt

Bürgerhilfe Florstadt Welche Menschen kommen? Erfahrungen mit der Aufnahme vor Ort vorgestellt von Anneliese Eckhardt, BHF Florstadt Flüchtlinge sind eine heterogene Gruppe Was heißt das für Sie? Jeder Einzelne ist ein Individuum,

Mehr

DAVID: und David vom Deutschlandlabor. Wir beantworten Fragen zu Deutschland und den Deutschen.

DAVID: und David vom Deutschlandlabor. Wir beantworten Fragen zu Deutschland und den Deutschen. Das Deutschlandlabor Folge 09: Auto Manuskript Die Deutschen sind bekannt dafür, dass sie ihre Autos lieben. Doch wie sehr lieben sie ihre Autos wirklich, und hat wirklich jeder in Deutschland ein eigenes

Mehr

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999 Mind Mapping am PC für Präsentationen, Vorträge, Selbstmanagement von Isolde Kommer, Helmut Reinke 1. Auflage Hanser München 1999 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 21222 0 schnell

Mehr

1. Weniger Steuern zahlen

1. Weniger Steuern zahlen 1. Weniger Steuern zahlen Wenn man arbeitet, zahlt man Geld an den Staat. Dieses Geld heißt Steuern. Viele Menschen zahlen zu viel Steuern. Sie haben daher wenig Geld für Wohnung, Gewand oder Essen. Wenn

Mehr

Anleitung für das MS Project Professional 2003 (Deutsche Version)

Anleitung für das MS Project Professional 2003 (Deutsche Version) Anleitung für das MS Project Professional 2003 (Deutsche Version) Erstes Starten... 2 Tutorial... 3 Hilfe... 4 Critical Path / Kritischer Weg... 5 Der Critical Path / Kritischer Weg wird nicht korrekt

Mehr

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 Referentin: Dr. Kelly Neudorfer Universität Hohenheim Was wir jetzt besprechen werden ist eine Frage, mit denen viele

Mehr

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten Das große x -4 Alles über das Wer kann beantragen? Generell kann jeder beantragen! Eltern (Mütter UND Väter), die schon während ihrer Elternzeit wieder in Teilzeit arbeiten möchten. Eltern, die während

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

Mehr

Selbsttest Prozessmanagement

Selbsttest Prozessmanagement Selbsttest Prozessmanagement Zur Feststellung des aktuellen Status des Prozessmanagements in Ihrem Unternehmen steht Ihnen dieser kurze Test mit zehn Fragen zur Verfügung. Der Test dient Ihrer persönlichen

Mehr

CSS-Grundlagen. Etwas über Browser. Kapitel. Die Vorbereitung

CSS-Grundlagen. Etwas über Browser. Kapitel. Die Vorbereitung Kapitel 1 Die Vorbereitung Vorgängerversionen. Bald darauf folgte dann schon die Version 4, die mit einer kleinen Bearbeitung bis vor Kurzem 15 Jahre unverändert gültig war. All das, was du die letzten

Mehr

Verpasst der Mittelstand den Zug?

Verpasst der Mittelstand den Zug? Industrie 4.0: Verpasst der Mittelstand den Zug? SCHÜTTGUT Dortmund 2015 5.11.2015 Ergebnisse einer aktuellen Studie der Technischen Hochschule Mittelhessen 1 Industrie 4.0 im Mittelstand Ergebnisse einer

Mehr

Die Gesellschaftsformen

Die Gesellschaftsformen Jede Firma - auch eure Schülerfirma - muss sich an bestimmte Spielregeln halten. Dazu gehört auch, dass eine bestimmte Rechtsform für das Unternehmen gewählt wird. Für eure Schülerfirma könnt ihr zwischen

Mehr

Meet the Germans. Lerntipp zur Schulung der Fertigkeit des Sprechens. Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten

Meet the Germans. Lerntipp zur Schulung der Fertigkeit des Sprechens. Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten Meet the Germans Lerntipp zur Schulung der Fertigkeit des Sprechens Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten Handreichungen für die Kursleitung Seite 2, Meet the Germans 2. Lerntipp

Mehr

DAVID: und David vom Deutschlandlabor. Wir beantworten Fragen zu Deutschland und den Deutschen.

DAVID: und David vom Deutschlandlabor. Wir beantworten Fragen zu Deutschland und den Deutschen. Manuskript Die Deutschen sind bekannt dafür, dass sie ihre Autos lieben. Doch wie sehr lieben sie ihre Autos wirklich, und hat wirklich jeder in Deutschland ein eigenes Auto? David und Nina fragen nach.

Mehr

Pädagogik. Melanie Schewtschenko. Eingewöhnung und Übergang in die Kinderkrippe. Warum ist die Beteiligung der Eltern so wichtig?

Pädagogik. Melanie Schewtschenko. Eingewöhnung und Übergang in die Kinderkrippe. Warum ist die Beteiligung der Eltern so wichtig? Pädagogik Melanie Schewtschenko Eingewöhnung und Übergang in die Kinderkrippe Warum ist die Beteiligung der Eltern so wichtig? Studienarbeit Inhaltsverzeichnis 1. Einleitung.2 2. Warum ist Eingewöhnung

Mehr

Zusammenarbeit im Projekt

Zusammenarbeit im Projekt Zusammenarbeit im Projekt Die folgenden Folien geben ein paar Grundsätze und Tips aus unserer Projektmanagement Erfahrung weiter. Vielleicht nicht viel Neues? just do it! Grundsätze Viele Firmen sind nach

Mehr

Erläuterungen zur Untervergabe von Instandhaltungsfunktionen

Erläuterungen zur Untervergabe von Instandhaltungsfunktionen Zentrale Erläuterungen zur Untervergabe von Instandhaltungsfunktionen Gemäß Artikel 4 der Verordnung (EU) 445/2011 umfasst das Instandhaltungssystem der ECM die a) Managementfunktion b) Instandhaltungsentwicklungsfunktion

Mehr

Lösungshinweise zur Einsendearbeit 2 SS 2011

Lösungshinweise zur Einsendearbeit 2 SS 2011 Lösungshinweise zur Einsendearbeit 2 zum Kurs 41500, Finanzwirtschaft: Grundlagen, SS2011 1 Lösungshinweise zur Einsendearbeit 2 SS 2011 Finanzwirtschaft: Grundlagen, Kurs 41500 Aufgabe Finanzierungsbeziehungen

Mehr

Unsere vier hilfreichsten Tipps für szenarienbasierte Nachfrageplanung

Unsere vier hilfreichsten Tipps für szenarienbasierte Nachfrageplanung Management Briefing Unsere vier hilfreichsten Tipps für szenarienbasierte Nachfrageplanung Erhalten Sie die Einblicke, die Sie brauchen, um schnell auf Nachfrageschwankungen reagieren zu können Sales and

Mehr

POCKET POWER. Projektmanagement. 3. Auflage

POCKET POWER. Projektmanagement. 3. Auflage POCKET POWER Projektmanagement 3. Auflage 3 Inhalt 1 Einleitung.................................... 5 2 Grundlagen des Projektmanagements................... 8 2.1 Projektdefinition..............................

Mehr

ONLINE-AKADEMIE. "Diplomierter NLP Anwender für Schule und Unterricht" Ziele

ONLINE-AKADEMIE. Diplomierter NLP Anwender für Schule und Unterricht Ziele ONLINE-AKADEMIE Ziele Wenn man von Menschen hört, die etwas Großartiges in ihrem Leben geleistet haben, erfahren wir oft, dass diese ihr Ziel über Jahre verfolgt haben oder diesen Wunsch schon bereits

Mehr

PLATTFORM PERSONALMANAGEMENT

PLATTFORM PERSONALMANAGEMENT PLATTFORM PERSONALMANAGEMENT Leitfaden MitarbeiterInnengespräch Vorbereitungsbogen für MitarbeiterInnen Dieser Bogen soll Ihnen als MitarbeiterIn zur persönlichen Vorbereitung auf das MitarbeiterInnengespräch

Mehr

Kurzanleitung. MEYTON Aufbau einer Internetverbindung. 1 Von 11

Kurzanleitung. MEYTON Aufbau einer Internetverbindung. 1 Von 11 Kurzanleitung MEYTON Aufbau einer Internetverbindung 1 Von 11 Inhaltsverzeichnis Installation eines Internetzugangs...3 Ist mein Router bereits im MEYTON Netzwerk?...3 Start des YAST Programms...4 Auswahl

Mehr

Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich?

Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich? Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich? Was verkaufen wir eigentlich? Provokativ gefragt! Ein Hotel Marketing Konzept Was ist das? Keine Webseite, kein SEO, kein Paket,. Was verkaufen

Mehr

Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation

Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation Einführung Mit welchen Erwartungen gehen Jugendliche eigentlich in ihre Ausbildung? Wir haben zu dieser Frage einmal die Meinungen von Auszubildenden

Mehr

Reizdarmsyndrom lindern

Reizdarmsyndrom lindern MARIA HOLL Reizdarmsyndrom lindern Mit der Maria-Holl-Methode (MHM) Der ganzheitliche Ansatz 18 Wie Sie mit diesem Buch Ihr Ziel erreichen Schritt 1: Formulieren Sie Ihr Ziel Als Erstes notieren Sie Ihr

Mehr

Lieber SPAMRobin -Kunde!

Lieber SPAMRobin -Kunde! Lieber SPAMRobin -Kunde! Wir freuen uns, dass Sie sich für SPAMRobin entschieden haben. Mit diesem Leitfaden möchten wir Ihnen die Kontoeinrichtung erleichtern und die Funktionen näher bringen. Bitte führen

Mehr

1. Einführung. 2. Archivierung alter Datensätze

1. Einführung. 2. Archivierung alter Datensätze 1. Einführung Mit wachsender Datenmenge und je nach Konfiguration, kann orgamax mit der Zeit langsamer werden. Es gibt aber diverse Möglichkeiten, die Software wieder so zu beschleunigen, als würden Sie

Mehr

Ende von Vertragsbeziehungen

Ende von Vertragsbeziehungen Ende von Vertragsbeziehungen Ende von Vertragsbeziehungen oder Alles hat (hoffentlich!) mal ein Ende! 170 Ende von Vertragsbeziehungen Vertragsbeziehungen enden: regulär durch vollständig erbrachten Leistungsaustausch

Mehr

Der Klassenrat entscheidet

Der Klassenrat entscheidet Folie zum Einstieg: Die Klasse 8c (Goethe-Gymnasium Gymnasium in Köln) plant eine Klassenfahrt: A Sportcamp an der deutschen Nordseeküste B Ferienanlage in Süditalien Hintergrundinfos zur Klasse 8c: -

Mehr

Was ist Sozial-Raum-Orientierung?

Was ist Sozial-Raum-Orientierung? Was ist Sozial-Raum-Orientierung? Dr. Wolfgang Hinte Universität Duisburg-Essen Institut für Stadt-Entwicklung und Sozial-Raum-Orientierte Arbeit Das ist eine Zusammen-Fassung des Vortrages: Sozialräume

Mehr

CARNEADES GmbH & Co. KG Billungstr. 2 D-06484 Quedlinburg www.carneades.de. Projekte Verträge Claims

CARNEADES GmbH & Co. KG Billungstr. 2 D-06484 Quedlinburg www.carneades.de. Projekte Verträge Claims CARNEADES GmbH & Co. KG Billungstr. 2 D-06484 Quedlinburg Projekte Verträge Claims LEISTUNGEN Unternehmens- profil Nehmen Sie nur Spezialisten! Ihr wirtschaftlicher Erfolg ist Ihnen wichtig - und immer

Mehr

Die sechs häufigsten Fehler

Die sechs häufigsten Fehler Die sechs häufigsten Fehler Broschüre 06 ... hätte ich das gewusst, hätte ich es anders gemacht! Gerade zum Anfang des Verkaufsprozesses passieren die meisten Fehler. Das wollen Sie bestimmt nicht irgendwann

Mehr

Also heißt es einmal mehr, immer eine eigene Meinungen bilden, nicht beeinflussen lassen, niemals von anderen irgend eine Meinung aufdrängen lassen.

Also heißt es einmal mehr, immer eine eigene Meinungen bilden, nicht beeinflussen lassen, niemals von anderen irgend eine Meinung aufdrängen lassen. Seite 1 von 5 Wirtschaft, Finanzen und IT Computer und Technologie Internetseiten Übersichtlich alle verfügbaren Internetseiten von wirfinit. de und darüber hinaus, weitere empfehlenswerte Internetseiten

Mehr

Leseprobe - Seite 5 - Kapitel 5 Fragetechniken - Einfürung

Leseprobe - Seite 5 - Kapitel 5 Fragetechniken - Einfürung So werden Sie ein Nutzenverkäufer Fernlehrgang 1-04 2b4u Kapitel 5-1 Leseprobe - Seite 5 - Kapitel 5 Fragetechniken - Einfürung Wie bereits oben erwähnt: haben die Funktion von Wegweisern! Kunde: Kunde:

Mehr

WO IST MEIN HUND? SICHER, SCHNELL UND ZUVERLÄSSIG

WO IST MEIN HUND? SICHER, SCHNELL UND ZUVERLÄSSIG WO IST MEIN HUND? SICHER, SCHNELL UND ZUVERLÄSSIG Die Hundepension Münster bedient sich aus Sicherheitsgründen dieser Technik um sicherzustellen, dass fremde von uns betreute Hunde nicht auf Abwege geraten.

Mehr

Flexibilität und Erreichbarkeit

Flexibilität und Erreichbarkeit Flexibilität und Erreichbarkeit Auswirkungen und Gesundheitsrisiken Ergebnisse einer Umfrage unter Führungskräften, in Zusammenarbeit mit dem Verband Die Führungskräfte e.v. BARMER GEK Hauptverwaltung

Mehr

SSC Basismodulprüfung Stufe höhere Fachprüfung Musterprüfung. Fach: Projektmanagement

SSC Basismodulprüfung Stufe höhere Fachprüfung Musterprüfung. Fach: Projektmanagement SwissSupplyChain SSC Basismodulprüfung Stufe höhere Fachprüfung Fach: Projektmanagement 5 Aufgaben Mögliche Gesamtpunkte: 60 Erreichte Punkte: Kandidat/in: Ausgangslage Das Unternehmen Wiso AG produziert

Mehr

ZIELE erreichen WERTSTROM. IDEEN entwickeln. KULTUR leben. optimieren. KVP und Lean Management:

ZIELE erreichen WERTSTROM. IDEEN entwickeln. KULTUR leben. optimieren. KVP und Lean Management: KVP und Lean Management: Damit machen wir Ihre Prozesse robuster, schneller und kostengünstiger. ZIELE erreichen WERTSTROM optimieren IDEEN entwickeln KULTUR leben 1 Lean Management Teil 1: Das Geheimnis

Mehr

Sitzungsleitung. Dr. Urs-Peter Oberlin www.oberlin.ch 1/5

Sitzungsleitung. Dr. Urs-Peter Oberlin www.oberlin.ch 1/5 Führungskräfte aller Ebenen verbringen einen grossen Teil ihrer Arbeitszeit an Sitzungen, Meetings und Besprechungen. Viele dieser Veranstaltungen werden von den Teilnehmern selbst als pure Zeitverschwendung

Mehr