Vorlesung. Projektmanagement. Sommersemester Wolfgang Kowarschick. Fachhochschule Augsburg

Transkript

1 Vorlesung Projektmanagement Sommersemester 2006 Wolfgang Kowarschick Fachhochschule Augsburg

2 Draft (29. Juni 2006) 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 Zusammenfassung Projekterfolg Wie vermeidet man einen Misserfolg? 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 (29. Juni 2006)

4 3 Schätzung Die Schätzgrößen Divide et Impera Akzeptierbare Abweichungen Dreipunkt-Schätzung Erwartungeswert und Standardabweichung Zentraler Grenzwertsatz der Statistik Schätzverfahren Die Function-Point-Methode COCOMO Die Güte von Schätzverfahren Was ist ein Personenmonat? Planung Projektpläne Grobplanung Tätigkeitensammlung Work-Breakdown-Structure Feinplanung Netzpläne Balkendiagramme Ressourcen-Management Personalplanung Bedarfsplanung der Betriebsmittel Kostenplanung Kalender Projektkontrolle (Controlling) Draft (29. Juni 2006) 4

5 Kapitel 1 Definitionen Fremdwörterduden (2001): Projekt: Plan, Unternehmung, Entwurf, Vorhaben managen: leiten, zustandebringen, geschickt bewerkstelligen, organisieren Brockhaus (1991): 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. Oyen, Schlegel (1986): Projekt (Frese 1980): Projekte umfassen Aufgaben, die durch folgende Merkmale gekennzeichnet sind: zeitliche Befristung Komplexität relative Neuartigkeit Management (Rogers 1975, Terry 1961): Planung, Organisation, Führung, Kontrolle der Aktivitäten im Hinblick auf eine effiziente (besonders wirtschaftliche, wirksame) und ökonomische (wirtschaftlich sparsame) Zielerreichung (Rogers, 1975). Management ist ein eindeutig identifizierbarer Prozess, bestehend aus den Phasen Planung, Organisation, Durchführung, Kontrolle, der über den Einsatz von Mensch zur Formulierung und Erreichung von Zielen führt (Terry, 1961). Projektmanagement (Schröder 1971): Projektmanagement ist die verantwortliche Leitung der Planung, Projektierung, Durchführung und Kontrolle öffentlicher wie auch industrieller Vorhaben. Kellner, Hedwig (1994): Merkmale eines Projektes: 5 Draft (29. Juni 2006)

6 es ist ein einmaliges Vorhaben es ist zeitlich begrenzt es ist ein komplexes Vorhaben es macht die Zusammenarbeit von Menschen aus unterschiedlichen Fachgebieten notwendig es sind neuartige und unbekannte Probleme zu lösen es steht unter besonderem Risiko es hat ein eigenes Budget während der Projektarbeit stehen die Mitarbeiter und der Leiter unter besonderem Druck Projektmanagement: alle Tätigkeiten, die das ausführende Arbeiten im Projekt erst ermöglichen DIN 69901: Projekt: Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe zeitliche, finanzielle oder andere Bedingungen Abgrenzung gegenüber anderen Vorhaben projektspezifische Organisation 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 begenztes, eigenständiges, komplexes Vorhaben mit klaren Vorgaben bezüglich Funktionalität und Qualität und mit eigenem, meist begrenztem Budget. Die Realisierung eines Projektes wird von einem Auftraggeber finanziert und einem Auftragnehmer übertragen. Der Auftragnehmer nimmt dazu ein Projektteam und (anderere) geeignete Ressourcen zuhilfe. Das Projektergebnis wird nach 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. Draft (29. Juni 2006) 6

7 Ein Projekt ist ein einmaliges Vorhaben. Neuartige, unbekannte Probleme sind zu lösen. Großes Risiko im Vergleich zum Tagesgeschäft. Risikomanagement ist die zweitwichtigste Aufgabe des Projektmanagements. Ein Projekt ist ein komplexes Vorhaben. Verschiedene Techniken, Methoden und Spezialisten müssen eingesetzt und koordiniert werden. 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. 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. Ein Projekt hat ein eigenes, begrenztes Budget. Der Auftraggeber trägt die Kosten; der Auftragnehmer akzeptiert oder lehnt ab. Kosten und Nutzen müssen gegeneinander aufgewogen werden. (die 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. 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 Auftragnehmer. 7 Draft (29. Juni 2006)

8 Ein Projekt wird von einem Projektteam realisiert. Der Auftragnehmer wählt geeignete Mitarbeiter und insbesondere einen geeigneten Projektleiter. Dieser sollte möglichst früh (in den allerersten Projektphasen) an Projketdefinitionen beteiligt werden. Ein großes Projekt kann in mehrere Teilprojekte mit eigenen Teams und Teilprojektleitern untergliedert werden. Einen Gesamtprojektleiter (Projektmanager) gibt es dennoch. Mitarbeiterführung ist die wichtigste Aufgabe des Projektmanagements. Ein Projekt verbraucht Ressourcen (Material 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, 7/99 Inkompatibel, IT-Anbieter verstehen ihre Kunden nicht, S. 37: Unterschätzte Anwender: IT-Abteilungen wissen, dass 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). 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. Draft (29. Juni 2006) 8

9 Die negativen Auswirkungen auf Betroffene müssen so minimal wie möglich gehalten werden. Prozesskosten, Entschädigungszahlungen etc. müssen berücksichtigt werden 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. 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. Auftragnehmer Auftraggeber Ressourcen Funktionalität Qualität strategische Ziele strategische Ziele Zeit Projektziele Kosten Beispiele für Projekte: Asterix und Kleopatra: Bau eines Palastes für Cäsar (Goscinny and 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 9 Draft (29. Juni 2006)

10 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 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 den Auftraggeber mit sich bringen (das gilt selbst für die Grundlagenforschung: das Menschheitswissen, das als Basis für alle anderen Projekte dient, wird vermehrt). Funktionalität und Qualität sowie Strategische Ziele Spezifikation Was soll im Projekt erreicht werden (Funktionalität), und von welcher Güte soll das Ergebnis sein (Qualität). Strategische Ziele werden i. Allg. nicht formuliert. Asterix und Kleopatra Funktionalität: Palast für Cäsar Qualität: rechtwinklige Stufen, Steine fallen nicht von der Decke, Türen klemmen nicht, prunkvoll strategische Ziele: Nachweis, dass Ägypter nicht dekadent sind; Gewinn einer Wette Auftraggeber und Auftragnehmer erwarten sich vom Projektergebnis einen Gewinn oder anderen Nutzen. Das Projektergebnis sollte die gewünschte Funktionalität (und nur diese!) in der gewünschten Qualität aufweisen. ständige Überwachung des Funktionsumfangs Draft (29. Juni 2006) 10

11 Qualitätstests Um wirklich von Nutzen zu sein (d. h. 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 vergrößert mit der Verminderung der Qualität (z. B. CD-ROM heute meist ohne Staubschutz, da billiger als mit Staubschutz; VHS war viel schlechter als Video 2000, aber dennoch erfolgreicher erst SVHS reicht an die Qualität von Video 2000 heran). 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 haben evtl. Katastrophen zur Folge, 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) 11 Draft (29. Juni 2006)

12 Anmerkung Nicht alle Auftraggeber erwarten die vollständige Erfüllung aller Projektziele. Special-Effects-Firmen (SFX-Firmen), wie die Firmen ILM (Flubber, 4 Monate Zeit) oder Digital Domain (Titanic, 25 Mio Dollar, Nachverhandlungen 40 Mio Dollar 4 Mio Dollar + 31 Mitarbeiter Verlust), müssen auf Verlangen der Hollywood Filmstudios entweder on time (d. h. im vorgegebenen Zeitraum) oder on budget (d. h. im Rahmen des vorgegebenen Budgets) arbeiten (am besten natürlich beides) 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 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 von einem unbekannten Autor bringt das sehr schön zum Ausdruck: Bei einer Firma werden 5 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 Projekt-Managern, damit keiner etwas merkt und du Depp musst die Putzfrau fressen...!!! Draft (29. Juni 2006) 12

13 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 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. 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 (Videokonferenzing!) etc. werden benötigt? Ressource Rechte : Für viele Multimediaobjekte müssen Lizenzgebühren gezahlt, d. h. Verwertungsrechte oder andere Rechte erworben werden. Unterauftragnehmer : Fremdfirmen, andere Abteilungen, Consultants etc. können als externe Unterauftragnehmer zur Erfüllung der Projektziele beitragen. Wenn irgendwelche Ressourcen zu den geplanten Kosten oder während des geplanten Zeitraums nicht zur Verfügung stehen, müssen eventuell Abstriche an den formalen Funktionalität, Qualität, Zeit 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. 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 13 Draft (29. Juni 2006)

14 führen, zu planen, zu organisieren und zu kontrollieren. Zu diesem Zweck werden i. Allg. ein verantwortlicher (Gesamt-)Projektleiter und eventuell mehrere Teilprojektleiter (d. h. Leiter von Teilprojekten) bestimmt Aufgaben des Projektmanagements Die wichtigste Aufgabe eines Projektleiters ist die Menschenführung. Außerdem muss er das Projekt planen und organisieren: 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 schriflich in verbindlicher Form festgelegt werden. Der Projektleiter muss die Spezifikation durch genaue Projektpläne (Kostenpläne, Zeitpläne, Ressourcenpläne, Aufgabenaufteilung etc.) absichern! Im laufenden Projekt muss 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 zu den erwarteten Terminen (Meilensteinen) 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 (sehr wichtig, da unzufriedene Mitarbeiter sehr teuer sind) etc. 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 nicht überschritten wurde die Termine eingehalten werden Draft (29. Juni 2006) 14

15 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. 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 soviel 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. Murphys Gesetze 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). Konfuzius: Wer einen Fehler macht und nichts daraus lernt, macht einen zweiten Zusammenfassung Wesentliche Aufgaben des Projektleiters: 1. Menschenführung 2. Risikomanagement (Murphy lebt) 3. Planung und Kontrolle 1.3 Projekterfolg Wann ist ein Projekt erfolgreich? Wenn man Projektleiter fragt: Misserfolge gibt es nicht! Daher meine Definitionen: 15 Draft (29. Juni 2006)

16 Projekterfolg aus neutraler Sicht (juristische Sicht) Die neutrale Sichtweise kann nur die schriflichen Vereinbarungen zwischen Auftraggeber und -nehmer zur Grundlage haben. erfolgreich: Ein Projekt ist erfolgreich, wenn alle vertraglich festgelegten Ziele erfüllt wurden: 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 (kein Dezemberfieber ) und/oder 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 Produktziele 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. späterer 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) Produkt immer noch von Nutzen ist, d. h., wenn Draft (29. Juni 2006) 16

17 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. 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. 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 surde, 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 gescheidert. 17 Draft (29. Juni 2006)

18 Beispiel 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.). Wie mann 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 and Lister (2003)). Häufig sieht die Planung jedoch so aus: Kosten: ,13 Euro Nutzen: Das müssen wir haben. 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 Infrastruktur (Gebäude etc.) laufende Projekte Achtung: ein länger andauernder negativer Cashflow führt i. Allg. zur Insolvenz, auch wenn der Gewinn und Rendite stimmen. Beispiele Titanic (der Film): sehr erfolgreich für den Auftraggeber, trotz Kosten von 200 Mio Dollar (100 Mio geplant) sowie 6 Monate Verzug. Draft (29. Juni 2006) 18

19 Aus Sicht von Digital Domain: weniger erfolgreich, wenn man den Prestigegewinn durch den Film berücksichtigt, oder gescheitert, wenn man die Verluste berücksichtigt (4 Millionen Dollar + 31 Mitarbeiter Verlust). (Quelle:?) Bahnhof 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.) Oppenheimer, Robert ( ; Krebs) Juli 1943: Direktor der Forschungslaboratorien in Los Alamos (New Mexiko) Projekt: Bau der ersten Atombombe ( Manhattan Project ) Budget: unbegrenzt; zum Schluss mehr als 2 Milliarden Dollar Zeit: genau 19 Monate Team: die besten Physiker Amerikas Das Projekt wurde erfolgreich abgeschlossen: funktionierendes Ergebnis genau zum angestrebten Termin ( Tag X ). 21 und 24 Tage nach Projektende wurde das Ergebnis in Hiroshima und Nagasaki eingesetzt. Für das amerikanische Militär war das Projektergebnis ein voller Erfolg; für die Betroffenen die Bewohner von Hiroshima und Nagasaki und später für die ganze Menschheit (Wettrüsten) war das Projekt katastrophal gescheitert (gerade weil es formal erfolgreich war). Oppenheimer war kurze Zeit ein Nationalheld. Während des Projektes hat er allerdings einen Mitarbeiter bei einem Atomunfall verloren (das erste Opfer einer Atombombe). Später widersetzte sich Oppenheimer dem Bau der Wasserstoffbombe Untersuchungsverfahren wegen angeblicher kommunistischer Gesinnung, 1954 Ausschluss von allen Staatsgeheimnissen und öffentlichen Ämtern, 1963 Rehabilitation Aussagen von Oppenheimer: 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. (Quelle: 19. Auflage des Brockhaus, Film Die Schattenmacher") 19 Draft (29. Juni 2006)

20 Betty Dong, Pharmazeutin an der Universität von Kalifornien in San Franzisko Untersuchung über Heilungswirkung verschiedener Varianten des synthetischen Hormons Levothyroxin bei Schilddrüsenerkrankungen. 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. (Quelle: SZ, , Wissenschaftler die Hilfsarbeiter der Industrie) 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. Brücke ohne Straße). 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. H.G. Gemünden ( Erfolgsfaktoren des Projektmanagements, 1990) Trotz dieser schönen Definitionen ist Erfolg schwer zu messen, da es keine normierten Erfolgsmaße und keine einheitliche Sichtweise gibt und auch nicht geben kann. Gemünden schlägt eine systematische Differenzierung nach folgenden Gesichtspunkten vor: Objekt: Erfolgsbestimmung wird umso schwieriger, je komplexer, innovativer, dynamischer und konflikthaltiger ein Projekt ist. Eigenschaft: Man muss technische, wirtschaftliche, soziale Kriterien etc. berücksichtigen (z. B. auch Auswirkungen auf Mitmenschen oder die Natur). Maßstab: Man benötigt konkrete Maßstäbe zum Messen dieser Kriterien. Draft (29. Juni 2006) 20

21 Perspektive: Der Standpunkt des Beurteilenden (Projektleiter, Auftraggeber, Benutzer, Gutachter) kann ganz unterschiedliche Ergebnisse liefern. Phase: Zu unterschiedlichen Zeitpunkten (während Projektphase bzw. Nutzungsphase) kommen die Beurteilenden zu unterschiedlichen Ergebnissen. zeitlicher Bezug: kurzfristiger Misserfolg, aber langfristiger Erfolg oder kurzfristiger Erfolg, aber langfristiger Flop. Frage Ist Titanic für Digital Domain ein erfolgreiches Projekt (Prestigegewinn, Folgeaufträge) oder ein erfolgloses Projekt (4 Mio + 31 Mitarbeiter Verlust) gewesen? Das wird sich erst im Laufe der Zeit herausstellen! Wie vermeidet man einen Misserfolg? Ein erfolgreiches Projekt zu leiten, sollte das Ziel eines jeden Projektleiters sein. Erfolgreich heißt dabei: erfolgreich aus Sicht des Projektleiters, des Auftragnehmers, des Auftraggebers und des Benutzers und sofern ein ethisches Verantwortungsbewustsein 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! (F. Brooks, 1986: There is no Silver Bullet ) 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, falls das Risiko zum echten Problem wird, 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 21 Draft (29. Juni 2006)

22 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 sich nachträglich nur kontrolliert ändern. 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). Typische Risiken aus der Sicht des Projektleiters (Beispiele) Im Folgenden werden Beispiele für Risiken angegeben, die ein Projekt scheitern lassen können, wenn sie nicht rechtzeitig bedacht werden. Abhilfe: frühzeitige und realistische Planungen, rechtzeitiges Gegensteuern falsche Funktionalität Benutzer akzeptieren System nicht überzogene Funktionalität Der Auftraggeber möchte eine eierlegende Wollmilchsau neue Techniken sollen eingesetzt werden, die noch gar nicht das Stadium der Forschung hinter sich gelassen haben nicht-realisierbare Funktionalität Inflation der Anforderungen (= ausufernde Änderungswünsche während der Projektlaufzeit) Qualitätsprobleme überzogene Qualität nicht-realisierbare Qualität z. B.: Ein System mit 100% Ausfallsicherheit soll 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 falsche oder fehlende Qualitätssicherung kritisches Zeitmanagement Mitarbeiter werden krank oder haben Urlaub. Mitarbeiter verlassen den Betrieb (Mitarbeiterfluktuation). Ein guter Mitarbeiter/Projektleiter arbeitet in normalen Zeiten höchstens 4 Tage a 6 Stunden (= 24 Stunden) pro Woche aktiv für das Projekt (Asterix: Arbeiter arbeiten zu langsam). Draft (29. Juni 2006) 22

23 Für jede Aufgabe muss ein Puffer eingeplant werden (wegen Krankheit, Lieferschwierigkeiten, Systemausfall etc.; Pyradonis behindert Steinnachschub). Pausen kosten Zeit (Microsoft-Lösung: Win95-Buttons für bevorzugte Abfertigung in Kantine). Telekommunikation kostet Zeit: Jedes Telefonat, jede reißt einen Wissensarbeiter aus seiner Denkarbeit es dauert danach jeweils ca. 10 Minuten seine Gedanken danach wieder auf die eigentliche Arbeit zu konzentrieren (sich zu vertiefen ). Konkurrenz schneller (evtl. mit weniger Funktionalität oder Qualität). inhärent falscher Zeitplan ( politischer Zeitplan, agressive Zeitplanung ) kritische Kostenplanung (bei Asterix nicht gegeben, Geld ist reichlich da) Spezialisten kosten Geld. (Es kann billiger sein, einen Profi zu 1000 Euro/Tag zu holen, als einen Amateur zu 100 Euro/Tag.) Geeign98 100etes Material kostet Geld. Lizenzen und andere Rechte kosten Geld. Repräsentatives Management und andere produktspezifische Aufgaben kosten Geld (Bewirtung von Gästen, Präsentationen etc.). Puffer- und Ausfallzeiten kosten Geld. Konkurrenz billiger (evtl. mit weniger Funktionalität oder Qualität). falsches Ressourcenmanagement Unzufriedene Mitarbeiter können jedes Projekt zu Fall bringen (Mobbing, zuviel Kontrolle, zu wenig Kontrolle etc.) Menschenführung (ganz wesentlich) (Asterix: Arbeiter wollen weniger Peitschenhiebe) Kommunikationsprobleme 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 Multimediarechner ohne Sound- 23 Draft (29. Juni 2006)

24 karten, unausgereifte Entwicklungswerkzeuge etc.) geringe Produktivität der (falschen oder auch unmotivierten) Mitarbeiter Ressourcenklau zwischen rivalisierenden Projekten Auftraggeber oder Lieferant liefert benötigte Ressourcen zu spät Sabotage Spezifikationskollaps 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. Probleme von außen (schwer abwendbar) höhere Gewalt (Konkurs des Auftraggebers, Streik, Umweltkatastrophen) Spionage Konkurrenz hat mehr Marktmacht Sonstiges Koordinationsprobleme Missverständnisse zwischen Auftragnehmer und Auftraggeber lückenhafte Verträge Projekte scheitern meist an Menschen: Management Projektteam (Projektleiter und Projektmitarbeiter) Auftraggeber externe Partner Typische zwischenmenschliche Probleme: Manager kümmern sich nicht um Projektinterna, treffen aber Entscheidungen. Angst vor Versagen zuviel Kontrolle. Angst vor Sympathieverlust zu wenig Kontrolle. nutzlose Meetings aufgrund von Profilierungssucht. irreale Kosten-/Zeitschätzungen, weil Auftragnehmer das Projekt unbedingt oder überhaupt nicht haben will. Draft (29. Juni 2006) 24

25 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. Projektrisiken gibt es viele. Am Besten ist es natürlich, alle managebare Risiken auch zu managen. (Ein Risiko wie z. B. Ein Asteroid vernichtet einen Großteil der Menschheit ist nicht managebar und kann daher ignoriert werden.) Es ist aber 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 (1995) 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 Tom DeMarco und Timothy Lister (DeMarco and 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. Die anderen Risiken können Sie durch harte Arbeit Ihres 25 Draft (29. Juni 2006)

26 Teams und kompetente Erledigung Ihrer Projektleitertätigkeit nach Vertragsabschluss kaum mehr beeinflussen. 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. 1.4 Vergleich von Projekten mittels Euro-Tagen Ein billiges Projekt mit langer Laufzeit beindet 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 (2005)). Wenn ein Projekt 1000 Euro einen Monat lang bindet, entspricht dies laut Goldratt einer Investition von 1000 Euro 30 Tage = Euro-Tage. Verschiedene Euro-Tag-Investitionen werden einfach aufaddiert. Nehmen wir an, unser Projekt hätte eine Laufzeit von 3 Monaten. Jeder Monat koste uns 1000 Euro, anschließend verdienen wir monatlich 500 Euro mit dem Projektergebnis. Das heißt, wir investieren 3000 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 3000 Euro, nach 9 Monaten hatten wir das Geld wieder. Das entspricht einer Investition von 3000 Euro 9 30 Tage = Eurotage, man spricht auch von Investitions-Euro-Tagen. Diese Rechnung ist allerdings etwas grob, da wir die 3000 Euro ja nicht sofort am Draft (29. Juni 2006) 26

27 ersten Tag investiert hatten und auch nicht 9 Monate lang auf jeden Cent verzichten mussten. Bei genauerer Rechnung ergibt sich folgende Investitionssumme: 1. Monat: 1000 Euro investiert 30 Tage 1000 Euro = Euro-Tage, Summe: Euro-Tage 2. Monat: weitere 1000 Euro investiert 30 Tage 2000 Euro = Euro-Tage, Summe: Euro-Tage 3. Monat: weitere 1000 Euro investiert 30 Tage 3000 Euro = Euro-Tage, Summe: Euro-Tage 4. Monat: 500 Euro verdient noch 2500 Euro investiert 30 Tage 2500 Euro = Euro-Tage, Summe: Euro-Tage 5. Monat: 500 Euro verdient noch 2000 Euro investiert 30 Tage 2000 Euro = Euro-Tage, Summe: Euro-Tage 6. Monat: 500 Euro verdient noch 1500 Euro investiert 30 Tage 1500 Euro = Euro-Tage, Summe: Euro-Tage 7. Monat: 500 Euro verdient noch 1000 Euro investiert 30 Tage 1000 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 nach 10 Monaten Geld, haben dafür aber 9 Monate lnag Investitionsmittel in Höhe von Euro-Tagen verzichtet. Wenn wir das Geld für diese Zeit anders (besser) angelegt hätten, hätten wir evtl. früher mehr Geld verdient. Das heißt, wir können erst dann von einem echten Reingewinn sprechen, wenn wir mir dem Projekt nicht nur das Geld, sondern auch die verlorenen Euro-Tage wieder verdient haben. Die Rechnung der so genannten Durchsatz-Euro-Tage, d. h. der Euro-Tage, die wir durch das Projekt gewinnen, beginnt ab dem Zeitpunkt, ab dem wir erstmals einen echten Gewinn einfahren. Bei unserem Projekt ist das der 10. Monat. Die Durchsatz-Euro-Tage werden geanuso wie die Investitions-Euro-Tage berechnet: 10. Monat: 500 Euro Gewinn 30 Tage 500 Euro = Euro-Tage, Summe: Euro-Tage 11. Monat: weitere 500 Euro Gewinn 30 Tage 1000 Euro = Euro-Tage, Summe: Euro-Tage 12. Monat: weitere 500 Euro Gewinn 30 Tage 1500 Euro = Euro-Tage, Summe: Euro-Tage 13. Mona:t weitere 500 Euro Gewinn 30 Tage 2000 Euro = Euro-Tage, Summe: Euro-Tage 27 Draft (29. Juni 2006)

28 14. Monat: weitere 500 Euro Gewinn 30 Tage 2500 Euro = Euro-Tage, Summe: Euro-Tage 15. Monat: weitere 500 Euro Gewinn 30 Tage 3000 Euro = Euro-Tage, Summe: Euro-Tage 16. Monat: weitere 500 Euro Gewinn 30 Tage 3500 Euro = Euro-Tage, Summe: Euro-Tage (26 Tage 3500 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 3500 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, wenn wir das Projekt gar nicht gestartet hätten und das auch noch früher. (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. Das Magazin TOC Times sagt:... the project Flushes we really return the investment in both money and opportunity lost TOC (2005). Allerdings nützen die ganzen schönen Prognosen nichts, wenn die Schätzungen der Projektdauer, der Kostenverläufe und der erwarteten Gewinne schlecht oder gar vollkommen unseriös sind. Andererseits macht einem die Berücksichtigung der Euro-Tage erst klar, welche Kosten eine große Zeitverzögerung wirklich verursacht. Es wird nicht nur der Reingewinn geschmälert (wenn sich das neue Handy beispielsweise nur noch ein halbes Jahr verkaufen lässt und nicht, wie geplant, ein ganzes Jahr, da es zu spät auf den Markt gekommen ist). Es wird auch die Investitionskraft, d. h. der Cashflow, empfindlich geschmälert. Fazit Wenn man die Auswahl zwischen mehreren Projekten hat, sollte man bei der Entscheidung, welche davon realisiert werden sollten, nicht nur die Kosten und den später erhofften Gewinn, sondern auch die Auswirkungen auf die Investitionskraft, d. h. die Investitions- und die Durchsatz-Euro-Tage berücksichtigen. Draft (29. Juni 2006) 28

29 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) 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. 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 Auftraggeber präsentiert werden und mit ihm das weitere Vorgehen abgestimmt wird. 29 Draft (29. Juni 2006)

30 Projektstart Meilenstein 1 Meilenstein 2 Projektende Prinzipielles Vorgehen Phase n: Dauer n Budget n Funktionalität und Qualität n Pläne n Produkt n (Meilenstein am Ende der Phase n) Review n mit Entscheidung: weiter: Phase n + 1 wird gestartet (bzw. Projektende, wenn Phase n + 1 nicht existiert) zurück: Phase n (oder sogar frühere Phase) wird 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 solte 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. Projektdauer = Σ(Dauer n + Dauer Review n) Projektkosten = Σ(Kosten n + Kosten Review n) Für die Planung hat die Einleitung in Phasen überdies den Vorteil, dass Dauer und Kosten genauer abgeschätzt werden können: geschätzte Projektdauer min = (geschätzte Dauer n inkl. Review r n,min ) geschätzte Projektkosten min = (geschätzte Zeit n inkl. Review r n,min ) geschätzte Projektdauer max = (geschätzte Dauer n inkl. Review r n,max ) geschätzte Projektkosten max = (geschätzte Zeit n inkl. Review r n,max) Draft (29. Juni 2006) 30