Ohne Ist-Zahlen keine Schätz-ompetenz Vortrag auf der regionalen Fachgruppe I-Projektmanagement, 24.10.2008, Stuttgart r. arsten Hoffmann, Steinbeis-ransferzentrum I-Projektmanagement, Stuttgart Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 1 Voraussetzung 1: rbeitsstruktur Es muss ein Projekt-Struktur-Plan (kurz: PSP), engl. Work Breakdown Structure (WBS) erarbeitet werden Ziel ist es zu klären: Was ist zu tun? Welche rbeitspakete? ie Erarbeitung der rbeitsstruktur ist die onkretisierung der Frage: Was bedeutet der Projektrauftrag? ies scheint bei allen Vorgehensweisen unstrittig - bei SCRUM entspricht dies z.b. dem Product-Backlog (der Feature-List) Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 2
ufwandsschätzungen - Grundlagen Es gibt zahlreiche Standardschätzverfahren Function-point: Pro ufgabe werden Function-Points vergeben, je Function-point gibt es einen Zeitwert ata-point: uf Basis von atenmodell, atenstrukturen und deren omplexität, je ata-point gibt es einen Zeitwert COCOMO-Verfahren: Mischung von mehreren Faktoren aus Funktionen, atengruppen, Masken, Schnittstellen - auch dies braucht alibrierung lle diese Verfahren benötigen eine Erfahrungsbasis und eine Vergleichbarkeit der Projekte - dies ist oft nur bruchstückhaft gegeben Besser: nalogie-verfahren, auf Basis bisheriger Projekte (siehe oben ) Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 3 ufwandsschätzungen - Grundlagen Wichtigste Grundlage von ufwandsschätzungen sind Erfahrungen... aus der rbeit mit den Werkzeugen... aus rbeiten in anderen Projekten... mit den Prozessen im Unternehmen onkrete Erfahrungen im Umfeld sind viel mehr wert als Standard-Schätzverfahren Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 4
Vorgehen zur ufwandsbestimmung: Schätzklausur Zunächst wird die Struktur der umzusetzenden ufgaben gemeinsam erarbeitet (also der Projekt-Struktur-Plan) am besten als Excel-Liste Zu den ufgabenpaketen sollte im Zweifelsfall in Stichworten beschrieben sein, was dazu gehört ann werden 2 Schätzteams (ggfs. nur aus je 1 Person) gebildet Jedes eam schätzt den zu erwartenden ufwand jedes Paketes und zusätzlich einen Risikofaktor: 10%, wenn einfach 30%, wenn mittel 50%, wenn sehr riskant lle Werte werden in das Excel-Sheet eingetragen, daraus wird der Mindestwert (100%) und der Höchstwert (100+Risikofaktor%) errechnet Mit beiden Werten wird die Summe gebildet Schließlich werden die Schätzungen der beiden eams je Zeile verglichen: ort wo stärkere bweichungen sind, wird diskutiert, warum Schließlich wird der Mittelwert der Höchstwerte sowie die nach iskussion ggfs. korrigierten Schätzwerte genommen. azu kommen möglicherweise Puffer (echnologierisiko) etc. Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 5 Projektbeispiel: + Erfassung von ufwänden Grundregel: Schätzung einzelner ufgaben wo immer möglich unter Einbeziehung des durchführenden Bearbeiters Grund: Erhöht die Identifikation mit den Vorgaben erheblich Realisierung z.b. durch EXCEL-abelle mit hierarchischen Ebenen Vorteil: etails ergänzen, ein- und ausblenden Einfache Handhabung, einfache Verifizierung abellarisch: ufgabe (mit Zusatzspalte: ufg.-beschreibg.), Planstunden, Wochenstunden, Reststunden (die 2 letzten pro Woche) Ist-aten je ufgabe pro Woche, ergänzt um Restzeitschätzung (Verantwortlich: der jeweilige ufgabenverantwortliche) Sichtbar werden Wochenaufwände, Mehraufwände, rends, etc. urch horizontale Hierarchie Ein-Blatt-Übersicht möglich Vorgehen: Start in einer Gruppe, sukzessive Erweiterungen später Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 6
ufgaben und ufwandsplanung - Projektbeispiel Zeitplan / ufwand Projekt X weit. M Übertrag W 14 Projektstufe: - Fertigstellg. urchstich -20.4.01 1 01.4.01 1-6.4.01 Beginn Ende Verant. Plan (20.4.01) Ist Rest bwg. Ist Rest bwg. Ist Rest bwg. Stand: -20.4.01 0 Realisierg. FW-Client 83 83 0 0 0 83 0 37 46 0 1 Realisg. ccess-schicht 487 185 302 0 141 346 0 18 328 0 1.1 nalyse Use Cases 05.02. 06.04. JG - 20 0 20 0 0 20 0 0 20 0 1.2 Vergleich and. System 09.04. 20.04. JG - 10 0 10 0 0 10 0 0 10 0 1.3 Feinkonzept 14.03. 23.05. HR JG 212 100 112 0 64 148 0 18 130 0 1.4 2 P-C emplate 26.02. 30.03. HR JR 77 77 0 0 77 0 0 0 0 0 1.5 Realisierung Version I 23.04. 20.06. HR - 168 8 160 0 0 168 0 0 168 0 1.6 XML-Performance-ests 15.05. 21.05. HR - 0 0 0 0 0 0 0 1.7 Sysdoku 22.05. 29.05. HR - 0 0 0 0 0 0 0 2 Realisg. FW-Server 40 16 24 0 0 40 0 0 40 0 3 nbindung JUN 99 75 24 0 0 99 0 36 63 0 4 Realisg. nwendung 249 3 246 0 0 249 0 0 249 0 5 Entwicklungsumgebung 184 0 184 0 0 184 0 0 184 0 6 Betrieb 263 3 260 0 0 263 0 3 260 0 7 Schulung 144 0 144 0 0 144 0 0 144 0 8 Qualitätssicherung 144 0 144 0 0 144 0 0 144 0 9 oordination 287 40 247 0 0 287 0 9 278 0 10 NN 0 0 0 0 0 0 0 0 0 0 Stand:-20.4.01 Gesamt-Summe 1980 405 1575 0 141 1839 0 103 1736 0 0 0 0 Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 7 Steuerung bei ufwänden (zu einzelnen Projektaufgaben) vgl. Folie zu Risiko bei rbeitspaketen: bschluss zügig herbeiführen urch Änderungsanforderungen entstehen fast immer Mehraufwände, deshalb jede fachliche Änderung, die Zeit benötigt (z.b. mehr als 2 Stunden) über sauberes CR-Verfahren abwickeln. Vorsicht vor vielen kleinen Änderungen!! Grundsätzlich prüfen: Geht es nicht einfacher? Lässt sich etwas abspecken? (=> ESIGN O COS ) Voraussetzung zur Steuerung : Mindestens: Ist-Erfassung der ufwände - besser: Wöchentliche Restzeitschätzungen zu allen offenen ufgaben Wenn ufwände zu einer ufgabe immer größer werden: er PL (und der Mitarbeiter) müssen genau hinschauen, was das eigentliche Problem ist (fachlich unsauber?, technische Mängel?,...) Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 8
ontinuierliches Controlling Erste Regel für Controlling: lle IS-Stunden sauber erfassen lare bgrenzung, was IN das Projekt gehört, was außerhalb liegt Regelungen für llgemein-stunden, Besprechungen, Feste etc. finden Ist-Erfassung ist ufgabe jedes Projektmitarbeiters, PL prüft Vollzug Standard sollte sein: Wochen-Ist-Stunden bis Freitagabend, spät. Montagmittag abliefern (auch im Urlaubsfall!) urch Erfassen des IS-Zustands lässt sich leicht auf die nächste Zukunft schließen Viele Projekte mit schlechten Zahlen haben mangelhafte IS-Erfassung lle für das Projekt geleisteten Stunden sind sofort bekannt zu machen (statt Nachläufern Wochen später, die die zunächst scheinbar gute Bilanz verhageln) lare Regelungen für bgleich zu rbeitszeiterfassung Ideal: Projektstunden + Sonstige Stunden = rbeitszeit afür aber klare efinition für Umgang mit Sonstigen Stunden notwendig Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 9 Steuerung der ufwände über Versionen Voraussetzungen zur Steuerungs-Möglichkeit: ie rbeitspakete für eine Version sind in MUSS-, SOLL- und NN-Funktionen kategorisiert - (MUSS-Funktionen werden für die nächste Version garantiert!) und der nteil der MUSS-Funktionen ist deutlich kleiner als 100% Bei Mehraufwänden ggfs. Verschiebung von SOLL-Funktionen in die nächste Version, BER beachten, welche Funktionen zusammengehören! Mögliche Vereinbarung: er vorgesehene ermin wird auf jeden Fall gehalten, notfalls gibt es Streichungen bei SOLL- und NN-Funktionen in die nächste Version Plan-ufgaben MUSS SOLL NN Plan-apazität Vorgesehene apazität Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 10
Iterative Entwicklung und kleine Wasserfälle Iterat. 1 Iterat. 2 Iterat. 3 Iterat. 4 Iterat. n+1... Iteration 1 Iteration 2 Iteration 3 Iteration n : nalyse : esign : onstruktion : est Entwicklungszeit Vortrag ufwandsschätzung, FG I-PM, 24.10.08 - Folie 11