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

Größe: px
Ab Seite anzeigen:

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

Transkript

1 Vorlesung Projektmanagement Wintersemester 2012/2013 Wolfgang Kowarschick Hochschule Augsburg

2 Draft (4. Oktober 2012) 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 (4. Oktober 2012)

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 Die Function-Point-Methode COCOMO Die Güte von Schätzverfahren Was ist ein Personenmonat? Planung Projektpläne Grobplanung Projektstrukturplan Feinplanung, insb. Ressourcen-Management 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 Integrierter Puffer Draft (4. Oktober 2012) 4

5 4.5.2 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 (4. Oktober 2012)

6 Draft (4. Oktober 2012) 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 7 Draft (4. Oktober 2012)

8 projektspezifische Organisation 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 (4. Oktober 2012) 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 (4. Oktober 2012)

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 (4. Oktober 2012) 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 (4. Oktober 2012)

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 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 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. 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). Draft (4. Oktober 2012) 12

13 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. 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 13 Draft (4. Oktober 2012)

14 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 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) Draft (4. Oktober 2012) 14

15 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 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...!!! 15 Draft (4. Oktober 2012)

16 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 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. 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 Draft (4. Oktober 2012) 16

17 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: 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! 17 Draft (4. Oktober 2012)

18 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! 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]). Draft (4. Oktober 2012) 18

19 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). 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]) 19 Draft (4. Oktober 2012)

20 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 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. Draft (4. Oktober 2012) 20

21 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). 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 21 Draft (4. Oktober 2012)

22 !"# -!- $# %& %'(& ) % &!"#.-!"# - &!"# - + &, + &, + &, + &, * &!"# Abbildung 1.2: Produktion 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 beschleunigen. 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. Draft (4. Oktober 2012) 22

23 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]). 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. 23 Draft (4. Oktober 2012)

24 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.) 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.) Draft (4. Oktober 2012) 24

25 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 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. 25 Draft (4. Oktober 2012)

26 1.2.4 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 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. Draft (4. Oktober 2012) 26

27 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) 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! 27 Draft (4. Oktober 2012)

28 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: 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. Draft (4. Oktober 2012) 28

29 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. Strategische Ziele eines gewinnorientierten Unternehmens Goldratt definiert die strategischen Ziele eines gewinnorientierten Unternehmens folgendermaßen (Goldratt [2003]): 1. Gewinn machen 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 steigern? 1. Nettogewinn steigern Nettogewinn = Einnahmen Ausgaben > 0 (unter Berücksichtigung der Inflation) 2. Rendite steigern Rendite = Gewinn / Investition 3. Cashflow steigern Cashflow = Menge des verfügbaren ( flüssigen ) Geldes für Investitionen etc. Geldmittel werden dem Cashflow entzogen durch: Lagerbestände 29 Draft (4. Oktober 2012)

30 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]). 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). Draft (4. Oktober 2012) 30

31 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 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. 31 Draft (4. Oktober 2012)

32 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). Draft (4. Oktober 2012) 32

33 1.4.2 Vorgehensweise (vgl. DeMarco und Lister [2003]) 1. Risiken identifizieren 2. Risiken bewerten Risiko-Eintrittswahrscheinlichkeit abschätzen Risikofolgen abschätzen Ist das Risko managebar? 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 möglich: 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) 33 Draft (4. Oktober 2012)

34 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, z. B. Spiralmodell) Benutzer akzeptieren System nicht (Vorsorgemaßnahme: Benutzer frühzeitig mit ins Boot holen, 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 kritisches bzw. falsches Zeitmanagement Mitarbeiter werden krank oder haben Urlaub. (Vorsorgemaßnahme: Puffermanagement, Gegenmaßnahme: Hilfskraft einstellen, aber keinen Ersatz-Mitarbeiter) Draft (4. Oktober 2012) 34

35 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) Die Mitarbeiter erliegen dem Studentensyndrom (Goldratt [2002], Fachbezeichnung: Prokrastination). (Vorsorgemaßnahmen: kurze Vorgänge, keine Parallelarbeit, realistische Schätzungen (Vertrauen!)) Arbeitseifer Oh, jetzt wird s aber knapp! anfängliche Begeisterung Ist ja noch Zeit! Start Ende Zeit 2/3 Zeit 1/3 Arbeit 1/3 Zeit 2/3 Arbeit Abbildung 1.3: Studentensyndrom, vgl. Goldratt [2002] 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)) 35 Draft (4. Oktober 2012)

36 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) Risikomanagement (wie z.b. Einplanung von Pufferzeiten) kostet Geld. (Vorsorgemaßnahme: nur sinnvolle Risiken managen) Probleme (wie z.b. Ausfallzeiten) kosten Geld. (Vorsorgemaßnahme: Puffermanagement) Spezialisten kosten Geld. (Es kann allerdings billiger sein, einen Profi zu Euro/Tag zu holen, als einen Amateur zu 100 Euro/Tag.) Geeignetes Material kostet Geld. (Vorsorgemaßnahme: Bei der Planung nicht übersehen) Lizenzen und andere Rechte kosten Geld. (Vorsorgemaßnahme: Bei der Planung nicht übersehen) Der Kostenplan ist inhärent falsch ( politischer Zeitplan, agressive Zeitplanung ). Die Konkurrenz ist billiger (evtl. mit weniger Funktionalität oder schlechterer Qualität). Ressourcen 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) Draft (4. Oktober 2012) 36

37 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 (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.) Auftraggeber oder Lieferant liefert benötigte Ressourcen zu spät Sabotage 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 37 Draft (4. Oktober 2012)

38 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) 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. Draft (4. Oktober 2012) 38

39 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. 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. 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 39 Draft (4. Oktober 2012)

40 DeMarco und Lister [2003] geben folgende fünf Kernrisiken an: inhärent fehlerhafter Zeitplan Inflation der Anforderungen (ausufernde Anforderungen) Mitarbeiterfluktuation Spezifikationskollaps geringe Produktivität 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 mehr beeinflusst 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). 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 nach anstehender Bundestagswahlen einigte man sich auf elf Monate (Borchers [2004]). Dass diese Zeitspanne für ein derart komplexes Projekt viel zu kurz war, dürfte selbst jedem Laien klar sein. 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. Draft (4. Oktober 2012) 40

41 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? 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 41 Draft (4. Oktober 2012)

42 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 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ück- Draft (4. Oktober 2012) 42

43 zubekommen (= 10 Euro Gewinn) 2 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 gefordert nicht möglich ist. Sehen wir uns dieses Beipiel (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 Investiotions-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-Investtionsmö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 2 Richard Zultner wählt ein etwas komplexeres Beispiel: Nach zwei und nach 5 Tage erhalte ich jeweils 20 Euro Gewinn. 43 Draft (4. Oktober 2012)

44 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. Draft (4. Oktober 2012) 44

45 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, Netzwerk 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 45 Draft (4. Oktober 2012)

46 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 (und evtl. mit Planänderungen): 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 (4. Oktober 2012) 46

47 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 47 Draft (4. Oktober 2012)

48 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 (4. Oktober 2012) 48

49 (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.). 49 Draft (4. Oktober 2012)

50 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 (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 geschrieben werden. Diese muss genau spezifizieren, 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. Beispiel Aufsatzdienst Elektra Der Aufsatzdienst Elektra soll druckbare Aufsätze in einer Qualität besser als Fax per Internet ausliefern. Draft (4. Oktober 2012) 50

51 Die Bearbeitung einer Bestellung durch eine Fachkraft dauert am Rechner nicht mehr als 20 Sek/Seite. Und so weiter. Beispiel Internetpräsentation für die HS Augsburg läuft auf allen Browsern insbesondere kann jede Seite mit jedem HTML-4.01-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. 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 51 Draft (4. Oktober 2012)

52 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. 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 Draft (4. Oktober 2012) 52

53 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 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 53 Draft (4. Oktober 2012)

54 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 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]). Draft (4. Oktober 2012) 54

55 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). 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. 55 Draft (4. Oktober 2012)

56 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). Geschätzte Kosten der Designfehler für das Y2K-Problem (vgl. Berghel [1998]) Draft (4. Oktober 2012) 56

57 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. 57 Draft (4. Oktober 2012)

58 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 (4. Oktober 2012) 58

59 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])): 59 Draft (4. Oktober 2012)

60 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 (4. Oktober 2012) 60

61 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 den fehlerhaften Teil 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. 61 Draft (4. Oktober 2012)

62 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 (4. Oktober 2012) 62

63 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 63 Draft (4. Oktober 2012)

64 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 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 Die Nutzungs- und Aufarbeitungsphase Während der Nutzungsphase müssen Wartungs- und/oder Pflegearbeiten durchgeführt werden. Draft (4. Oktober 2012) 64

65 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? 3. Wie war und ist die Zufriedenheit von Benutzern, Auftraggeber, Management, Team, Projektleiter und externen Partnern? Achtung: Es geht nicht um Anschuldigungen und Rechtfertigungen. 65 Draft (4. Oktober 2012)

66 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. Das von mir im letzten Abschnitt vorgestellte Wasserfallmodell ist im Prinzip wie folgt aufgebaut (graphisch angelehnt an Royce): Draft (4. Oktober 2012) 66

67 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 67 Draft (4. Oktober 2012)

68 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) 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 Rational Unified Process (Jacobson et al. [1999], IBM [2011]) oder Scrum (Schwaber [2004]), folgten. Draft (4. Oktober 2012) 68

69 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. 69 Draft (4. Oktober 2012)

70 AG AN AG AN AG AG AN Projekt 1 Projekt 2 Anforderungen3 Projekt 4 Angebot 5 genehmigt definiert festgelegt ausgeschrieben abgegeben AG AN Änderungsplan festgelegt 14 AG AN Projekt 6 beauftragt Verifizierung Validierung AG AN Abnahme erfolgt 13 AG AN Projekt 15 abgeschlossen AN System 7 spezifiziert AN Lieferung 12 durchgeführt 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 (4. Oktober 2012) 70

71 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 71 Draft (4. Oktober 2012)

72 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 (4. Oktober 2012) 72

73 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. 73 Draft (4. Oktober 2012)

74 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 (4. Oktober 2012) 74

75 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. 75 Draft (4. Oktober 2012)

76 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 (4. Oktober 2012) 76

77 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 Anmerkung Projektkosten = n Kosten i i=1 Zu den Kosten können evtl. noch irgendwelche phasenunabhängige Fixkosten hinzukommen, die gegebenenfalls bei der Berechnung der Gesamtkosten oder bei den im Folgenden vorgestellten Schätzungen dazugerechnet werden müssen. 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 = n geschätzte Kosten i,min i=1 Projektkosten max = 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! 77 Draft (4. Oktober 2012)

78 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 = Kosten i + n geschätzte Kosten i,min i=1 i=j+1 j Projektkosten max = 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 (4. Oktober 2012) 78

79 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 [????]) Beispiel Phase 1: +/- 5 % Kostenabweichung 79 Draft (4. Oktober 2012)

80 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 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). Draft (4. Oktober 2012) 80

81 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) 81 Draft (4. Oktober 2012)

82 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 (4. Oktober 2012) 82

83 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]): 83 Draft (4. Oktober 2012)

84 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 (4. Oktober 2012) 84

85 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? 85 Draft (4. Oktober 2012)

86 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 (4. Oktober 2012) 86

87 Abbildung 3.2: Beta-Verteilung Für die obige Beta-Verteilung ergeben sich bessere Schätzwerte als bei der 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 % F B 1 (0, 5) = 23 (50 %-Quantil = Median) FB 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 umso mehr je unsymmetrischer die Verteilung ist. 87 Draft (4. Oktober 2012)

88 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 ) = µ(x B ) = = 31, (50 %-Quantil) 1, , = 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 (4. Oktober 2012) 88

89 ( 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 % 89 Draft (4. Oktober 2012)

90 Draft (4. Oktober 2012) 90 Abbildung 3.3: Standardabweichungen der Normalverteilung

91 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 91 Draft (4. Oktober 2012)

92 Abbildung 3.4: Dichtefunktionen der Schätzungen von fünf Phasen Abbildung 3.5: Simulation und Schätzung: Dauer von fünf Phasen Die zugehörigen Dichtefunktionen sind in Abbildung 3.4 zu sehen. In Abbildung 3.5 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 Gesamtsum- Draft (4. Oktober 2012) 92

93 me addiert. Der jeweilige Histogrammwert gibt an, wie oft der jeweilige x-wert (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 93 Draft (4. Oktober 2012)

94 Anmerkung 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 Projektergenissen erzielen möchte 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 Ergebnis Dichte Verteilung (Standardabweichung c Normalverteilung ist fix) Draft (4. Oktober 2012) 94

95 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 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 Draft (4. Oktober 2012)

96 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 PERT Für PERT wird eine 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. Draft (4. Oktober 2012) 96

97 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 jeweils absolute Minimum und das absolute Maximum als Schätzwerte verwenden. 97 Draft (4. Oktober 2012)

98 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 Draft (4. Oktober 2012) 98

99 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)!! 99 Draft (4. Oktober 2012)

100 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: Draft (4. Oktober 2012) 100

101 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 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, Draft (4. Oktober 2012)

102 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) Draft (4. Oktober 2012) 102

103 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 103 Draft (4. Oktober 2012)

104 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): Draft (4. Oktober 2012) 104

105 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 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: $. Damit liegt der durch die Methode π Daumen ermittelte Schätzwert gut im Rennen. 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 105 Draft (4. Oktober 2012)

106 Schätzparameter der jeweiligen Methode durch mathematisch-statistische Analyse historischer Projektdaten an die Verhältnisse des jeweiligen Entwicklungsbereiches angepasst werden. 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]) Draft (4. Oktober 2012) 106

107 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. 107 Draft (4. Oktober 2012)

108 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): 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): 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. Draft (4. Oktober 2012) 108

109 Beispiel Aufgabe: 200 LOC-Programm erstellen Produktivität: 25 LOC/(PT MA) Dauer: 5 PT (MA = Mitarbeiter) Bedarf MA = Aufwand/Dauer = (200 LOC/25( LOC/(PT MA)))/5 PT = 8 PT MA/5 PT = 1, 6 MA 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. 109 Draft (4. Oktober 2012)

110 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. Draft (4. Oktober 2012) 110

111 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). 111 Draft (4. Oktober 2012)

112 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. Draft (4. Oktober 2012) 112

113 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. 113 Draft (4. Oktober 2012)

114 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 (4. Oktober 2012) 114

115 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 so genannten Projektstrukturpläne (PSP, engl.: work breakdown structures, WBS). Komponenten-Projektstrukturplan (KPSP) Internet Auftritt Metzgerei Meier Startseite Katalog Bestellung Fleisch Wurst Käse Sonstiges Draft (4. Oktober 2012)

116 Aktivitäten-Projektstrukturplan (APSP) Tools und Techniken auswählen Internet Auftritt Metzgerei Meier erstellen Seitenstruktur festlegen Content beschaffen/erstellen Layout festlegen Text Fotos Videos Grafiken Web Seiten erstellen Startseite erstellen Katalog programmieren Bestell komponente programmieren Abbildung 4.1: APSP in MS Project 2010 Prerequisite-Tree (Klein et al. [2005]) fehlt noch Draft (4. Oktober 2012) 116

117 4.3 Feinplanung, insb. Ressourcen-Management Im Aktivitäten-Prozessstrukturplan enthalten die Blätter die so genannten Vorgänge: Ein Vorgang ist eine in sich abgeschlossene genau spezifizierte Aktivität, die innerhalb einer angemessenen Zeitdauer durchgeführt werden kann. 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, Pufferzeitenetc. Es gibt mehrere Arten von Netzplänen: Vorgangspfeil-Netzpläne (VPN; Vorgänge werden als Beziehungen modelliert) Vorgang 117 Draft (4. Oktober 2012)

118 Ereignisknoten-Netzpläne (EKN; Beziehungen zwischen Ereignissen = Ergebnissen von Vorgängen werden modelliert, z. B. Vorgang Startseite erstellen ˆ= Ereignis Startseite wurde erstellt ). Ereignis Ereignis 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. Draft (4. Oktober 2012) 118

119 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 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. 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: 119 Draft (4. Oktober 2012)

120 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. 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 00: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 nichts für das Projekt machen, sondern auch noch ein Privatleben haben. (Die genauen Anfangs- und Endzeiten variieren natürlich von Unternehmen zu Unternehmen.) Anmerkung 2 Obwohl Netzdiagramme den zeitlichen Aspekt stark betonen, eignen sie sich auch zur Kosten- und Ressourcenschätzung und -planung. Draft (4. Oktober 2012) 120

121 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 (4. Oktober 2012)

122 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 (4. Oktober 2012) 122

123 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 ;> 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 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) 123 Draft (4. Oktober 2012)

124 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 (4. Oktober 2012) 124

125 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 125 Draft (4. Oktober 2012)

126 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 (4. Oktober 2012) 126

127 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 (4. Oktober 2012)

128 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 (4. Oktober 2012) 128

129 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. 129 Draft (4. Oktober 2012)

130 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 (4. Oktober 2012) 130

131 !!!!! $ # & % & ' * ) - G6 D FE D C6.0. /. $ #!" $!" $ ) ( ' % $, + * % $, $ +, - )! ) - - * 1 #? >= = ;5< : > <B 5 > Abbildung 4.5: Gantt-Diagramm für den Netzplan aus Abschnitt (mit MS Project 2010 erstellt) 131 Draft (4. Oktober 2012)

132 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 (4. Oktober 2012) 132

133 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 133 Draft (4. Oktober 2012)

134 Draft (4. Oktober 2012) 134 Abbildung 4.8: Beispiel für Netzplan- und Balkendiagramm mit komplexeren Abhängigkeiten (mit MS Project 2010 erstellt)

135 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. 135 Draft (4. Oktober 2012)

136 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 (4. Oktober 2012) 136

137 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). 137 Draft (4. Oktober 2012)

138 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 (4. Oktober 2012) 138

139 V <Nummer> Vorgangsname D MA D MA = = Dauer 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): 139 Draft (4. Oktober 2012)

140 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 (4. Oktober 2012) 140

141 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. 141 Draft (4. Oktober 2012)

142 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 (4. Oktober 2012) 142

143 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 143 Draft (4. Oktober 2012)

144 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 (4. Oktober 2012) 144

145 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. 145 Draft (4. Oktober 2012)

146 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 (4. Oktober 2012) 146

147 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. 1 Insofern ist die Wikipedia-Schätzung ziemlich gewagt. 1 Für die Normalverteilung ist das 50 %-Quartil gleich dem Erwartungswert. 147 Draft (4. Oktober 2012)

148 Draft (4. Oktober 2012) 148 Abbildung 4.21: Gantt-Diagramme für das PERT-Beispiel; oben: µi; unten: µi + σi

149 Um ein deutlich besseres Ergebnis zu erhalten, muss man zu jedem Vorgang einen Sicherheitspuffer zuschlagen. Wenn man beispielsweise zu jedem Vorgang einen Puffer von einem σ i hinzuaddiert (σ i = (b i a i )/6, sofern man wieder eine PERT-Schätzung zugrunde legt), erhält man deutlich längere Laufzeiten. Die Gesamtdauer beträgt nun: 4, , , , 00 = 22, 01. Sie ist also um 2, 5 Tage angewachsen. Diese Dauer ermittelt man, indem man alle µ i + σ i aufaddiert (rechte Spalte Abbildung 4.20). In Abbildung 4.21 wird unten das zugehörige Gantt-Diagramm gezeigt. Laut zentralem Grenzwertsatz ist µ weiterhin gleich 19, 51 und σ = 0, , , , 83 2 = 1, 28 bzw. 2σ = 2, 56. Das heißt, die Gesamtdauer von 22 Tagen entspricht ungefähr dem Wert µ + 2σ. Dieser Termin kann nach der 84/98/99,9-Regel mit einer Wahrscheinlichkeit von ca. 98 % eingehalten werden. Fazit: Wenn man die PERT-Methode oder eine verwandte Methode verwendet, muss man für jeden einzelnen Vorgang eine gewissen Sicherheitspuffer einplanen, um eine gute Schätzung für die Gesamtdauer zu erhalten Integrierter Puffer In den klassischen Gantt-Diagrammen ist wie zuvor gezeigt wurde normalerweise für jeden Vorgang ein Puffer implizit in der geschätzten Dauer enthalten. 50% Quartil Puffer Gerade wenn ein Projektleiter Einpunkt-Schätzungen vornimmt, bei denen er sein Team nach der Dauer von Vorgängen fragt, erhält er niemals 50/50-Schätzwerte. Je wichtiger ein Vorgang ist, desto mehr Puffer enthält die geschätzte Dauer, damit sich die Mitarbeiter ziemlich sicher sein können, dass sie den Termin auch halten. Das heißt, man erhält 80 %-/90 %-/95 %- oder gar 99 %-Schätzungen. Beispielsweise fahre ich an Prüfungstagen spätestens 50 Minuten vor Prüfungsbeginn zur HSA, um rechtzeitig anzukommen, obwohl mir mit 99-prozentiger Sicherheit 35 Minuten ausreichen würden. Bislang habe ich nur einmal eine Stunde zur HSA gebraucht, weil ich in einem Stau stand: Und das war natürlich ein Prüfungstag. Das Vorgehen, für jeden Vorgang einen großen Puffer in die Schätzung zu integrieren, hat zwei gravierende Nachteile: Selbst wenn man jedem Vorgang nur einen geringen Puffer hinzufügt (z. B. σ i ), ist der Gesamtpuffer fast immer deutlich größer als dies nach dem zentralen Grenzwertsatz notwendig wäre. Im obigen Beispiel haben sich bereits die vier Einzelpuffer von jeweils σ i schon zu einem Projektgesamtpuffer 149 Draft (4. Oktober 2012)

150 von 2σ aufaddiert. Bei weiteren Vorgängen und insbesondere bei deutlich größeren Vorgangspuffern sprengt die Gesamtsumme aller Einzelpuffer sehr schnell jede sinnvolle Grenze: 2σ, 3σ, 4σ... Gemäß dem Gesetz von Parkinson [1955] hat viel Puffer einen gravierenden Nachteil: Der Arbeitsaufwand wächst immer so weit, wie die Zeit, die zur Verfügung steht. Die Gründe dafür sind folgende: Das Studentensyndrom (vgl. Abbildung 1.3) Parallelarbeit: Wenn genügend Zeit vorhanden ist, können auch noch andere Aufgaben parallel bearbeitet werden. Die Angst der Mitarbeiter, eine Arbeit zu früh erfolgreich zu beenden, da dies i. Allg. zur Folge hat, dass beim nächsten Projekt die abgegebenen Schätzungen vom Projektleiter reduziert werden (vgl. Dezemberfieber). Diese Angst geht häufig sogar soweit, dass der implizite Puffer auch dann nicht genutzt wird, wenn der Vorgängervorgang verspätet beendet wurde. Fazit: Egal wie lange die Projektdauer geplant wurde und wie viel Puffer für jeden einzelnen Vorgang eingeplant wurde, das Projekt wird nicht vorzeitig fertig, sondern höchstens noch später. Das heißt, auch wenn für das Wikipedia-Beispiels-Projekt (Abbildung 4.21) eine Fifty-fifty-Chance besteht, dass es vor dem fertiggestellt werden könnte, wird es nicht vor dem fertig gestellt. Und wenn man, wie vorgeschlagen, in jeden Vorgang zusätzlichen Puffer einfügt, dann wird es nicht vor dem fertig. PUNKT! Laut DeMarco [2001] trifft das Parkinsonsche Gesetz [...] auf Ihre Mitarbeiter mit Sicherheit nicht zu, da die Lebenszeit der Angestellten einfach zu kurz ist, um bei der Arbeit herumzutrödeln. Er betont dies, weil er ein Gegner von Druck ist. Projektleiter sollen sich nicht verleitet fühlen, das Parkinsonsche Gesetz auszuhebeln, indem sie Scheintermine das heißt, Termine, die nicht gehalten werden können vorgeben. Ein derartige Termin wäre im Wikipedia-Beispiel der (µ 2σ), ein theoretisch machbarer Termin, der mit ca. 0 % Wahrscheinlichkeit auch gehalten werden kann. Laut Goldratt sind die Projektleiter selbst Schuld, wenn das Parkinsonsche Gesetz zuschlägt: Erstens ist Resource Leveling ein Muss, d. h. Parallelarbeit sollte wann immer möglich vermieden werden. Und zweitens sind fixe Termine von Übel. Termine sind Schätzungen und damit keine unverrückbaren Größen. Die Mitarbeiter müssen sicher sein, dass jede Schätzung auch als solche angesehen wird. Wer früher fertig wird, hat nicht schlechter geschätzt, als derjenige der später fertig wird. Bei einer guten Schätzung das ist eine 50 %-Schätzung ohne zusätzlichen Puffer ist beides gleich wahrscheinlich. Absolut tödlich für das Vertrauen der Mitarbeiter ist es, wenn ein Projektleiter für Vorgänge, die vorzeitig abgeschlossen wurde, in Folgeprojekten automatisch kürzere Laufzeiten ansetzt! Draft (4. Oktober 2012) 150

151 Wie kann man es erreichen, dass das Projekt tatsächlich irgendwann zwischen den und dem fertig gestellt wird? Laut Goldratt [2002] erreicht man dies, indem man die Vorgangspuffer explizit verwaltet. Genauer: Man nimmt für die einzelnen Vorgänge Fifty-fifty-Schätzungen vor und fügt am an Ende des kritischen Pfades einen Gesamtpuffer hinzu, der von allen Vorgängen genutzt werden kann. Im folgenden Diagramm sieht man in Abbildung a drei Vorgänge, die einen impliziten Puffer enthalten. In Abbildung b wurde dieser Puffer separiert, summiert und hinter den verkürzten Vorgängen als eigenständiger Puffervorgang eingefügt. Dadurch hat sich die Gesamtdauer der drei Vorgänge nicht verändert. Wie wir aber bereits wissen (Zentraler Grenzwertsatz der Statistik: Abschnitt 3.3.2), kann man den Puffer von einer Summe von Vorgängen kürzer wählen. Dies wird in Abbildung c visualisiert. a) µ 1 2σ 1 µ 2 2σ 2 µ 3 2σ 3 b) c) µ 1 µ 2 µ 3 2σ 1 2σ 2 2σ 3 µ 1 µ 2 µ 3 2 σ σ2 2 + σ2 3 Ein weiteres Beispiel finden Sie in Abbildung Hier wurde der Gesamtpuffer, der für das Gantt-diagramm in Abbildung 4.21 gemäß dem zetralen Grenswertsatz berechnet wurde, als expliziter Vorgang (Nr. 9) ins Diagramm eingefügt. Den Mitarbeitern werden keine fixen Termine mehr genannt. Stattdessen wird jeder Vorgang begonnen, sobald der Vorgängervorgang abgeschlossen wurde. Den Mitarbeitern wird mitgeteilt, dass z. B. ca. vier Tage für den gerade gestarteten Vorgang eingeplant wurden. Allerdings wird kein Termin gesetzt. Das heißt, sagen Sie nicht: In vier Tagen muss das Ergebnis da sein (nicht früher und nicht später). Sondern die Mitarbeiter werden angehalten, so lange wie nötig am Vorgang zu arbeiten, um alle Vorgaben hinsichtlich Funktionalität und Qualität zu erfüllen. Sobald sie fertig sind, startet der nächste Vorgang und der Projektleiter passt den Gesamtpuffer an: Wurde der Vorgang zu spät beendet, wird der Gesamtpuffer entsprechend gekürzt, anderenfalls wird er entsprechend verlängert. Ganz wichtig: Mitarbeiter, die an kritischen Vorgängen arbeiten, werden von allen anderen Tätigkeiten entlastet. Bei einem gut geschätzten Projekt und guter Menschenführung (d. h., die Mitarbeiter vertrauen darauf, dass weder Terminverzögerungen noch vorzeitige Vorgangsfertigstellung negative Folgen für sie haben) sollte die Größe des Gesamtpuffers pulsieren (vgl. Abschnitt 4.8.4). 151 Draft (4. Oktober 2012)

152 Draft (4. Oktober 2012) 152 Abbildung 4.22: CCPM-Diagramme für das PERT-Beispiel; oben: Gesamtpuffer; unten: Gesamtpuffer und Zubringerpuffer

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

Vorlesung. Projektmanagement. Sommersemester 2015. Wolfgang Kowarschick. Hochschule Augsburg Vorlesung Projektmanagement Sommersemester 2015 Wolfgang Kowarschick Hochschule Augsburg Draft (13. März 2015) 2 Inhalt 1 Definitionen 7 1.1 Projekte............................... 8 1.1.1 Definition (von

Mehr

Vorlesung. Projektmanagement. Sommersemester 2006. Wolfgang Kowarschick. Fachhochschule Augsburg

Vorlesung. Projektmanagement. Sommersemester 2006. Wolfgang Kowarschick. Fachhochschule Augsburg Vorlesung Projektmanagement Sommersemester 2006 Wolfgang Kowarschick Fachhochschule Augsburg Draft (29. Juni 2006) 2 Inhalt 1 Definitionen 5 1.1 Projekte............................... 6 1.1.1 Definition

Mehr

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Raphael Leiteritz, raphael@leiteritz.com, 22. April 2002 1 Inhalt 1 Was

Mehr

Grundlagen der Projektarbeit

Grundlagen der Projektarbeit Lerninhalte ❶ ❷ ❸ ❹ ❺ ❻ Ziele und Aufgaben des s Beteiligte des s Aufstellung der IS-Architektur (Überblick) Projektplanung Projektentwicklung Projektorganisation Lerninhalte L1 i Ziele und Aufgaben des

Mehr

Einführung in das Projektmanagement 1

Einführung in das Projektmanagement 1 Einführung in das Projektmanagement 1 Gliederung 1. Einführung und Grundlagen 1.1 Beispiele 1.2 Grundbegriffe und Definitionen 1.3 Erfolgsfaktoren des Projektmanagements 2. Projektorganisation 3. Projektphasen

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements 1 1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements Herr Maier wurde von einem Tag auf den anderen Projektleiter: Übernehmen Sie das Projekt Orion, sagte sein Chef. Ohne zu wissen,

Mehr

Semesterprojekt SS 2011

Semesterprojekt SS 2011 Semesterprojekt SS 2011 Projektmanagement Teil 1 Dr. rer. nat. Andreas Tewes Als Vorlage zu dieser Vorlesung diente: projektmanagement für newcomer RKW Sachsen GmbH Kompetenzzentrum Managementsysteme Selbst

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Thema: Risikomanagement

Thema: Risikomanagement 1.1. Risikomanagement Eine der elementarsten Anforderungen an die Projektplanung ist, durch zielgerichtete Planung mögliche Risiken, die den Projekterfolg in Frage stellen, zu identifizieren und präventiv

Mehr

Einführung in das Projektmanagement

Einführung in das Projektmanagement Einführung in das Projektmanagement Komplexe und neuartige Aufgaben werden in Form von Projekten abgewickelt. Zur erfolgreichen Projektsteuerung ist ein Projektmanagement unverzichtbar. Projektmanagement

Mehr

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

Mehr

tzung - Microsoft Project

tzung - Microsoft Project Projektmanagement mittels Softwareunterstützung tzung - Microsoft Project Umwelt- und Unternehmens- Beratung Dr. Anke Schwan Berlin, 1. Juli 2009 Jana-Maria Seiferth Gliederung 1] Grundlagen des Projektmanagements

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

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

Management von IT- Projekten. Einführung in Projektmanagement und ausgewählte Schwerpunktthemen

Management von IT- Projekten. Einführung in Projektmanagement und ausgewählte Schwerpunktthemen Management von IT- Projekten Einführung in Projektmanagement und ausgewählte Schwerpunktthemen Magisches Dreieck Kosten Qualität Zeit => welche Auswirkungen auf Planung? Beispiel 1 2 Key-Account-Kunden

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

GPM/IPMA Zertifizierung ICB 3.0 Fragen zur Prüfungsvorbereitung (PM3, Auflage 1) Kapitel 3.02

GPM/IPMA Zertifizierung ICB 3.0 Fragen zur Prüfungsvorbereitung (PM3, Auflage 1) Kapitel 3.02 Was ist ein Programm? Ein Programm ist eine Menge von Projekten, die miteinander verknüpft sind und ein gemeinsames übergreifendes Ziel verfolgen. Ein Programm ist zeitlich befristet. Es endet spätestens

Mehr

Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten

Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten Rainer Ahlers Verkaufsleiter Sport-Thieme GmbH Grasleben, 01.06.2009 Projekte Ein Projekt ist ein einmaliger Prozess, der

Mehr

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen

Alles richtig machen Prozessorientierung hilft Ziele zu erreichen und schafft Vertrauen Information zum Thema Prozess Der Erfolg eines Unternehmens die Durchsetzung seiner Produkte und Dienstleistungen auf dem Markt, effiziente interne Abläufe, eine gesunde wirtschaftliche Situation hängt

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

Wichtig, aber nicht immer einfach Durchführung einer Kosten- Nutzenanalyse

Wichtig, aber nicht immer einfach Durchführung einer Kosten- Nutzenanalyse Einsatz von Projektmanagement-Software Fragen - ist PM-Software in jedem Fall sinnvoll, lohnt sich die Investition? - Spezialsoftware oder eigene Lösung? - wie hoch ist die emotionale Bindung von Mitarbeitern

Mehr

Projekte präsentieren

Projekte präsentieren Projekte präsentieren von Hedwig Kellner 1. Auflage Hanser München 2003 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 22093 5 Zu Inhaltsverzeichnis schnell und portofrei erhältlich bei beck-shop.de

Mehr

Die Critical Chain Methode zur Ressourcen- und Zeitplanung

Die Critical Chain Methode zur Ressourcen- und Zeitplanung Projektmanagement SS 2003 Die Critical Chain Methode zur Ressourcenund Zeitplanung Michael Mruczek 11027784 11028473 2 1 3 Critical Chain (1997), Kritische Kette (2002), E.Goldratt Anwendung der Theory

Mehr

Wie man mit Change Management IT-Projektkosten senken kann

Wie man mit Change Management IT-Projektkosten senken kann Wie man mit Change Management IT-Projektkosten senken kann ein Artikel von Ulrike Arnold Kaum ein Projekt wird in der vorgegebenen Zeit und mit dem geplanten Budget fertiggestellt. Und das, obwohl die

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

Ablauf der Vorstudie zu einem Projekt

Ablauf der Vorstudie zu einem Projekt Ablauf der Vorstudie zu einem Projekt DHPol Seminar 2011 Dipl.-Ing. Thomas Schlüter, MBA Projektdefinition Vorstudie Internet: www.korff-schlueter.de, E-Mail: info@korff-schlueter.de 1 von 22 Projektplanung

Mehr

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe Praxis-Handbuch Projektmanagement Kapitel 01 - Einführung und Grundlagen Unternehmen im Wandel der Zeit Wandel der Organisation 01-03 Gründe für Projektmanagement 01-04 Projektdefinition Merkmale eines

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

(Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung

(Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung (Management großer Softwareprojekte) Sommersemester 2007 Kap. 1 - Einführung Prof. Dr. rer. nat. Uwe Aßmann Lehrstuhl Softwaretechnologie Fakultät Informatik TU Dresden Version 07-0.6, April 11, 2007 [1]

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

Mehr

Whitepaper. Warum Usability-Tests wichtig sind

Whitepaper. Warum Usability-Tests wichtig sind Whitepaper 01 Die Wichtigkeit von Usability-Tests Haben Sie sich schon einmal gefragt, ob Ihre Webseite ihr Potential voll ausschöpft? Ob es irgendwelche Stellschrauben gibt, an denen Sie drehen können

Mehr

Termine. 1 Terminarten. 2 Statische Termine

Termine. 1 Terminarten. 2 Statische Termine 1 Terminarten Termine Starttermin Beginn von ganzen Projekten oder Teilgewerken. Es ist wichtig einen Anfang zu definieren, damit auch das Projektende bestimmbar ist. Bei Projekten ist es wichtig den Start

Mehr

Zuckerbrot oder Peitsche

Zuckerbrot oder Peitsche Zuckerbrot oder Peitsche Rendite Wie man ein Projekt aus der Klemme holt 1. Juli 2008 Peter Stevens, Sierra-Charlie Consulting www.scrum-breakfast.com Idee 1 Projektsanierung der König ist tot... 2 Projektsanierung

Mehr

Verhalten schlägt Methode. Teamkultur und Methodologie von High-Speed-Projekten PM-Forum 22.10.2008

Verhalten schlägt Methode. Teamkultur und Methodologie von High-Speed-Projekten PM-Forum 22.10.2008 Verhalten schlägt Methode Teamkultur und Methodologie von High-Speed-Projekten PM-Forum 22.10.2008 1&1 und High-Speed... 1992 entwickelt 1&1 für T-Online eine der erfolgreichsten Internet- 1988 Kampagnen

Mehr

Keywords: Projektmanagement, Erfahrungen Projektmanagement

Keywords: Projektmanagement, Erfahrungen Projektmanagement Sage mir, wie ein Projekt beginnt und ich sage Dir, wie es endet". "Projektmanagement - heute" Projektmanagement stellt eine klare Herausforderung an die Managementqualitäten der Unternehmen dar. Projektmanagement

Mehr

Leitfaden Projektmanagement Seminarreihe Allgemeinmedizin

Leitfaden Projektmanagement Seminarreihe Allgemeinmedizin Krankenhaus Barmherzige Brüder Regensburg BLINDTEXT THEMA Leitfaden Projektmanagement Seminarreihe Allgemeinmedizin Dagmar Alzinger, Referentin der Geschäftsführung 1 Inhalt 1 2 3 4 5 6 Was ist ein Projekt?

Mehr

Funktionen im Überblick Projektmanagement proalpha Projektmanagement Das proalpha Projektmanagement-Modul ist ein Werkzeug, mit dem alle im Projektbereich anfallenden Aufgaben gelöst werden können. Die

Mehr

Qualität. Referenzbericht Privatmolkerei Bauer. statt Durchschnitt. Webdevelopment Responsive Design Webdesign

Qualität. Referenzbericht Privatmolkerei Bauer. statt Durchschnitt. Webdevelopment Responsive Design Webdesign Qualität statt Durchschnitt Referenzbericht Privatmolkerei Bauer Webdevelopment Responsive Design Webdesign Redakteur: Herr Fischer, Sie kamen mit dem Wunsch einer neuen Internetpräsenz zu uns. An welchen

Mehr

Projektmanagement: Software braucht Anwenderakzeptanz

Projektmanagement: Software braucht Anwenderakzeptanz Projektmanagement: Software braucht Anwenderakzeptanz Autor: Dr. Michael Streng, Gründer und Geschäftsführer der parameta Projektberatung GmbH & Co. KG In allen Unternehmen, die Projekte durchführen, spielt

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

Dokumentation Projektmanagement:

Dokumentation Projektmanagement: Dokumentation Projektmanagement: Am ersten Tag haben wir am Morgen zuerst eine PDF Präsentation angeschaut, um was genau es eigentlich geht. Ziele des Projektmanagement Workshops: -Kennen lernen... -der

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Einsatz von Projektmanagement-Software

Einsatz von Projektmanagement-Software Einsatz von Projektmanagement-Software Fragen - ist PM-Software in jedem Fall sinnvoll, lohnt sich die Investition? - Spezialsoftware oder eigene Lösung? - wie hoch ist die emotionale Bindung von Mitarbeitern

Mehr

Aktuelle Herausforderungen im öffentlichen Beschaffungswesen für ICT-Projekte

Aktuelle Herausforderungen im öffentlichen Beschaffungswesen für ICT-Projekte Aktuelle Herausforderungen im öffentlichen Beschaffungswesen für ICT-Projekte Frühjahrstagung der Schweizerischen Informatikkonferenz, 23. Mai 2013 Oliver Vaterlaus, Partner www.awk.ch WTO-Beschaffungen

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Prüfung eines Migrationsprojekts

Prüfung eines Migrationsprojekts Prüfung eines Migrationsprojekts Peter Ursprung Ursprung Consulting Postfach 8042 Zürich 044 361 12 21 peter.ursprung@bluewin.ch 1 Inhalt Interdisziplinarität von in IT-Projekten Welche Kompetenzen sind

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

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts 6. COMBATing Breast Cancer Chances for Cure Aller Anfang ist schwer Starthilfen in der Wissenschaft Projektplanung: Do s and Don ts Dieter Niederacher COMBATing Breast Cancer 2013 Präsymposium TraFo Kommission

Mehr

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen E-Mail : Berkan.Kutlutuerk@hs-furtwangen.de Seite

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Um einen Prozess bewerten zu können, sind zwei Arten von Kennzahlen erforderlich:

Um einen Prozess bewerten zu können, sind zwei Arten von Kennzahlen erforderlich: Prozessmanagement in der Instandhaltung1) 6. Kennzahlen festlegen Ob ein Prozess leistungsfähig ist, lässt sich daran ablesen, ob die Kosten eines Prozesses in einem angemessenen Verhältnis zur erbrachten

Mehr

Riskikomanagement. No risk, no fun? No risk, no project! PROJEKTMANAGEMENT I - 18. Risikomanagement

Riskikomanagement. No risk, no fun? No risk, no project! PROJEKTMANAGEMENT I - 18. Risikomanagement Riskikomanagement No risk, no fun? No risk, no project! Risikomanagement 1 Ein paar Fragen zum Start Was sind Risiken? Wie gehen Sie mit Risiken um? Welche Bedeutung hat das Risiko in einem Projekt? Risikomanagement

Mehr

Projektmanagement. H.Wolf

Projektmanagement. H.Wolf Projektmanagement H.Wolf Projekt Projektdefinition Nach DIN 69901 ist ein Projekt ein befristetes Vorhaben, das im Wesentlichen durch die Einmaligkeit seiner Bedingungen in ihrer Gesamtheit gekennzeichnet

Mehr

Projekte planen und überwachen mit OpenProject Anwenderhandbuch

Projekte planen und überwachen mit OpenProject Anwenderhandbuch Projekte planen und überwachen mit OpenProject Anwenderhandbuch Force4project GmbH force4project.ch@ziknet.ch Schulstrasse 1 +41 627390090 CH-5037 Muhen www.force4project.ch Anwenderhandbuch OpenProject

Mehr

Software-Projektmanagement

Software-Projektmanagement Software-Projektmanagement Björn Lohrmann Software Engineering Projekt Technische Universität Berlin WS 2007/2008 February 1, 2008 Software-Projektmanagement 1/29 Gliederung Gliederung des Vortrags: Begriffe

Mehr

Begriffe, Ziele, Anforderungen - Das Ohr zum Kunden -

Begriffe, Ziele, Anforderungen - Das Ohr zum Kunden - Begriffe, Ziele, Anforderungen - Das Ohr zum Kunden - - 1 - Gliederung 1. Seite 1. Was versteht man unter einem Help Desk? 2 2. Vorteile einer Benutzerservice / Help Desk Funktion 7 3. Zielsetzung bei

Mehr

5.3.2 Projektstrukturplan

5.3.2 Projektstrukturplan 5.3.2 Der ist eine der wichtigsten Planungs- und Controllingmethoden und das zentrale Kommunikationsinstrument im Projekt. Er bildet die Basis für sämtliche weitere Projektmanagement- Pläne sowie für die

Mehr

Modul: Managementtechniken II Veranstaltung: Projektmanagement Themenbereich: Überblick und Einführung

Modul: Managementtechniken II Veranstaltung: Projektmanagement Themenbereich: Überblick und Einführung Modul: Managementtechniken II Veranstaltung: Projektmanagement Themenbereich: Überblick und Einführung Fachhochschule Düsseldorf, Fachbereich Wirtschaft Dozent: Prof. Dr. Andreas Diedrich Veranstaltungsübersicht

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

CONSIDEO PROCESS MODELER

CONSIDEO PROCESS MODELER CONSIDEO PROCESS MODELER CONSIDEO PROCESS MODELER genauso einfach wie der CONSIDEO MODELER Was-Wäre-Wenn-Betrachtungen von parallelen Prozessen/Projekten Berechnung der Kritischen Kette Aufzeigen von Constraints

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

Die Provokationstechnik

Die Provokationstechnik Die Provokationstechnik Ideenfindung durch Infragestellen von Wissen und Annahmen Prof. Dr.-Ing. Graham Horton Einführung: Provokationen Die Grundgedanken der Provokationstechnik: Wissen und Erfahrung

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 3 Teil 2 (05.05.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 3 Teil 2 (05.05.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 3 Teil 2 (05.05.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Operations Strategie und Management. - Projektmanagement - Helmut M. Dietl 1

Operations Strategie und Management. - Projektmanagement - Helmut M. Dietl 1 Operations Strategie und Management - Projektmanagement - Helmut M. Dietl 1 Lernziele Nach dieser Veranstaltung sollen Sie wissen, was man unter einem Projekt versteht was Projektmanagement bedeutet wie

Mehr

Spielregeln (die Vollversion mit den Optionen)

Spielregeln (die Vollversion mit den Optionen) Spielregeln (die Vollversion mit den Optionen) Ziel des Spiels Plyt Herausforderungen Spieler richtig multiplizieren (oder hinzufügen) eine Anzahl von Würfeln zusammen und Rennen entlang der Strecke der

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Zielvereinbarung. Team JAMT.

Zielvereinbarung. Team JAMT. Ziele des Projektes. Wer benötigt das Ergebnis des Softwareprojektes? Gruppenprozessleiter, welche keine Expertise auf dem Gebiet der Gruppenprozesserstellung haben Teams, die computergestützte Gruppenarbeit

Mehr

Unsere Leidenschaft. Service, Bestände, Kosten mit uns haben Sie das magische Dreieck des Supply-Chain-Managements im Griff. Supply Chains never sleep

Unsere Leidenschaft. Service, Bestände, Kosten mit uns haben Sie das magische Dreieck des Supply-Chain-Managements im Griff. Supply Chains never sleep Unsere Leidenschaft Service, Bestände, Kosten mit uns haben Sie das magische Dreieck des Supply-Chain-Managements im Griff Supply Chains never sleep - 1 - ILOCS bietet Software, Trainings und Lösungen

Mehr

PROJECTS that FLOW. PROJECTS that FLOW

PROJECTS that FLOW. PROJECTS that FLOW PROJECTS that FLOW 1 2 PROJECTS that FLOW Uwe Techt PROJECTS that FLOW Mehr Projekte in kürzerer Zeit Die Geheimnisse erfolgreicher Projektunternehmen 3 Ein TOC Institute Buch Das Werk ist in allen seinen

Mehr

Mit Mindjet Software und Vorlagen IT- Projekte planen

Mit Mindjet Software und Vorlagen IT- Projekte planen Erste Schritte Anleitung Mit Mindjet Software und Vorlagen IT- Projekte planen 68% aller IT-Projekte sind nicht erfolgreich. Viele dieser Fehlschläge sind auf schlechte Anforderungsanalysen zurückzuführen,

Mehr

Prozess- und Projektmanagement

Prozess- und Projektmanagement Prozess- und Projektmanagement Prozess vs. Projekt 2011 Manfred Bauer Dipl.-Ing. Dipl.-Projektmanager (FH) Ist dies ein Projekt? Bild rein zur Frage Minimierung der Unfallzahlen 2 Bild rein zur Frage Ist

Mehr

Gute Aussichten für die Zukunft.

Gute Aussichten für die Zukunft. Siemens Business Services Gute Aussichten für die Zukunft. Erstellung des Uni-Masters Zu Beginn des Projektes werden sich die Projektteams auf die Erstellung des Uni-Masters konzentrieren. Dieser Master

Mehr

Kundenorientierung im Projekt. Kundenorientierung im Projekt

Kundenorientierung im Projekt. Kundenorientierung im Projekt Kundenorientierung im Projekt Daniela Mayrshofer (Der nachfolgende Artikel ist ein Auszug aus Mayrshofer, D., Kröger, H. A. : Prozeßkompetenz in der Projektarbeit. Windmühle Verlag, Hamburg, 1999, S. 20-25)

Mehr

Kennzahlen: Nutzen & Risiken

Kennzahlen: Nutzen & Risiken Kennzahlen: Nutzen & Risiken Was sind Key Performance Indicators? Führungskräfte und ihre Mitarbeiter verlieren zwischen allen Zielen und Vorgaben leicht den Überblick über das, was wirklich wichtig ist.

Mehr

Volkswagen Coaching Zertifizierter ProjektManager

Volkswagen Coaching Zertifizierter ProjektManager Volkswagen Coaching Zertifizierter ProjektManager Die heutigen Herausforderungen an das Projektmanagement In unserer heutigen dynamischen Umwelt sehen wir uns vielfältigen Herausforderungen gegenüber.

Mehr

Verbreitete Praxishürden einer IT-System-Umstellung

Verbreitete Praxishürden einer IT-System-Umstellung Verbreitete Praxishürden einer IT-System-Umstellung Die großen DOs Die Einhaltung der Theorie des Projektmanagements ist sowieso Pflicht! - direkt bei den ersten Überlegungen zu einem IT-Projekt (vor dem

Mehr

KUBUS Ihr kompetenter Ansprechpartner, wenn es um Kommunalberatung geht

KUBUS Ihr kompetenter Ansprechpartner, wenn es um Kommunalberatung geht KUBUS Ihr kompetenter Ansprechpartner, wenn es um Kommunalberatung geht Projekt- und Prozesskompetenz 6. Führungskräfteforum 2014 17.09.2014 in Kiel, 18.09.2014 in Schwerin Rahmenbedingungen in unserer

Mehr

Erkennen Sie die Rollen der Personen auf dem Team Management Rad anhand der kurzen Beschreibungen?

Erkennen Sie die Rollen der Personen auf dem Team Management Rad anhand der kurzen Beschreibungen? Wer bin ich? Erkennen Sie die Rollen der Personen auf dem Team Management Rad anhand der kurzen Beschreibungen? René Ich habe ein sehr schlechtes Gefühl bei dem Projekt, dass wir jetzt gestartet haben.

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 1. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 1. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 1. Vorlesung 1 Thomas Patzelt patzelt@htw-berlin.de, 0172 390 4230 49 Jahre, verheiratet, 3 Söhne: 17, 22 und 24 Jahre Studium, Tutor-Tätigkeit & Diplom am

Mehr

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen.

Des Weiteren gibt es Anpassungsprogrammierer, die reine Projektanpassungen umsetzen, eventuell Mitarbeiter für Datenübernahmen oder Schulungen. ERP Einführung 1. Vorgehen, Terminplan, Projektrealisierung 1.1 Kickoff Termin Bei diesem Termin wird das Projektmanagement definiert. Dies bedeutet, dass das Projektteam auf beiden Seiten skizziert wird.

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV 1 Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg Dr. Harald Bayer Innenministerium BW, StaV 2 Zum Redner Mitarbeiter der Stabsstelle für Verwaltungsreform (StaV) des Innenministeriums

Mehr

Thomas Schissler Uwe Baumann

Thomas Schissler Uwe Baumann Thomas Schissler Uwe Baumann Warum sind sie hier? Agenda Warum ist die Mitwirkung des Managements so wichtig? Betriebswirtschafliche Argumentation Vorteile von Agilität für Organisationen Scrum is extremly

Mehr

Wie Einzelhändler die Warenverfügbarkeit sicherstellen, die Lagerhaltung optimieren und ihre Umsätze steigern können

Wie Einzelhändler die Warenverfügbarkeit sicherstellen, die Lagerhaltung optimieren und ihre Umsätze steigern können LÖSUNGEN FÜR DIE BESTANDSVERWALTUNG RFID-Lösungen im Überblick Wie Einzelhändler die Warenverfügbarkeit sicherstellen, die Lagerhaltung optimieren und ihre Umsätze steigern können LÖSUNGEN FÜR DIE BESTANDSVERWALTUNG

Mehr

MATERNA Beschwerde-Management-Check. Umsetzungsorientierte Bestandsaufnahme zum Beschwerde-Management in Versicherungen

MATERNA Beschwerde-Management-Check. Umsetzungsorientierte Bestandsaufnahme zum Beschwerde-Management in Versicherungen MATERNA Beschwerde-Management-Check Umsetzungsorientierte Bestandsaufnahme zum Beschwerde-Management in Versicherungen >> MATERNA Beschwerde-Management-Check Ist in Ihrer Versicherung die Einführung,

Mehr

Projektmanagement Aufgabenstellung

Projektmanagement Aufgabenstellung Modulprüfungen SVF-ASFC Ausgabe Herbst 2010 Projektmanagement Aufgabenstellung Dauer der Prüfung: 60 Minuten Erlaubte Hilfsmittel: keine Kleben Sie Ihre Prüfungsmarke hier auf! Punkte: Note: Unterschrift

Mehr

Donnerstag, 10.10.2013 Newsletter Jahrgang 1 / Ausgabe 24

Donnerstag, 10.10.2013 Newsletter Jahrgang 1 / Ausgabe 24 Donnerstag, 10.10.2013 Newsletter Jahrgang 1 / Ausgabe 24 Liebe Leser/innen, herzlich willkommen zu einer neuen Newsletter Ausgabe von Bühner Invest. Heute möchte ich Ihnen ein wenig zum Thema die Deutschen

Mehr

CONSIDEO: Meetings verkürzen Fehler vermeiden besser entscheiden

CONSIDEO: Meetings verkürzen Fehler vermeiden besser entscheiden CONSIDEO: Meetings verkürzen Fehler vermeiden besser entscheiden 1. Einführung: Umgang mit Komplexität Unsere täglichen Herausforderungen: Wie gehen wir mit Komplexität um? Meetingfrust Wer kennt das nicht?

Mehr

Die Fachgruppe Critical Chain PM Status 05.03.2011

Die Fachgruppe Critical Chain PM Status 05.03.2011 Die Fachgruppe Critical Chain PM Status 05.03.2011 Seite 1 Vereinspräsentation www.gpm-ipma.de Fachgruppe Critical Chain Projektmanagement Die Fachgruppe "Critical Chain Projektmanagement" steht für die

Mehr

Denise Comando Ulrich Swiss AG Mövenstrasse 12 9015 St. Gallen

Denise Comando Ulrich Swiss AG Mövenstrasse 12 9015 St. Gallen Denise Comando Ulrich Swiss AG Mövenstrasse 12 9015 St. Gallen Inhaltsverzeichnis Inhaltsverzeichnis...2 Flussdiagramm...3/4 Einführung in die Prozesseinheit...5 Prozessbeschreibung...5/6 Schlusswort...6

Mehr

Ihre Funktion: Leitung Finanzen CFO

Ihre Funktion: Leitung Finanzen CFO Seite 1 Ihre Funktion: Leitung Finanzen CFO Als zuständige Person werden Sie sich in erster Linie mit den Zahlen der Unternehmung auseinander setzen. Es ist also wichtig, dass Sie einen ersten Überblick

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Sanierung von IT-Projekten

Sanierung von IT-Projekten Sanierung von IT-Projekten Präsentation zur Vorlesung Juristisches IT-Projektmanagement bei Dr. Frank Sarre im Wintersemester 2013/2014 Ludwig-Maximilians-Universität München Folie 1 Agenda Motivation

Mehr

Wie Sie mit Change Management bei der SAP-Implementierung bis zu 30 % der Kosten sparen

Wie Sie mit Change Management bei der SAP-Implementierung bis zu 30 % der Kosten sparen Wie Sie mit Change Management bei der SAP-Implementierung bis zu 30 % der Kosten sparen Wie Sie mit Change Management bei der SAP-Implementierung bis zu 30 % der Kosten sparen Eine Software-Implementierung

Mehr

Kapitel 2: Projektmanagement Umsetzung

Kapitel 2: Projektmanagement Umsetzung 1. Projektmanagement-System 2. Projektphasen 3. Aufbauorganisation 4. Menschen im Projekt und ihre Rollen 5. Excurs: Gruppendynamik 6. Methoden und Werkzeuge Dr. Ulrich Meyer 22 Kapitel 2: PM-Umsetzung

Mehr

Agile Projekte in Auftrag geben

Agile Projekte in Auftrag geben Agile Projekte in Auftrag geben Jens Coldewey (BDU) Coldewey Consulting Toni-Schmid-Str. 10 b D-81825 München Germany Tel: +49-700-COLDEWEY Tel: +49-700-26533939 Fax: +49-89-74995703 jens.coldewey@coldewey.com

Mehr