Projekt-Management
Projekt-Management
Projekt-Management
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Software Engineering<br />
Informatik II.<br />
3. Software-Entwicklung<br />
– <strong>Projekt</strong>-<strong>Management</strong> –<br />
Dipl.-Inform. Hartmut Petters
Vorwort – was ich noch zu sagen hätte ...<br />
Basis dieser Vorlesung sind vor allem die folgenden Ausarbeitungen<br />
Vorlesungsskript „Software Engineering“<br />
von Prof. Dr. Martin Glinz Universität Zürich<br />
http://www.ifi.unizh.ch/groups/req/courses/se_I/<br />
Vorlesungsskript „Informatik II – Software Engineering“<br />
von Frau Prof. Dr. Kühn FH Karlsruhe FB W<br />
http://www.home.fh-karlsruhe.de/~kuin0001/inhalt.htm<br />
Das Buch „Software Engineering“ 6. Auflage/2001<br />
von Prof. Ian Sommerville University of Lancaster (UK)<br />
Addison Wesley ISBN 3-8273-7001-9<br />
Konkret entnommene Beiträge sind i.d.R. mit einem Quellen-Verweis<br />
gekennzeichnet – sollte dieser fehlen bitte ich um Nachsicht.<br />
Den „roten Faden“ durch die Vorlesung habe ich dem Skript der<br />
Vorlesung von Prof. Dr. Martin Glinz entnommen und um eigene<br />
Beiträge erweitert bzw. aus den beiden anderen Quellen ergänzt.<br />
Für die Möglichkeit der Verwendung der wesentlichen Inhalte möchte<br />
ich mich an dieser Stelle bei den Autoren herzlich bedanken.<br />
22.12.2003 2<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Erkenntnisse<br />
"Ein <strong>Projekt</strong> ist ein außergewöhnliches Vorhaben"<br />
(Madauss, GPM 2/91)<br />
"Bei der überwältigenden Mehrheit der gescheiterten<br />
<strong>Projekt</strong>e wurde kein einziges Anzeichen von<br />
Technologie-Schwierigkeiten gefunden, welches<br />
das Scheitern erklären könnte„<br />
"Je planvoller der Mensch vorgeht,<br />
umso härter vermag ihn der Zufall zu treffen„<br />
"Sage mir, wie das <strong>Projekt</strong> begonnen hat<br />
und ich sage wie es enden wird"<br />
(De Marco, 1987)<br />
(Dürrenmatt, 1987)<br />
22.12.2003 3<br />
© by Hartmut Petters
Besonderheiten bei Software-<strong>Projekt</strong>en<br />
Was ist bei Software-<strong>Projekt</strong>en anders?<br />
Software ist immateriell!<br />
Führung durch genaues Hinsehen funktioniert nicht!<br />
Sorgfältige Planung<br />
Ständige Überprüfung + Kontrolle<br />
Permanente Steuerung<br />
Beachtung aller <strong>Projekt</strong>risiken<br />
22.12.2003 4<br />
© by Hartmut Petters
<strong>Projekt</strong> - Fehlerkosten<br />
Relative<br />
Kosten zur<br />
Beseitigung<br />
eines Fehlers<br />
500<br />
200<br />
100<br />
50<br />
20<br />
10<br />
5<br />
2<br />
1<br />
Analyse Design Realisierung Test Wartung<br />
Phase in der der Fehler entdeckt wird<br />
22.12.2003 5<br />
© by Hartmut Petters
Ertragsminderung in % (nach Steuer)<br />
Auswirkungen bei Abweichungen<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
"Time to Market"<br />
6 Monate<br />
zu spät<br />
(33%)<br />
Produktionskosten<br />
9% zu hoch<br />
(22%)<br />
Entwicklungskosten<br />
50%<br />
überschritten<br />
(3,5%)<br />
Auswirkungen von Abweichungen auf den<br />
Gesamtertrag des Produkts<br />
Annahmen:<br />
20% Marktwachstum<br />
12% jährlicher<br />
Preisverfall<br />
5 Produkt-Lebenszeit<br />
Quelle: McKinsey<br />
22.12.2003 6<br />
© by Hartmut Petters
Kritische Erfolgsfaktoren im <strong>Projekt</strong><br />
Kosten<br />
Zeit<br />
Qualität<br />
22.12.2003 7<br />
© by Hartmut Petters
<strong>Projekt</strong> - Einflussfaktoren<br />
Einflussfaktoren:<br />
Information<br />
Zusammenarbeit<br />
Entscheidungen<br />
Ergebnisse<br />
Anwender<br />
Lieferanten<br />
Auftraggeber<br />
Linien-Mgmt.<br />
EDM / PDM-<strong>Projekt</strong><br />
Support-<br />
Bereiche<br />
Rahmenbeding.<br />
im Unternehmen<br />
Promotoren<br />
weitere<br />
<strong>Projekt</strong>e<br />
22.12.2003 8<br />
© by Hartmut Petters
Ganzheitliches <strong>Projekt</strong><br />
z.B.<br />
Ziele, Sollkonzept<br />
Pflichtenheft<br />
Entscheidungs-<br />
Vorlagen<br />
Steuernde<br />
Eingriffe<br />
z.B.<br />
Team-Sitzungen<br />
Aufwandsschätzung<br />
Problemlösung<br />
Transparenz durch<br />
Information<br />
Akzeptanz-<strong>Management</strong><br />
Fachliches<br />
<strong>Management</strong><br />
Mitarbeitergerechte<br />
Führung<br />
<strong>Projekt</strong>-<br />
Organisation<br />
<strong>Projekt</strong>-<br />
Administration<br />
z.B.<br />
<strong>Projekt</strong>-Strukturierung<br />
Teilprojekte definieren<br />
Stufenplan<br />
Meilensteine<br />
<strong>Projekt</strong>-Rollenund<br />
Besetzung<br />
Kompetenzen<br />
z.B.<br />
<strong>Projekt</strong>-Controlling<br />
Change-<strong>Management</strong><br />
Arbeitsaufträge<br />
22.12.2003 9<br />
© by Hartmut Petters
Arten von Software-<strong>Projekt</strong>en<br />
Entwicklungsprojekt<br />
Interner Auftraggeber (Hersteller)<br />
Spezifikation vorgegeben<br />
Marktuntersuchung<br />
Interne Planungen<br />
Software Engineering<br />
Planung, Realisierung<br />
Neuerstellung, Weiterentwicklung<br />
Abnahme, Erfolgskontrolle<br />
Interne Abnahmetests, Testkunden<br />
Erfüllungsgrad der Spezifikation<br />
Ergebnis: Software-Produkt<br />
22.12.2003 10<br />
© by Hartmut Petters
Arten von Software-<strong>Projekt</strong>en<br />
Einführungsprojekt<br />
Externer Auftraggeber (Endkunde)<br />
Spezifikation abhängig<br />
Leistungsfähigkeit des Software-Produkts<br />
Kundenumfeld / Geschäftsprozesse<br />
Software Engineering<br />
Prozess-Analyse, Integration, Einführungskonzept<br />
Anpassung, Erweiterung<br />
Abnahme, Erfolgskontrolle<br />
Pilotanwendern, Endanwender<br />
Integration in Kundenumfeld<br />
Ergebnis: lauffähige Kundenanwendung<br />
22.12.2003 11<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Vorgehensweise<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
22.12.2003 12<br />
© by Hartmut Petters
<strong>Projekt</strong>-Voraussetzungen<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
Betrachtung als strategisches Vorhaben<br />
Klärung der Aufgabenstellung<br />
Definition klarer, quantifizierbarere Ziele<br />
Commitment des Top-<strong>Management</strong>s<br />
Einbeziehung aller davon Betroffenen<br />
Gemischte Betrachtung: DV und Organisation<br />
Kommunikation, Transparenz<br />
22.12.2003 13<br />
© by Hartmut Petters
Software Engineering - <strong>Projekt</strong>-Kick-Off<br />
Ist-<br />
Analyse<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Zielsetzung<br />
Informationen über gestartetes <strong>Projekt</strong><br />
Begründung<br />
Inhalte<br />
Zeithorizont<br />
Mitarbeitsbedarf<br />
Präsentation der eingesetzten Technologien<br />
und deren Zielsetzung<br />
Teilnehmer:<br />
Bereichsverantwortliche<br />
22.12.2003 14<br />
© by Hartmut Petters
<strong>Projekt</strong>-Komponenten<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
Zieldefinition / <strong>Projekt</strong>-Vision<br />
<strong>Projekt</strong>abgrenzung<br />
Was gehört dazu – Was nicht?<br />
Detaillierter Stufenplan + Meilensteinplan<br />
Kosten- und Ressourcen-Planung<br />
Risikobewertung des <strong>Projekt</strong>s<br />
Wirtschaftlichkeitsberechnung<br />
22.12.2003 15<br />
© by Hartmut Petters
Beziehungen der <strong>Projekt</strong>beteiligten<br />
Demokratisches Team Hierarchisch organisierte Teams<br />
PL<br />
klein mittel<br />
Idealfall: pro Person nur ein <strong>Projekt</strong> gleichzeitig<br />
Andernfalls Probleme durch Umdenken<br />
Steering Committee<br />
22.12.2003 16<br />
© by Hartmut Petters<br />
PL<br />
Stab<br />
groß
<strong>Projekt</strong>management - Machbarkeitsstudie<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
<strong>Projekt</strong>-Machbarkeitsstudie<br />
Grobe<br />
Ist-<br />
Analyse<br />
Rahmenkonzept<br />
Wirtschaftlichkeitsrechnung<br />
<strong>Projekt</strong>planung<br />
22.12.2003 17<br />
© by Hartmut Petters
Machbarkeitsstudie - Grobe Ist-Analyse<br />
Grobe<br />
Ist-<br />
Analyse<br />
Rahmenkonzept<br />
Ziele<br />
Wirtschaftlichkeitsrechnung<br />
<strong>Projekt</strong>planung<br />
Einarbeitung des <strong>Projekt</strong>-Teams<br />
Beteiligung und Sensibilisierung<br />
der Anwender / Betroffenen<br />
Grundlage für die Planung<br />
Ermittlung der Defizite / Baustellen<br />
Ermittlung der Prioritäten<br />
Aufbauorganisation<br />
Systemwelt<br />
22.12.2003 18<br />
© by Hartmut Petters
Machbarkeitsstudie - Rahmenkonzept<br />
Grobe<br />
Ist-<br />
Analyse<br />
Ziele<br />
Rahmenkonzept<br />
Wirtschaftlichkeitsrechnung<br />
<strong>Projekt</strong>planung<br />
Bebauungsplan<br />
Klare Zielvorstellungen<br />
Einheitliches Verständnis<br />
Vision für das <strong>Management</strong><br />
Grundlage für die Planung<br />
Inhalte<br />
<strong>Projekt</strong>ziele<br />
22.12.2003 19<br />
© by Hartmut Petters<br />
Leitlinien<br />
System-Architektur<br />
HW-Umgebung<br />
SW-Umgebung<br />
Funktions-Architektur<br />
Daten-Architektur<br />
Integrations-Konzept<br />
Organ. Maßnahmen
Machbarkeitsstudie - Kosten/Nutzen-Rechnung<br />
Grobe<br />
Ist-<br />
Analyse<br />
Ziele<br />
Rahmenkonzept<br />
Wirtschaftlichkeitsrechnung<br />
<strong>Projekt</strong>planung<br />
<br />
Aufwand / Kosten<br />
Konkretisierung des Nutzen<br />
Amortisationszeit<br />
Risikobewertung<br />
Lernkurve<br />
Inhalte<br />
<strong>Projekt</strong>kosten<br />
Prozess-Redesign<br />
Ausbau Infrastruktur<br />
Lizenzen / Schnittstellen<br />
Konfiguration<br />
Wartung / Schulung<br />
Datenübernahme<br />
Produktivität (Lernkurve)<br />
Direkte Einsparungen<br />
Indirekter Nutzen<br />
Time to Market-Effekte<br />
Qualität (Prozesse,<br />
Daten, Produkte)<br />
Ablösung von Anwendungen<br />
Ersatz lokaler Archive<br />
Ablösung laufender /<br />
geplanter <strong>Projekt</strong>e<br />
22.12.2003 20<br />
© by Hartmut Petters
Machbarkeitsstudie - <strong>Projekt</strong>planung<br />
Grobe<br />
Ist-<br />
Analyse<br />
Ziele<br />
Rahmenkonzept<br />
Wirtschaftlichkeitsrechnung<br />
<strong>Projekt</strong>planung<br />
Gesamt-<strong>Projekt</strong>plan<br />
Termine<br />
Ressourcen<br />
Meilensteine / Freigaben<br />
Detailpläne für Folgephasen<br />
Inhalte<br />
<strong>Projekt</strong>struktur<br />
Aufwands- und Zeitplanung<br />
<strong>Projekt</strong>organisation<br />
22.12.2003 21<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Start Konzeptphase<br />
Ist-<br />
Analyse<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Was sollte unbedingt vermieden werden?<br />
Großveranstaltungen vor zukünftigen<br />
Anwendern<br />
Workshop<br />
Teilnehmerbefragung<br />
Entscheidungen ohne/gegen Anwender<br />
Lange <strong>Projekt</strong>phasen ohne Rückkopplung<br />
Mammut-<strong>Projekt</strong>e<br />
22.12.2003 22<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Phase: IST-Analyse<br />
Ist-<br />
Analyse<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Zielsetzung<br />
Dokumentation der Abläufe<br />
Funktionen<br />
Daten-<strong>Management</strong>, Daten-Weitergabe<br />
Analyse der "Baustellen"<br />
Ermittlung<br />
Problemstellungen<br />
vorbereitende Maßnahmen definieren<br />
Hauptfunktionen festlegen<br />
Dokumenten-Klassen, Mengengerüst<br />
Datenmodell, Übernahmemechanismen, Schnittstellen<br />
Zielanwender, Pilotanwender, Anzahl<br />
22.12.2003 23<br />
© by Hartmut Petters
<strong>Projekt</strong> - IST-Analyse / Workshop<br />
einzelne Workshops<br />
Informationen über <strong>Projekt</strong> und<br />
Technologie<br />
gezielte Teilnehmer-Auswahl<br />
Verantwortliche<br />
ausgewählte Mitarbeiter<br />
Verantwortliche für Anwendungen<br />
Erarbeiten der Anforderungen<br />
Fragenkatalog zur Vorbereitung<br />
22.12.2003 24<br />
© by Hartmut Petters
<strong>Projekt</strong> - IST-Analyse<br />
Ist-<br />
Analyse<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Was sollte unbedingt vermieden werden?<br />
für Anwender undurchschaubare<br />
Methodik und Darstellung<br />
zu viele Teilnehmer<br />
mehrere Themengebiete<br />
Lösungen präjudizieren<br />
Orientierung an bekannten Systemen<br />
die Anwender unvorbereitet hinzuziehen<br />
22.12.2003 25<br />
© by Hartmut Petters
<strong>Projekt</strong> - Phase: SOLL-Konzeption<br />
Ist-<br />
Analyse<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Zielsetzung<br />
Strukturierung der Funktionalitäten<br />
Anwendungsübergreifend<br />
anwendungsspezifisch<br />
Beschreibung der Sollprozesse<br />
Beschreibung der<br />
Applikationen / Plattformen<br />
Ist-Zustand<br />
Planung<br />
Entwicklung des Datenmodells<br />
22.12.2003 26<br />
© by Hartmut Petters
Ist-<br />
Analyse<br />
<strong>Projekt</strong>-Phase: Konzeption<br />
Sollkonzept<br />
Pflichtenheft<br />
System-<br />
Auswahl<br />
Was sollte unbedingt vermieden werden?<br />
Überschreitung des Zeitrahmens<br />
Detaillierungsgrad<br />
zu wenig Abstimmung<br />
zu wenig Akzeptanz<br />
wichtige Bereiche übergehen<br />
ungeeignete Zusammensetzung des<br />
<strong>Projekt</strong>-Teams<br />
Zusammenfassen von Sollkonzept<br />
und Pflichtenheft<br />
22.12.2003 27<br />
© by Hartmut Petters
<strong>Projekt</strong>umsetzung - Theorie vom Nutzen<br />
Quantifizierbar<br />
nicht <strong>Projekt</strong><br />
beeinflusst<br />
durch <strong>Projekt</strong><br />
beeinflußt<br />
Einsparung<br />
Arbeitsplatzfunktionen<br />
Senkung der Kosten um<br />
ca. 20-25%<br />
Schwer quantifizierbar<br />
Fehlervermeidung<br />
aktuelle, direkt<br />
verfügbare Daten<br />
keine redundante<br />
Datenerfassung<br />
Qualitätsverbesserung<br />
Prozessunterstützung<br />
standardisierte<br />
Produktstruktur<br />
früherer Markteintritt<br />
Normenkonformität<br />
Ertragssteigerung bis 30%<br />
22.12.2003 28<br />
© by Hartmut Petters
<strong>Projekt</strong>-Umsetzung – BPR-Maßnahmen<br />
Wegfall von Tätigkeiten<br />
Neue Aufgabenverteilung,<br />
Re-Integration in den Hauptprozess<br />
Ausführung und Entscheidung in einer Hand,<br />
Verlagerung des Entscheidungsprozesses<br />
Parallelisierung von Tätigkeiten<br />
Zeitliche und räumliche Entkopplung,<br />
Unabhängigkeit der Kooperation<br />
Qualitäts-<strong>Management</strong> für den Prozess<br />
Einsatz moderner Technik und Technologien<br />
22.12.2003 29<br />
© by Hartmut Petters
<strong>Projekt</strong> - Kosten-Nutzen-Analyse<br />
Prozess- und Tätigkeitsanalyse<br />
Ablaufschritte<br />
Tätigkeiten<br />
Bewertung der Tätigkeiten<br />
nach Zeit (Ausführungszeit, Liegezeit,<br />
Transferzeit)<br />
nach Kosten<br />
Prozess- und Tätigkeitsoptimierung<br />
Tätigkeiten (Notwendigkeit? Optimierung?)<br />
Bewertung der optimierten Tätigkeiten<br />
Umsetzung mittels <strong>Projekt</strong><br />
22.12.2003 30<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Kritische Erfolgsfaktoren<br />
Commitment und aktive Unterstützung<br />
durch das <strong>Management</strong><br />
erfahrene, durchsetzungsstarke und<br />
anerkannte <strong>Projekt</strong>leiter<br />
ausgewogenes, motiviertes <strong>Projekt</strong>-Team<br />
fachlich, organisatorisch, wirtschaftlich und<br />
terminlich abgesicherte <strong>Projekt</strong>definition<br />
präzise und realistische Planung<br />
22.12.2003 31<br />
© by Hartmut Petters
Planung bei Software-<strong>Projekt</strong>en<br />
Was muß geplant werden?<br />
Der Prozess + das Prozess-Modell<br />
Die Organisationsstruktur<br />
Personal + Personaleinsatz<br />
Termine + Kosten<br />
Dokumente + Verfahren<br />
Wie wird geplant?<br />
Sach- + zielorientiert<br />
Anspruchsvoll, aber realistisch<br />
Aufgaben + Ressourcen im Gleichgewicht<br />
22.12.2003 32<br />
© by Hartmut Petters
Der <strong>Projekt</strong>plan<br />
Dokumentiert<br />
Alle Ergebnisse der Planung<br />
Die Plan-Fortschreibung<br />
Gibt Antwort auf 6 W-Fragen<br />
Warum? Veranlassung + <strong>Projekt</strong>ziele<br />
Was? Zu liefernde Resultate (Produktziele)<br />
Wann? Geplante Termine<br />
Wer? Personen + Verantwortlichkeiten<br />
Womit? Verfügbare Mittel (Geld, Geräte, ...)<br />
Wie? Vorgehensweise + Maßnahmen zur<br />
Sicherstellung des <strong>Projekt</strong>erfolgs<br />
22.12.2003 33<br />
© by Hartmut Petters
Mögliche <strong>Projekt</strong>plan-Gliederung<br />
1. Einleitung<br />
2. Ziele<br />
3. Arbeitsplan<br />
(1) Arbeitspakete<br />
(2) Lieferungen + Abnahmen<br />
(3) Risiken<br />
4. Terminplan<br />
5. Personalplan<br />
(1) <strong>Projekt</strong>-Organigramm<br />
(2) Personal-Einsatzplan<br />
6. Kostenplan<br />
7. Sonstige Ressourcen<br />
8. Vorgehen<br />
22.12.2003 34<br />
© by Hartmut Petters
Planungshilfsmittel<br />
Grafische Darstellung in Diagrammen der<br />
Terminpläne<br />
Kostenpläne<br />
Arbeitspläne<br />
Personal-Einsatzpläne<br />
Immer: SOLL + IST Vergleich<br />
Einsatz geeigneter Werkzeuge<br />
Ermittelung des geplanten + tatsächlichen<br />
Aufwandes + Dokumentation<br />
Grundlage für Schätzung + Planung neuer <strong>Projekt</strong>e<br />
22.12.2003 35<br />
© by Hartmut Petters
<strong>Projekt</strong>kontrolle + <strong>Projekt</strong>lenkung<br />
Fortschrittskontrolle ist unabdingbar!<br />
Ergebnisse müssen messbar sein<br />
90%-Syndrom!<br />
Bei Abweichung<br />
Lenkung!<br />
Rahmen für Kontrolle + Lenkung<br />
Termin-Verfolgung<br />
Sachziel-Verfolgung<br />
Kosten-Verfolgung<br />
Risiko-Verfolgung<br />
22.12.2003 36<br />
© by Hartmut Petters
Sachziel- + Terminverfolgung<br />
Mit Hilfe definierter Meilensteine<br />
Planung<br />
Meilensteine strukturieren die Sachziele in Teilziele<br />
Festlegung der SOLL-Termine für alle Meilensteine<br />
Meilenstein erreicht<br />
Zwischenziel nachweislich erreicht<br />
Gesicherte quantitative Aussage der Termin-Situation<br />
durch SOLL-IST-Vergleich<br />
Meilenstein am geplanten Termin nicht erreicht<br />
Schätzung der Termin-Situation durch Schätzung des<br />
verbleibenden Aufwands bis Zielerreichung<br />
22.12.2003 37<br />
© by Hartmut Petters
Kostenverfolgung<br />
Scheinbar einfach<br />
Aufzeichnen budgetierter + tatsächlicher Kosten<br />
über die Zeit<br />
„De Facto“ unbrauchbar!<br />
Alternativen<br />
Kosten + fiktive Erträge auf einer Zeitachse<br />
Kosten auf einer Meilensteinachse<br />
SOLL-Kosten am geplanten Meilenstein-Termin mit IST-<br />
Kosten bei Erreichung des Meilensteins vergleichen<br />
22.12.2003 38<br />
© by Hartmut Petters
Verantwortlichkeiten + Berichtswesen<br />
Verantwortlichkeiten + Kompetenzen aller<br />
Beteiligten klar geregelt<br />
Keine Übertragung von Verantwortung ohne die<br />
dafür notwendigen Kompetenzen + Ressourcen<br />
Stufengerechtes Umgehen mit Problemen<br />
Berichtswesen<br />
Keine bürokratische Schikane ...<br />
... sondern Frühwarnfunktion<br />
Arbeitspaket-Ordner als Organisations-Hilfsmittel<br />
22.12.2003 39<br />
© by Hartmut Petters
Maßnahmen bei Abweichungen<br />
Abweichungen<br />
Gegenmaßnahmen<br />
Beispiel: Terminüberschreitung<br />
Bereitstellung zusätzlicher Ressourcen<br />
Befreiung der <strong>Projekt</strong>mitarbeiter von anderen Verpflichtungen<br />
Anordnung von Überstunden / Urlaubsstreichung<br />
Vergabe von Teilaufträgen an Dritte<br />
Abstriche bei den geplanten Funktionalitäten<br />
Neuplanung der Leistungsziele (Wachstumsmodell)<br />
Falls Gegenmaßnahmen versagen oder nicht möglich<br />
Planung anpassen<br />
22.12.2003 40<br />
© by Hartmut Petters
<strong>Projekt</strong>-Abschluss<br />
<strong>Projekt</strong> geordnet in die Wartungsphase überleiten<br />
Entstandenes Wissen sichern<br />
Dokumentation<br />
Dokumente Abschließen + archivieren<br />
Messungen<br />
abschließen<br />
Gesamtergebnisse berechnen<br />
(z.B. Gesamtaufwand, gesamte <strong>Projekt</strong>laufzeit, ...)<br />
Messwerte speichern / archivieren<br />
<strong>Projekt</strong>geschichte dokumentieren<br />
SOLL / IST für Kosten, Termine, Sachziele, Personal<br />
Erfahrungen + „Learnings“<br />
22.12.2003 41<br />
© by Hartmut Petters
<strong>Projekt</strong>organisation bei Software-<strong>Projekt</strong>en<br />
Beteiligung mehrer –<br />
grundsätzlich bei allen <strong>Projekt</strong>en<br />
Besondere Beachtung<br />
Rolle der <strong>Projekt</strong>leitung<br />
Beziehungen der <strong>Projekt</strong>beteiligten<br />
<strong>Management</strong><br />
Anwender<br />
Lieferanten<br />
IT-Abteilung<br />
<strong>Projekt</strong>-Team-Mitglieder<br />
Lenkungsausschuss - Steering-Committee<br />
„Politische“ Rahmenbedingungen<br />
22.12.2003 42<br />
© by Hartmut Petters
<strong>Projekt</strong>leitung<br />
<strong>Projekt</strong>leitung ist eine sehr anspruchsvolle Aufgabe<br />
<strong>Projekt</strong>leiter(in) ist die Schlüsselfigur<br />
Führung durch klare Zielsetzung<br />
<strong>Management</strong> der<br />
Kompetenzen<br />
Verantwortung<br />
Ressourcen<br />
Eigenverantwortliches Handeln<br />
Generell: berichten + informieren<br />
Führung durch Informations-<strong>Management</strong><br />
22.12.2003 43<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Softwareprojekte<br />
Gutes <strong>Projekt</strong>management<br />
Kann den <strong>Projekt</strong>erfolg „nicht garantieren“ - aber<br />
Generell alles im Überblick<br />
Rechtzeitiges Gegensteuern<br />
Transparenz + gutes Informations-<strong>Management</strong><br />
Schlechtes <strong>Projekt</strong>management<br />
Führt gewöhnlich zum Scheitern des <strong>Projekt</strong>s durch<br />
Auslieferung zu spät<br />
Kostenüberschreitung<br />
Anforderungen nicht erfüllt<br />
22.12.2003 44<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Softwareprojekte<br />
<strong>Management</strong>-Aufgaben<br />
Erstellung + Kalkulation des Angebots<br />
<strong>Projekt</strong>- und Zeitplan<br />
Aufgabenpakete + Meilensteine<br />
Lieferungen + Abnahme<br />
<strong>Projekt</strong>kostenkalkulation<br />
Aufgaben-Planung + Zuteilung<br />
Ressourcen-<strong>Management</strong> + Qualifizierung<br />
Kostenkontrolle + Kosten-<strong>Management</strong><br />
<strong>Projekt</strong>überwachung + Reviews<br />
Auswahl und Beurteilung des Personals<br />
Erstellen + Präsentation von Berichten<br />
22.12.2003 45<br />
© by Hartmut Petters
<strong>Projekt</strong>planung - Softwareprojekte<br />
Aufgaben<br />
bestimmen<br />
Software<br />
Anforderungen<br />
Abhängigkeiten<br />
der Aufgaben<br />
Ressourcen<br />
abschätzen<br />
Personen<br />
zuordnen<br />
Mögliche Probleme + Risiken vorhersehen<br />
Lösungen erarbeiten + präsentieren<br />
Aufgaben definieren + zuordnen<br />
Pflege + Weiterentwicklung der Planung<br />
Risikoanalyse + Risikominimierung<br />
<strong>Projekt</strong>diagram<br />
erstellen<br />
Netz- und<br />
Balkenpläne<br />
22.12.2003 46<br />
© by Hartmut Petters
<strong>Projekt</strong>planung – Aufgaben + Abhängigkeiten<br />
Zuordnung der<br />
Mitarbeiter<br />
Termin: <strong>Projekt</strong>start<br />
Name der Aufgabe<br />
Dauer der Aufgabe<br />
Start der Aufgabe<br />
Ende der Aufgabe<br />
Abhängigkeiten<br />
Meilenstein<br />
22.12.2003 47<br />
© by Hartmut Petters
<strong>Projekt</strong>planung - Balkendiagramm<br />
<strong>Projekt</strong>start<br />
Aufgaben<br />
Meilenstein<br />
Abhängigkeit<br />
<strong>Projekt</strong>ende<br />
22.12.2003 48<br />
© by Hartmut Petters
<strong>Projekt</strong>planung - Netzplantechnik<br />
22.12.2003 49<br />
© by Hartmut Petters
Softwareprojekt - Risikomanagement<br />
Risiko-<br />
Erkennung<br />
Liste<br />
potenzieller<br />
Risiken<br />
Risiko-<br />
Analyse<br />
Priorisierte<br />
Liste der<br />
Risiken<br />
Risiko-<br />
Planung<br />
Risikovermeidung<br />
und<br />
Notfallpläne<br />
Risiko-<br />
Überwachung<br />
Risiko-<br />
Bewertung<br />
Risiko-<strong>Management</strong> ist Erkennen + Minimierung möglicher<br />
<strong>Projekt</strong>-Risiken + Ergreifen geeignete Maßnahmen<br />
Generell Risiken vorhersehen, die sich auswirken auf<br />
<strong>Projekt</strong>ablauf / Zeitplan<br />
Qualität des Ergebnisses<br />
Kosten des <strong>Projekt</strong>s<br />
22.12.2003 50<br />
© by Hartmut Petters
Risiken bei Software-<strong>Projekt</strong>en<br />
Personal (<strong>Projekt</strong>)<br />
Erfahrenes Personal verlässt das <strong>Projekt</strong> vor <strong>Projekt</strong>ende<br />
<strong>Management</strong> (<strong>Projekt</strong>)<br />
<strong>Management</strong>-Wechsel bringt Änderung in den Prioritäten<br />
Hardware-Verfügbarkeit <strong>Projekt</strong>)<br />
Unverzichtbare Hardware ist nicht verfügbar<br />
Veränderung der Anforderungen (<strong>Projekt</strong> / Produkt)<br />
Gravierende Änderungen der Anforderungen stellen die Planung in Frage<br />
Verzögerungen bei der Spezifikation (<strong>Projekt</strong> / Produkt)<br />
Spezifikation von Funktionen / Schnittstellen erheblich verspätet<br />
Fehleinschätzungen des Arbeitsumfangs <strong>Projekt</strong> / Produkt)<br />
Aufwand für Module / Funktionen / Schnittstellen / etc. werden unterschätzt<br />
Mangelhafte CASE-Werkzeuge (Produkt)<br />
Produktivität leidet unter der schlechten Qualität der Werkzeuge<br />
Technologieveränderungen (Wirtschaftlichkeit)<br />
Zugrundeliegende Technologie wird durch neue verdrängt<br />
Produktkonkurrenz (Wirtschaftlichkeit)<br />
Konkurrenzprodukte sind vor dem eigenen Produkt verfügbar<br />
22.12.2003 51<br />
© by Hartmut Petters
Die 10 häufigsten Software-Risiken<br />
1. Zu wenig Leute<br />
2. Unrealistische Kosten- und Terminpläne<br />
3. Falsche Funktionalitäten<br />
4. Falsche Benutzerschnittstellen<br />
5. Vergoldung (überflüssiger Luxus)<br />
6. Sich ständig verändernde Anforderungen<br />
7. Probleme mit zugekauften Komponenten<br />
8. Probleme mit extern vergebenen Aufträgen<br />
9. Nichterreichung der verlangten Leistungen<br />
(z.B. Reaktionszeit)<br />
10. Überforderung der Mitarbeiter in Bezug auf ihr<br />
Software-technisches Können<br />
Quelle: Boehm (1991)<br />
22.12.2003 52<br />
© by Hartmut Petters
Risiko-Erkennung – 1. Schritt<br />
Technologische Risiken aus Funktionalität +<br />
Verfügbarkeit von Hardware + Software<br />
Personenbezogene Risiken bzgl. des Einsatzes + der<br />
Verfügbarkeit des Entwicklungs-Teams<br />
Risiken durch „Werkzeug-Einsatz“ im <strong>Projekt</strong><br />
Anforderungsrisiken durch Änderungen und/oder<br />
Erweiterungen der Funktionalitäten<br />
Schätzrisiken aus Fehlabschätzungen bzgl. der<br />
System-/<strong>Projekt</strong>-Charakteristik + Ressourcen<br />
22.12.2003 53<br />
© by Hartmut Petters
Risiken + Arten von Risiken<br />
Risiko-Art Mögliche Risiken<br />
Technologisch DB kann nicht so viele Transaktionen ausführen / Sek. wie erwartet.<br />
Zur „Wiederverwendung“ vorgesehene Software-Komponenten<br />
enthalten Fehler, die die Funktionalität einschränken<br />
Personen-bezogen Nicht genügend Personal mit benötigten Skills rekrutierbar<br />
Schlüsselpersonen sind krank oder nicht verfügbar<br />
Erforderliche Schulungen sind nicht durchführbar<br />
Unternehmens-bezogen Umstrukturierung des Unternehmens, dadurch Wechsel der<br />
Zuständigkeit für das <strong>Projekt</strong>.<br />
Finanz-Probleme zwingen zu Kürzungen der <strong>Projekt</strong>-Budgets<br />
Werkzeuge Der durch CASE-Werkzeuge generierte Programm-Code ist ineffizient<br />
CASE-Werkzeuge können nicht eingebunden werden<br />
Anforderungen Nachträgliche Änderungen der Anforderungen ziehen erhebliche<br />
Nacharbeit des Entwurf nach sich.<br />
Schätzung Entwicklungszeit wird zu niedrig eingeschätzt<br />
Zu geringe Schätzung für Fehlerbehebung + Software-Umfang<br />
22.12.2003 54<br />
© by Hartmut Petters
Risiko-Analyse – 2. Schritt<br />
Alle erkannten Risiken betrachten + beurteilen<br />
Wahrscheinlichkeit<br />
Konsequenzen<br />
Stark abhängig von der Erfahrung des Managers<br />
Tabellarische Auflistung der Risiko-Abschätzung<br />
Basis für Risiko-Analyse<br />
Informationen über das <strong>Projekt</strong><br />
Informationen über das <strong>Projekt</strong>-Team<br />
Informationen über das Unternehmen<br />
Informationen über den Markt<br />
Informationen über den Wettbewerb<br />
Änderung der Analyse-Ergebnisse durch zusätzliche<br />
Informationen ist jederzeit möglich<br />
22.12.2003 55<br />
© by Hartmut Petters
Risiko-Analyse<br />
Bestimmung der Gefährlichkeit von<br />
Einzelrisiken<br />
Risiko-Kombinationen<br />
Gefährlichkeit<br />
Wahrscheinlichkeit des Eintretens: p (Risiko)<br />
Mögliche Schadenshöhe: s (Risiko)<br />
Bewertung mit Risikofaktor<br />
f (Risiko) = p(Risiko) * s (Risiko)<br />
Risiken mit gleichem Risikofaktor sind etwa gleich<br />
gefährlich<br />
Problem der Restrisiken<br />
22.12.2003 56<br />
© by Hartmut Petters
Risiken + Arten von Risiken<br />
Risiko Wahrscheinlichkeit<br />
Finanzielle Probleme zwingen zur Kürzung des <strong>Projekt</strong>-Budgets niedrig<br />
Es ist unmöglich, genügend Personal mit den, für das <strong>Projekt</strong><br />
benötigten Fähigkeiten zu rekrutieren<br />
Schlüsselpersonen werden zu wichtigen Zeitpunkten des<br />
<strong>Projekt</strong>s krank<br />
Zur Wiederverwendung vorgesehen Software-Komponenten<br />
enthalten Fehler, die ihre Funktionalität einschränken<br />
Es werden Änderungen der Anforderungen vorgeschlagen, die<br />
eine beträchtliche Nacharbeit des Entwurfs nach sich ziehen<br />
Das Unternehmen wird umstrukturiert, so dass ein anderes<br />
<strong>Management</strong> für das <strong>Projekt</strong> verantwortlich zeichnet<br />
Die im System eingesetzte Datenbank kann nicht so viele<br />
Transaktionen pro Sekunde durchführen wie erwartet<br />
Auswirkung<br />
22.12.2003 57<br />
© by Hartmut Petters<br />
hoch<br />
mittel<br />
mittel<br />
mittel<br />
hoch ernst<br />
mittel<br />
katastrophal<br />
katastrophal<br />
ernst<br />
ernst<br />
ernst<br />
ernst
Risiken + Arten von Risiken<br />
Risiko Wahrscheinlichkeit<br />
Die zur Entwicklung der Software benötigte Zeit wird<br />
unterschätzt<br />
Auswirkung<br />
CASE-Werkzeuge können nicht eingebunden werden hoch tolerierbar<br />
Kunden verstehen die Auswirkungen von Änderungswünschen<br />
(Anforderungen) nicht<br />
Es gibt keine Möglichkeit erforderliche Schulungen<br />
durchzuführen<br />
22.12.2003 58<br />
© by Hartmut Petters<br />
hoch<br />
mittel<br />
mittel<br />
Die Anzahl der Fehlerbehebungen wird unterschätzt mittel tolerierbar<br />
Der Umfang der Software-Entwicklung wird unterschätzt hoch tolerierbar<br />
Der durch CASE-Werkzeuge generierte Code ist ineffizient mittel unbedeutend<br />
ernst<br />
tolerierbar<br />
tolerierbar
Risiko-<strong>Management</strong><br />
Risiken<br />
Erkennen<br />
Analysieren<br />
Überwachen<br />
Boehm schlägt vor die „Top-10-Risiken“ zu<br />
erkennen + überwachen<br />
Zahl der Risiken hängt vom <strong>Projekt</strong> ab<br />
Orientierung der Risiken an der Praxis<br />
„Überschaubare“ Anzahl von Risiken überwachen<br />
Risiken mit Prioritäten versehen<br />
22.12.2003 59<br />
© by Hartmut Petters
Risiko-Planung<br />
Alle erkannten Haupt-Risiken betrachten +<br />
Strategie zum Risiko-Handling entwickeln<br />
Abhängig von der Erfahrung des <strong>Projekt</strong>-Managers<br />
Strategien zum Risiko-Handling<br />
Vermeidungs-Strategie<br />
Ziel: Wahrscheinlichkeit für das Auftreten des<br />
Risikos verkleinern<br />
Minimierungs-Strategie<br />
Ziel: Auswirkungen des Risikos zu reduzieren<br />
Notfall-Pläne<br />
Ziel: Einstellen auf den schlimmsten Fall um<br />
vorbereitet zu sein und Lösung parat ist<br />
22.12.2003 60<br />
© by Hartmut Petters
Risikomanagement – Lösungs-Strategien<br />
Risiko Strategie<br />
Finanzielle Probleme des<br />
Unternehmens<br />
Zusammenfassung vorbereiten und das Top-<strong>Management</strong> überzeugen,<br />
dass das <strong>Projekt</strong> für das Unternehmen existenziell wichtig ist<br />
Rekrutierungs-Probleme Kunden über Probleme alarmieren + auf Verzögerungen vorbereiten,<br />
prüfen, ob fertige Komponenten zugekauft werden können.<br />
Krankheit des Personals Reorganisation des Teams, damit mehr Überschneidungen bei Arbeiten,<br />
damit die Kenntnisse über alle Aufgaben verteilt sind<br />
Fehlerhafte Komponenten Fehlerhafte Komponenten durch zuverlässige (zugekaufte) Komponenten<br />
ersetzen<br />
Änderung der<br />
Anforderungen<br />
Umstrukturierung des<br />
Unternehmens<br />
Rückverfolgbarkeits-Informationen ableiten, damit die Auswirkungen<br />
von Änderungen transparent werden.<br />
Zusammenfassung vorbereiten, um neues <strong>Management</strong> von den<br />
Hintergründen + der Wichtigkeit des <strong>Projekt</strong>s zu überzeugen<br />
Datenbank-Leistung Austausch der Datenbank mit einer Datenbank, die besserer Leistung<br />
hat, erwägen<br />
Schätzung Zugekaufte Komponenten untersuchen, Einsatz von Programm-<br />
Generatoren prüfen.<br />
22.12.2003 61<br />
© by Hartmut Petters
Risikomanagement - Risikofaktoren<br />
Risiko-Art Mögliche Anzeichen<br />
Technologisch Späte Anlieferung von Hardware oder Unterstützungs-Software;<br />
Berichte über viele technische Probleme<br />
Personen-bezogen Schlechte Moral beim Personal; schlechtes Verhältnis zwischen den<br />
Team-Mitgliedern untereinander<br />
Unternehmens-bezogen Gerüchte im Unternehmen;<br />
zu geringe Aktivitäten des höheren <strong>Management</strong>s<br />
Werkzeuge Abneigung der Team-Mitglieder Werkzeuge zu benutzen; Klagen über<br />
CASE-Werkzeuge Forderungen nach Arbeitsstationen mit mehr Leistung<br />
Anforderungen Viele Anfragen zur Änderung der Anforderungen;<br />
Beschwerden des Kunden<br />
Schätzung Überschreiten des vereinbarten Zeitplans;<br />
Versäumnisse, gemeldete Fehler zu beseitigen<br />
22.12.2003 62<br />
© by Hartmut Petters
Risikomanagement - Risikoüberwachung<br />
regelmäßige Beurteilung erkannter Risiken<br />
Weitere Faktoren zur Beurteilung heranziehen<br />
Risikoüberwachung ist ein fortlaufender Prozess<br />
Bei Meilenstein-/Fortschritts-Review Hauptrisiken<br />
einzeln betrachten + erörtern<br />
Beurteilung + Risikoabschätzung gemeinsam mit<br />
dem Team durchführen (Konsens-Entscheidung)<br />
Maßnahmen definieren zur Verbesserung des<br />
Risikomangements<br />
22.12.2003 63<br />
© by Hartmut Petters
Cando - <strong>Projekt</strong>darstellung<br />
Ausgelegt für<br />
> 2.500 (Teil-)<strong>Projekt</strong>e<br />
> 50.000 Ressourcen<br />
> 10.000 Anwender<br />
Internet-Zugriff<br />
Technologie<br />
JAVA<br />
Datenbank (Oracle)<br />
Voll skalierbar<br />
Vollgrafische Bedienung<br />
Unternehmenslösung<br />
Mehrsprachig<br />
Mandantenfähig<br />
Mehrere Währungen<br />
Client-Server-Struktur<br />
22.12.2003 64<br />
© by Hartmut Petters
<strong>Projekt</strong>-<strong>Management</strong> – Basiselemente<br />
Stundensätze, Kostenträger,<br />
vertikale + horizontale Aggregation,<br />
Darstellung von Kosten und Preisen<br />
Spezifikation, zentrale<br />
Risikodatenbank, automatische<br />
Beobachtung und Optimierung<br />
Berichtswesen via Dialoge,<br />
Ticker, Mail, SMS, Präsentationen,<br />
voll skalierbarer Ausdruck<br />
<strong>Projekt</strong>e, Phasen, Pakete, Meilensteine,<br />
Netzplantechnik, Gantt, CPM, Critical Chain<br />
Bestimmung von Unternehmensvorgaben,<br />
Modifikationsmöglichkeit während der Simulation<br />
Delegation von Paketen und/oder Phasen<br />
(intern und unternehmensübergreifend),<br />
Echtzeitverfolgung<br />
Java-Mitarbeiter Client,<br />
Ist-Zeit-Erfassung,<br />
Fertigstellungsgrad (%)<br />
Zentrale Ressourcendatenbank,<br />
Skill-<strong>Management</strong>, Ressourceleveling<br />
22.12.2003 65<br />
© by Hartmut Petters
Cando - Darstellungsformen<br />
<strong>Projekt</strong>-Leitstand<br />
Mitarbeiter-Infos<br />
Rückmeldungen Online<br />
Historie nachvollziehbar<br />
Basispläne + Varianten<br />
Simulation<br />
Permanenter Soll-Ist-<br />
Vergleich<br />
Integriertes Risiko-<strong>Management</strong><br />
Zentrale Bibliothek mit<br />
Risiken + Kategorien<br />
Puffersysteme (relativ<br />
/ absolut)<br />
Verschiedene Analyse-<br />
Techniken<br />
Statistische Auswertung +<br />
Analyse der Risiken<br />
Buchung der Abweichungen<br />
gegen bestehende Puffer<br />
22.12.2003 66<br />
© by Hartmut Petters
Cando – unscharfe Planungsdaten<br />
Planung aufgrund<br />
unscharfer Angaben<br />
2-3 Wochen<br />
20-30 Tagen<br />
Alle Angaben entsprechend<br />
der Realität<br />
Zeitangaben<br />
Kalenderwoche 12<br />
1-2 Monate<br />
Kostenschätzungen<br />
10-20 Manntage<br />
10.000-20.000 Euro<br />
Rückmeldungen<br />
Fertigstellung 50%<br />
20-40% fertig<br />
„Ontime“<br />
Ungenaues Paket<br />
Ungenauer Meilenstein<br />
22.12.2003 67<br />
© by Hartmut Petters
Cando – Multi-Ressourcen-<strong>Management</strong><br />
Vollständige Abbildung der<br />
Unternehmens-Organisation<br />
Skills-Verwaltung + Planung<br />
Gruppen + Abteilungs- Zuweisung<br />
Automatische Ressourcen-Findung<br />
Echtzeit-Kapazitätsauskunft<br />
Echtzeit-Konfliktlösung<br />
Zuweisungsstadien<br />
Reserviert<br />
Geplant<br />
...<br />
Einfachstes Handling<br />
Einbindung fremder Ressourcen<br />
Integration mit Fremdsystemen<br />
Online-Auskunft über alle<br />
Mitarbeiter<br />
22.12.2003 68<br />
© by Hartmut Petters
Cando – Dokumenten-<strong>Management</strong><br />
Vollständig integriertes<br />
Dokumenten-<strong>Management</strong><br />
22.12.2003 69<br />
© by Hartmut Petters
Akzeptanz-<strong>Management</strong><br />
Zielsetzung:<br />
"Machen Sie die Betroffenen zu Beteiligten"<br />
22.12.2003 70<br />
© by Hartmut Petters
Erfolgsfaktor im <strong>Projekt</strong>: Beteiligung<br />
Gebrauchstauglichkeit und <strong>Projekt</strong>erfolg<br />
durch frühzeitige Beteiligung aller Betroffenen<br />
funktionale<br />
Anforderungen<br />
Qualitätsmaßstab im<br />
produktiven Betrieb:<br />
"Gebrauchstauglichkeit"<br />
Erstelltes<br />
Anwendersystem<br />
22.12.2003 71<br />
© by Hartmut Petters
<strong>Projekt</strong> begleitende Maßnahmen (1)<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
<strong>Projekt</strong>vorbereitung<br />
interne Information<br />
(Kick-Off, Workshops)<br />
externe Information<br />
(Fachveranstaltungen zum Thema)<br />
<strong>Projekt</strong>-Team früh zusammenstellen<br />
und einbeziehen<br />
22.12.2003 72<br />
© by Hartmut Petters
<strong>Projekt</strong> begleitende Maßnahmen (2)<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
<strong>Management</strong>-Akzeptanz<br />
<strong>Management</strong>-Workshops<br />
Besuche bei Referenzanwendern<br />
Beteiligung im Lenkungsausschuss<br />
- regelmäßig von Beginn an -<br />
Berichtswesen<br />
- regelmäßig, auch wenn "in line"<br />
- offen mit Lösungsansätzen bei Problemen<br />
22.12.2003 73<br />
© by Hartmut Petters
<strong>Projekt</strong> begleitende Maßnahmen (3)<br />
Organisation<br />
Planung Konzeption Einführung<br />
Akzeptanz-<strong>Management</strong><br />
Mitarbeiter-Akzeptanz<br />
Einbeziehung in die <strong>Projekt</strong>arbeit<br />
"Go into the factory and ask the people"<br />
kontinuierliche Ausbildung<br />
kontinuierliche Transparenz und<br />
regelmäßige Information<br />
(schriftliche <strong>Projekt</strong>informationen)<br />
(Lopez)<br />
22.12.2003 74<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Empfehlungen (1 of 3)<br />
<strong>Projekt</strong>initialisierung für das Einführungsprojekt<br />
Detaillierte Aufgabenanalyse<br />
Zieldefinition (Meßlatte des <strong>Management</strong>s für das <strong>Projekt</strong>ergebnis)<br />
Verfeinerte <strong>Projekt</strong>planung, Detaillierung phasenbezogen abnehmen<br />
(Schätzungen der Vorphasen verifizieren, Risikozuschläge anpassen)<br />
Konsequentes <strong>Projekt</strong>-Controlling<br />
Permanente Auskunftsfähigkeit über das aktuell zu erwartende<br />
<strong>Projekt</strong>ergebnis<br />
("Wie kommen wir am Ende raus")<br />
Zyklische, max. monatliche Aktualisierung von Soll/Ist/Rest-Aussagen<br />
hinsichtlich der Erfüllung der Anforderungen (Q) und hinsichtlich<br />
der real zu erwartenden <strong>Projekt</strong>kosten (Kosten-Trend-Analyse)<br />
Aktualisierung des erreichbaren Endtermins und der Meilensteine<br />
(Meilenstein-Trend-Analyse auf Basis der Restschätzungen)<br />
Planung der Restlaufzeit auf breite Basis stellen und stets aktualisieren<br />
22.12.2003 75<br />
© by Hartmut Petters
<strong>Projekt</strong>management - Empfehlungen (2 of 3)<br />
Nachvollziehbare <strong>Projekt</strong>steuerung<br />
Steuernde Eingriffe nicht ohne vorhergehende<br />
Standortbestimmung durch das <strong>Projekt</strong>-Controlling<br />
(Was sagt das Konzept? Was steht im Pflichtenheft?<br />
Was war geplant? Was gewinnen, was verlieren wir?)<br />
nicht: die Anstrengungen verdoppeln, wenn<br />
das Ziel aus den Augen verloren wurde!<br />
Maßnahmen mit Auswirkung auf das vereinbarte <strong>Projekt</strong>ziel<br />
müssen vom Lenkungsausschuss abgesegnet werden!<br />
22.12.2003 76<br />
© by Hartmut Petters
<strong>Projekt</strong>-<strong>Management</strong> - Empfehlungen (3 of 3)<br />
Zielführendes Änderungs-<strong>Management</strong><br />
Änderungen sind unvermeidbar; z.B. aus folgenden Gründen:<br />
„Customizing“ einzelner Funktionen nicht machbar, aufwendiger<br />
Erfolgskritische Anforderungen wurden nicht identifiziert<br />
Schnittstellen leisten nicht den erforderlichen Funktionsumfang<br />
etc.....<br />
Jede Änderung der <strong>Projekt</strong>ziele, des Soll-Konzepts oder des<br />
Pflichtenhefts, etc. - und sei sie noch so klein - muss vor dem<br />
Hintergrund ihrer Auswirkungen auf das <strong>Projekt</strong>ergebnis<br />
bewertet und bewusst durchgeführt werden.<br />
Das <strong>Projekt</strong>-Team trifft keine unternehmerischen Entscheidungen<br />
(bei <strong>Projekt</strong>-typischen unternehmensübergreifenden Entscheidungen<br />
den Lenkungsausschuss und ggf. den Auftraggeber und wesentliche<br />
Promotoren einbeziehen.<br />
22.12.2003 77<br />
© by Hartmut Petters
Zusammenfassung<br />
Ein <strong>Projekt</strong> ist ein außergewöhnliches Vorhaben<br />
Aufgrund des unternehmensweiten Ansatzes sind<br />
die Akzeptanz, die Mitarbeit und die<br />
Unterstützung der Betroffenen jeweils ein<br />
wesentlicher Erfolgsfaktor.<br />
Der Aufwand für Kommunikation und<br />
Schnittstellen-<strong>Management</strong> zwischen den<br />
Mitwirkenden ist hoch.<br />
Die <strong>Projekt</strong>planung, das <strong>Projekt</strong>-Controlling und<br />
die <strong>Projekt</strong>steuerung sind anspruchsvoll.<br />
Der <strong>Projekt</strong>manager hat eine Schlüsselposition<br />
22.12.2003 78<br />
© by Hartmut Petters
Zusammenfassung<br />
Gutes <strong>Management</strong> bei Software-<strong>Projekt</strong>en ist zwingend<br />
<strong>Management</strong> von Software-<strong>Projekt</strong> unterscheidet sich von<br />
herkömmlichen <strong>Projekt</strong>en, da<br />
Immaterielles Gut<br />
Einsatz neuer, innovativer Technologien<br />
Wenig Erfahrungswerte<br />
Wissenschaftlich kaum erforscht<br />
Software-Manager spielen verschiedene Rollen<br />
<strong>Projekt</strong>planung<br />
<strong>Projekt</strong>kalkulation<br />
Zeit- / Terminplanung<br />
<strong>Projekt</strong>meilensteine durch formellen Bericht dokumentieren<br />
Grafische Darstellungen zur <strong>Projekt</strong>planung sind wichtig<br />
Hauptrisiken erkennen, analysieren + beurteilt werden<br />
Strategien + Notfallpläne für <strong>Projekt</strong>risiken entwickeln<br />
Risiken bei <strong>Projekt</strong>-Fortschrittssitzungen erörtern<br />
22.12.2003 79<br />
© by Hartmut Petters
Literatur – Software Engineering<br />
Skript Informatik II Prof. Dr. Kühn / Fb W FH Karlsruhe<br />
http://www.home.fh-karlsruhe.de/~kuin0001/inhalt.htm<br />
Skript Software Engineering Prof. Dr. Martin Glinz Universität Zürich<br />
http://www.ifi.unizh.ch/groups/req/courses/se_I/<br />
Skript Software Engineering II Bernd Kahlbrandt FH Hamburg<br />
http://www.informatik.fh-hamburg.de/~khb/st4se2/<br />
Software Engineering<br />
Ian Sommerville (ISBN3-82737-001-9)<br />
Software Engineering<br />
- Grundkurs für Praktiker –<br />
Roger S. Pressman (ISBN 3-89028-163-X)<br />
Software Entwurf<br />
- Methoden und Werkzeuge –<br />
A. Schulz (ISBN 3-486-21608-2)<br />
Software Engineering und Prototyping<br />
Thorsten Spitta (ISBN 3-540-17542-3)<br />
CASE<br />
Helmut Balzert (ISBN 3-411-03224-3)<br />
Software-Qualitätssicherung<br />
Ernest Wallmüller (ISBN 3-446-15846-4)<br />
22.12.2003 80<br />
© by Hartmut Petters
Software Engineering<br />
Informatik II.<br />
4. Software-Entwicklung<br />
– Software Anforderungen –
Change language