PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
31
2005
161
GPM Deutsche Gesellschaft für Projektmanagement e. V.3 SpanischesT-Systems-Team eröffneteseinenMitbürgerndas „WorldWideWeb“ Mit„E-Government“-Projektzum„InternationalProjectManagementAward“ OliverSteeger SolcheinWerbespektakelwirdselteneinemIT-Projektzuteil.InTV-Spotsläufteinejunge SpanierinmitwehendemKleiddurcheineAltstadtgasse,lachtundberührtmitdemZeigefingereinenimaginärenTouchscreen.Klick.EbensoeinGeschäftsmannindenbestenJahren,gediegenundtraditionsbewusst.MitdemZeigefingerzumfiktivenTouchscreen.Klick! ImnächstenWerbeclipeinEhepaar,dasseineKindervonderSchuleabholt-undwieder diesesKlicken.Nordspanien,sosollendieWerbespotsmitdem„Klick“andeuten,geht online.UndallenvorandieöffentlicheVerwaltung.E-GovernmentistinKatalonienangesagt.„WoimmerSiesind“,sodieTV-Botschaft,„dieBehördenkommenviaInternetzu Ihnen.“6,1MillionenBürgerkönnendaheimamComputerihreBehördengängeerledigen. Call-CenternehmenAnrufeentgegen.BescheidekommenperSMS.Diesen„großenWurf“ inSachenE-GovernmenthateinProjektteamderdeutschenTelekom-TochterT-Systems Spainermöglicht-unddamitselbstden„InternationalenProjektmanagementAward2004“ gewonnen. J oan Monrabà Vilarrubias aus Barcelona strahlt jene Ruhe aus, die Projektleiter umgibt, wenn sie „alles sicher im Griff“ haben. Diese Contenance (gelegentlich mit smartem Lächeln kombiniert) signalisiert dem Kunden: „Wir packen es.“ Es ist jene Unerschütterlichkeit, mit der man widerstreitende Interessen der Stakeholder zusammenführt, mit der man ein Team motiviert und hinter der Mannschaft steht. Mit der Joan Monrabà Vilarrubias auch die Fragen des Ministerpräsidenten zu dem E-Government-Projekt beantwortete. Und der Ministerpräsident der Region Katalonien besuchte das Projektteam mehr als einmal. Monrabà Vilarrubias ist ein Ruhepol im Zentrum des Projekts. Und diesen Ruhepol hat ein solches Vorhaben wie das Projekt „Open Administration of Catalunia“ nötig. Die in Spitzenzeiten einhundertfünfzig Mitarbeiter um Monrabà Vilarrubias kehren in der öffentlichen Verwaltung das Unterste zuoberst. Punkt eins: Die lokalen und regionalen Verwaltungen der bevölkerungsreichen Region sollen sich dem E-Government öffnen. Will meinen: Bürger sollen via Internet beispielsweise Gebühren und Steuern bezahlen und Sozialleistungen beantragen können. Eine Art regionales Serviceportal fasst unter der Webadresse „www.cat365.net“ die Dienste der einzelnen Verwaltungen zusammen; „one face to the costumer“, würde man in der Wirtschaft sagen. Und dazu noch soll das Portal ein üppiges Info-Angebot zu Arbeitsplatz, Gesundheitswesen, Bildung, Familie, Sport und Kultur bieten. Punkt zwei: Die Politik will die Abläufe in der Verwaltung verbessern und den Bedürfnissen des Informa- JoanMonrabàVilarrubias(rechts)leitetedaspreisgekrönteProjektteam,das mitseinerE-Government-LösungmehrerePreiseeinsammelte.HierimBildmit GPM-VorstandOttoZieglmeier. Foto: OliverSteeger projekt M A N A G E M E NT 1/ 20 0 5 aktuell 4 REPORT Bürger - mit dem Medium Internet vertraut machen. Im Wissen liegt die Zukunft, und der Weg zu diesem Wissen führt (auch) übers Internet. MitE-GovernmentzurInformationsgesellschaft Das alles hieß mehr, als nur eine Homepage für Verwaltung zu erarbeiten. Der „große Wurf“ war gefragt. Letztlich ein solcher Wurf schwebte 1998 dem Parlament Kataloniens vor, als es sich darauf verständigte, die „Informationsgesellschaft“ zu fördern. Derlei hoch gesteckte politische Ziele und Erwartungen sind für Projektteams eine Risikoanleihe. Misslingt ein solches Projekt, ist der Schaden groß; da wird mehr als nur der Vorwurf laut, das Projektteam habe sich nicht eben mit Ruhm bekleckert. Es geht letztlich um Ansehen und Image der IT-Branche und auch des Projektmanagements. „Der empfindlichste Faktor der Regierungsarbeit steht auf dem Spiel, nämlich die Beziehung zu unseren Bürgern“, mahnte Kataloniens Verwaltungsminister Antoni Vives zum Projektstart. Scheitere dieser erste Schritt in die neue „e-world“, sei dies eine schwere Hypothek für alle weiteren Projekte. „Wir müssen sichergehen, dass wir alles richtig machen.“ Also umsichtig vorgehen. Und auf höchste Qualität beim Projektmanagement setzen. Das gemeinsame Team der „Generalitat de Catalunya“ (autonome Regierung Katalonien) und T-Systems Spain machte sich mit Willen zur Spitzenleistung ans Werk; mit im Boot waren Experten des weltweit tätigen Beratungsunternehmens Accenture sowie von Microsoft. Der Erfolg der konzertierten Aktion zeichnet sich immer mehr ab: Schon heute, ein Jahr nach Projektende, gilt das spanische E-Government als beispielhaft für die EU. Politiker und Verwaltungsspezialisten anderer Regionen kommen und studieren das Barcelonaer Exempel. Beim „e-Europe Award for e-government“ der EU gehörte Kataloniens Bürgerportal zu den „Top Five“ unter 110 Bewerbern. „PDCA-Modell“fürmehrFreiheitundVerantwortung Weitere Lorbeeren für das Team gab es im Juni dieses Jahres in Budapest. Diesmal aber ging es um das Thema E-Government nur am Rande; im Rampenlicht des „18. IPMA World Congress on Project Management“ standen die Projektmanagement-Leistungen. In der deutschen Konzernzentrale löste die Erfolgsnachricht Begeisterung aus. „T-Systems hat sich mit seinem Projektmanagement dem internationalen Vergleich gestellt“, freute sich tionszeitalters anpassen. Die Mitarbeiter sollen sich auf die neuen Kommunikations-Kanäle vorbereiten. Es nutzt wenig, wenn die Bürger auf der Datenautobahn mit der Verwaltung in Verbindung treten - und die Anfragen, Anträge und Bescheide dort im „Off“ der Bürokratie verschwinden. Mausklick statt Behördenstempel gewissermaßen, ein Bruch mit der Tradition. In der Tat gelang dem Team auch behutsam diese kleine Reform. „Unser Projekt war auch ein systematischer Prozess, die Dienstleistungen der Verwaltung zu überprüfen und zu verbessern“, berichtet Monrabà Vilarrubias. Und da gibt es noch Punkt drei, den Wunsch der Politiker: Das Projekt soll der gesamten Gesellschaft einen Impuls geben, sich dem Informationszeitalter zu öffnen. Politik und Verwaltung wollen mit gutem Beispiel vorangehen und ein Signal geben. Es soll „New-Economy“- Unternehmen in die Region holen und die Wirtschaft stimulieren. Es soll Kinder und Jugendliche - eigentlich alle Dr.StephanWitteler,MitglieddesExecutiveBoardvon T-Systems,unterstrichdieBedeutungdesAward-Gewinns fürseinUnternehmen. Foto: T-Systems ❏ Weichenstellung für die Zukunft der katalonischen Verwaltung und ihres Services für 6,1 Millionen Bürger ❏ Hohe Motivation und Begeisterung aller Beteiligten für das Projekt ❏ Förderung aller Mitarbeiter mit dem Ziel einer „winwin“-Situation ❏ Ständige Verbesserung des Projektmanagements nach dem Modell „Project Excellence“ ❏ Flache Hierarchien, Delegation von Verantwortung an Mitarbeiter nach dem „PDCA-Modell“ ❏ Systematische Einbindung aller Stakeholder ❏ Aktive Teilnahme der Katalonischen Regierung am Projektgeschehen ❏ Aufwendige Öffentlichkeitsarbeit und Promotion für das Projekt ❏ Bedeutendes Referenzmodell für E-Government und Organisationsentwicklung im öffentlichen Bereich SchlaglichterdespreisgekröntenProjekts aktuell projekt M A N A G E M E NT 1/ 20 0 5 5 Dr. Stephan Witteler, Mitglied des Executive Board von T- Systems, „mit dieser Auszeichnung sind uns nun von unabhängiger Seite Spitzenleistungen bestätigt worden.“ Monrabà Vilarrubias nahm die Trophäe mit zu seinem Team nach Barcelona. Und diesem Team gönnte die Award-Jury den Erfolg von Herzen. „Hier ist es gelungen, die Begeisterung für Projektmanagement auf den Kunden zu übertragen“, berichtet GPM-Vorstand Dr. Thor Möller, seinerzeit Leiter des für dieses Projekt zuständigen Assessorenteams, „die konsequente Integration des Auftraggebers und der Endkunden haben dieses Projekt zu einem besonderen Erfolg wachsen lassen.“ Vor allem: Die Motivation des spanischen Teams beschrieben die Juroren schlichtweg als „enthusiastisch“. Man war beeindruckt. Was war geschehen? Natürlich reizt es IT-Spezialisten ungemein, in einem Team unter den Augen von Politikern, Medienleuten und der Öffentlichkeit eine Softwarelösung zu erarbeiten, mit der jeder Bürger in Berührung kommen soll. Doch da war mehr. Projektleiter Monrabà Vilarrubias hatte mit zwar einfachen, doch geschickten und hochwirksamen Strategien die Begeisterung seiner Mitarbeiter geweckt. Zum einen gab er ihnen Gelegenheit, ihre Fähigkeiten optimal zu entfalten. Zum anderen übertrug er ihnen vorbildlich Verantwortung. Genauer: Mitarbeiter laufen dann zur Hochform auf, wenn sie ihr Know-how und ihre Talente entfalten und damit dem Projekt nutzen können. Das gehört zum kleinen Einmaleins des Projektmanagement-Wissens. Einmal mehr motiviert es, wenn die Ziele des Projekts mit den eigenen - fachlichen oder beruflichen - Zielen übereinstimmen. So legte das Team Wert auf Personalarbeit. „Wir haben die Bedürfnisse und Ziele jedes Einzelnen mit den Erfordernissen und Zielen des ganzen Projekts harmonisiert“, beschreibt der Projektleiter die „Personalpolitik“. Will meinen: Das Projekt gewann - und die Mitarbeiter profitierten ebenfalls. Ebenso gehört es zum kleinen Einmaleins des Projektmanagements, dass Verantwortung und Entscheidungsfreiheit einem Team Flügel verleihen. Folglich wurde das Team in vier Bereiche gegliedert; jeder Bereich konnte eigenverantwortlich über seine Ressourcen verfügen und selbstständig handeln. Einzige Bedingungen: Sie hatten nach dem PDCA-Modell zu verfahren, dem Rahmen für eigenverantwortliches Tun. VerantwortungundEntscheidungsfreiheitverleihen einemTeamFlügel „P“ steht dabei für „Plan“: ein Problem oder eine Chance erkennen und beschreiben, die Lage und das Problem studieren, über Ursachen und mögliche Lösungen nachdenken („brainstorm“), kreativ Lösungsschritte und bestmögliche Korrektur erörtern; einen Lösungsplan entwickeln. „D“ für „Do“: die Maßnahme umsetzen, das Vorgehen und die Beobachtungen dokumentieren; Daten nutzen, um Informationen zu sammeln. „C“ für „Check“: Informationen und Trends analysieren; Vergleich der Ergebnisse mit den Erwartungen. „A“ für „Act“: Klappt alles, ist’s in Ordnung. Entsprechen die Ergebnisse nicht den Erwartungen, nochmals die Schritte Plan, Do und Check durchgehen und den Prozess sowie den revidierten Plan dokumentieren. Erfreulicher Nebeneffekt, wenn einem Team mit dem PDCA-Modell Freiheiten gegeben werden: Der Kunde arbeitet mit solchen Mitarbeitern zusammen, die auf seine Anfrage hin Entscheidungen treffen können. „Für unsere Kunden war jederzeit ein kompetenter Mitarbeiter in jedem Bereich erreichbar“, erklärt der Projektleiter, „ich habe unabhängiges Handeln in meinem Team gewünscht und gefördert.“ Eine simple, doch bestechende Anleitung. Das PDCA- Modell, so beobachtete das Team, machte Schule und wurde seitens der Projektpartner übernommen. Es hat sich in der öffentlichen Verwaltung verbreitet. Dieser Effekt gilt heute als ein „Nebenerfolg“ des Projekts. Vor allem: Das Modell ermöglichte schnelle Abhilfe bei überraschenden Problemen. „Es nahm dem Projektmanagement eine große Bürde ab“, berichtet Monrabà Vilarrubias. Er konnte sich ganz auf die Koordination des Vorhabens konzentrieren und verzettelte sich nicht im Tagesgeschäft. EinProjektmitBreitenwirkung: MehralssechsMillionenBürgerrundumdie MetropoleBarcelonaprofitierenvonderArbeitdesProjektteams. Foto: OliverSteeger projekt M A N A G E M E NT 1/ 20 0 5 aktuell 6 REPORT Jährlich„taktischeStudie“fürStakeholder Solche Koordinierung tut in einem Projekt Not, das das öffentliche Leben in Bewegung bringen soll und gewissermaßen eine breite Mission zu erfüllen hat. Mit einem entsprechend breiten Geflecht von Gremien und Kompetenzzentren suchte der Projektleiter Rückendeckung und Unterstützung. Dem Projekt stand ein Lenkungsausschuss vor; ihm an die Seite gestellt waren zwei zusätzliche Gremien: Zum einen kam das „Director Committee“ zusammen, um die Projektziele zu überprüfen, um bereichsübergreifende Aktionen zu koordinieren und Konflikte zu schlichten. Zum anderen wurde ein „Technical committee“ eingerichtet mit der Aufgabe, den Fortschritt der einzelnen Arbeiten zu verfolgen. Skeptiker überzeugen und zu Freunden machen und diese Freunde als Promotoren gewinnen - so lautete die Devise. „Beispielsweise haben wir Grundbuchämter, Finanzämter sowie Verbände der Mediziner und Rechtsanwälte in den Lenkungsausschuss einbezogen“, erläutert der Projektleiter. Für seine Stakeholder gab das Team jährlich eine „Taktische Studie“ heraus. Dort skizzierte das Team Ziele und Rahmen des Vorhabens; die Stakeholder revidierten die Studie. Eine Sammlung von Wünschen und Erfordernissen wuchs heran. „Dieser ständig aktualisierte, systematische Katalog unterschiedlicher Interessen sicherte dem Projekt breite Akzeptanz“, berichten die Spanier. Und die 6,1 Millionen Bürger selbst, also die künftigen Nutzer der „Open Administration of Catalonia“? „Die Bürger haben wir nicht nur als Hauptkunden unseres Projektes betrachtet, sondern gewissermaßen als Fundament“, sagt Monrabà Vilarrubias. Bedeutsam sei gewesen, das Projekt offensiv zu vermarkten. Die sympathischen, aus dem Leben gegriffenen TV-Spots waren nur Teil der Kampagne. Öffentlichkeitsarbeit und Werbung griffen ineinander. Mit„ProjectExcellence“zurSpitzenleistung Wer Spitzenprojekte studiert, wird häufig auf einfache Strategien und Mittel stoßen. Das „Erfolgsgeheimnis“ für exzellente Projekte besteht indes darin, diese Strategien zielstrebig zu nutzen und in möglichst vielen Bereichen hervorragendes Projektmanagement zu erzielen. Der Erfolg ist die Summe vieler einzelner Maßnahmen, die Projektqualität zu verbessern. In diesem Punkt überließ das spanische Projektteam nichts dem Zufall. Es VorstoßindasE-Government: IndervitalenStadtBarcelonabegegnensichModerneundTradition. Foto: OliverSteeger Mit dem Projekt „Open Administration Catalunya“ hat das Team der T-Systems Leistungen bewiesen, die international Vorbildfunktion für das Benchmarking vieler Projekt-Teams haben werden. Ich hebe folgende Punkte als Beispiele hervor: Das Team hat die Anforderungen der beteiligten Interessengruppen beispielhaft entwickelt. Die Zufriedenheit der verschiedenen Kunden wurde kontinuierlich erhoben; sie fand als Steuergröße im Projekt Berücksichtigung. Die Mitarbeiter identifizierten sich in hohem Maße mit dem Projekt und brachten Ideen und Anregungen ein. Ihr Potential wurde zudem fortlaufend weiterentwickelt. All dies trug dazu bei, die Projektziele in vollem Umfang zu erreichen. Die ermittelte Kundenzufriedenheit bei den direkten und indirekten Indikatoren stieg auf Spitzenwerte. Diese Ergebnisse sind keine Zufallswerte; sie sind eindeutig auf die Vorgehensweise beim Projektmanagement zurückführbar. OttoZieglmeier,IPMAVice-President T-Systems-ProjektmitweltweiterVorbildfunktion aktuell projekt M A N A G E M E NT 1/ 20 0 5 7 PROMON(ProjectMonitoring)nenntsichdieMethode,mitderbeiT-SystemsProjekteüberwachtundgesteuertwerden. projekt M A N A G E M E NT 1/ 20 0 5 aktuell 8 REPORT spürte mit System die Möglichkeiten auf, besser zu werden. Schon vor der Bewerbung um den Projektmanagement-Award nahm das Team das „Project Excellence“- Modell zur Hand, das dem Wettbewerb um den Projektmanagement Award zugrunde liegt. Nach diesem Modell werden Punkt für Punkt die Leistungen eines Projektteams gemessen. Jeder Bereich, der für erfolgreiches Projektmanagement bedeutsam ist, wird geprüft und in gewisser Weise abgetastet. Insgesamt neun Kriterien mit vielen Unterkriterien umfasst das Modell. Unter diesen neun Kriterien finden sich fünf Kriterien für das Projektmanagement und vier Kriterien für die Projektergebnisse. Kriterien für das Projektmanagement sind: Zielorientierung, Führung, Mitarbeiter, Ressourcen und Prozesse. Die Kriterien für die Projektergebnisse: Kundenzufriedenheit, Mitarbeiterzufriedenheit, Zufriedenheit bei sonstigen Interessengruppen sowie die Zielerreichung. T-SystemsgiltalsSpitzenkönnerinpuncto Projektmanagement Das spanische Team entwickelte für jedes dieser Kriterien einen eigenen Kreislauf ständigen Verbesserns. Hier setzte das Team das PDCA-Modell ein, den Kreislauf aus Analyse, Planung, Umsetzung und Kontrolle. In einfachen Worten: „Was können wir besser machen? Wie können wir es besser machen? Dann lass es uns tun - und danach prüfen, wie es gelungen ist.“ Joan Monrabà Vilarrubias: „Das ständige Optimieren war eine Aufgabe für alle.“ So habe das Team nahezu wöchentlich seine Potentiale geprüft. ToolboxfürProjektleiter Dieses konsequente Bemühen zeichnet die in zwanzig Ländern tätige T-Systems (43.500 Mitarbeiter, 11.900 Millionen Euro Umsatz) aus. Der Konzern gilt als Spitzenkönner in puncto Projektmanagement. Bei solch anspruchsvollen Aufgaben erhalten Projektleiter von T-Systems innerhalb ihres Konzerns breite Unterstützung. Sie greifen auf eine „Toolbox“ zu, eine Art Werkzeugkasten, der neben dem Methoden-Rahmen Checklisten, Dokumentvorlagen, Richtlinien, Beispiele und Hintergrundinformationen umfasst. Mit dieser „Box“ verlinkt der Konzern weltweit laufende und zurückliegende Projekte. „Jedem steht es frei, eigene Dokumente beizusteuern und die Toolbox mitzuentwickeln“, erläutert Monrabà Vilarrubias, „auf diesem Weg werden Erfahrung und Wissen weltweit geteilt und ausgetauscht.“ Die Mühe und das Zutun jedes Einzelnen lohnen sich. Fast jährlich stehen T-Systems-Projekte im Finale um den internationalen oder deutschen Projektmanagement-Award. Das Team aus Barcelona ließ die Erfolgsserie nicht abreißen. ■ Der„Generalplan“gibtÜberblicküberdieAbhängigkeitenderProjektphasenmitausgewähltenMeilensteinen. aktuell projekt M A N A G E M E NT 1/ 20 0 5 9 „WirwollteneinSchätztool, dasdieKunden-Lieferanten- Zusammenarbeitunterstützt” Software-Projektmanagement-PionierBarryW.BoehmüberseinCOCOMO-Modell SiegfriedSeibert FasttäglichhörenwirMeldungenüberProjekte,beidenenKostenundTerminenicht eingehaltenwerden.MehralsdieHälftederSoftwareprojekteüberschreitetihreTermine undihreKostenummehrals50%.AuchwenneinzelnedieserÜberschreitungennicht vorhersehbarsind,sokönnendochdiemeistenFehleinschätzungendurchfundierteSchätzmethodenvermiedenwerden.EinesderbekanntestenModellezurSchätzungderKosten vonSoftwareprojektenistCOCOMO(„COnstructiveCOstMOdel“).EswirdvonTausenden vonProjektmanagernweltweiteingesetzt,umdieKosten-undTerminsituationvonSoftwareprojektenzuanalysieren.EntwickeltundvorangetriebenwurdeCOCOMOvonProfessorBarryW.Boehm,einemdereinflussreichstenundamhäufigstenzitiertenFachleuteim Software-Projektmanagement.projektMANAGEMENTaktuellsprachmitBarryBoehmüber denNutzendesCOCOMO-Modells,überdessenProblembereicheundüberdiezukünftige Weiterentwicklung. C OCOMO ist ein Modell, mit dem Kosten, Aufwand und Termine von Softwareprojekten geschätzt werden können. Im Gegensatz zu anderen Kostenschätzsystemen ist COCOMO ein „offenes“ Modell, für das alle Einzelheiten veröffentlicht wurden, einschließlich der zugrunde liegenden Schätzgleichungen und jeder Annahme und jeder Definition, die den Gleichungen zugrunde liegen. Das Modell beruht auf der Auswertung von rund 250 Projekten in mehreren bekannten amerikanischen Unternehmen. Weil COCOMO genau spezifiziert ist und weil es nicht auf geheim gehaltenen Algorithmen beruht, weist es für seine Benutzer folgende Vorteile auf: ❏ COCOMO-Schätzungen sind objektiver und nachvollziehbarer als Schätzungen, die auf intuitiven Methoden oder auf (teureren) geschützten Modellen beruhen. ❏ Die COCOMO-Gleichungen können an die speziellen organisatorischen Randbedingungen eines Unternehmens angepasst (kalibriert) werden, um genauere Schätzungen zu ermöglichen. ❏ COCOMO ist bei kleinen Projekten einfach anwendbar, gleichzeitig aber mächtig genug, um damit auch sehr große Projekte zu planen und zu steuern. ❏ COCOMO kann bereits zu frühen Zeitpunkten eingesetzt werden, wenn noch kein abgesicherter Projektstrukturplan für eine detailliertere Projektkalkulation vorliegt. Wegen dieser Vorteile ist COCOMO heute das bekannteste Softwarekostenschätzmodell weltweit. Es wurde von Boehm erstmals 1981 veröffentlicht. Damals war es eine kleine Sensation in der IT-Industrie. Seither haben sich die Softwareentwicklungsmethoden allerdings dramatisch verändert. Um diesem Wandel Rechnung zu tragen, wurde im Jahr 2000 ein komplett überarbeitetes und zukunftsweisendes Modell COCOMO II veröffentlicht. Herr Boehm, was waren Ihre wichtigsten Ziele, als Sie COCOMO entwickelten? Wir entwickelten COCOMO bei meinem damaligen Arbeitgeber TRW in den späten 70er Jahren, um bessere und realistischere Schätzungen für unsere Softwareprojekte zu erhalten. Außerdem wollten wir die Wirtschaftlichkeit der Softwareentwicklung erhöhen. Als eine der größten Softwareorganisationen arbeitete TRW damals bereits mit vielen externen Unternehmen zusammen. Ein wichtiges Ziel dabei war, mit einem solchen Modell die Zusammenarbeit von Kunden und Lieferanten zu unterstützen. Jede der beteiligten Parteien sollte das gleiche Tool zur Verfügung haben, um den Projektaufwand zu schätzen und zu analysieren, insbesondere bei der Diskussion und Verhandlung von Änderungsanträgen. Und dieses Ziel wurde erreicht? COCOMO war ein großer Erfolg. Viele Unternehmen in der ganzen Welt benutzen es und entwickelten eigene Anpassungen wie Ada COCOMO (US-Verteidigungsministerium), REVIC (Revised COCOMO), Incremental COCOMO oder SICOMO (Siemens). In jüngster Vergangenheit kamen zusätzliche Impulse für die systematische Kostenschätzung aus den Anforderungen des Capability Maturity Models CMMI. Stufe 3 dieses Modells erfordert, dass die betreffende Organisation systematische Kostenschätzungen auf Basis quantitativer Erfahrungsdaten durchführt. projekt M A N A G E M E NT 1/ 20 0 5 aktuell 10 REPORT Können Sie uns interessante Projekte nennen, in denen COCOMO erfolgreich eingesetzt wurde? Ja, davon gibt es eine ganze Reihe. Beispielsweise hatten die US Air Force und das Unternehmen General Dynamics (heute Lockheed Martin) lange Zeit Probleme, den Leistungsumfang neuer Software Releases für das Kampfflugzeug F-16 festzulegen. Jedes Jahr forderten Piloten, Betriebs- und Wartungspersonal viel mehr Verbesserungen, als mit dem vorhandenen Budget und Personal machbar waren. Irgendwann wurde es dem Einkaufsmanager der Air Force zu bunt und er lud die Verhandlungspartner von General Dynamics zu sich nach Hause ein. Dort sollten beide Seiten eine realistische Schätzung für den Änderungs- und Weiterentwicklungsumfang des nächsten Jahres erarbeiten. Wie bei der Papstwahl durften die Beteiligten das Haus nicht verlassen, bevor die gemeinsame Schätzung unter Dach und Fach war. Dazu benutzten sie das COCOMO-Modell. Es dauerte zwei Tage, bis sie zu einer übereinstimmenden Beurteilung kamen. Aber die erwies sich als außerordentlich realitätsnah und robust. Das Verfahren wenden sie nun schon seit mehr als zehn Jahren an, um die im nächsten Jahr zu realisierenden, neuen Anforderungen zu verhandeln. COCOMO scheint demnach besonders nützlich bei Projekten für öffentliche Auftraggeber? Nicht allein. Vor kurzem hatten wir ein Projekt, bei dem eine Bank versuchte, ihre Softwareentwicklungsproduktivität zu steigern. Der Chief Information Officer (CIO) war der Meinung, dass er mit einem einzigen linearen Prozentsatz das Produktivitätsverbesserungspotenzial und die erreichbaren Einsparungen abschätzen könne. Mit Hilfe des COCOMO-Modells zeigten wir ihm, dass Produktivitätsverbesserungen von den Anforderungen und Randbedingungen in jedem einzelnen Projekt abhängen. Wenn Mitarbeiter komplexere Software oder Software mit sehr hohen Echtzeitanforderungen entwickeln, produzieren sie weitaus weniger Befehlszeilen pro Personenmonat als bei kaufmännischen Anwendungen. Statt einfacher Produktivitätsprozentsätze wurden die Kostentreiber jedes einzelnen Projekts mit COCOMO geschätzt. Diese wurden dann als Basis für Programm- und Multiprojektschätzungen und -vergleiche genutzt. Mit diesen Schätzwerten kommt die Bank sehr gut voran. Wird COCOMO auch in kleineren Unternehmen für kleinere Projekte genutzt? COCOMO wird hauptsächlich in größeren Unternehmen der Luft- und Raumfahrt, der Telekommunikation, des Automobilbereiches sowie im öffentlichen und im Verteidigungssektor eingesetzt. In kleineren Unternehmen ist es nicht so stark verbreitet. Welche Arten von Schätzungen kommen in kleineren Unternehmen zum Einsatz? Meistens irgendwelche Analogieschlüsse. Die Schätzer fragen sich dann: Wie haben wir es letztes Mal gemacht, und welchen Aufwand haben wir dafür benötigt? Wenn Unterschiede zwischen dem früheren und dem neuen Projekt bestehen, werden entsprechende Zu- und Abschläge gemacht. InjüngsterVergangenheitkamenzusätzlicheImpulse fürdiesystematischeKostenschätzungausden AnforderungendesCapabilityMaturityModellsCMMI Kann ein parametrisches System wie COCOMO auch bei solchen Analogieschätzungen helfen? Ja, alle COCOMO-Kostentreiber können als Analogierelationen dienen, um die Auswirkungen geänderter Foto: UniversityofSouthernCalifornia Seitknapp50JahrenhatProfessorDr.BarryW.Boehmals Wissenschaftler,ManagerundHochschullehrergearbeitet. Inden60erJahrenwarerLeiterdesInformationSciences DepartmentderRandCorporation,eines„ThinkTanks“ derUS-Regierung.Inden70erund80erJahrenwarer ChefwissenschaftlerderDefenseSystemsGroupbeiTRW, einemkalifornischenAutomotive-undIT-Unternehmen. SpäterarbeiteteeralsDirektordesInformationSciences andTechnologyOfficeimUS-Verteidigungsministerium. Seit1993isterProfessorfürSoftwareEngineeringund DirektordesZentrumsfürSoftwareEngineeringander UniversityofSouthernCalifornia(USC).ErhatimBeirat mehrererwissenschaftlicherMagazinesowieinvielenBeratungsgremienundKomiteesmitgewirktundeinegroße ZahlnationalerundinternationalerEhrungenundAuszeichnungenerhalten.BoehmhatdasSoftwareEngineering undManagementmaßgeblichbeeinflusstundgestaltet.Er warderErste,derinden60erJahrendieSoftwarealsden HauptkostenfaktorzukünftigerComputersystemeidentifizierte.ErentwickeltedasCOCOMO-Kostenschätzmodell.Er istErfinderdesSpiralmodellsfürrisikogetriebene,iterative Softwareprojekte,dasspäteralsGrundlagefürdenRationalUnifiedProcessRUPdienteunddiederzeitintensiv diskutiertenagilenProjektmodellebeeinflusste.Under entwickeltebereitsvormehrals15Jahrenden„Win-win- Approach“,mitdemdiesystematischeStakeholderanalyse inSoftwareprojekteintegriertwurde. aktuell projekt M A N A G E M E NT 1/ 20 0 5 11 Projektrandbedingungen abzuschätzen. Wir hatten einmal sogar ein Computertool entwickelt, mit dem COCOMO für Analogieschätzungen eingesetzt werden konnte. Im Sommer 2000 haben Sie ein komplett erneuertes COCOMO II veröffentlicht. Was wollten Sie damit erreichen? Bereits seit Anfang der 90er Jahre hatte die 1981er-Version von COCOMO zunehmend Probleme, mit einer Reihe neuer Entwicklungen in Softwareprojekten Schritt zu halten. COCOMO 81 beruhte auf Befehlszeilen (Source Lines of Code SLOC). Aber vielen Leuten fällt es schwer, den Umfang der Befehlszeilen für ein neues Projekt zu schätzen. Anwenderbezogene Schätzgrößen, wie die Funktionspunkte, gewannen an Bedeutung und wurden immer besser standardisiert. Für bestimmte Aufgaben, wie den Entwurf grafischer Benutzeroberflächen, waren Befehlszeilen sogar mehr oder weniger irrelevant. Die Entwicklungsprozesse in Projekten änderten sich. Das ursprüngliche COCOMO funktionierte sehr gut mit Wasserfallprozessen. Im Spiralmodell, im Rational Unified Process und in ähnlichen iterativen Projektabläufen werden die Meilensteine und die Projektendpunkte aber anders gesetzt. COCOMO 81 war darauf nicht ausgerichtet. Außerdem gab es ganz neue Kostentreiber, wie die Entwicklungsprozessreife, neue Erkenntnisse zur Software-Wiederverwendung und Ähnliches mehr. Mit COCOMO II wollten wir ein Schätzmodell schaffen, das stärker auf die Anforderungen moderner Projekte ausgerichtet ist als auf die Randbedingungen der Vergangenheit. Sind die Funktionspunkte damit zur wichtigsten Messgröße für den Umfang von Softwareprojekten geworden? Funktionspunkte sind die wichtigste Messgröße im Bereich von Geschäftsanwendungen und Informationssystemen. Bei wissenschaftlichen Systemen und Echtzeitsystemen messen Funktionspunkte das, was sich innerhalb der Software abspielt, nicht besonders gut. Außerdem sind Funktionspunkte abgeschlossener Projekte bisher nur aufwändig „von Hand“ zu zählen. Wir experimentieren daher auch mit anderen Größenmaßen, wie den Konstrukten der Unified Modelling Language UML. Diese Größen, beispielsweise die Anzahl der Use Cases, der Klassen und Objekte einer Anwendung, sind mit den Funktionspunkten verwandt, können aber automatisch gezählt werden. Kann man das bereits praktisch einsetzen? Wir arbeiten darauf hin, haben aber ähnliche Hürden zu überwinden, wie sie die Funktionspunktleute früher hatten. Jeder hat eine andere Vorstellung, was ein Use Case genau ist oder was eine Aktionsfolge ist. Was wir dringend benötigen, sind allgemein akzeptierte Standards zur Definition planungsbasierter und entwurfsbasierter Use Cases. Wenn man mehrere Projekte vergleicht, haben diese oft unterschiedliche Detaillierungsgrade in ihren Planungsdokumenten. Nicht selten nimmt dann die Anzahl der Use Cases zu, ohne dass sich am Umfang der Anwendung wirklich etwas geändert hat. In einem Forschungsprojekt haben wir zwischen der Anzahl der Use Cases und der Anzahl der Befehlszeilen lediglich Korrelationskoeffizienten von 0,4 bis 0,5 gemes- Mitmehrals4.200EinheitenistdieF-16dasweltweitamweitestenverbreiteteMehrzweck-Kampfflugzeug.Software-ÄnderungenwerdendortseitvielenJahrenerfolgreichmitdemCOCOMO-Modell geschätzt.DerSystemumfangistdabeiexponenziellangestiegen: DerKernspeicherderneuesten F-16-Generationist2.000-malsogroßundderDurchsatz260-malsohochwieindererstenF-16-VersionimJahr1978. Foto: LockheedMartin Anzeige projekt M A N A G E M E NT 1/ 20 0 5 aktuell 12 REPORT sen, nicht die wünschenswerten 0,8 oder 0,9. Wir müssen noch andere Faktoren finden, mit denen eindeutiger bestimmt werden kann, ob ein einfacher oder ein komplexer Use Case vorliegt. In COCOMO II und fast allen anderen parametrischen Schätzsystemen werden die Funktionspunkte mit Hilfe des so genannten „Backfiring“ in Befehlszeilen umgerechnet. Allerdings weisen die Backfiring-Multiplikatoren für die jeweilige Programmiersprache sehr hohe Schwankungsbreiten auf. Wird dadurch das gesamte Schätzverfahren nicht sehr ungenau? Wenn man mit Funktionspunktzählungen neu beginnt, bleibt einem nichts anderes übrig. Die Vertreter der Funktionspunktmethode sagen selbst, dass mit Funktionspunkten die Produktivitätssteigerungen höherer Programmiersprachen besser verdeutlicht werden können. Schätzformeln, die den Projektaufwand direkt aus den Funktionspunkten ableiten, funktionieren daher aber auch nur dann, wenn sie zumindest die Generation der verwendeten Programmiersprache berücksichtigen. Die Umrechnungstabellen zum Backfiring sind nicht perfekt, aber sie sind besser als gar nichts. Sicher wäre es gut, noch detailliertere Umrechnungsfaktoren von Funktionspunkten in Befehlszeilen zu haben, die nicht nur die Programmiersprache, sondern auch die Art der Anwendung berücksichtigen. Wenn solche Werte empirisch erhoben würden, wäre die Umrechnung weitaus genauer. Heute nutzen fast alle Softwareschätzsysteme Backfiringtabellen, die ursprünglich von Capers Jones auf Basis des Function-Point-Standards IFPUG 3 (International Function Point User Group) erhoben wurden. Gibt es keine neueren Tabellen für die heutigen Standards der IFPUG-4-Generation? Die David Consulting Group hat vor kurzem neue Umrechnungsfaktoren ermittelt, die rund 60 % höher sind als die Faktoren von Capers Jones. In unserem automatisierten COCOMO-Tool haben wir jetzt die Option eingerichtet, entweder mit den älteren oder mit den neueren Faktoren zu rechnen. Aber bei dieser großen Differenz: Welcher dieser beiden Umrechnungssätze ist denn nun der bessere? Wir bewegen uns hier noch auf unsicherem Boden. Wir hätten auch gern besser abgesicherte Zahlen und haben dazu schon eine Reihe von Workshops durchgeführt. Aber bisher haben wir noch nicht genügend eigene Daten für eine gesicherte Aussage. UmeineErfahrungsdatenbasisfürProjektkostenschätzungenschrittweiseaufzubauen,kannmanmit einfachenNäherungsbetrachtungenbeginnen Auch die meisten Unternehmen haben keine eigene Datenbasis mit Termin-, Aufwands- und Kostentreiberdaten früherer Projekte, die für die Kalibrierung der Schätzgleichungen benötigt wird. Was können diese Firmen tun? Man kann mit Näherungsbetrachtungen beginnen, um eine solche Datenbasis schrittweise aufzubauen. Normalerweise kennt man die durchschnittliche Teamgröße und das Start- und das Abschlussdatum der Projekte. Daraus kann man näherungsweise die Laufzeit und die Personenmonate ableiten. Das ist nicht perfekt, aber ein Beginn. Man kann automatische Zähltools verwenden, um die Anzahl der Befehlszeilen des Systems und der Systemmodule zu ermitteln. Und man kann das Projektkernteam interviewen, um Aussagen zu den Kostentreibern zu erhalten, insbesondere um die Kostentreiber zu identifizieren, die außerhalb des Normalbereichs lagen. Welche neueren Entwicklungen sehen Sie, die für die weitere Entwicklung von Kostenschätzmethoden und von COCOMO II wichtig sind? Function Point Analyse Function Point- Umrechnung („Backfiring“) Funktionenzählung, Modulstruktur Befehlszeilenmultiplikatoren Bewertungsregeln Programmiersprache Befehlszeilen Function Points COCOMO II Gleichungen Koeffizienten, Multiplikatoren Kostentreiber, Wiederverwendung, Tech. Änderungen Projektaufwand und -dauer, Termine, Phasen- und Aktivitätenverteilung, Projekt- und Arbeitspaketpläne Projektplanungstools (z. B. MS Project, Excel) Aktivitäten, Phasen, Aufwand, Dauer Function Point Analyse Function-Point- Umrechnung („Backfiring“) Funktionenzählung, Modulstruktur Befehlszeilenmultiplikatoren Bewertungsregeln Programmiersprache Befehlszeilen Function Points COCOMO II Gleichungen Koeffizienten, Multiplikatoren Kostentreiber, Wiederverwendung, Tech. Änderungen Projektaufwand und -dauer, Termine, Phasen- und Aktivitätenverteilung, Projekt- und Arbeitspaketpläne Projektplanungstools (z. B. MS Project, Excel) Aktivitäten, Phasen, Aufwand, Dauer StrukturdesCOCOMO-Modells Grafik: SiegfriedSeibert aktuell projekt M A N A G E M E NT 1/ 20 0 5 13 Wir entwickeln COCOMO II laufend weiter, um mit dem Modell auch die Schätzanforderungen der kommenden Jahre und Jahrzehnte bearbeiten zu können. Hierzu wurden eine Reihe von Zusatzmodulen für spezielle Anwendungen und Projektrandbedingungen entwickelt. Beispielsweise gehört dazu das Modell COCOTS, mit dem die Kosten der Evaluation, der betriebsspezifischen Anpassung und Integration bei der Anschaffung von Standardsoftware (COTS: Commercial of the Shelf) geschätzt werden können. In COCOMO II war dieser Projekttyp nicht gut genug abgebildet. Das Modell CO- RADMO ist auf schnell abzuwickelnde RAD-Projekte (Rapid Application Development) ausgerichtet. Die Teamstärke ist in solchen Projekten ganz anders als in Projekten, bei denen mehr Wert auf die Optimierung von Aufwand und Kosten gelegt wird. COCOMO und die meisten anderen Kostenschätzmodelle gehen standardmäßig davon aus, dass die Projektdauer (in Monaten) bei ungefähr dem dreifachen Wert der Kubikwurzel des Aufwands (in Personenmonaten) liegt. Bei RAD-Projekten liegt die Projektdauer eher bei der Quadratwurzel des Projektaufwands. Ein Projekt mit 25 Personenmonaten Aufwand benötigt dann als RAD-Projekt fünf Monate lang ein Team von fünf Leuten. Als „Normalprojekt“ würden wir nur drei Leute einplanen, dies allerdings für eine Laufzeit von etwa neun Monaten. Sind diese Erkenntnisse noch im Forschungsstadium? Ja, das ist teilweise der Fall. Für Standard-COCOMO hatten wir ursprünglich Datenpunkte von rund 160 Projekten, die jetzt auf knapp 250 Projekte angewachsen sind. Für COCOTS haben wir 20 Projekte, für CORAD- MO erst knapp zehn Projekte. Gibt es noch andere neue Entwicklungen? Seit das COCOMO-II-Buch veröffentlicht wurde, haben wir noch das Zusatzmodell COSYSMO entwickelt. Damit soll bei sehr großen Projekten der Aufwand zur Integration von Systemen geschätzt werden, die selbst wiederum aus größeren, bereits integrierten Teilsystemen bestehen. COSYSMO schätzt neben dem Aufwand zur Integration der individuellen Teilsysteme auch den Zusatzaufwand, um diese Teilsysteme zu einem Gesamtsystem zu integrieren. Benötigen moderne agile Prozessmodelle auch speziell darauf ausgerichtete Schätzmodelle? Ja, das tun sie sicher. Insbesondere, wenn sie keine vollständige oder fast vollständige Anforderungsliste haben. Wie können Sie da überhaupt die Größe eines Projekts schätzen? Im Prinzip können wir hier eine vereinfachte Funktionspunktschätzung verwenden. Oder wir können Analogieschlüsse, Befehlszeilen- und Funktionspunktschätzungen kombinieren. Das ist zwar alles nicht perfekt, aber es ist das Einzige, was zu diesem Zeitpunkt bei einem solchen Vorgehen möglich ist. Herr Boehm, vielen Dank für das Gespräch. ■ HauptveröffentlichungenvonBarryBoehmzur Kostenschätzung [1]SoftwareEngineeringEconomics,PrenticeHall,1981. [2]SoftwareRiskManagement,IEEEComputerSociety Press,1989. [3]SoftwareCostEstimationwithCOCOMOII,Prentice Hall,2000. [4]BalancingAgilityandDiscipline: AGuideforthe Perplexed,Addison-Wesley2003. Kontakt Prof.Dr.BarryW.Boehm UniversityofSouthernCalifornia 518AdelaideDr SantaMonica,CA90402 E-Mail: boehm@sunset.usc.edu www.sunset.usc.edu/ cse/ Organisationsfaktoren ❏ ErfahrungimProduktbereich ❏ Entwicklungsflexibilität ❏ AusgereiftheitdesEntwurfs ❏ Stakeholder-Zusammenhalt ❏ Software-Prozessreife Personalfaktoren ❏ Systemanalysefähigkeiten ❏ Programmierfähigkeit ❏ Anwendungserfahrung ❏ Plattformerfahrung ❏ Sprach-undToolerfahrung ❏ PersonelleKontinuität Produktfaktoren ❏ ErforderlicheZuverlässigkeit ❏ Datenbankgröße ❏ Produkt-/ Modulkomplexität ❏ Wiederverwendbarkeit ❏ Dokumentationsumfang Plattformfaktoren ❏ Rel.Rechnerzeitnutzung ❏ Rel.Hauptspeichernutzung ❏ Plattform-Änderungsdynamik Projektfaktoren ❏ NutzungvonSW-Tools ❏ StandortübergreifendeTeamarbeit ❏ VerfügbareProjektdauer COCOMO-Kostentreiber projekt M A N A G E M E NT 1/ 20 0 5 aktuell 14 WISSEN 1 HerausforderungenundTrends Obwohl das Fachgebiet Projektmanagement seit der Mitte des letzten Jahrhunderts eine beträchtliche Professionalisierung erfahren hat (vgl. zum Beispiel [1]), zählt die Aufwandsschätzung immer noch zu den schwierigsten Aufgaben eines Projektleiters [2]. Die Aufwandsschätzung eines Projekts bildet eine zentrale Grundlage essenzieller Entscheidungen. Sie wird benötigt, um ❏ zu bewerten, ob das Projekt überhaupt durchführbar ist, ❏ die für die Durchführung des Projekts erforderlichen Ressourcen, insbesondere Geldmittel, bereitstellen zu können, ❏ die Priorität des Projektes im Vergleich zu anderen Projekten und Investitionen festzulegen und ❏ die Wirkungen des Projekts, seien es Einsparungen, schnellere Durchlaufzeiten oder zusätzliche Einnahmen, zeitnah realisieren zu können. Damit wirkt die Aufwandsschätzung sowohl im einzelnen Unternehmen (Budgetierung, Ressourcenplanung) als auch zwischen mehreren Unternehmen (Angebots- und Vertragsgestaltung). Fehlerhafte Aufwandsschätzungen führen in der Regel zu einer Unterschätzung des Projektaufwands und somit zu Fehlentscheidungen bei den oben aufgeführten Punkten. Dadurch entstehen Schäden wie entgangene Marktchancen und entgangene Gewinne. Darüber hinaus können dauerhafte Imageschäden für einzelne Unternehmen oder eine ganze Branche entstehen oder Arbeitsplätze durch Insolvenzen vernichtet werden. Folgende Trends verstärken die Bedeutung der Aufwandsschätzung: ❏ Die stetige Verschärfung des Wettbewerbs verhindert die bislang geübte Praxis, Schätzprobleme durch Risikozuschläge in der Kalkulation abzudecken. Mit dieser Reduktion der finanziellen Spielräume wird die Möglichkeit eingeschränkt, die Kostenunterdeckung in einem Projekt durch eine größere Anzahl erfolgreicher Projekte abzudecken. ❏ Das rechtliche Umfeld verstärkt den Druck auf Verantwortliche in Unternehmen, einen professionellen Umgang mit Risiken nachzuweisen und unterstreicht diese Forderung mit erheblichen Sanktionen. Für die angesprochenen Pflichten sind vor allem der Deutsche Corporate Governance Kodex, das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) und das Transparenz- und Publizitätsgesetz (TransPuG) ausschlaggebend, während die persönliche Haftung des Vorstands für bestimmte Sachverhalte im Aktiengesetz (AktG) verankert wurde. Je nach Branche und Unternehmen stellen die aufwands- und somit (personal-)kostenbezogenen Projektrisiken den überwiegenden Anteil der Risiken im Unternehmen überhaupt dar. Der vorliegende Beitrag versucht in diesem Kontext, ❏ den aktuellen Stand der Aufwandsschätzung in Forschung, Lehre und Praxis mit besonderem Fokus auf die Situation in der Bundesrepublik Deutschland überblicksartig darzustellen, ❏ die Bedeutung der Aufwandsschätzung zu veranschaulichen, AufwandsschätzungvonProjekten: EineStandortbestimmung ProfessionalisierungderAufwandsschätzungdringenderforderlich AchimKindler,BerndJahnke,WolframvonSchneyder DieAufwandsschätzungistfürdenbudget-undterminbezogenenProjekterfolginerheblichemUmfangausschlaggebend.InForschungundLehreinnerhalbdesProjektmanagementssowieindenmeistenanderenFachgebietenwirddemThemaAufwandsschätzung insgesamteinevielzuniedrigeBedeutungbeigemessen.AuchdiePraxisschöpftdie bestehendenPotenzialenurzueinemgeringenTeilaus.DervorliegendeBeitragnimmteine Standortbestimmungvor.DarüberhinauszeigterdenbestehendenHandlungsbedarfsowie verfügbareLösungs-undVerbesserungsansätzeauf.DiedreiAutorenklagendabeidringendeineProfessionalisierungbeiderAufwandsschätzungvonProjektenein. ❏ WirtschaftlichesAusmaßdieserThematikwirdnoch unterschätzt ❏ TeilweiseunzureichendeDetailkenntnisseübermöglicheLösungsansätze ❏ FehlendeAkzeptanzfürMaßnahmenzurVerbesserungbeimManagement ❏ BedenkenundWiderständebeidenMitarbeiterinnen undMitarbeitern ❏ KurzfristigePrioritätenbeeinträchtigendaslängerfristigerforderliche„Durchhaltevermögen“ „5größteHemmnisse“ aktuell projekt M A N A G E M E NT 1/ 20 0 5 15 ❏ den Handlungsbedarf für Forschung und Lehre aufzuzeigen, ❏ kurzfristige Möglichkeiten zur Verbesserung der Aufwandsschätzung in der Praxis zu benennen und somit zu einer Reduzierung der Projektrisiken beizutragen und ❏ nicht zuletzt die unseres Erachtens nach dringend notwendige verstärkte Diskussion über das Thema zu forcieren. Im Vergleich zu vielen anderen Veröffentlichungen erfolgt hierbei keine Beschränkung auf Software-Entwicklungsprojekte. Auf Unterschiede im internationalen Vergleich wird nicht näher eingegangen, da dies an anderer Stelle in diesem Sonderheft erfolgt (vgl. zum Beispiel das Interview mit Barry W. Boehm). Schon Ende der 80er Jahre wurde durch umfangreiche Befragungen ermittelt, dass eine Budgetüberschreitung bei fast 40 % der Software-Entwicklungsprojekte als „normal“ (! ) angesehen wurde [3]. Die aktuelle Diskussion, die gegenwärtig zum Beispiel in Expertenforen im Internet geführt wird, bestätigt die angegebene Größenordnung [4]. In bestimmten Fällen werden sogar noch höhere, teilweise weit über 50 % liegende Quoten zugegeben (zum Beispiel in Projekten der Telekommunikationsbranche). Vermutlich kann die auffallend hohe Anzahl der Beiträge im Harvard Business Manager über den gesteuerten Projektabbruch auch als Indikator für diese dramatische Relation gewertet werden (vgl. zum Beispiel [5] oder [6]). Abb. 1 konkretisiert die skizzierte Situation und den monetären Schaden mit einem Beispiel aus eigenen Untersuchungen. Ähnliche Auswertungen mit konkreten, wertmäßig quantifizierten Projektabweichungen existieren in der Bundesrepublik fast ausschließlich in Form von Berichten der Rechnungshöfe über Projekte der öffentlichen Verwaltung. Da es aus nachvollziehbaren Gründen, insbesondere Geheimhaltungsinteressen, keine vergleichbaren und repräsentativen Angaben über die Privatwirtschaft gibt, kann der volkswirtschaftliche Gesamtschaden durch solche „Projektkatastrophen“ derzeit nur näherungsweise durch Hochrechnungen beziffert werden (vgl. zum Beispiel [7]). 2 StandderAufwandsschätzung Der unzureichende Stellenwert der Aufwandsschätzung in der Bundesrepublik kann zunächst generell am Beispiel des einzigen Anwenderverbandes für Aufwandsschätzung im deutschsprachigen Raum, der DASMA [8], verdeutlicht werden. Die DASMA hat etwa 70 (! ) Mitglieder und 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 Stunden Planstunden im Angebot Verlustgrenze Aufwandsprognose im Projektverlauf 2.200 3.190 7.300 Abb.1: BeispielhafteEntwicklungeinesProjektbudgetsin einemFestpreisprojekt Anzeige projekt M A N A G E M E NT 1/ 20 0 5 aktuell 16 WISSEN beschäftigt sich - wie der Name sagt - mit Projekten im Software-Bereich. Die nicht auf Software beschränkten Projektmanagement-Vereinigungen GPM [9] und PMI [10] beschäftigen sich mit dem Thema Aufwandsschätzung nur am Rande (vgl. zum Beispiel [11]). 2.1 VerfügbareMethodenundVerfahren Zur Erstellung von Aufwandsschätzungen werden Methoden und Verfahren benötigt. Diese zentralen Begriffe werden höchst unterschiedlich verwendet (teilweise synonyme, teilweise widersprüchliche Begriffsverwendung). Methoden können zum Beispiel in Anlehnung an die Systematik von Noth/ Kretzschmar [12] als grundlegende Rechenregeln verstanden werden, die in kombinierter Form komplexere Verfahren (Vorschriften zur Anwendung von Methoden) ergeben. Von dieser Definition wird im vorliegenden Beitrag ausgegangen. Einen Überblick über die bekanntesten Methoden und Verfahren bietet Abb. 2. Vielfach werden Schätzungen auf Basis von Expertenschätzungen erstellt, wobei die Festlegung einer definierten, transparenten und nachvollziehbaren Methodik dann durch den Rückgriff auf den Erfahrungsschatz eines oder mehrerer Experten ersetzt wird. Als strukturierte Weiterentwicklung der Expertenschätzung stehen Delphi- und Dreipunkt-Verfahren (auch als „BETA-Methode“ bekannt) zur Verfügung. Alle Methoden und Verfahren greifen in irgendeiner Form auf konkrete oder abstrahierte Erfahrungen zurück und übertragen diese in einem Analogieschluss auf den Gegenstand der Schätzung. In der Literatur wird die Analogie häufig als eine selbstständig einsetzbare Methode dargestellt, was nicht zutrifft. In Abb. 2 ist sie daher - im Gegensatz zur Darstellung anderer Autoren - nicht als eigenständige Methode enthalten. Übersicht Aufwandsschätzung vonIT-Projekten[13], [14] Software- Messungin derPraxis [15] Software Measurementand Estimation [16] Aufwandsschätzung vonIV-Projekten[17] Software- Metrikenin derPraxis [18] Aufwandsschätzung vonDV-Projekten[19] Software Engineering Economics [20] Spezialthemen Akzeptanzprobleme [21] COCOMO (Linesof Code)[20] Dreipunkt- Verfahren [22] Fallbasierte Aufwandsschätzung [23],[24],[25] Function Point[13], [26],[27] Java-Anwendungen [28] Mann- Monat[29] Modernisierungvon Schulgebäuden[30] Monte-Carlo-Methode [31] Objektorientierte Software [32] Organisation derAufwandsschätzung[33] Projektvergleichstechnik[34] Quantitative Projektsteuerung [35] Schätzgenauigkeit durch Erfahrungsdaten[35] Software- Messung [15],[16], [36] Software- Reengineering-Projekte [37] Standardfür Software-Produktivitätsmetriken[38] Testkosten [39] Unsicherheit/ Ungewissheit[22], [31] Wartungsaufwand [13],[20], [27],[40] Webbasierte Informationssysteme[41] Analogien • COCOMO • Function Point • Data Point • Object Point • Fallbasierte Aufwandschätzung • ... • Delphi-Verfahren • Dreipunkt-Verfahren • Schätzklausur • ... • Relationsmethode • Multiplikatormethode • Gewichtungsmethode • Prozentsatzmethode • Methode der parametrischen Schätzgleichung (Regressionsanalyse) Expertenschätzung Methoden Verfahren Abb.2: Übersichtüber(Basis-)MethodenundausgewählteVerfahrenzurAufwandsschätzung Abb.3: AusgewählteQuellenzumThemaAufwandsschätzung ❏ AkzeptanzbeiManagement,Mitarbeiterinnenund Mitarbeiternschaffen ❏ OffeneKommunikationüber„Projektkatastrophen“ undBerücksichtigunghiermitverbundenerMitarbeiterängste ❏ EntwicklungoderAdaptionvonVerfahrenfürspeziellenAnwendungsbereich ❏ SchätzungvongrößerenProjektendurchmehrere ExpertennacheinheitlichenVorgaben ❏ UnterstützungderSchätzendendurchErfahrungsdatenausabgeschlossenenProjekten ❏ UnterstützungundBeratungderSchätzendendurch einezentraleStelle ❏ DokumentationderinderAufwandsschätzungund KalkulationunumgänglichenAnnahmen ❏ AusweisderermitteltenSchätz-undKostenrisiken ❏ SicherungderProjekt-undErfahrungsdatenimProjektabschlussbericht ❏ ZuständigkeitfürVerbesserungdermessbaren SchätzqualitätdurchZielvereinbarungabsichern „10SchrittezumErfolg“ aktuell projekt M A N A G E M E NT 1/ 20 0 5 17 In Abb. 3 sind ausgewählte Quellen zum Thema Aufwandsschätzung zusammengestellt. Abb. 4 gibt eine Übersicht über Organisationen, die sich mit dem Thema Aufwandsschätzung und den dafür entwickelten Metriken (Kennzahlen) beschäftigen. Methoden und Verfahren, die auf einer größeren Datenbasis und der Regressionsanalyse aufbauen, sind ziemlich selten (vgl. zum Beispiel [20]). Deswegen wird - insbesondere in der Bundesrepublik - häufig mit Thesen und logisch-induzierten Schlussfolgerungen gearbeitet (vgl. zum Beispiel [32]). Die absolute Mehrheit der dargestellten Verfahren bezieht sich auf die Aufwandsschätzung von Software-Entwicklungsprojekten. Bei anderen Projekttypen wird die Aufwandsschätzung in der Regel nur unzureichend berücksichtigt. Zur Veranschaulichung wird dann häufig wieder auf die Verfahren zur Schätzung des Aufwands in Software-Projekten zurückverwiesen (zum Beispiel Function Point). Ein höherer Entwicklungsstand ist beispielsweise in der Baubranche gegeben, da auf Basis der in der Honorarordnung für Architekten und Ingenieure (HOAI) präzise definierten Leistungen eine statistisch repräsentativ ermittelte Kostenübersicht durch Baupreisindizes gegeben ist [49]. Als wesentliche Voraussetzungen für diesen hohen Standardisierungsgrad sind zu nennen: Definition von Objekten, Baumaßnahmen und Leistungen in Verbindung mit gültigen DIN-Normen. 2.2 AufwandsschätzunginderForschung Die geringe Forschungsintensität im deutschsprachigen Raum kann an einem einfachen Indikator aufgezeigt werden. Eine Literaturrecherche bei der Deutschen Bibliothek [50] in Frankfurt mit dem Stichwort „Aufwandsschätzung“ ergibt ohne zeitliche Einschränkung insge- ❏ COSMICON: TheCommonSoftwareMeasurement InternationalConsortium[42] ❏ DASMA: DeutschsprachigeAnwendergruppefür Software-MetrikundAufwandsschätzunge.V.[8] ❏ FESMA: FederationofEuropeanSoftwareMetrics Associations[43] ❏ GPM/ IPMA: DeutscheGesellschaftfürProjektmanagemente.V.[9] ❏ GI: GesellschaftfürInformatike.V.[44] ❏ IFPUG: InternationalFunctionPointUsersGroup[45] ❏ ISBSG: InternationalSoftwareBenchmarkingStandardsGroup[46] ❏ NESMA: NetherlandsSoftwareMetricsUsersAssociaton[47] ❏ PMI: ProjectManagementInstitute[10] ❏ UKSMA: UnitedKingdomSoftwareMetricsAssociation[48] Abb.4: Organisationen,diesichmitderAufwandsschätzung undgeeignetenMetriken(Kennzahlen)beschäftigen projekt M A N A G E M E NT 1/ 20 0 5 aktuell 18 WISSEN samt zehn Treffer. Davon sind neun direkt auf Software- Projekte bezogen, einer auf Bauprojekte (vgl. Abb. 3). Allein dieses Ergebnis zeigt, wie wenig Veröffentlichungen es zum Thema Aufwandsschätzung gibt! Zum Vergleich: Dieselbe Recherche mit dem Schlagwort „Risikomanagement“ ergibt 704 Treffer; „Projektmanagement“ führt zu 1.180 Treffern. Durch ergänzende Recherchen, zum Beispiel beim BSZ [51], werden diese Ergebnisse bestätigt. Diese abgeleitete Einschätzung wird auch von Wissenschaftlern geteilt: So stufen etwa Broy/ Rombach [52], die den erreichten Stand des Software Engineering - einschließlich Management und Aufwandsschätzung - beschreiben, die Forschungsaktivitäten als unzureichend ein. 2.3 AufwandsschätzunginderLehre Die Aufwandsschätzung ist regelmäßiger Bestandteil der universitären Ausbildung in den Fächern Informatik, Wirtschaftsinformatik und Projektmanagement. Im Rahmen der Lehre in den Fächern Informatik und Wirtschaftsinformatik beschränkt sich die Ausbildung in der Regel auf die bekannten Verfahren (COCOMO, Function Point, teilweise auch Data- und Object Point) und deren Grundlagen. Weiterentwicklungen, wie zum Beispiel Full- Function-Point [42], werden bereits wesentlich seltener gelehrt. Im Informatik-Bereich erfolgt üblicherweise auch eine Schulung zum sinnvollen Einsatz von Metriken. Innerhalb des Projektmanagements werden in der Regel die grundlegenden Methoden sowie das Delphi- und das Dreipunkt-Verfahren dargestellt. Leider wird das Fach Projektmanagement in der Bundesrepublik Deutschland bislang nur sehr vereinzelt gelehrt (zum Beispiel im ersten Weiterbildungsstudiengang zum Diplom-Projektmanager [FH] an der FH Gießen-Friedberg und im Studienschwerpunkt „Projektmanagement“ im Studiengang Wirtschaftsingenieurwesen der FH Darmstadt). In den Studiengängen Bauingenieurwesen und Architektur werden meistens fakultative Lehrveranstaltungen zur Kostenschätzung auf Basis des schon angesprochenen Baupreisindex angeboten. In anderen Fächern dominieren vielfach immer noch die klassischen, nicht projektbezogenen Ansätze (zum Beispiel Grenzplankostenrechnung). 2.4 AufwandsschätzunginderPraxis In der Praxis existiert eine große Anzahl unterschiedlicher Projektarten, für die es noch keine allgemein anerkannte Klassifizierung gibt. Schon bei vergleichsweise einfachen Beispielen fällt eine eindeutige Zuordnung zu Projektklassen bzw. -typen schwer (vgl. zum Beispiel [53]). Abb. 5 gibt eine beispielhafte Übersicht zu der angesprochenen Vielfalt. Im Wesentlichen sind zwei Bereiche erkennbar, in denen die Aufwandsschätzung - zumindest teilweise - mit fundierten, erprobten Verfahren durchgeführt wird. Diese sind: 1. Projekte der Software-Entwicklung und 2. hoch standardisierte „Order“-Projekte. Ad 1: Projekte der Software-Entwicklung Wie bereits beschrieben, bezieht sich der Schwerpunkt der Verfahrensentwicklung auf den Bereich der Software- Entwicklung. Daher verwundert es nicht, dass in diesem Bereich häufiger eine professionelle Aufwandsschätzung durchgeführt wird. Einerseits erfolgt hierbei in der Regel eine Orientierung am unternehmenseigenen Vorgehensmodell. Zum Teil werden auch bekannte Verfahren wie COCOMO und Function-Point - in teilweise modifizierter oder spezifizierter Form - eingesetzt. Für die Schätzung des Wartungsaufwands werden in diesen Or- Organisationsprojekte Softwareprojekte Verwaltungsreformprojekte Politische Projekte DV-/ IT-/ IuK-Projekte HR-Projekte Logistikprojekte Bauprojekte ... Forschungsprojekte Technologieprojekte Projektarten Organisationsentwicklung M&A-Projekte Teamentwicklung Outsourcing ... Reorganisation BPR-Projekte Schnittstellenoptimierung ... Entwicklung Wartung Migration Integration Leitbildentwicklung Aufgabenkritik Dezentrale Budgetierung Dezentrale Fach- und Ressourcenverantwortung KLR-Projekte Zielvereinbarung E-Government ... Wahlkampf Koalitionsverhandlungen Schwarzkontenaufklärung Gesetzesinitiative Kriege Katastropheneinsatz Katastrophenprävention (Experten-) Kommissionen ... Vernetzung Standardsoftware E-Learning B2B-Projekte ... Recruiting Coaching Outplacement ... Castor-Transporte Bundeswehr-Auslandseinsatz Produktionsstättenverlagerung ... Neubau Umbau ... Demoskopie Ausgrabungen Genforschung Nanotechnik Brennstoffzellen Life Sciences ... Prozessinnovation ... Produktinnovation SUV´s Synthetische Bio-Kraftstoffe ... (NSM-/ NPM-Projekte) Abb.5: Beispiel verschiedener Projektarten aktuell projekt M A N A G E M E NT 1/ 20 0 5 19 ganisationen häufig die gleichen Verfahren angewandt. Doch auch bei Projekten der Software-Entwicklung hat die Expertenschätzung einen erheblichen „Marktanteil“ - in einfacher (unstrukturierter) Form, in strukturierter Form als Delphi-Schätzung oder in Form des Estimeeting [33]. Einen Überblick über Entwicklungsstand und Anwendung von Verfahren bietet beispielsweise die jährliche Konferenz MetriKon der DASMA. Ad 2: Hoch standardisierte „Order“-Projekte Wenn ein Unternehmen immer wieder ähnlich strukturierte Projekte durchführt (zum Beispiel F&E-, Logistik- oder Qualifizierungsprojekte), so verfügt es - bei entsprechendem Wissensmanagement - auf Grund der Wiederholungsrate über umfassende Erfahrungen. Unter diese Rubrik fallen Projekte, die vom selben Unternehmen als Kundenauftrag in identischer oder ähnlicher Form immer wieder durchgeführt werden (wie Straßenbau-, Schiffsbau- und zuweilen auch Beratungsprojekte). Manche dieser Unternehmen besitzen speziell auf ihre Projekte zugeschnittene Verfahren der Aufwandsschätzung. Aufgrund der großen Ähnlichkeiten und der dadurch relativ einfachen Identifizierbarkeit von Aufwandstreibern sind meistens Analogien zu bereits durchgeführten Projekten möglich (z. B. in der Automotive-Branche). Auf Grund der durch HOAI und Baupreisindex gegebenen hohen Standardisierung können Bauprojekte auch zu dieser Kategorie gezählt werden. Insgesamt dominiert, wie schon von Kurbel/ Dornhoff [54] betont wurde, der Einsatz der Expertenschätzung, wobei der durch die Schätzung entstehende Aufwand erheblich differiert. Am unteren Ende der Aufwandsskala liegt die durch Projektleiter oder Auftraggeber teils in wenigen Minuten erstellte „Intuitivschätzung“, die auch als „Informelle Expertenschätzung auf Basis intuitiver Analogiebildung“ bezeichnet wird [24]. Am oberen Ende liegen systematische, mit Analogien abgesicherte Schätzungen, zum Beispiel nach dem Delphi-Verfahren oder Bottom-up angelegte Schätzungen nach dem Dreipunkt-Verfahren. Abb. 6 veranschaulicht die beschriebenen Unterschiede und zeigt schematisch, wie das Schätzrisiko durch eine bessere Vorbereitung und Organisation reduziert werden kann. Zentrales Problem beim Einsatz der Expertenschätzung ist, dass für zeitaufwändige Schätzungen oft keine Experten zur Verfügung stehen, die über umfassende Erfahrungen in der Projektplanung, Aufwandsschätzung und Projektdurchführung vergleichbarer Projekte verfügen. Das systematische und strukturierte Vorgehen wird vor allem auch durch den vorherrschenden Zeitdruck im „Tagesgeschäft“ erschwert. Für die organisationsinterne Verbesserung der Schätzgrundlagen ergeben sich aber auch Schwierigkeiten aus den hierzulande geltenden Mitbestimmungsgesetzen. Aussagefähige Erfahrungsdaten machen eine differenzierte Erfassung des Arbeitsaufwands erforderlich. Die Einführung und Ausgestaltung der Arbeitszeiterfassung unterliegen hierzulande aber der uneingeschränkten Mitbestimmung des Betriebs- und Personalrats laut Betriebsverfassungs- und Bundespersonalvertretungsgesetz (vgl. zum Beispiel [55]), da die Leistungsüberwachung der Beschäftigten verhindert werden soll. In Anlehnung an Projekte zur Einführung der Kosten- und Leistungsrechnung in Behörden, bei denen es ebenfalls um die produktbezogene Personalkostenermittlung geht, sind aber - über die individuelle Regelung in Dienstvereinbarungen hinausgehend - mehrere Maßnahmen denkbar, um diesen Bedenken ausreichend Rechnung zu tragen. MitbestimmungsgesetzeerschwereninDeutschland dieErfassungaussagefähigerErfahrungsdaten In dieser gesetzlichen „Erschwernis“ ist vermutlich auch einer der ausschlaggebenden Gründe für den Rückstand der Bundesrepublik im internationalen Vergleich zu sehen. Ein weiterer wichtiger Grund ist - neben dem unzureichenden Problembewusstsein - sicherlich auch auf die unterschiedlichen Anforderungen bei öffentlichen Ausschreibungen zurückzuführen (zum Beispiel Function Points bei Softwareprojekten in Italien). In vielen Organisationen gibt es Projektmanagement- Richtlinien, in denen geregelt ist, wie Projekte durchzuführen sind. Mit diesen Richtlinien sind allerdings nicht selten folgende Probleme verbunden: ❏ Die Richtlinien beinhalten lediglich den Hinweis, dass eine Aufwandsschätzung durchzuführen ist (ohne Hinweis, wie). ❏ Es gibt sehr detaillierte Beschreibungen, wie die Aufwandsschätzung durchzuführen ist, die in der Mehrzahl der Fälle leider nicht wie beschrieben anwendbar sind (zum Beispiel fehlende Schätzgrundlagen, andere Projektart, veränderte Organisationsstrukturen). Andererseits treiben viele Unternehmen mit Projekten zur Einführung von Metriken die Professionalisierung ihres Projektmanagements voran - wodurch dann auch die ❏ VerantwortlichkeitenundKompetenzenklären ❏ MindestanforderungenanAufwandsschätzungen definierenunddurchsetzen ❏ BasisqualifikationfürSchätzendeherstellen ❏ „Projektfamilien“definieren,dieÄhnlichkeitenaufweisen ❏ VorgehenzurSchätzungjeProjektfamiliedefinieren ❏ ErgebnisseimZeitablaufbeobachten „QuickWinsbeiderOptimierung derAufwandsschätzung“ Schätzrisiko Delphi- Verfahren Dreipunkt- Verfahren Intuitivschätzung Estimeeting Strukturierungs-/ Organisationsgrad/ Vorbereitung Verfügbarer Input (Zeit, Informationen) Abb.6: DasreduzierteSchätzrisikoalsErgebnisderorganisiertenAufwandsschätzung projekt M A N A G E M E NT 1/ 20 0 5 aktuell 20 WISSEN Aufwandsschätzung verbessert werden kann (zum Beispiel [56], [57]). Durch die Einrichtung von projektmanagementbezogenen „Competence Centern“ in Großunternehmen - bis hin zur verselbständigten Beratungsfirma - erfolgen ebenfalls eine weiter gehende Professionalisierung und Optimierung, zum Beispiel auch im Hinblick auf Multi-Projektmanagement. Maßnahmen zur Einführung von DIN-Normen und anderen Standards (zum Beispiel Rational Unified Process) können ebenfalls dazu beitragen, eine systematische und strukturierte Aufwandsschätzung zu unterstützen. 3 Handlungsbedarf Zweifelsfrei besteht ein erheblicher Handlungsbedarf, und zwar sowohl in der Forschung als auch in der Lehre und Praxis. Um den Umfang dieser Veröffentlichung nicht zu sprengen, werden die für notwendig erachteten Entwicklungen im Folgenden lediglich kurz angerissen [58]. 3.1 Forschung Eine generelle Aufgabenstellung der Wissenschaft ist darin zu sehen, über Grundlagenforschung und angewandte Forschung Verfahren zu entwickeln, mit denen die Praxis auch in anderen Projektarten arbeiten kann. Diesem Anspruch wird die Wissenschaft derzeit im Bereich Aufwandsschätzung eindeutig nicht gerecht. Zur Verbesserung der Situation sind Aktivitäten auf verschiedenen Ebenen notwendig. Ansatzpunkte könnten sein: ❏ Aufbau einer zentralen Koordinationsstelle für Forschung und Mobilisierung im Bereich Aufwandsschätzung, ❏ Schaffung einer Basis durch Aufbau einer allgemein gültigen Systematik zur Konstruktion von Methoden und Verfahren der Aufwandsschätzung, ❏ Erarbeitung einer standardisierten, allgemein anwendbaren Klassifikation von Projekten als Basis für die Klärung der Ausgestaltung und Anwendbarkeit von Verfahren zur Aufwandsschätzung, ❏ Übertragung von für die Aufwandsschätzung anwendbaren Forschungsergebnissen (zum Beispiel aus der Wirtschaftsinformatik), ❏ intensive Zusammenarbeit von Forschung und Aufwandsschätzungen erstellenden Organisationen, auch auf finanzieller Basis (zum Beispiel über Promotionsstipendien und Stiftungslehrstühle). 3.2 Lehre Vorschläge zu Verbesserungen in der Lehre müssten beinhalten: ❏ Ausdehnung der Lehre von Aufwandsschätzung auf alle Fächer, die sich mit Projekten und/ oder Projektmanagement befassen, ❏ Intensivierung der Lehre von der Kenntnis der Verfahren durch die Vermittlung von Anwendungskompetenz (zum Beispiel durch Praxisvorträge), ❏ Definition von Aus- und Weiterbildungsangeboten für die Betroffenen in der Wirtschaft. Kernthema bleibt jedoch, dass häufig noch das grundlegende Problembewusstsein fehlt! 3.3 Praxis Das Vorgehen zur Aufwandsschätzung lässt sich kurzfristig deutlich verbessern. Um dauerhaft optimale Ergebnisse zu erzielen, sind allerdings längerfristige Maßnahmen erforderlich. Kurzfristige Maßnahmen können umfassen: ❏ verbindlich vorgegebene Schätzgrundlagen, ❏ Analyse und Dokumentation von Annahmen und Risiken, ❏ qualifikationsabhängige Auswahl der Schätzenden, ❏ zusätzliche interne Qualitätssicherungsmaßnahmen, ❏ kunden- und projektspezifische Abstimmung des Vorgehensmodells mit dem Auftraggeber. Den Durchbruch zu erheblich besserer Qualität erreicht ein Unternehmen durch die folgenden, längerfristigen Maßnahmen: ❏ Aufbau von Richtlinien zur Aufwandsschätzung einschließlich Integration in das betriebliche Projekt-, Qualitäts- und Risikomanagement, ❏ Auswahl und Adaption von Methoden und Verfahren zur Entwicklung einer unternehmens- und projektspezifischen, adäquaten Lösung, ❏ systematische Auswertung von Datensammlungen und Ableiten von Erfahrungen, ❏ Standardisierung der Projekte einschließlich Aufwandsschätzung, Kalkulation und Projektdokumentation (insbesondere Projektabschlussbericht), ❏ Aufbau und Weiterentwicklung einer dauerhaft im Unternehmen vorhandenen Kompetenz im Thema Aufwandsschätzung (zum Beispiel auch über Zertifizierungen), ❏ systematische Verbesserung der erreichten Präzision (zum Beispiel durch Benchmarking und Integration von Verbesserungen in Zielvereinbarungen). 4 Fazit Für Software-Entwicklungsprojekte gibt es schon sehr viele wichtige, verwendbare Grundlagen. Bei anderen Projektarten fehlen vergleichbare Ansätze weitgehend. Der wirtschaftliche Druck auf Projekte und Projektverantwortliche nimmt beständig zu. Aus den gesetzlichen Änderungen bis hin zur persönlichen Verantwortung und Haftung des Vorstands ergeben sich weitere Anforderungen, die von den Projektverantwortlichen erfüllt werden müssen. Für einen Teil der Unternehmen sind es die Anforderungen des Risikomanagements nach dem Deutschen Corporate Governance Kodex, die eine grundlegende Professionalisierung der Aufwandsschätzung unumgänglich machen. Viele andere Unternehmen haben aufgrund des wirtschaftlichen Drucks keine Alternative zu einer schnellen Verbesserung der Schätzqualität. Das Thema Aufwandsschätzung muss deswegen ❏ systematisch ins Bewusstsein aller Stakeholder gebracht, ❏ Markt(Konkurrenz-undPreisdruck) ❏ Kunde(Zeitdruck) ❏ PrioritätaufinterneVerbesserungenfehlt ❏ SensibilisierungfürmöglicheVerbesserungfehlt „DiehäufigstenAusreden“ aktuell projekt M A N A G E M E NT 1/ 20 0 5 21 ❏ endlich in der vollen Breite des Bedarfs „beforscht“ und ❏ in Forschung, Lehre und Praxis sukzessive professionalisiert werden. Der geforderte Fortschritt wird für den Unternehmenserfolg, die Beschäftigungssituation und -entwicklung und somit letztlich für die Wettbewerbsfähigkeit und Arbeitsplatzsicherheit ganzer Branchen (mit)entscheidend sein. ■ Literatur [1]Madauss,B.J.: HandbuchProjektmanagement: Mit HandlungsanleitungenfürIndustriebetriebe,UnternehmensberaterundBehörden.6.überarbeiteteunderweiterteAufl.,Stuttgart2000 [2]DeMarco,T.: Software-Projektmanagement: Wieman Kosten,ZeitaufwandundRisikokalkulierbarplant.1.Aufl., Attenkirchen1989 [3]vanGenuchten,M.J.I.M.: TowardsaSoftwareFactory, DissertationTechnischeUniversitätEindhoven.Helmond1991 [4]Terglane,N.: IT-StrategienalsProzessanstattalsProjektbegreifen.Serie: RentabilitätderIT-Ausgaben,www. computerzeitung.de [5]Keil,M./ Montealegre,R.: WenneinIT-Projektgestoppt werdenmuss.In: HarvardBusinessManager,22.Jg.,6/ 2000, S.74-92 [6]Royer,I.: BremserfürdenNotfall.In: HarvardBusiness Manager,Mai2003,S.44-63 [7]Gröger,M.: Projektkompetenz: Mangelhaft.Stolperstein aufdemWegzumUnternehmenserfolg,www.leadershipfestival.de/ pdf/ groeger_pbm.pdf [8]DASMA: DeutschsprachigeAnwendergruppefürSoftware-MetrikundAufwandschätzunge.V.,www.dasma.org [9]GPM/ IPMA: DeutscheGesellschaftfürProjektmanagemente.V.,www.gpm-ipma.de [10]ProjectManagementInstitute(PMI),www.pmi.org/ [11]GPMDeutscheGesellschaftfürProjektmanagement (Hrsg.): ProjektmanagementFachmann,Bd.2.RKW-Verlag, 7.überarbeiteteundaktualisierteAufl.,Eschborn2003 [12]Noth,T./ Kretzschmar,M.: AufwandschätzungvonDV- Projekten: DarstellungundPraxisvergleichderwichtigsten Verfahren.2.Aufl.,Berlinetal.1986 [13]Bundschuh,M./ Fabry,A.: AufwandschätzungvonIT- Projekten.2.überarbeiteteunderweiterteAufl.,Bonn2004 [14]Bundschuh,M.: AufwandschätzungvonIT-Projektenin derPraxis.In: Bernecker,M./ Eckrich,K.(Hrsg.): Handbuch Projektmanagement.München,Wien2003 [15]Büren,G./ Bundschuh,M./ Dumke,R.(Hrsg.): Software- MessunginderPraxis.TagungsbanddesDASMASoftware MetrikKongressesMetriKon2003,10.-11.Nov.2003.Neu- Ulm,Aachen2003 [16]Dumke,R./ Abran,A./ Bundschuh,M./ Symons,Chr.(Eds.): SoftwareMeasurementandEstimation.Proceedingsofthe 12thInternationalWorkshoponSoftwareMeasurement, October7-9,Magdeburg,Germany.MagdeburgerSchriften zumEmpirischenSoftwareEngineering.Aachen2002 [17]Noth,T.: AufwandschätzungvonIV-Projekten.In: A.Backetal.(Hrsg.): LexikonderWirtschaftsinformatik. 4.vollständigneubearbeiteteunderweiterteAufl.,Berlin, Heidelberg2001,S.54-56 [18]Ebert,Chr./ Dumke,R.(Hrsg.): Software-Metrikeninder Praxis: EinführungundAnwendungvonSoftware-Metriken inderindustriellenPraxis.Berlinetal.1996 [19]Noth,T./ Kretzschmar,M.: AufwandschätzungvonDV- Projekten: DarstellungundPraxisvergleichderwichtigsten Verfahren.2.Aufl.,Berlinetal.1986 [20]Boehm,B.W.: SoftwareEngineeringEconomics.EnglewoodCliffs,New Jersey1981 [21]Hürten,R.: WhydoestheFunctionPointAnalysisfindsolittleAcceptance. In: Dumke,R.; Albran,A.; Bundschuh,M.; Symons,Ch.(Eds.): SoftwareMeasurementandEstimation.Proceedingsofthe12thInternationalWorkshopon SoftwareMeasurement.Aachen2002,p.259-268 [22]Gartner,P.: DieDrei-Punkt-SchätzungzurKalkulationdesProjektaufwands. In: FachzeitschriftProjektmanagement,10.Jg.,Heft4/ 99,S.33-37 [23]Passing,U./ Strahringer,S.: EstimatingSoftwareProjectEffortBasedonthe DevelopmentProcessModel.InSoftwaretechnik-Trends,Bd.22,Heft2,Mai 2002,S.11-17 [24]Passing,U./ Strahringer,S.: ProzessorientierteExperten-AufwandschätzungfürSoftwareprojekte: EinführungundUmsetzungbeiderBausparkasse SchwäbischHallAG.In: InformationManagement&Consulting18,2003,4, S.25-32 [25]Veloso,M./ Aamodt,A.(Eds.): Case-BasedReasoningResearchandDevelopment.FirstInternationalConference,ICCBR-95Sesimbra,Portugal,October 23-26,1995,Proceedings.Berlinetal.1995 [26]IBMDeutschlandGmbH(Hrsg.): DieFunctionPointMethode: EineSchätzmethodefürIS-Anwendungs-Projekte.IBMFormGE12-1618-1,o.O.1983,1985 [27]Großjohann,R.: ManagementderAnwendungsentwicklungbeiVolkswagen.In: Schweiggert,F.(Hrsg.): WirtschaftlichkeitvonSoftware-Entwicklung und-Einsatz: Investitionssicherung,Produktivität,Qualität.Stuttgart1992, S.69-92 [28]Wolle,B.: StatischeAnalysevonJava-Anwendungen: EignensichLinesof-Code-MetrikundHalstead-Länge? In: Wirtschaftsinformatik45,2003,1, S.29-40 [29]Brooks,F.P.: VomMythosdesMann-Monats.EssaysüberSoftware-Engineering.Bonnetal.1987 [30]Friedl,G./ Wolf,R.: AufwandschätzungfürdieModernisierungvonSchulgebäuden.Berlin1983 [31]Kehl,Chr.: IT-ProjektmanagementmitderMonteCarloMethode.In: InformationManagement&Consulting18,2003,4,S.33-37 [32]Sneed,H.M.: SchätzungderEntwicklungskostenvonobjektorientierter Software.In: InformatikSpektrum,OrganderGesellschaftfürInformatike.V., Bd.19,Heft3,Juni1996,S.133-140 [33]Taff,L.M./ Borchering,J.W./ Hudgins,W.R.: Estimeetings: Development EstimatesandaFront-EndProcessForaLargeProject.In: IEEETransactions onSoftwareEngineering,Vol.17,No.8,August1991,p.839-849 [34]vonWasielewski,E.: Projektvergleichstechnik: Datenabgeschlossener ProjektefürTrendermittlung,BenchmarksundPrognosennutzen.1.Aufl.,Köln 2003 [35]Seibert,S.: Softwaremessung,quantitativeProjektsteuerungundBenchmarking: WiehelfensiedemSoftware-Projektmanager? In: projektMANAGE- MENTaktuell,14.Jg.,4/ 2003,S.26-34 [36]Jones,C.: AppliedSoftwareMeasurement: AssuringProductivityandQuality.2nded.,NewYorketal.1996 [37]Sneed,H.M.: AufwandschätzungvonSoftware-Reengineering-Projekten. In: Wirtschaftsinformatik,45.Jg.,2003,6,S.599-610 [38]InstituteofElectricalandElectronicsEngineers(Ed.): IEEEStandardfor SoftwareProductivityMetrics.IEEEStd1045-1992.NewYork1993 [39]Sneed,H.M.: TestmetrikenfürdieKalkulationderTestkostenunddie BewertungderTestleistung.In: Softwaretechnik-Trends.Band23,Heft4,Nov. 2003,S.11-14 [40]Bundschuh,M.: EstimationofMaintenanceTasks.In: [16],p.125-136 [41]Sneed,H.M.: AufwandschätzungfürWeb-basierteInformationssysteme unddieStrukturderSoftwareindustrie.In: Wirtschaftsinformatik,44.Jg.,Heft 3,2002,S.202-205 [42]COSMICON: TheCommonSoftwareMeasurementInternationalConsortium,www.cosmicon.com.Vgl.hierzuISO/ IEC19761: 2003,www.iso/ ch/ [43]FESMA: FederationofEuropeanSoftwareMetricsAssociations,www. fesma.org/ [44]GI: GesellschaftfürInformatike.V.,www.gi-ev.de [45]IFPUG: InternationalFunctionPointUsersGroup,www.ifpug.org/ projekt M A N A G E M E NT 1/ 20 0 5 aktuell 22 WISSEN [46]ISBSG: InternationalSoftwareBenchmarkingStandardsGroup,www.isbsg.org [47]NESMA: NetherlandsSoftwareMetricsUsersAssociation,nesma.nl/ english/ [48]UKSMA: UnitedKingdomSoftwareMetricsAssociation,www.uksma.co.uk [49]StatistischesBundesamt,www.destatis.de/ presse/ deutsch/ abisz/ baupreisindex.htm [50]DeutscheBibliothekFrankfurtamMain,www.ddb.de [51]Bibliotheksservice-ZentrumBaden-Württemberg(BSZ), www.bsz-bw.de [52]Broy,M./ Rombach,D.: SoftwareEngineering: Wurzeln, StandundPerspektiven.In: InformatikSpektrum,Bd.25, Heft6,Dez.2002,S.438-451 [53]Kindler,A./ vonSchneyder,W.: Aufwandschätzungvon Projekten-zwischenFehlanzeigeundPerfektion.In: [15], S.107-119 [54]Kurbel,K./ Dornhoff,P.: MehrFlexibilität: EininnovativerAnsatzfürdasSoftwareprojektmanagement.In: HMD, 30.Jg.,170/ 1993,S.111-127 [55]Spitta,T./ Becker,F.G.: ZeiterfassunginderIV-KostentransparenzoderPersonalkontrolle? In: Sonderheft WirtschaftsinformatikIT&Personal,Okt.2000,S.48-55 [56]Grady,R.B./ Caswell,D.L.: SoftwareMetrics: EstablishingaCompany-WideProgram.EnglewoodCliffs,New Jersey1987 [57]Fehrling,N.: Software-MetrikimUmfeldderAutomobilindustrie.In: [15],2003,S.163f. [58]Kindler,A.: Aufwändeeinfachpräziserschätzen.In: Rackelmann,G./ Schelle,H.(Hrsg.): 21.Internationales DeutschesProjektmanagementForum2004,Nürnberg, 4.-7.Okt.2004,Meistersingerhalle,Nürnberg2004,S.51-60 Schlagwörter Aufwandsschätzung,Budgetabweichung,Forschung, Handlungsbedarf,Lehre,Methoden,Praxis,Projekt,Projektrisiko,Schätzqualität,Verfahren Autor Dr.AchimKindler,geb.1958,hatnach einerAusbildungalsIndustriekaufmanndasStudiumderWirtschaftswissenschaften(Betriebswirtschaftslehre)anderEberhardKarlsUniversitätTübingenalsDiplom-Kaufmann absolviert.ImRahmenseinerPromotionamLehrstuhlvonHerrnProf.Dr. B.Jahnke,diemiteinerUnternehmensberatunginForm einesDrittmittelprojekteserfolgte,hatersichab1989mit demThemaProjektaufwandsschätzungbeschäftigt.Heute istHerrKindlerSeniorberaterundGesellschafterbeider UnternehmensberatungIMAKAInstitutfürManagement GmbH.SeitNovember2004istHerrKindlerVorstandder DASMAe.V.(DeutschsprachigeAnwendergruppefürSoftwaremetrikenundAufwandsschätzung). Anschrift IMAKAInstitutfürManagementGmbH Einsteinstraße57 D-71229Leonberg Tel.: 07152/ 33070 E-Mail: Achim.Kindler@imaka.de Autor Univ.-Prof.Dr.BerndJahnke,geb. 1947,StudiumanderUniversität Göttingen,wissenschaftlicheAusbildunganderUniversitätHamburg, istseit1988OrdinariusfürBetriebswirtschaftslehre,insbesondereWirtschaftsinformatik,anderEberhard KarlsUniversitätTübingen.Erist MitgliedeinerReihewissenschaftlicherundpraxisnaherGesellschaftenundKommissionenzurWirtschaftsinformatik,soetwainderGesellschaftfürInformatikund imVerbandderHochschullehrerfürBetriebswirtschaft. AusgewählteForschungsschwerpunktedesLehrstuhlinhabersbetreffenFührungsinformationssysteme,Enterprise ApplicationIntegration(EAI),E-Learning.AlsKonsequenz desdabeiverfolgtenParadigmas„ForschungdurchEntwicklung“bestehenvielfältigePraxiskontakteund-kooperationen,indienebenMitarbeiternundDoktorandenauch Studierendeeinbezogenwerden. Anschrift LehrstuhlfürWirtschaftsinformatik EberhardKarlsUniversität Melanchthonstr.30 D-72074Tübingen Tel.: 07071/ 29-75422 E-Mail: jahnke@uni-tuebingen.de Autor WolframvonSchneyder,Diplom- Kaufmann,geb.1967,istLeiterVertriebSüd/ WestderILTISGmbHin RottenburgamNeckar.Wolframvon SchneyderhatinzehnJahrenUnternehmensberatungunterdemMotto „DamitausStrategienHandelnwird“ einegroßeZahlvonProjektenverantwortetundverschiedeneleitendeFunktionenimUnternehmenwahrgenommen.SeineArbeitsschwerpunktesind VerwirklichungvonStrategien,Strategie-undZielfindung, Projekt-undProgrammmanagementsowieFührungs-und Steuerungsinstrumente. Anschrift ILTISGmbH Röntgenstraße15 D-72108Rottenburg Tel.: 07472/ 9839-0 E-Mail: Wolfram.von.Schneyder@iltis.de aktuell projekt M A N A G E M E NT 1/ 20 0 5 23 EinsatzundNutzenderFunction- Point-Methode AufwandsschätzungvonSoftwareprojekten ManfredBundschuh DieserAufsatzbeschäftigtsichsowohlmitdenProblemenalsauchmitdenMöglichkeiten,inSoftwareprojektenzugutenSchätzergebnissenzugelangen.ErzeigtChancenauf, diedieprofessionelleAufwandsschätzungderProjektplanungbietet.DieFunction-Point- MethodedokumentiertobjektivundeinheitlichdieAnwendungssystemeausBenutzersicht, undzwarkonsistentmitdemVerständnisderAnwender(einheitlicheSprachefürITund Fachbereich).AufdieserBasiskönnenProjektentscheidungen,InvestitionenundVerträge abgesichertundkanneineLieferantenauswahldurchgeführtwerden.Außerdemerhältdas Unternehmendadurchkonsistente,projektübergreifendeDatenüberdenUmfangseines Anwendungssystem-undProjektportfolios,diebeispielsweisederBewertungdieserimmateriellenVermögenswerteinderBilanzzugrundegelegtwerdenkönnen.Darüberhinaus liefernFunctionPointszahlreicheMetriken,unteranderemzurQualitätsplanungundfür Management-Reviews,mitdenenStabilitätundZuverlässigkeitsowieProduktivitätvonIT- Systemenbeurteiltwerdenkönnen.DurchdieinternationaleStandardisierungsindsogar unternehmensübergreifendeBenchmarksmöglich. HerausforderungenderAufwandsschätzung Bei der Aufwandsschätzung von IT-Projekten ist Deutschland immer noch Entwicklungsgebiet [1]. Die Anzahl der Teilnehmer bei einschlägigen Tagungen in europäischen Nachbarländern (über 100) im Vergleich zu Tagungen der DASMA (Deutschsprachiger Anwenderverband für Softwaremetriken und Aufwandsschätzung e. V., www.dasma.org) oder der GI-Fachgruppe 2.1.10 (Software-Messung und -Bewertung, Gesellschaft für Informatik e.V., www.ivs.cs.uni-magdeburg.de/ sw_eng/ us) in Deutschland (ca. 50 Teilnehmer) vermittelte in den letzten Jahren jedenfalls diesen Eindruck. Aber es ist Bewegung im Markt, denn die Anzahl der DASMA-Mitglieder z. B. ist in den letzten Jahren auf inzwischen fast 70 gewachsen. Das heißt, dass zunehmend mehr Firmen ernsthaft am Thema Aufwandsschätzung interessiert sind. Oder sie haben schmerzhaft erfahren, was der Guru der Aufwandsschätzung, Capers Jones, in die Worte gefasst hat: „Ein fehlgeschlagenes Projekt kostet mehr als aller Aufwand, um ein Aufwandschätzverfahren in einem Unternehmen zu etablieren.“ [7] Für eine fundierte Planung von IT-Projekten und die Messung des Erfolgs nach Projektabschluss ist es notwendig, Schätzungen über Aufwand, Kosten, Termine und Dauer professionell durchzuführen. Das häufig angesprochene Problem fehlender empirischer Daten sowie der erhöhte zeitliche Aufwand können durch den Einsatz von Werkzeugen, durch ausführliche Dokumentation oder durch den Aufbau eines Competence Centers kompensiert werden [2]. Dieser Aufsatz beschäftigt sich daher sowohl mit den Problemen als auch den Möglichkeiten, zu guten Schätzergebnissen zu gelangen, und den Chancen, die die professionelle Aufwandsschätzung der Projektplanung bietet. Um es mit Capers Jones [7] klar auszusprechen: „Wer diese Software-Entwicklungsaufgabe nicht professionell wahrnimmt, handelt in seinem Beruf grob fahrlässig.“ In Italien ist deshalb gesetzlich vorgeschrieben, dass Softwareanbieter bei staatlichen Stellen den Leistungsumfang in Function Points angeben müssen. Die Hauptthemen der Aufwandsschätzung sind in Abb. 1 zusammengefasst. Die wichtigsten Themen der Aufwandsschätzung Schätzobjekt Zeitpunkte der Aufwandsschätzung Schätzgenauigkeit Schätzfehler Aufwand für die Aufwandsschätzung Schätzmethoden Tracking der Schätzungen Schätztools Schätzparameter Schätzehrlichkeit Schätzerfahrung Einführung der Aufwandsschätzung Schätzkultur ! ! Abb.1: HauptthemenderAufwandsschätzung projekt M A N A G E M E NT 1/ 20 0 5 aktuell 24 WISSEN DieFunction-Point-MethodealsVoraussetzungfür solideAufwandsschätzung Die Function-Point-Methode wurde 1979 von A. J. Albrecht bei IBM entwickelt und hat seither weite Verbreitung gefunden.1986 wurde die International Function Point Users Group (IFPUG) zum Zweck einer internationalen Standardisierung dieser Methode gegründet. Die Mitglieder der IFPUG erhalten kostenlos das so genannte IFPUG Counting Practices Manual (CPM), das die standardisierte und vereinheitlichte Version der Function-Point-Methode beschreibt, derzeit Release 4.2 (ISO- Standard ISO/ IEC 20926: 2003). Die IFPUG-Function-Point-Methode ist eine nach der ISO-Norm 14143-1 anerkannte Methode zur Messung der funktionalen Größe bzw. des Umfangs einer Anwendung aus Benutzersicht. Das heißt, es wird die vom Benutzer geforderte Funktionalität gemessen, die von der Fachabteilung nachgefragt, anhand des logischen Systementwurfs quantifiziert und für sie erbracht wird. Dieses Maß ist unabhängig von der für die Implementierung verwendeten Technologie, da nicht die technische Realisierung der Anwendung betrachtet wird. Grundlage der Aufwandsschätzung sind Informationen über das zu schätzende Projekt, beispielsweise ❏ Übersicht über die benötigten Daten (z. B. Objektkatalog oder relationales Datenmodell), ❏ Masken-, Listenlayout etc., ❏ Anzahl und Umfang der Schnittstellen, ❏ Abläufe aus Benutzersicht, Dialogablauf, z. B. alle Prozessflussmodelle mit den dazugehörigen Aktivitäten, Use Cases etc. Fehlende Informationen müssen durch dokumentierte Annahmen ersetzt werden, ansonsten gerät das Schätzen zum Raten. Die Bandbreite des Schätzergebnisses hängt dabei von der Sicherheit dieser Annahmen ab. Grundsätzlich gilt: Je mehr Informationen über das Schätzobjekt vorliegen, desto genauer wird die Schätzung. FunctionPointsaufeinenBlick Abb. 2 zeigt die Komponenten der Function-Point-Methode. Als Erstes wird die Grenze der Anwendung in einem Architekturdiagramm festgelegt, damit festgestellt werden kann, welche vom Benutzer geforderten Geschäftsvorfälle Daten über die Grenzen der Anwendung transportieren. Das können ❏ Eingaben (EI = External Inputs), ❏ Ausgaben (EO = External Outputs) oder ❏ Abfragen (EQ = External Inquiries) sein. Dazu werden ❏ interne Dateien (ILF = Internal Logical File) und ❏ externe Dateien (EIF = External Interface Files) benötigt. Diese fünf Komponenten (EI, EO, EQ, ILF, EIF) werden für alle vom Benutzer geforderten Geschäftsvorfälle jeweils nach den Regeln des IFPUG CPM mit einfach, mittel oder hoch bewertet. Anhand einer im CPM vorgegebenen Tabelle wird dazu die Anzahl der Function Points bestimmt. Die Summe aller Function Points der Anwendung ist der funktionale Umfang. Der interessierte Leser findet in [3, Kapitel 8 bis 12] eine genaue Beschreibung der Function-Point-Methode. Die Function-Point-Methode unterscheidet zwischen den ungewichteten Function Points und den gewichteten Function Points. Zur Berechnung der gewichteten Function Points werden 14 Systemmerkmale jeweils mit 0 bis 5 Punkten eingestuft. Diese 14 Systemmerkmale berücksichtigen Parameter aus der Systementwicklung. Sie sind daher kein funktionales Maß mehr, sondern bereits ein Schritt in Richtung Aufwandsschätzung. Da diese Schätzparameter unternehmensspezifisch und projektspezifisch sind, werden für das externe Benchmarking sinnvollerweise nur ungewichtete Function Points verwendet. Die ISO hat deshalb als funktionales Maß für IT-Systeme nur die ungewichteten Function Points anerkannt. DerSchrittvomMessenzumSchätzen Grundsätzlich gilt es, zwischen Zählen und Schätzen zu unterscheiden. Das Ergebnis der Zählung von Funktions- Punkten (Function Points) oder Code-Zeilen (KLOCs: Kilo Lines of Code) ist lediglich ein Ausgangspunkt (der wichtigste Parameter) für die eigentliche Aufwandsschätzung. Dabei gilt folgende Prämisse: „Was Sie nicht messen können, können Sie auch nicht kontrollieren.“ [4] Die Schätzerfahrungen vergangener Projekte spielen dabei eine große Rolle, lassen sich jedoch nur nutzen, wenn sie auch ausreichend dokumentiert wurden [2]. Prinzipiell wird bei der Aufwandsschätzung, ausgehend vom Umfang der zu entwickelnden Software, unter Berücksichtigung weiterer Parameter der Aufwand berechnet, indem Daten von Umfang und Ist-Aufwand früherer Projekte zueinander in Bezug gesetzt werden. Dazu werden typischerweise mindestens je drei kleine, mittlere und große Projekte nachkalkuliert, so dass im einfachsten Fall aus den Zahlenpaaren Umfang/ Aufwand durch eine Regressionsanalyse eine Erfahrungskurve berechnet werden kann. Diese Erfahrungskurven haben die Form y = a · x b mit y = Aufwand, x = Umfang und a, b aus der Regressionsanalyse ermittelt: a = Koeffizient, b = Exponent. Weiterentwickelte Verfahren aufgrund von Projektdatenbanken, wie z. B. die ISBSG-Datenbank, COCOMO (Constructive Cost Model, Barry Boehm), SLIM (Software Lifecycle Management, L. H. Putnam) und weitere Schätztools berücksichtigen in ihren Schätzgleichungen noch weitaus mehr beziehungsweise andere Parameter als Anwendungsgrenze Andere Anwendung Benutzer Eingabe (EI) Ausgabe (EO) Abfrage (EQ) Interner Datenbestand Externer Datenbestand EI EO EQ Abb.2: DieFunction-Point-Methode aktuell projekt M A N A G E M E NT 1/ 20 0 5 25 den Umfang. Teilweise werden diese Einflussgrößen von den Anbietern allerdings als Betriebsgeheimnis gehütet. COCOMO und SLIM z. B. sind im Gegensatz zu Function Points LOC-basierte Schätzmethoden. Lines of Code (LOC) sind gegenüber Function Points (Fachkonzept) erst spät im Projekt bekannt (Realisierungsphase) und messen den technischen Umfang, während Function Points den funktionalen Umfang messen. Backfiring nennt man den Versuch, Formeln für die Umrechung von Functions Points in LOC oder umgekehrt zu entwickeln. Das setzt voraus, dass man beide Größen misst und den Unterschied zwischen technischem und funktionalem Maß vernachlässigt. LOCs haben auch mit dem Paradoxon der Sprachumrechnungsfaktoren zu kämpfen (Assembler-Äquivalent). Danach hat z. B. ein Programm bei einem Ist-Aufwand von angenommen einem Personenmonat (PM) einen Umfang von beispielsweise 10.000 LOC Cobol und damit eine Produktivität von 10.000 LOC pro PM. Das gleiche Programm in Assembler entspricht einem Umfang von 30.000 LOC (Assembler-Äquivalent) und hat damit eine Produktivität von 30.000 LOC/ PM, ist also dreimal so produktiv wie die COBOL-Programmierung, was der praktischen Erfahrung widerspricht. LOC-Methoden sind deshalb bei Metrikspezialisten weltweit sehr umstritten. UmfangmaßenachISO-Norm Es gibt in der Software-Industrie die international normierten Metriken der ISO 14143 (ISO = International Organization for Standardization). ISO 14143-1 ist seit 1999 Standard und beschreibt die grundlegenden Prinzipien einer funktionalen Größenmetrik (Functional Size Metric) und die nötigen Definitionen dazu. ISO 14143-2 beschreibt die Prüfkriterien zur Feststellung, ob eine Methode funktionale Metrik im Sinne von ISO 14143-1 ist. ISO 14143-3 stellt Messkriterien in Form von Checklisten für Assessments zur Verfügung, anhand deren bewertet werden kann, wie gut eine funktionale Größenmetrik ISO 14143-1 erfüllt. Derzeit (Ende 2004) sind nur Varianten der Function-Point-Methode nach ISO 14143-1 anerkannte Public Available Standards (PAS). Dabei handelt es sich um ❏ die IFPUG-Function-Point-Methode Version 4.1 (IFPUG = International Function Point User Group, www.ifpug.org), ISO/ IEC 20926; ❏ die COSMIC Full Function Points (COSMIC = Common Software Measurement Consortium, www.cosmicon.com), ISO/ IEC 19761; ❏ die NESMA-Function-Point-Methode (NESMA = Niederländische Metrik Organisation, www.nesma.org), ISO/ IEC 24570; ❏ die Mark-II-Function-Point-Methode (von Charles Symons in England für Entwicklungen mit Programmiersprachen der 4. Generation entwickelt, www. uksma.co.uk), ISO/ IEC 20968. COSMICFullFunctionPoints(FFP) Die IFPUG-Methode ist anerkannt für Zählungen von so genannten Geschäftsanwendungen und MIS-Systeprojekt M A N A G E M E NT 1/ 20 0 5 aktuell 26 WISSEN men (Management-Informationssysteme). Ein wesentlicher Kritikpunkt daran ist jedoch, dass sie nicht für die Messung von Echtzeit-Anwendungen, Anwendungen zur Prozesskontrolle oder auch Betriebssystemen geeignet sein soll, obwohl A. J. Albrecht sie ursprünglich bei einem Projekt zur Entwicklung eines Betriebssystems entwickelt hat. Darüber hinaus war zwar die Technologieunabhängigkeit der Methode begrüßt worden, aber das Fehlen von verschiedenen Sichten (Entwickler, Endbenutzer, …) bemängelt worden. Genau in diese Lücke stößt das Common Software Metrics Consortium (COS- MIC) mit seinen Full Function Points (FFP). Diese COS- MIS FFP Version 2.2 wurden nach zahlreichen Feldversuchen 2003 als ISO-Norm ISO/ IEC 19761: 2003 standardisiert. Das Handbuch dazu kann aus dem Internet heruntergeladen werden unter www.lrgl.uqam.ca/ cosmicffp. Eine genaue Beschreibung der Methode ist in [3, Kapitel 9.3] zu finden. Die COSMIC-FFP-Methode leitet die funktionale Größe aus der Anzahl der zur Durchführung eines Prozesses notwendigen Datenbewegungen ab. Daneben wird ein Schichtenkonzept (Software-Layers) verwendet. Eine Überprüfung von fünf Applikationen mit IFPUG FP und COSMIC FFP ergab kaum Differenzen im MIS-Umfeld, aber 70 % Unterschied bei Realtime-Systemen. In der ISBSG-Benchmarking-Datenbank sind bereits mehr als 60 COSMIC-FFP-Projekte enthalten. Durch die Entwicklung mit einem weltweiten Konsortium von Unternehmen unter wissenschaftlicher Begleitung der Universität von Montreal, Canada (Prof. Alan Abran) ist die COSMIC- FFP-Methode die erste Methode zur Umfangmessung, die vor dem Einsatz validiert wurde. Dadurch stand bereits von Anfang an eine Erfahrungsdatenbank zur Verfügung. Die COSMIC-FFP-Methode konnte auf den Erfahrungen der anderen Methoden aufbauen und wird deshalb auch als Methode der zweiten Generation bezeichnet. PraktischeErfahrungenundSynergieeffektebeim EinsatzderFunction-Point-Methode Die Function-Point-Methode dokumentiert objektiv und einheitlich die Anwendungssysteme aus Benutzersicht, und zwar konsistent mit dem Verständnis der Anwender über die Funktionalität der Anwendungssysteme (einheitliche Sprache für IT und Fachbereich). Damit kann die Benutzerzufriedenheit mit dem Projekt gesteigert werden. Die Strukturierung aus der Sicht der Endbenutzer zeigt die Elementarprozesse entsprechend den Business Requirements (Geschäftsprozesse) und führt damit zu einem besseren Design zu und besseren Steuerungsmöglichkeiten im Projektverlauf. Die Informationen sind für Architektur, Spezifikation, Entwicklung, Weiterentwicklung und Wartung sowie die Ableitung von Testfällen, für die Releaseplanung und nach Dokumentation für die Einarbeitung von anderen Mitarbeitern wiederverwendbar. Veränderungen können damit in der Entwicklungsphase in das Fachkonzept eingearbeitet und abgestimmt werden. Somit können Abweichungen erkannt und gegebenenfalls neue Zielvereinbarungen getroffen werden. Durch Toolunterstützung können die Geschäftsvorfälle standardisiert einem Projekt zugeordnet, festgehalten, beschrieben, gruppiert, Datenfeldern und Dateien zugeordnet und von Fachbereich und IT gemeinsam bearbeitet werden. Der Entwicklungsstand kann in einzelnen Phasen archiviert sowie eingefroren und als IST-Konzept vereinbart werden. Bei wiederholter Zählung kann der schleichende Funktionszuwachs gemessen werden und damit eine Frühwarnung erfolgen, falls das Projekt aus dem Ruder zu laufen droht. Insgesamt fördert das die gute Zusammenarbeit zwischen IT und Fachbereich, hilft Missverständnisse zu beseitigen, unterstützt das Gelingen der Projekte und führt insgesamt zu einer deutlichen Verbesserung der Qualität und zu Reuse-Möglichkeiten im ganzen Software-Entwicklungsprozess. DieAufwandsschätzungalsVoraussetzungfürsolideProjektplanung Voraussetzung für das Gelingen eines Softwareprojekts ist eine fundierte Planung. Dazu gehört vor allem eine realistische Aufwandsschätzung. Aufwandsschätzungen liefern Werte zu Aufwand, Terminen, Kosten und Projektdauer, die in die Planungen einfließen und später nachverfolgt werden können. Neben Planung und Controlling wird dadurch auch die Erfolgsmessung sowie das Lernen aus der Vergangenheit zur Schätzung zukünftiger Projekte unterstützt [2]. Die für eine realitätsnahe Planung benötigten Größen Aufwand, Termine, Kosten, Projektdauer und Ressourcen sind neben den sachlichen Projektzielen die wichtigsten Einflussfaktoren auf den Erfolg eines Projekts. Nur durch eine professionell durchgeführte Aufwandsschätzung kann der Projektleiter diese Informationen verlässlich erhalten. Nicht vorhandene Dokumentationen und fehlende Erfahrungen sind eines der häufigsten Probleme, auf die Projektleiter stoßen, wenn sie Aufwandsschätzungen (oder Projektplanungen) vornehmen müssen. Da hilft nur, sofort damit anzufangen, sonst kann der Teufelskreis nie durchbrochen werden! [2] KritischeErfolgsfaktorenderAufwandsschätzung Die in Abb. 1 aufgeführten Hauptthemen der Aufwandsschätzung sind auch gleichzeitig die kritischen Erfolgsfaktoren. Davon stehen besonders die Schätzgenauigkeit und die Schätzzeitpunkte im Vordergrund, zumindest bei der Einführung von Aufwandschätzmethoden. Außerdem sind frühe Schätzungen und das Managen von Akzeptanzproblemen kritische Variablen des Einführunsprozesses. SchätzgenauigkeitundSchätzzeitpunkte Die, je nach Schätzzeitpunkt (siehe Abb. 3), mehr oder weniger große Unwissenheit über die Schätzparameter hat zur Folge, dass ❏ das Ergebnis einer Schätzung nie eine absolute Zahl, sondern immer ein Intervall ist, ❏ die Bandbreite dieses Intervalls mit dem zur Verfügung stehenden Wissen über das Schätzobjekt zusammenhängt und ❏ die Unsicherheit in dem Maße abnimmt, in dem die Aufwandsschätzung nachverfolgt wird [2]. Ein weiteres Problem liegt in einem schleichenden Funktionszuwachs (requirements creep) aufgrund technischer Änderungen. Dieser Funktionszuwachs kann, in aktuell projekt M A N A G E M E NT 1/ 20 0 5 27 Abhängigkeit vom Projektumfang, bei mehr als drei Prozent je Monat Projektlaufzeit liegen. Er lässt sich durch wiederholte Messung des Umfangs während des Projektverlaufs ermitteln und steuern. Die Aufwandsschätzung darf deshalb nicht als ein einmaliges Ereignis angesehen werden, sondern ist ein Prozess, der das Projekt während der gesamten Dauer begleitet. Erneutes Schätzen mit zeitlichem Fortschritt oder nach größeren Änderungen eines Projekts ist unerlässlich, um die Schätzgenauigkeit zu erhöhen. Werden Schätzungen zudem mit unterschiedlichen Methoden durchgeführt und eventuell mit Hilfe Dritter validiert, trägt dies weiter zu einer Qualitätssteigerung bei. FrüheSchätzungen Paradox an der Situation ist, dass gleichzeitig sowohl frühe als auch genaue Schätzungen benötigt werden. Frühe Schätzungen sind jedoch in der Regel ungenau. Da oft die Schätzungen nicht professionell dokumentiert werden, kann auch nicht aus den Erfahrungen der Vergangenheit gelernt werden. So schließt sich der Teufelskreis: Schätzen erfolgt zu früh und zu selten! Bei frühen Schätzungen kann nur grob anhand der wenigen vorhandenen Informationen geschätzt werden. Für Unsicherheit und Risiken wird mit Zuschlägen, abhängig vom Projektumfang, in Höhe von 10 bis 30 % gerechnet. Hinzu kommt der geschätzte Funktionszuwachs für noch zu erwartende technische Änderungen (siehe oben: Schätzgenauigkeit und Schätzzeitpunkte). Bei Auswertungen genau dokumentierter Function- Point-Zählungen mit Hilfe von Regressionsanalysen konnte in der AXA Service AG ein starker Zusammenhang zwischen der Anzahl der gezählten Eingaben und Ausgaben mit den Funktionspunkten insgesamt ermittelt werden (siehe Abb. 4). Damit können bereits zu frühen Zeitpunkten (zum Zeitpunkt der Studie, also vor Projektbeginn) Prognosen für die erst später genauer zählbaren Function Points vorgenommen werden, die eine hohe Prognosegenauigkeit aufweisen (Fehlermarge ca. 12 %). Akzeptanz Die Einführung einer neuen Methode hat üblicherweise mit Akzeptanzproblemen zu kämpfen. Als Lösung bietet sich an, den Königsweg für die Einführung von Innovationen zu beschreiten: umfassende Information, gute Ausbildung und Partizipation aller Beteiligten! Daneben kann man einige akzeptanzfördernde Maßnahmen ergreifen, wie z. B. ❏ Vorbereitung von Gegenargumenten gegen Killerphrasen und Befürchtungen, ❏ Schätzklausuren, die das gemeinsame Verständnis im Team fördern, ❏ Toolunterstützung, die die Überlebenschancen von Methoden erhöht, ❏ Messen von Prozessen, nicht Personen, ❏ Bewusstsein dafür schaffen, dass Umfangmessung notwendig und nicht Overhead ist und ❏ Unterstützung durch das Management. Die Auswirkungen fehlender Akzeptanz sind Wider- Studie Projektvorbereitung Analyse Design Realisierung Test Einführung Start Projekt Abschluss 1 2 3 4 5 6 7 Grobe Schätzung Verbindliche Schätzung (daran wird der Projekterfolg gemessen) Tracking der Schätzung Schätzerfahrungen dokumentieren, Nachkalkulation durchführen Abb.3: Schätzzeitpunkte IO (Anzahl EI + EO) y = 7,7905x + 43,499 R 2 = 0,9483 Function Points Abb.4: Function-Point-Prognose projekt M A N A G E M E NT 1/ 20 0 5 aktuell 28 WISSEN stände bei den betroffenen Mitarbeitern. Einige beliebte Killerphrasen gegen die Function-Point-Methode und Gegenargumente dazu zeigt Abb. 5. Zum Umgang mit Widerständen sind die in Tabelle 1 gezeigten Maßnahmen empfehlenswert. AufwandsschätzunginspeziellenUmgebungen Das Aufkommen neuer Technologien in der Software- Entwicklung hat für die Aufwandsschätzung und Function-Point-Zählung Herausforderungen gebracht, denn die Methoden wurden aus Erfahrungen der Vergangenheit entwickelt, um Hilfen für die Planung von zukünftigen Projekten und Anwendungssystemen zu bieten. Dabei zeigte sich, dass die bewährten Konzepte auch in neuen Umfeldern einsetzbar sind. Speziell im objektorientierten Paradigma, bei Datawarehouse-Systemen und Web- Entwicklungen ist die Function-Point-Methode einsetzbar, wobei einzelne Anpassungen vorzunehmen sind. ObjektorientierteMetriken Über 200 verschiedene objektorientierte Software-Metriken sind in den letzten Jahren publiziert worden. Horst Zuse [8] hat über 130 davon zusammengestellt und teilweise erläutert. Auch die ISBSG-Benchmarking-Datenbank vom Juni 2002 enthält knapp 25 % Projekte, in denen mit objekorientierten Metoden gearbeitet wurde [6]. Häufig wird behauptet, dass objektorientierte Metriken nicht mit der Function-Point-Methode kompatibel seien, obwohl Fetcke et al. [5] für die objektorientierte Systementwicklung eine Konzeption und konkrete Regeln für die Umsetzung in Function Points vorgelegt haben. Auch die IFPUG hat eine ausführliche Fallstudie (Case Study III) für den Einsatz der Function-Point-Methode bei objektorientierter Systementwicklung vorgelegt. Dabei sind Klassen Kandidaten für interne und externe Dateien. Objekte sind Kandidaten für Eingaben, Ausgaben und Abfragen. Ebenso beschreiben Use Cases aus dem UML- Umfeld (Unified Modelling Language) die Funktionalität aus Benutzersicht und können somit leicht in Function Points bemessen werden [3, Seite 223 ff.]. Function-Point-ZählungvonDatawarehouse- Projekten Die Anforderungen an Datawarehouse-Systeme unterscheiden sich erheblich von den Anforderungen an transaktionsorientierte Systeme. Nach Auswertungen der ISBSG-Benchmarking-Datenbank beträgt der Anteil von Code- und Referenztabellen in Datawarehouse-Systemen im Verhältnis zum funktionalen Umfang bis zu 60 % gegenüber Management-Informationssystemen, wo er oft 30 bis 40 % beträgt. Die Multidimensionalität der Datawarehouse-Architektur ist eine Herausforderung für die Function-Point-Zählung. Inzwischen sind zwei Vorschläge für die Zählung von Datawarehouse-Systemen publiziert worden [3, Seite 386 ff.]. AufwandsschätzungvonWeb-Entwicklungen Web-Entwicklungen unterscheiden sich von konventioneller Software-Entwicklung durch ihre Einbettung in mehrstufige, komponentenbasierte Client-Server-Architekturen (oft vier oder fünf Stufen). Dabei werden häufig bestehende Alt-Anwendungen integriert. Bei der komponentenbasierten Software ist die Implementierung gekapselt. Die Komponentenorientierung ändert nichts an der Zählweise der Function Points, unterstützt vielmehr den Einsatz der Function-Point-Methode für die Messung des Softwareumfangs von Web-Entwicklungen [3, Seite 398 ff.]. Die Erweiterung von Alt-Anwendungen um Web-Frontends kann dabei wie ein Weiterentwicklungsprojekt gezählt werden, die Neuentwicklung kompletter Web-Anwendungen wie ein Neuentwicklungsprojekt. Einzige Herausforderung ist die Aufwandsschätzung statischer Webseiten. Dabei geht es hauptsächlich um die Gestaltung und Verlinkung hart kodierter HTML-Seiten über spezielle Entwicklungsprogramme oder Texteditoren. Die Aufwandsschätzung erfolgt hier zweckmäßiger durch Expertenschätzungen auf Basis der jeweiligen Mengengerüste. Function Points sind unbeliebt, weil … ... sie von Theoretikern erstellt und praxisfern sind. Ursprünglich von A. Albrecht in einem Projekt zur Erstellung von Systemsoftware entwickelt. ... sie Verwaltungsaufwand produzieren. Der Aufwand ist im Vergleich zu Nutzen und Projektgesamtaufwand vernachlässigbar gering. ... sie nicht für objektorientierte Anwendungsentwicklung geeignet sind. Die FP stellen ein Meta-Modell dar, daher ist eine Abbildung der Requirements, egal in welcher Beschreibung, möglich. Vorurteil Gegenargument Abb.5: KillerphrasenundGegenargumente Widerstand Istnatürlichundunvermeidlich. ErwartenSieWiderstand! Zeigtsichnichtimmeroffen. FindenSieWiderstand! HatvieleUrsachen. VerstehenSieWiderstand! DiskutierenSieüberdieBedenken, nichtüberdieArgumente! KonfrontierenSieWiderstand! EsgibtnichtnureinenWeg,Widerstandzubekämpfen! ManagenSieWiderstand! Tabelle1: MaßnahmenzumUmgangmitWiderständen aktuell projekt M A N A G E M E NT 1/ 20 0 5 29 AufwandsschätzungvonWartungsaufträgen/ Changes Bei Wartungsaufträgen/ Changes handelt es sich um kleinere Arbeitspakete, die in der Regel weniger als 100.000 EUR kosten und keine funktionale Weiterentwicklung der Software betreffen (0 Function Points). Damit entfällt der Umfang als wesentlicher Einflussfaktor für die Aufwandsschätzung. Dazu empfiehlt es sich, excelbasierte Schätzformulare zu entwickeln [3, Seite 160 ff.]. Die AXA Service AG hat mehrere Varianten solcher Schätzformulare im Einsatz: für grobe Schätzungen sowie Host, PC und Client/ Server, Bürokommunikation und Agentursystem. Dabei werden meist vorgegebene Standardaufwandssätze mit Einflussparametern multipliziert (z. B. Anzahl Ansprechpartner im Fachbereich mal Standardaufwand). Weitere Gemeinkosten-Zuschläge, z. B. für Projektmanagement und Testen, werden hinzugefügt. Damit wurden in der Pilotphase in zwei Jahren 220 Aufwandsschätzungen in fünf Abteilungen gesammelt, ausgewertet und daraufhin die Standardwerte verbessert. Im letzten Jahr wurden 130 Aufwandsschätzungen aus zwölf Monaten ebenfalls zu einer erneuten Aktualisierung der Standardwerte ausgewertet. Das Verfahren hat sich durch Mund-zu-Mund-Propaganda im Unternehmen verbreitet (Piloten waren drei Abteilungen, aber von fünf Abteilungen lagen am Ende der Pilotphase Aufwandsschätzungen zur Auswertung vor). Funktionale Erweiterungen/ Changes werden generell wie Neuentwicklungen behandelt. Beim Einsatz der Function-Point-Methode mit Toolunterstützung hat sich dabei herausgestellt, dass eine vernünftige Dokumentation der ursprüglichen Function-Point-Zählung (z. B. entlang den Menüpunkten der Bildschirmmasken und entsprechend den Transaktionen) bei der späteren Änderungsschätzung eine schnelle Zuordnung der zugehörigen Function Points erleichtert und damit der Umfang für die Änderungen schnell ermittelt und dem Auftraggeber mitgeteilt werden kann. ProfessionelleHilfestellungdurchMetrikorganisationen Speziell für Anfänger, aber auch zur Diskussion mit Fortgeschrittenen und Experten empfiehlt sich die Mitgliedschaft in einem nationalen Metrikverband, gegebenenfalls auch die weitere Mitgliedschaft in einer internationalen Metrikorganisation. Zum einen erhält man von Anwendern Hilfen für die effektive Einführung der Function- Point-Methode sowie durch den Erfahrungsaustausch in den Gremien der Organisationen die Möglichkeit, die eigene Betriebsblindheit zu überwinden. Außerdem bekommt man ständig neue Anregungen. Zum anderen trägt man durch seine Mitgliedschaft mit dazu bei, dass sich Software-Metriken weiter verbreiten und noch mehr etablieren. Dies ist insbesondere für das Benchmarking wichtig, denn ohne eine internationale Standardisierung ist ein firmenübergreifendes Benchmarking undenkbar. DASMA Die Deutschsprachige Anwendergruppe für Software- Metrik und Aufwandschätzung e. V. (DASMA) ist ein gemeinnütziger Verein und befasst sich mit der Entwicklung und Festsetzung von Standards zum Messen von Software. Sie fördert die Bewertung der Software zur Verbesserung ihrer Nutzung in Wirtschaft und Verwaltung. Gegründet 1993 in Darmstadt, hat sie derzeit (2004) ca. 70 Mitglieder in Deutschland, Österreich und der Schweiz. Außerdem ist die DASMA Mitglied der wichtigsten internationalen IT-Metrikorganisationen. Die DASMA versteht sich als Netzwerk und Berufsverband der deutschsprachigen Anwender von Software-Metriken und der Aufwandsschätzung [3, Seite 254 ff.]. GI-FG2.1.10Software-Messungund-Bewertung Die GI-Fachgruppe 2.1.10 Software-Messung und -Bewertung in Magdeburg besteht seit 1992 und wird von Prof. Reiner Dumke geleitet. Inhaltlich befasst sie sich sowohl mit den theoretischen Grundlagen im Bereich Softwaremessung und -bewertung als auch mit der praktischen Umsetzung im Software-Entwicklungsprozess, wie beispielsweise Zertifizierungen, Metrikdatenbanken oder Experience Factories. Dazu veranstaltet sie regelmäßig den International Workshop on Software Measurement - IWSM, der im Wechsel in Deutschland (zusammen mit der MetriKon- Tagung der DASMA) und Kanada (in Zusammenarbeit mit der Universität Quebec, Prof. Alain Abran) stattfindet (Proceedings 2001 unter www.lrgl.uqam.ca). Die Fachgruppe betreut auch das Softwaremesslabor (SMLab), das den Prototyp einer Messdatenbank im Internet anbietet. Darüber hinaus publiziert sie zweimal im Jahr die Meprojekt M A N A G E M E NT 1/ 20 0 5 aktuell 30 WISSEN trics News mit Informationen zu den Themen Softwaremessung und -Metriken. Die Homepage der Fachgruppe (www.ivs.cs.uni-magdeburg.de/ sw-eng/ us/ ) bietet zahlreiche Informationsmöglichkeiten [3, Seite 256 ff.]. IFPUG Die International Function Point User Group (IFPUG) in den USA (gegründet 1984) hat mit Version 4.1 eine standardisierte Function-Point-Methode verabschiedet, die genaue Anleitungen für die Zählung der Function Points enthält. Dieser Standard ist von der ISO im Oktober 2003 als ISO/ IEC-20926-Standard für die Umfangmessung von Software anerkannt worden (ohne die 14 Systemmerkmale). Die Aufwandsschätzung der IT-Projekte soll mit der Version 4.1 der IFPUG-Function-Point-Methode in einen aktuellen Stand versetzt und überbetrieblich vergleichbar werden. Ende 2004 veröffentlichte die IFPUG die weiter verbesserte Version 4.2. Weiter bietet die IFPUG an, ihre Mitglieder als Function-Point-Zähler zertifizieren zu lassen (seit 2004 auch als Metrikspezialist in mehreren Stufen). Sie richtet jährliche Tagungen zum Erfahrungsaustausch aus und arbeitet in zahlreichen Arbeitsgruppen an der Weiterentwicklung der Function-Point-Methode. So ist bereits 1998 als Ergänzung zu den zwei bereits bestehenden, detaillierten Fallstudien zur Function-Point-Methode noch eine dritte für die objektorientierte Software-Entwicklung herausgegeben worden. Die Homepage der IFPUG (www.ifpug.org) bietet Foren zum Informationsaustausch und aktuelle Informationen zu Software-Metriken und Aufwandsschätzung sowie zahlreiche Links zu anderen IT-Metrikorganisationen und Services für die IFPUG-Mitglieder [3, Seite 257 ff.]. ISBSG Die International Software Benchmarking Standards Group (ISBSG, gesprochen: IceBags - Eistüten) begann als ein loser Zusammenschluss von internationalen IT- Metrikorganisationen. Sie verwenden für die Schätzung des Projektumfangs zum überwiegenden Teil die Function-Point-Methode (meistens nach IFPUG). Diese IT- Metrikorganisationen trugen Informationen und Techniken mit dem Ziel zusammen, die Praktiken zur Software- Entwicklung zu verbessern. Im Juli 1994 trafen sich Vertreter von IT-Metrikorganisationen aus USA, England, Australien und Neuseeland und gründeten die ISBSG. Das bisher letzte Release 9 der ISBSG-Benchmarking- Datenbank erschien im Juni 2003 auf der Basis von mehr als 3.000 Projekten. Der bisher letzte Report „The Benchmark“ Release 8 wurde Mitte Januar 2004 anhand von 2.027 Projekten publiziert. Alle Unterlagen der IS- BSG können auch über das DASMA-Sekretariat bezogen werden [3, Seite 259 ff.]. MAIN Das Metrics Association’s International Network (MAIN) wurde 2002 in Brüssel mit dem Ziel gegründet, den Austausch von Informationen zwischen den europäischen Usergroups im Software-Metrik-Bereich durch Organisation von Konferenzen und Workshops etc. zu koordinieren. Es wurde beschlossen, die Informationen über Aktivitäten und Resultate der nationalen europäischen IT-Metrikorganisationen auszutauschen und eine gemeinsame Vertretung in der ISO, ISBSG und anderen internationalen IT- Metrikorganisationen sicherzustellen [3, Seite 266 ff.]. ■ Literatur [1]Bundschuh,Manfred: DieFunction-Point-Methodeim praktischenEinsatzbeiSoftwareprojekten.In: Schelleet al.(Hrsg.): LoseblattsammlungProjekteerfolgreichmanagen.13.Aktualisierungs-undErgänzungslieferung,Köln, November1999 [2]Bundschuh,Manfred: AufwandsschätzungalsVoraussetzungfürdieProjektplanung.In: Bernecker,Michael; Eckrich,Klaus: HandbuchProjektmanagement.R.OldenbourgVerlagMünchenWien2003,S.239-259 [3]Bundschuh,M.; Fabry,A.: Aufwandschätzungvon IT-Projekten.2.Auflage,MITPVerlag,Bonn2004,ISBN 3-8266-0864-X [4]DeMarco,Tom: Wasmannichtmessenkann…kann mannichtkontrollieren.MITPVerlag,Bonn2004,ISBN 3-8266-1488-7 [5]Fetcke,T.; Abran,A.; Nguyen,T.: FunctionPointAnalysis fortheOO-JacobsonMethod: AMappingApproach.In: ProceedingsoftheFESMAConference1998.Antwerp, pp.395-402 [6]ISBSG: TheBenchmark,Release8.ISBSG,Warrandyte, Victoria2002,ISBN0-9577-2018-1 [7]Jones,C.: AppliedSoftwareMeasurement.McGraw- Hill,NewYork1996,ISBN0-0703-2826-9 [8]Zuse,H.: AFrameworkforSoftwareMeasurement. DeGruyter,Berlin,NewYork1997,ISBN3-1101-5587-7 Schlagwörter FullFunctionPoints(COSMIC),Function-Point-Methode, Function-Point-Prognose,ISBSG-Benchmarking-Datenbank,Metrikorganisationen,objektorientierteMetriken, schleichenderFunktionszuwachs(requirementscreep), SoftwareumfangvonWeb-Entwicklungen,Umfangmaße nachDIN,ZählungvonDatawarehouse-Systemen Autor Dipl.-Math.ManfredBundschuhistseit über20JahrenimIT-RessortderAXA ServiceAGtätig,derzeitalsIT-Controller.Seitmehrals20Jahrenhater LehraufträgefürSoftwareEngineering sowieProjektmanagementundArbeitsmethodikanderFachhochschuleKöln undhatdabeiüber200DiplomandInnenbetreut.FürdiesenbesonderenEinsatzwurdeihm1996 dieEhrenmedaillederFachhochschuleKölnverliehen.Seit einigenJahrenisterVorstandsvorsitzenderderDASMAe.V. (DeutschsprachigerAnwenderverbandfürSoftware-MetrikenundAufwandsschätzung,www.dasma.org/ ).EristMitautorundMitherausgebervoneinigenIT-Fachbüchern.Sein Buch„AufwandschätzungvonIT-Projekten“ist2004inder2. Auflageerschienen. Anschrift SanderHöhe5 51465BergischGladbach Tel./ Fax: 02202/ 35719 E-Mail: manfred.bundschuh@freenet.de www.gm.fh-koeln.de/ ~bundschu aktuell projekt M A N A G E M E NT 1/ 20 0 5 31 Schätzklausur-MitExpertenwisseneinerealistische Projektkalkulationaufbauen MaxL.J.Wolf ImZugederProjektplanungmüssendieArbeitszeitenunddieDurchlaufzeitenderArbeitspaketeundderProduktkomponentengeschätztwerden.EineSchätzungberuhtaufErfahrungswerten,dieeinerseitsausvergangenenProjektengewonnenwerdenkönnen,andererseitsinMethodenundVerfahreneingearbeitetsind.WenndieErfahrungnichtvorliegt, istessinnvoll,sichentsprechendeExpertenandenTischzuholen,ummitdenFachleuten proArbeitspaketdenZeitaufwand(Mengengerüst)zuermitteln.EinesolcheSitzungwird Experten-oderSchätzklausurgenannt.EineSchätzklausurbedarfeinerintensivenVorbereitung,siesolldurcheinenModeratorgeführtwerden,unddieErgebnissefließeninden TerminplanundindieKalkulationdesProjektsein.ImFolgendenwerdenMethodenund VerfahrensweisenzurExperten-oderSchätzklausurvorgestellt.DieserArtikelistbereits inderLoseblattsammlung„Projekteerfolgreichmanagen“erschienen[1]undwurdenun aktualisiert. N achdem das Projektteam den Liefer- und Leistungsumfang (Projektergebnisstruktur), die Meilensteine und die Projektstruktur für sein Projekt aufgestellt hat, müssen die Arbeitspakete aus dem Projektstrukturplan zeitlich, kapazitäts- und kostenmäßig bewertet werden. Die zum Schätzen erforderliche Erfahrung hat das Projektteam möglicherweise aus vergangenen Projekten. Voraussetzung dazu ist, dass die Daten aus abgeschlossenen Projekten in einer Projektstruktur gesammelt werden. Die Projektstruktur aus solchen Projekten soll inhaltlich ähnlich dem zukünftigen Projekt sein. Erfahrungen aus früheren Vorhaben können nur dann vernünftig genutzt werden, wenn nicht Äpfel mit Birnen verglichen werden. In der Praxis scheitert die Dokumentation der Erfahrungswerte oft an den großen Unterschieden von Projekt zu Projekt. Es gibt allerdings verschiedene Firmen, die eine Erfahrungsdatenbank aufgebaut haben und trotzdem damit das Problem der Vergleichbarkeit von Projekten kaum lösen konnten. Nach wie vor müssen die gesammelten Erfahrungswerte stark subjektiv interpretiert werden. Dennoch können sie nach der Kalkulation der Arbeitspakete zu Plausibilitätskontrollen herangezogen werden. Das soeben beschriebene Vorgehen zeigt Abb. 1. Abb. 2 zeigt aus einem Software-Projekt (Anwendungsprogramm für Großrechner), wie viel Zeit prozentual ein Projektleiter für bestimmte Tätigkeiten verwendet. So werden zum Beispiel für die Projektplanung 25 %, für die Projektüberwachung 35 % und für die Koordinierung der Fachabteilungen 40 % aufgebracht. Diese Erkenntnis kann dazu verwendet werden, die Arbeitspakete des Projektleiters daraufhin zu prüfen, ob die neu ermittelten Aufwendungen mit den Erfahrungen kompatibel sind. Bisher ist der Weg „Erfahrungsauswertungen“ betrachtet worden. Liegen die Erfahrungen weder aus vergangenen Projekte noch aus Schätzungen vor, ist es erforderlich, die jeweiligen Arbeitspakete so weit zu verkleinern, dass sie zur Ermittlung des Aufwandes überschaubar und nachvollziehbar werden. Abb.1: GenerellesVorgehenzumSchätzeneinesArbeitspakets projekt M A N A G E M E NT 1/ 20 0 5 aktuell 32 WISSEN VorteilederSchätzklausur In der Praxis erreicht man mit der Expertenklausur eine Reihe von Vorteilen: ❏ Die durch die Experten ermittelten Aufwendungen sind tagesaktuell. ❏ Die Pläne wie Liefer- und Leistungsumfang und Projektstruktur werden durch die Experten kritisch unter die Lupe genommen. Dies trägt zur Klärung der Arbeitspakete bei und beseitigt bei den Beteiligten Missverständnisse, z. B. über den wirklichen Leistungsumfang und Zulieferungen, so dass ein gemeinsames Verständnis über die Arbeitspakete entsteht. Es ist wichtig, dass die Erkenntnisse der Experten über zugrunde liegende Annahmen schriftlich für jedes Arbeitspaket festgehalten werden. DerSchätzgegenstand Damit Termine und Kosten geplant werden können, werden die erforderliche Arbeitszeit pro Mitarbeiter und ihre Bewertung benötigt. Die Arbeitszeit, die ein Mitarbeiter pro Tag ohne Störung zum Bearbeiten des Arbeitspaketes benötigt, wird Aufwand genannt. Der Aufwand ist im Sinne der Kalkulation ein Produkt aus Arbeitszeit mal Mitarbeiter oder mal Anzahl der Mitarbeiter (Kapazität). Wenn dieser Aufwand mit einem firmenspezifischen Stundensatz bewertet wird, erhält man die Personalkosten. Neben den Personalkosten entstehen in einem Projekt so genannte Sachkosten wie zum Beispiel für Rechenzeiten, Geräte, Reisen, Material und Werkzeuge. Wenn ein Mitarbeiter auf Reisen geht, so fallen Reisezeiten (Personalkosten) und Reisekosten (Sachkosten) an (Abb. 3). Die ermittelten Personal- und Sachkosten fließen am Ende einer Projektplanung in eine Deckungsbeitragsrechnung ein. Die Kalkulation (Abb. 4) betrachtet verschiedene Kostenarten, die im herkömmlichen Sinne pro Baugruppe oder Komponente einer Anlage/ eines Produkts ermittelt werden. Im Wesentlichen handelt es sich um Material-, Fertigungs-, Forschungs-, Entwicklungs- oder Konstruktionskosten sowie Vertriebs- und Verwaltungsgemeinkosten. Wenn die Expertenklausur eingesetzt wird, dann müssen die Aufwendungen und Kosten pro Arbeitspaket ermittelt werden. Dies bedeutet, dass die Kosten der Arbeitspakete dokumentiert und zu einer Gesamtdeckungsbeitragsrechnung für das Projekt zusammengeführt werden. Dahinter steckt das Prinzip, immer die Kosten nach dem Verursacher zu schätzen und später auch zu ermitteln. Von pauschalen Zuschlägen im Gießkannenprinzip über das Projekt hinweg ist abzusehen. Abb.2: ErfahrungswertefürZeitbudgeteinesProjektleiters (Software-Projekt) Abb.3: Personal-undSachkosten Abb.4: KalkulationsschemaBaugruppen aktuell projekt M A N A G E M E NT 1/ 20 0 5 33 DieSchätzklausur Im Folgenden sollen Organisation, Spielregeln, Vorgehen, Voraussetzungen und Risikobetrachtung dargestellt werden. Organisation Mit der Vorbereitung der Expertenklausur steht und fällt der Erfolg bei der detaillierten Bewertung der Arbeitspakete. Experten in einer Firma sind in der Regel in die verschiedenen Projekte sehr stark eingebunden. Deshalb ist es sinnvoll, sie frühzeitig über den Termin der Expertenklausur zu informieren. Je nach Art der Arbeitspakete sind verschiedene Klausuren durchzuführen und die entsprechenden Experten einzuladen. Wird ein Projektstrukturplan für das Bauvorhaben Ampel als vereinfachtes Demonstrationsbeispiel betrachtet (Abb. 5), so könnten drei Expertenklausuren in Absprache des Moderators mit den Projektleitern durch- Abb.5: ProjektstrukturplanfürBauvorhaben„Ampel“ projekt M A N A G E M E NT 1/ 20 0 5 aktuell 34 WISSEN geführt werden: zum einen die Klausur für die Signalanlage und -steuerung, zum anderen eine Klausur für die Baumaßnahme und zum dritten eine Veranstaltung für Dienste, Management und übergreifende Aktivitäten. Den teilnehmenden Experten ist rechtzeitig der Projektstrukturplan mit Arbeitspaketbeschreibungen zur Vorbereitung zur Verfügung zu stellen. Für die Schätzklausur ist eine störungsfreie Atmosphäre zu schaffen. Im Durchschnitt werden nach vorliegenden Erfahrungen pro abzuschätzendes Arbeitspaket 10 bis 15 Minuten benötigt. Daraus ergibt sich die Zeit, die für die Schätzung des gesamten Projekts benötigt wird. DurchführungderSchätzklausur Moderator Der Moderator soll die Schätzklausur so organisieren, dass während der Klausur die Schätzwerte auf Flip- Charts oder in einem Kalkulationsprogramm erfasst werden können. Es muss sichergestellt sein, dass später nicht nachvollziehbar ist, welche Person welchen Schätzwert abgegeben hat. Es empfiehlt sich, am Ende der Klausur entsprechende Daten, die Rückschlüsse zulassen würden, zu vernichten. Damit soll verhindert werden, dass nach der Klausur Personen mit ihren Schätzwerten konfrontiert werden. Falls der Projektleiter darauf dringt, dass Arbeitspaketverantwortliche als Experten mitschätzen, ist darauf zu achten, dass diese nicht zu viel Reserven in die Arbeitspakete zur Sicherheit hineinschätzen. Der Moderator sollte vor Beginn der Expertenklausur auf einem Flip-Chart einen Standardtätigkeitsbogen (Abb. 6) mitbringen. Neben der eigentlichen Durchführung der Aufgabe werden Aktivitäten wie Übernahme der Aufgabe, Einarbeitung, Prüfung, Nacharbeiten, Abnahme, Koordination und Kommunikation sowie Schreibarbeiten und Reisezeiten mit geschätzt. Besonders zu Beginn der Schätzklausur ist dieser allgemeine Tätigkeitsrahmen abzuklären, damit alle Schätzer eine einheitliche Grundlage zum Ermitteln ihrer Schätzwerte haben. Spielregeln Zu Beginn der Expertenklausur sind die Regeln zum Schätzen zu verabreden und öffentlich auszuhängen. Wenn mehr als drei Personen schätzen, empfiehlt es sich, die Extremwerte zu streichen und aus den verbleibenden Werten den Mittelwert zu bilden. Eine Spielregel könnte auch sein, eine Diskussion unter den Experten zuzulassen, wenn beispielsweise die Abweichung von Einzelwerten vom Mittelwert mehr als 20 % beträgt. Damit soll herausgefunden werden, weshalb ein Fachmann sehr hoch oder ein anderer sehr niedrig geschätzt hat. Nach einer solchen Diskussion könnte die Schätzung auch wiederholt werden, um den Beteiligten die Möglichkeit zu geben, ihren zunächst genannten Wert zu revidieren. Ferner ist festzulegen, ob auf der Basis von Mitarbeiter-Tagen (MT) oder Mitarbeiter-Wochen (MW) kalkuliert wird. Bei größeren Projekten empfiehlt es sich, auf der Basis von Mitarbeiterwochen zu schätzen. Außerdem ist es hilfreich, konsequent nach 1,5 Stunden eine Pause einzulegen, um für jedes Arbeitspaket die gleiche Aufmerksamkeit und Konzentration zu erzielen. Vorgehen Nach dem Vorstellen der Tagesordnung und der Begrüßung der Experten wird anhand des Projektsteckbriefes das Projekt eingehend erläutert. Anschließend folgt, wie schon erwähnt, die Klärung der Schätzmethode und -regeln. Hier ist auf eine klare Kommunikation und Verabredung mit den Experten zu achten. Nun stellt der Moderator die Teile des Liefer- und Leistungsumfanges und der Projektstruktur vor, die Gegenstand dieser Schätzklausur sind. Das Schätzen erfolgt in zwei Schritten: Zunächst ruft der Moderator das jeweilige Arbeitspaket unter Nennung der Annahmen, des Ergebnisumfan- Abb.6: StandardtätigkeitenproArbeitspaket Abb.7: VorgehenbeiderSchätzklausur aktuell projekt M A N A G E M E NT 1/ 20 0 5 35 ges und der am Paket arbeitenden Personen auf. Gemeinsam legen die Experten mit dem Projektleiter den Ergebnisumfang fest. Dies kann bei einem Pflichtenheft die geschätzte Anzahl der zu schreibenden DIN-A4-Seiten, bei einem Software-Paket der prognostizierte Umfang des Source-Codes oder bei Grafiken die Anzahl der voraussichtlich zu erstellenden Zeichnungen sein. Ferner muss von den Schätzern entschieden werden, ob sie den Aufwand bezogen auf eine Person oder mehrere Personen ermitteln. Bei mehreren Personen fällt Kommunikationsaufwand an, der schon bei zwei Personen 10 bis 20 Prozent des Aufwands eines Arbeitspaketes betragen kann. Im zweiten Schritt schätzt jeder Experte unbeeinflusst von den anderen Teilnehmern den Aufwand pro Arbeitspaket. Jeder Schätzer schreibt seinen Aufwand auf eine Karte. Der Moderator ruft jeden Experten einzeln auf und notiert den Aufwand in ein Schätzformular (Abb. 8). Nachdem alle Werte ermittelt sind, werden zum Beispiel je nach Schätzregeln die Extremwerte weggestrichen und Abb.8: SchätzformularzurDokumentationderSchätzergebnisseproArbeitspaket Abb.9: BeispielfüreinenArbeitspaket-Auftrag projekt M A N A G E M E NT 1/ 20 0 5 aktuell 36 WISSEN es wird der Mittelwert gebildet. Bei größeren Abweichungen der genannten Aufwände pro Arbeitspaket erläutert jeder Experte, weshalb er zu seinem Wert gekommen ist. Bei dieser Diskussion werden häufig weitere Annahmen und offene Punkte aufgedeckt, die festzuhalten sind. Alternativ zu den Schätzformularen können auch die Arbeitspaket-Aufträge verwendet werden (Abb. 9). Der obere Teil des Arbeitspaket-Auftrages, wie Lieferungen/ Leistungen, Voraussetzungen und Abnahmebedingungen, wird vor der Expertenklausur erarbeitet. Der untere Teil wird während der Klausur von den Schätzern ermittelt. Sie ermitteln pro Arbeitspaket den Personalaufwand, den Materialaufwand und die Fremdbezüge. Wer später die Deckungsbeitragsrechnung durchführen muss, nimmt pro Arbeitspaket das Kalkulationsschema „Arbeitspaket“ (Abb. 10). Die Schätzklausur endet mit einer kurzen Zusammenfassung und der Versicherung an die Experten, ihnen am Ende des Projektes die IST-Werte pro Arbeitspaket zur Verfügung zu stellen. Dadurch werden die Experten motiviert, wiederzukommen und durch die Analyse der Abweichung ihre eigenen Erfahrungen zu stärken. Risikobetrachtung Die Expertenklausur kann um die Risikoanalyse erweitert werden (Abb. 11). Arbeitspaket für Arbeitspaket filtern die Schätzer die Risiken heraus. Diese werden dann nach Tragweite und Eintrittswahrscheinlichkeit bewertet. Zusätzlich schätzen die Experten die Kosten bei Eintritt des Risikos. Wird die Eintrittswahrscheinlichkeit mit den Kosten multipliziert, so können die Risikokosten für die jeweilige Wahrscheinlichkeit dargestellt werden. ■ Literatur [1]Wolf,M.L.J.: Expertenklausur-mitExpertenwisseneinerealistischeProjektkalkulationaufbauen.In: Schelle,H.; Reschke,H.; Schnopp,R.; Schub,A.: Projekteerfolgreichmanagen.Loseblattwerk,8.Aktualisierung,Kap.4.6.7,TÜV-Verlag,Köln1997 [2]Wolf,M.L.J.; Mlekusch,R.; Hab,G.: Projektmanagementlive.Instrumente,VerfahrenundKooperationenals GarantendesProjekterfolgs.5.,neubearbeiteteAuflage. Expert-Verlag,Renningen2004 Schlagwörter Arbeitspakete,Kostenschätzung,Projektdeckungsbeitragsrechnung,Risikoanalyse,Schätzklausur Autor MaxL.J.WolfistDiplom-Volkswirtund seit1990alsselbstständigerTrainerund BeraterfürUnternehmenundbeimVDI WissensforumzurStärkungderProjektmanagement-Kompetenzentätig.Erist LehrbeauftragteranderFachhochschule München,FachbereichWirtschaftsingenieurwesen,zumThemaProjektmanagement.SchwerpunkteseinerArbeitsindVermittlungvon MethodenvomStartbiszumEndekleinerundmittlererProjekte, UnterstützungbeiderKommunikationundKonfliktlösungin Teams,EinführungvonProjektmanagement-StandardsimMittelstand.Ihmistwichtig,dassdaserlernteWissenindiePraxis umgesetztwird.ErhatzahlreicheBeiträgevonderArbeitsmethodikbiszurProjektarbeitveröffentlicht,u.a.„Projektmanagementlive“(gemeinsammitR.MlekuschundG.Hab). Anschrift E-Mail: max.wolf@wolf-pmt.de Abb.11: SchemazurErmittlungderRisiken Abb.10: Kalkulationsschema„Arbeitspaket“ aktuell projekt M A N A G E M E NT 1/ 20 0 5 41 PM-Software: CostXPert Aufwands-/ Kostenschätzungfür Software-Entwicklungsprojekte MeyMarkMeyer DieSchwerpunktbeiträgeindieserAusgabebefassensichmitparametrischenSchätzverfahrenimAllgemeinenundderFunction-Point-MethodeimSpeziellen.Konsequenterweise stehtauchdieSoftware-ProduktvorstellungdiesesMalimZeichenderKostenschätzung: CostXPertbietetalgorithmischeKostenschätzungaufderBasisvonCoCoMoIIundenthält hierfürErfahrungswerteausüber20.000Softwareentwicklungsprojekten. D ie Benutzeroberfläche von CostXPert ist entsprechend einer fünfstufigen Vorgehensweise in einzelne Reiter unterteilt (siehe Abb.), die nacheinander die Eingabe der Projektdaten, des Produktumfangs der zu erstellenden Software, der Projektumgebung und die Beurteilung weiterer Randbedingungen erfordern und schließlich die Ergebnisse der Schätzung liefern. Der Anwender geht diese Reiter nacheinander durch und erhält im Ergebnis eine wahlweise auf mehreren verschiedenen Volumenschätzungen basierende Angabe zu den zu erwartenden Kosten und Dauern. Die Beschreibung des Projekts beinhaltet neben den administrativen Angaben (Projektbezeichnung, Angaben zu Projektleitung, …) auch die Angaben zu Stundensätzen und den verwendeten Programmiersprachen. Vor allem aber lässt sich das Projekt durch die Festlegung des Projekttyps, des Vorgehensmodells und der zu erfüllenden Standards beschreiben. Die Software bietet hier in der Voreinstellung rund 30 unterschiedliche Projekttypen: Webanwendungen unter Verwendung von ASP lassen sich hier ebenso auswählen wie Sprachsysteme für die Telekommunikation. Hinter diesen Projekttypen stehen jeweils (individuell anpassbare) Einstellungen für mögliche Risiken und Fehlerquoten sowie die typabhängigen CoCoMo-Koeffizienten nach Boehm zur Berechnung des Entwicklungsaufwands und der Entwicklungszeit. Auch für das verwendete Vorgehensmodell stehen mit etwa 40 Standardmodellen zahlreiche Alternativen zur Auswahl oder zur Anpassung an die unternehmensintern verwendeten Modelle zur Verfügung. Das ausgewählte Modell beeinflusst zunächst die resultierende Projektstruktur (beispielsweise im Vergleich eines Vorgehens nach dem Spiralmodell im Gegensatz zum Wasserfall-Modell) durch die dem Modell zu Grunde liegende Projektvorlage. Diese beschreibt die einzelnen Projektaktivitäten und ihren prozentualen Anteil am Gesamtprojekt, getrennt nach kleinen und großen Projekten. Die Auswahl eines Standards legt die im Zuge der Produkterstellung anzufertigenden Dokumente (z. B. Anforderungsspezifikation, Entwurf der Systemarchitektur) fest und umfasst auch die Koeffizienten zur Abschätzung des Umfangs dieser Dokumente in Abhängigkeit vom ermittelten Projektaufwand. Zur Einschätzung des Projektumfangs besteht neben der Angabe der Anzahl von Zeilen im Quelltext (Source Lines of Code - SLOC) die Möglichkeit, Schätzungen auf der Basis weiterer Methoden, wie Function Points, Internet Points oder UML Use-Case Points, durchzuführen. Zur Schätzung werden diese parametrischen Methoden anhand einer Umrechnungstabelle in SLOC umgerechnet - die Standardtabelle des Programms umfasst hierfür mit rund 600 Einträgen sowohl abstrakte Angaben (Sprache der 4. Generation) als auch konkrete Programmiersprachen bis hin zu herstellerspezifischen Entwicklungsumgebungen (C++, Borland C++ Builder 4). Die Berücksichtigung der Nutzung von wieder verwendbarem Code oder von Drittsoftware ist unabhängig von der gewählten Methodik zur Bestimmung des Produktumfangs möglich. In der Rubrik PM-Software stellt projektMANAGEMENTaktuell seinen Lesern neue und interessante Projektmanagementtools in Form herstellerunabhängiger Erfahrungsberichte und Nachrichten vor. Die Berichte stammen von Mey Mark Meyer, dem Leiter der GPM- Fachgruppe „Projektmanagement-Software“. Falls Sie zu diesen Berichten Ergänzungen oder eigene Erfahrungen einbringen oder sich an der Arbeit der GPM-Fachgruppe beteiligen möchten, können Sie sich per Mail unter „PM-Software@GPM-IPMA.de“ melden. In Kooperation zwischen der GPM-Fachgruppe und dem IPMI Institut für Projektmanagement und Innovation der Universität Bremen wurde zusätzlich eine umfangreiche Internet-Seite aufgebaut, in der Informationen zu über 120 Softwareprodukten rund um das Projektmanagement zu finden sind und eine Windows-Software zur Nutzwertanalyse von PM-Tools downloadbar ist. Dieses Informationsangebot wird laufend aktualisiert und erweitert. Sie erreichen es unter der Adresse „www.PM-Software.info“. GPM-Fachgruppe„Projektmanagement-Software“ projekt M A N A G E M E NT 1/ 20 0 5 aktuell 42 WISSEN Unter der Kategorie „Environment“ verbergen sich die Skalierungsfaktoren wie die Erstmaligkeit, die Entwicklungsflexibilität, der Zusammenhalt der Projektbeteiligten sowie die Reife des Entwicklungsprozesses und die Klärung von Architektur und Risiken. Jeder Faktor kann in sechs Stufen bewertet werden - bei Unsicherheit hilft jeweils ein Assistent, der nach einer Reihe von Einzelfragen die Einstellung auf eine der Stufen vornimmt. Weitere Parameter werden auf der Registerseite „Constraints“ eingestellt, hierzu zählen unter anderem die Reaktionszeit des Kunden in Hinblick auf seine Review-Aufgaben, die Risiko-Bereitschaft, der Umfang der erforderlichen Ermittlung von Kundenbedürfnissen oder der Anteil parallel laufender Vorgänge. Für diese Parameter stehen Skalen als Schieberegler zur Verfügung, für deren Einstellung jedoch kein Assistent angeboten wird. SchätzungsergebnisseundWeiterverwendung Das Ergebnis seiner Berechnungen stellt CostXPert auf dem letzten Reiter dar - für jede der verwendeten Methoden zur Bestimmung des Produktumfangs werden der ermittelte Aufwand und die Dauer in einer Übersichtstabelle ausgegeben, aus denen die zur Mittelwertbildung heranzuziehenden Methoden ausgewählt werden können. Das Ergebnis lässt sich nach dem eingesetzten Personal, dem Projektstrukturplan und den Auswirkungen der Projektrisiken weiter detaillieren. Daneben erstellt die Software auch eine Prognose der vermuteten Wartungskosten und schätzt den Umfang der Projektdokumentation ab. Die gewonnenen Schätzwerte lassen sich zur Weiterverarbeitung als Dateien für MS Excel, Primavera Team- Play und MS Project (MPX) exportieren. Hier offenbart sich allerdings eine mangelnde Internationalität der Anwendung - CostXPert erstellt englischsprachige MPX- Dateien, die von einer deutschen Version von MS Project CostXPert-derAnwenderarbeitetsichnacheinanderdurchdiehinterdeneinzelnenReiternliegendenDialogfenster. ■ Auseinsmachzwei: Projectplace.dehatseinProduktangebot aufgeteilt.MitdemProjectWorkspacestehtnuneinvornehmlichauf dieTeamkoordinationausgerichtetesAngebotzurVerfügung,dasim WesentlichenDokumentenmanagement,Vorgangsverwaltungund Kalenderfunktionenumfasst.DerProjectManagementWorkspace entsprichthinsichtlichPreisenundFunktionenamehestendembisherbekanntenFunktionsumfang.EtwasknappistundbleibtderSpeicherplatz.(www.projectplace.de) ■ AstaDevelopmentlieferteinenVersionssprung: DieneueVersion8 vonAstaPowerprojectermöglichtdieEinbindungvonPuffervorgängen. AußerdemwurdedieReporting-Funktionalitätverbessert. (www.astadev.de) ■ BBLSoftwareermöglichtfür>Projekta<nundenZugriffmittels HandyundGPRS.>Projekta<WAPistvorallemaufdenZugriffauf Adress-undTermininformationenausgelegt,ermöglichtaberauch denZugriffaufE-Mails.(www.bbl.de) +++ PM-Software-News +++ PM-Software-News +++ aktuell projekt M A N A G E M E NT 1/ 20 0 5 43 2003 nur unvollständig eingelesen werden - Ressourcen, Kosten und Anordnungsbeziehungen fehlten anschließend aufgrund der unterschiedlichen Feldbezeichner. Mit der englischsprachigen Version lässt sich eine so erstellte Datei hingegen problemlos einlesen. Die Übernahme der Ergebnisse wird daher zumeist Handarbeit bedeuten. Zur Präsentation der Daten bietet CostXPert die Option, eine MS-PowerPoint-Präsentation zu erstellen, welche die getroffenen Annahmen aufzählt und einige grafische Darstellungen der Ergebnisse beinhaltet. Den Berechnungen liegen nach Herstellerangaben über 20.000 ausgewertete Softwareprojekte zu Grunde. Das Programm liefert nach eigenen Angaben Schätzungen, die im Bereich von +/ - 7 % um die tatsächlichen Kosten liegen sollen, wenn - und hier greift die entscheidende Einschränkung - die Software mit den „genauen“ Basisdaten versorgt wird. Diese zu ermitteln dürfte angesichts der zahlreichen Parameter zunächst nicht einfach werden: Für die Einschätzung, mit welchem konkreten Prozentwert ein erwarteter hoher Aufwand für Integration und Tests als Abweichung von den als Standard vorgeschlagenen 100 % zu Buche schlägt, wird sich erst nach der Erfahrung einiger Projekte ein Gefühl entwickeln. Die Verbesserung zukünftiger Schätzungen anhand abgeschlossener Projekte wird unter anderem durch die Möglichkeit unterstützt, die in den Projekttypen hinterlegten Koeffizienten anhand eigener Ist-Werte zu kalibrieren. ToDos… Mehrere Währungen vermag das Programm nicht klar zu trennen - die Kosten werden in den in den Systemeinstellungen festgelegten Währungen erfasst. Der Kollege in Großbritannien, dem man die erstellte Schätzung zusendet, dürfte angesichts der nun auf Pfund lautenden identischen Beträge also zunächst einen wahren Kostenschock erleben. Immerhin: Sendet man ihm eine exportierte MPX-Datei, wird das korrekte Währungssymbol mit übermittelt. Die Plausibilitätsprüfung der Eingaben wirkt vereinzelt wie mit der heißen Nadel gestrickt. Wer beispielsweise die Angabe aktueller Projektdaten aktiviert, jedoch keine entsprechenden Werte einträgt, sieht sich mit Fehlermeldungen konfrontiert, die zwar aus der Sicht eines Softwareentwicklers einleuchtend sind, aber keinen Hinweis auf die Ursache des Problems liefern. Fazit Mit CostXPert liegt ein Produkt vor, das die Kosten- und Aufwandsschätzung von Softwareentwicklungsprojekten auf der Grundlage von CoCoMo II mit durchdachten Ansätzen unterstützt. Die Vielzahl von Parametern erfordert Erfahrung, die sich nur durch den Vergleich eigener Projekte mit den Schätzwerten der Software erlangen lässt. Bereits durch die strukturierte Darstellung der Parameter sorgt CostXPert jedoch in der Anwendung dafür, dass aufwands- und kostenrelevante Parameter erkannt werden. Die Schätzung wird zudem stark systematisiert, was tendenziell deutlich bessere Ergebnisse erwarten lässt, als „Ad-hoc-Schätzungen“ liefern würden. Die Möglichkeit, durch verschiedene Personen erstellte Schätzungen eines Projekts vergleichend betrachten zu können, würde das Produkt abrunden. Auf der Website des Herstellers steht eine zeitlich begrenzte Testversion zum Download zur Verfügung. Cost Xpert Group, Inc., San Diego, CA 92019, USA, E-Mail: info@costxpert.com, www.costxpert.com ■ + Unterstützung einer systematischen Schätzung + Umfangreiche, erweiterbare Bibliotheken zu Programmiersprachen, Vorgehensmodellen und Projekttypen - Datenexport nur als englischsprachige MPX-Datei möglich - Unterstützung mehrerer Währungen fehlerhaft Stärken/ Schwächen projekt M A N A G E M E NT 1/ 20 0 5 aktuell 44 KARRIERE „Führerschein“für Projektmanager „Projektmanagement-ZertifikatebietenVorteileaufdemArbeitsmarkt“ OliverSteeger DerMeisterbriefweistHandwerkeraus,dieApprobationdenArzt,dasDiplomdenIngenieur.UndProjektmanager? IhnenbietensichZertifikatean,dieihreKompetenznachweisen.DieseChancesolltensienutzen,meintDr.WernerDostal,LeiterderArbeitsgruppe BerufsforschungbeiderBundesagenturfürArbeit.DieBescheinigungkanndiePosition aufdemArbeitsmarktdeutlichverbessern.Allerdings: DasZertifikatmussstichhaltige AngabenzurQualifikationmachen-undauchzudemjenigen,deresausstellt.„Dreh-und AngelpunktderZertifikateistihreGlaubwürdigkeit“,betontderNürnbergerQualifikationsforscherimGesprächmitprojektMANAGEMENTaktuell.IstderAusstellerfürseineNeutralität,ObjektivitätundVerlässlichkeitbekannt,könnenZertifikatebeiderKarriereplanung sogarmehrnützenalsArbeitszeugnisse. Ein Blick in die Stellenseiten der großen Tageszeitungen zeigt: Projektmanagement-Qualifikationen werden in der Wirtschaft immer häufiger gefordert. Das ist richtig. Projektmanagement wird zunehmend zur Schlüsselqualifikation in Arbeitsfeldern, in denen geplant wird und Innovationen generiert werden. Immer mehr Mitarbeiter sind für Projektdurchführung und Projekterfolge verantwortlich und benötigen Projektmanagement-Kenntnisse. Das Problem für die Projektmanager besteht allerdings darin, diese Kenntnisse - also Theorie und auch Erfahrungen in der Praxis - nachzuweisen … Der Beruf „Projektmanager“ ist nicht geschützt, wie das bei anderen Berufen möglich ist, beispielsweise bei Ärzten oder Handwerksmeistern. Projektmanager haben keinen einheitlichen Meisterbrief und in der Regel kein staatliches Diplom. An die Stelle dieser Dokumente treten Zertifikate sehr unterschiedlicher Herkunft, die Kompetenz nachweisen sollen. Solche Zertifikate werden beispielsweise nach einem Lehrgang oder einer Prüfung ausgestellt. Projektmanager sollten sich also um den Erwerb von Zertifikaten bemühen? Zunächst einmal um eine gute Ausbildung. Viele, die sich im Projektmanagement qualifizieren, kommen aus der Praxis. Ihr Qualifizierungsbedarf ergibt sich aus ihrer aktuellen Tätigkeit. Sie wollen Wissen vertiefen oder verbreitern. Sie reflektieren ihr Wissen, verinnerlichen es und ordnen es ein. Auch werden Lücken gefüllt. Das ist ein guter Weg. Wichtig ist nur, dass diese berufliche Weiterbildung optimal dokumentiert wird. Und das geschieht mit Zertifikaten? Zertifikate sind im Allgemeinen ein empfehlenswerter Weg, Kompetenz und Erfahrung beim Arbeitgeber nachzuweisen. Generell erhalten Zertifikate auf dem Arbeits- Dr.WernerDostal,LeiterderArbeitsgruppeBerufsforschungbeiderBundesagenturfürArbeit: „Zertifikatefür ProjektmanagererhaltenaufdemArbeitsmarkteineimmer stärkereBedeutung.“ Foto: privat aktuell projekt M A N A G E M E NT 1/ 20 0 5 45 markt eine immer stärkere Bedeutung. Das betrifft nicht nur die Zertifikate, die zum Projektmanagement ausgestellt werden. Inwiefern erhalten sie eine stärkere Bedeutung? Die Erstauswahl von Bewerbungen erfolgt nach den eingereichten Unterlagen, denen ja Zertifikate beiliegen. Personalabteilungen wollen ihre Entscheidungen absichern und auf neutrale, objektive Argumente stützen. Ein Arbeitszeugnis, das ja keine negativen Aussagen beinhalten darf, kommt dafür nur bedingt in Frage. Also stützt man sich auf Zertifikate. Manche Seminaranbieter verleihen den Titel Projektmanager schon nach dem Besuch von kurzen Seminaren … Hier ist Misstrauen angebracht! Eine Berufsbezeichnung Projektmanager sollte erst verliehen werden, wenn der Unterricht ein halbes Jahr in Vollzeit gedauert hat. Wenn aber Berufsbezeichnungen so leichtfertig vergeben werden - wie sieht es dann um die Glaubwürdigkeit der Zertifikate aus? Eine allgemeine Antwort auf diese Frage gibt es nicht. Der freie Markt entscheidet über den Wert einzelner Zertifikate. Dies geht sogar so weit, dass sich der Wert einzelner Zertifikate von Unternehmen zu Unternehmen unterscheidet. Wie darf ich das verstehen? Es geht letztlich um die Frage, ob die jeweiligen Zertifikate glaubwürdig für die Personalabteilungen sind. Die Institution, die sie ausstellt, muss einen guten Ruf haben und die nötige Objektivität, Neutralität und Verlässlichkeit dokumentieren. Es kommt also nicht nur darauf an, welche Kompetenzen in dem Zertifikat bescheinigt werden - sondern auch, wer diese Bescheinigung vornimmt? Richtig. Was sollte ein Zertifikat über die Weiterbildung aussagen? Wesentliche Inhalte, Dauer der Ausbildung und Teilnehmerauswahl. Die Kompetenztiefe muss aufgezeigt werden. Eine Note sollte dokumentieren, wie gut jemand abgeschnitten hat. Was sollte es über den Anbieter aussagen? Informationen, die das Image des Ausstellers stützen: seine internationalen Kooperationen beispielsweise. Wenn das Zertifikat für die Teilnahme an einem Qualifizierungsangebot ausgestellt wird, sollte auch verzeichnet werden, ob eine dritte Instanz dieses Angebot akkreditiert hat. Diese akkreditierende Instanz müsste als Institution oder als Person über eine entsprechende Reputation verfügen. Wie gehen Unternehmen bei der Bewertung einzelner Zertifikate vor? Vorteilhaft ist es in jedem Fall, wenn der Aussteller des Zertifikats in dem Unternehmen bekannt ist und einen guten Ruf hat. Zusätzlich spielen die individuellen Erfahrungen eine Rolle, die ein Unternehmen mit Trägern dieser Zertifikate gemacht hat. Häufig ist es so, dass ein Unternehmen probeweise einen oder zwei Träger eines Zertifikats einstellt und beobachtet, wie sie sich entwickeln. Überzeugen die Leistungen, wird auch das Zertifikat gestützt. Das meine ich damit, wenn ich sage, dass der Markt den Wert der Zertifikate frei verhandelt. So sehr die Zertifikate ein Segen für Projektmanager sind: Auf den ersten Blick scheint es eher ungewöhnlich, dass man allein mit Zertifikaten die Qualifikation für verantwortungsvolle Tätigkeiten wie Projektmanagement nachweisen kann. So ungewöhnlich ist dies gar nicht. Wie gesagt, viele Berufe und berufliche Tätigkeiten sind in Deutschland ungeschützt. Ungeschützt heißt: Jeder kann diese Berufsbezeichnung benutzen. Es hat seinerzeit beispielsweise eine lange Diskussion darüber gegeben, ob die Bezeichnung Ingenieur geschützt werden soll. Man hat sie nicht geschützt, dafür aber mit Zusätzen versehen, beispielsweise mit dem Diplom. „EineBerufsbezeichnungProjektmanagersollteerst verliehenwerden,wennderUnterrichteinhalbes Jahrgedauerthat.“ Wie sind die Aussichten, dass auf ähnlichem Weg die Grenzen auch für den Beruf Projektmanager enger gezogen werden? Solche Impulse gehen entweder von Arbeitgebern, ihren Vereinigungen oder von Berufs- oder Fachverbänden aus. Hier fällt ins Gewicht, welche Bedeutung diese Verbände haben und welchen Stellenwert der Beruf für die Wirtschaft hat. In jüngerer Vergangenheit haben IT-Verbände durchgesetzt, dass eine Reihe neuer IT-Berufe als Ausbildungsberufe anerkannt und geschützt werden. Welche Funktion haben bei solchen Prozessen die Fach- und Berufsverbände? Die Rolle dieser Verbände darf man nicht unterschätzen, gleich, ob es Verbände der Industrie oder Berufs- und Fachverbände sind. Von ihnen geht häufig die Initiative aus, und sie machen auch mit Öffentlichkeitsarbeit den nötigen Druck. Zumeist sind sie es auch, die die Berufsbilder definieren. Besteht die Chance, dass Projektmanagement zu einem Ausbildungsberuf wird? Man sollte die berufliche Weiterbildung nicht unterschätzen. Viele, die sich im Projektmanagement qualifizieren, kommen aus der Praxis. Ihr Qualifizierungsbedarf ergibt sich aus ihrer aktuellen Tätigkeit. Sie wollen Wissen vertiefen oder verbreitern. In der Weiterbildung reflektieren sie ihr Wissen, verinnerlichen es und ordnen es ein. Auch werden Lücken gefüllt. Das ist ein guter Weg. Wichtig ist nur, dass diese berufliche Weiterbildung detailliert und objektiv dokumentiert wird. projekt M A N A G E M E NT 1/ 20 0 5 aktuell 46 KARRIERE ■ Premiere für das Projektmanagement-Diplom: Die ersten elf Dipl.- Projektmanager (FH) haben jetzt ihr Studium an der Fachhochschule Gießen-Friedberg abgeschlossen. Auf einer Feier in Bad Nauheim übergaben Professor Ulrich Vossebein, Professor Richard Roth und Professor Nino Grau die Urkunden. „Der staatlich anerkannte Abschluss öffnet vielen Absolventen auf dem Arbeitsmarkt ganz neue Türen“, unterstrich Vossebein. Wie aufmerksam Unternehmen das neu geschaffene Diplom verfolgen, zeige sich darin, dass Siemens, Audi und ABB robotics den Studiengang unterstützen. Was ihn freute: Zur feierlichen Diplomübergabe erschienen auch Vorgesetzte der Absolventen und gratulierten zum Erfolg. So wurde beispielsweise Friedrich Schöngarth (44) von seinem Abteilungsleiter begleitet. Der Gießener Projektmanager und Architekt ist beim Hessischen Baumanagement tätig. „Man stand mit Interesse und Teilnahme hinter meinem Studium“, berichtet er. Schöngarth hatte wie auch Tanja Kaul (34) und Thomas Diegelmann (36) seinerzeit aus der Tageszeitung von dem neuen Projektmanagement-Studium erfahren. Der weite Fokus des berufsbegleitenden Studiums reizte sie; neben Projektmanagement stehen allgemeines Management, interkulturelle Arbeit sowie Business English auf dem Curriculum. Friedrich Schöngarths Architekturstudium hatte in den achtziger Jahren das Thema Projektmanagement nicht einmal berührt. Heute gehört Projektmanagement zum täglichen Handwerkszeug im „Hessischen Baumanagement“, einem Unternehmen, das sich als ehemals staatliche Behörde jetzt dem Wettbewerb mit Anbietern aus der Wirtschaft stellt: ein klares Signal für den Architekten, sich weiter zu qualifizieren. „Nach dem Ende meines Studiums hoffe ich jetzt, mich bei größeren Projekten profilieren zu können“, sagt Schöngarth. Ein Wunsch, der durch anstehende Bauvorhaben gute Chancen auf Erfüllung hat. Indes, nicht nur für das aktive Projektmanagement leistet die Qualifikation gute Dienste. „In unserem Haus wickeln wir kleine und mittlere Projekte selbst ab“, berichtet Schöngarth, „größere Projekte lassen wir von externen Projektsteuerern begleiten.“ Um deren Leistung bewerten zu können, benötige er selbst profunde Projektmanagement-Kenntnisse. „Ein Auftraggeber kann halt nicht das gesamte Projektmanagement ungeprüft delegieren“, unterstreicht Schöngarth. Den beiden Frankfurter Volljuristen Tanja Kaul und Thomas Diegelmann dient das Studium gewissermaßen als „Grundstein“, auf dem sie sich beruflich breiter aufstellen wollen. „Ich habe in Projekten einer Frankfurter Bank mitgewirkt“, berichtet Thomas Diegelmann. Diese ersten Erfahrungen wollte er gezielt vertiefen. Er suchte eine Ausbildung, die Wissen vermittelt und mit einem akademischen Abschluss elegant in den Lebenslauf eines Juristen passt. Jetzt will Thomas Diegelmann seine beiden Qualifikationen miteinander verbinden und auf Rechtsfragen im Projektmanagement ausdehnen. Erster Schritt auf diesem Weg: Seine Diplomarbeit (gemeinsam mit Kommilitonin Tanja Kaul verfasst) steht unter der Überschrift „Recht im Projekt - Praxisrelevante rechtliche Aspekte im Projektmanagement und in der Projektmanagementausbildung“. „Auch in unserer Bank haben Projekte immer mehr an Bedeutung gewonnen“, berichtet Tanja Kaul, „deshalb ist ein gewisses Basiswissen im Projektmanagement förderlich.“ Doch Projekte zu managen kann man nur eingeschränkt lernen, indem man nur den Profis über die Schulter schaut. Nach dem Motto „ganz oder gar nicht“ entschied sie sich für das Studium an der FH Gießen-Friedberg. „Es ist für Arbeitgeber reizvoll, wenn man beide Qualifikationen zum Recht und zum Projektmanagement mit jeweils einem staatlich anerkannten Abschluss einbringen kann“, meint die 34-jährige Volljuristin; zumal Diplom-Projektmanager in Deutschland derzeit noch selten sind - und diplomierte Projektmanagerinnen noch seltener. Es gibt nämlich erst zwei … Das Sommersemester des Diplomstudiengangs „Projektmanagement (FH)“ startet am 14. März 2005 (Einschreibefrist bis 28. Februar 2005; Studiengebühren 10.500 EUR; GPM-Mitglieder erhalten zehn Prozent Rabatt). Weitere Informationen: Fachhochschule Gießen-Friedberg (Standort Friedberg), Professor Dr. Ulrich Vossebein, Tel.: 0 60 31/ 60 45 53, E-Mail: Ulrich.Vossebein@wp.fh-friedberg.de, www.fh-friedberg.de/ pm OliverSteeger ElfmaleinDiplomfürdieKarriereplanung FriedrichSchöngarth(44)ausGießen freutsichüberdasInteresseseines ArbeitgebersamProjektmanagement- Diplom. TanjaKaul,VolljuristinmitZusatzqualifikation„Diplom-Projektmanager(FH)“ ausFrankfurt ThomasDiegelmann,vonersten BankprojektenzumPM-Diplom Foto: privat Foto: privat aktuell projekt M A N A G E M E NT 1/ 20 0 5 L ei der w ur den i n H ef t 1/ 2005 von pr oj ek t M A - NAGEMENT aktuell im Artikel „Elfmal ein Diplom für die Karriereplanung“ auf Seite 46 die Fotos von Herrn Friedrich Schöngarth und Herrn Thomas Die gel m ann ver t auscht und den f al schen Bi l dunt er schr i ften zugeordnet. Die Redaktion bittet um Entschuldigung. 47 ■ Über 200 Projektmanager haben sich an der Gehaltsstudie, die die GPM erstmals in diesem Jahr durchgeführt hat, beteiligt. Damit wurde eine Datenbasis erhoben, auf deren Grundlage wesentliche Zusammenhänge zwischen der Ausbildung, der aktuellen Tätigkeit, der beruflichen Erfahrung sowie dem Gehalt aufgezeigt werden können. Ähnliche Studien, wie sie bereits häufiger bei anderen Berufsgruppen durchgeführt wurden, gelten Vorgesetzten und Personalleitern nicht selten als „objektive“ Grundlage für Gehaltsverhandlungen. Diese Orientierungsfunktion haben die Studien natürlich auch für die Bewerber, so dass die Verhandlungen auf einer gemeinsamen Informationsbasis geführt werden können, die den aktuellen Markt widerspiegelt. Darüber hinaus bietet die Studie einen sehr guten Einblick in die aktuelle Arbeitsmarktsituation von Projektmanagern. Wie viel Prozent der Projektmanager arbeiten ausschließlich in Projekten? Wie lange arbeiten sie durchschnittlich pro Woche und wie verteilt sich ihre Arbeitszeit? Wie viel Prozent der Projektleiter haben sowohl im Projekt als auch außerhalb von Projekten Führungsaufgaben? Welchen Anteil haben internationale Kontakte? Die Vielfältigkeit der Analysemöglichkeiten auf Grundlage der Studie ist in der Abbildung schematisch dargestellt, wobei der explizite Ausweis von Abhängigkeiten eine entsprechend große Teilgruppe in der Stichprobe voraussetzt. Die ersten Auswertungen zeigen, dass die Studie einen breiten Bereich des Projektmanagements abdeckt. Beispielsweise ergibt sich beim Alter der Befragungsteilnehmer eine Spanne von Mitte 20 bis fast 70 Jahren. Einige Befragte arbeiten nur zu einem geringen Anteil in Projekten, andere dagegen die gesamte Arbeitszeit. Große Unterschiede ergeben sich auch bei der Weiterbildung im Bereich Projektmanagement. Geringen Weiterbildungsaktivitäten stehen hier intensive Qualifizierungsmaßnahmen mit mehreren Zertifikaten gegenüber. Eine beeindruckende Spannbreite ergab sich auch beim Projektvolumen. Kleinprojekte mit einem Budget von einigen Tausend Euro treten ebenso auf wie Großprojekte mit Budgets von über 1 Mrd. Euro. PreiseimWertvonüber 5.000EURverlost! Die Ergebnisse der Studie sollen neben der Beschreibung der aktuellen Situation im Projektmanagement auch dazu dienen, weitere Erkenntnisse im Zusammenhang mit der Karriereentwicklung im Projektmanagement zu erhalten. Dieses Thema wird alle, die mit Projekten zu tun haben (und dies werden immer mehr), zukünftig noch stärker interessieren, da nach und nach die bisherigen Strukturen in vielen Unternehmen durch eine Projektorganisation ersetzt werden. D. h., neben der Linien- und Fachlaufbahn muss eine „Projektlaufbahn“ entwickelt werden. Zur Erfassung und Verfolgung dieser erwarteten Veränderungen wird die Studie zukünftig regelmäßig durchgeführt. In der nächsten Ausgabe soll an dieser Stelle ausführlicher über die Ergebnisse der Studie berichtet werden. Die GPM bedankt sich bei allen teilnehmenden Projektmanagern und freut sich, dass die erste von ihr durchgeführte Gehaltsstudie eine so beachtliche Resonanz gefunden hat. Jeder Teilnehmer an der Studie wird von der kommenden Auswertung der Daten profitieren, setzt sie ihn doch in die Lage, sein Einkommen in einem objektiveren Licht zu sehen und es mit seiner Karriereentwicklung in Beziehung zu setzen. Drei Befragte haben aber noch mehr Grund zur Freude. Alle Teilnehmer haben nämlich an der Verlosung von drei wertvollen Sachpreisen teilgenommen. Erster Preis - ein Semester im Weiterbildungsstudiengang zum Diplom-Projektmanager/ Projektmanagerin (FH) an der Fachhochschule in Friedberg im Wert von 4.000 EUR - geht an Herrn Oliver Bischoff aus München. Der zweite Preis - Teilnahme an einem bis zu dreitägigen Seminar der GPM - geht an Herrn Carsten Borth in CH-9443 Widnau. Den dritten Preis - eine Flasche Champagner - darf Herr Klaus Helbig aus Münster sein Eigen nennen. Allen drei Gewinnern sei an dieser Stelle ganz herzlich gedankt und gratuliert. Prof.Dr.NinoGrau,GPM-Vorstand, N.Grau@GPM-IPMA.de UlrichVossebein,Fachhochschule Gießen-Friedberg ErsteErgebnissederGPM-GehaltsstudieimProjektmanagement Ausbildung Weiterbildung Berufliche Erfahrung Projektmanager Position im Projekt Entscheidungsbefugnis Anzahl Mitarbeiter PM-Ebene Gehalt Grundgehalt Sonderleistungen Arbeitsstunden Region, Branche, Unternehmensgröße (Umsatz, Mitarbeiter), Funktion, Projektgröße AuswertungsschemafürdieGehaltsstudie GPM-MitarbeiterinReginaSimonundGPM-Vorstände(von links)SiegfriedSeibertundNinoGraubeiderZiehungder GewinnerderGehaltsumfrage Foto: GPM projekt M A N A G E M E NT 1/ 20 0 5 aktuell 48 NACHRICHTEN ■ Welche Folgen haben die Internationalisierung und die zunehmende Vernetzung von Automotive-Projekten und wie kann Projektmanagement helfen, die in letzter Zeit immer problematischer gewordene Produktqualität zu verbessern? Mit diesen Fragen haben sich bereits in der Vergangenheit mehrere GPM-Expertentagungen beschäftigt, letztmals im Oktober 2003 (siehe projektMA- NAGEMENTaktuell 1/ 2004, S. 15). Das Echo auf die damals diskutierten Fragen war größer als erwartet. Grund genug für die Organisatoren Prof. Hasso Reschke und Reinhard Wagner, mit Unterstützung der GPM-Fachgruppe Automotive-PM die erfolgreiche Tagungsreihe fortzusetzen. Am 10. und 11. November 2004 trafen sich in Darmstadt erneut rund 100 Experten, um sich über neueste Trends im Automotive- Projektmanagement aus erster Hand ein Bild zu machen. Hierbei bedienten sich die Veranstalter eines besonderen Highlights, um den Erfahrungsaustausch und das Networking zwischen den Teilnehmern zu fördern: In drei interaktiven Kleingruppen wurden in Form einer „Zukunftswerkstatt“ kritische Erfolgsfaktoren und innovative Konzepte für das Automotive-PM der kommenden Jahre diskutiert. Reinhard Wagner, der diese Methode initiiert und moderiert hat, berichtet dazu auf der gegenüberliegenden Seite. Viele Anregungen erhielten die Teilnehmer auch von den 18 Fachvorträgen der Tagung, von denen hier nur einige ausgewählte Einzelaspekte vorgestellt werden können. Nach Erhebungen der Mercer Management Consulting, über die deren Principal Christian Kleinhans berichtete, wächst der Weltmarkt für Automobile in den nächsten zehn Jahren weiter um durchschnittlich zwei bis drei Prozent pro Jahr. Von diesem Wachstum profitieren in erster Linie die Zulieferer, zu denen immer mehr Wertschöpfung verlagert wird. Eine Ausnahme machen lediglich Premiummarken, wie BMW und Audi, die im Gegensatz zu den meisten Massenherstellern ihre Eigenleistung weiter steigern werden. Selbst diese Firmen verlagern aber gleichzeitig immer mehr Entwicklungsdienstleistungen an Externe. Der Grad der Vernetzung mit und zwischen den Zulieferern nimmt daher bei allen Herstellern deutlich zu. Neben bereits etablierten Zusammenarbeitsformen wie Produktions- und Systemkooperationen kommen dabei auch innovative Geschäftsmodelle zum Zuge, wie z. B. „Spin-offs“ oder „Little OEMs“. Ein Unternehmen, das mit solchen Partnernetzwerken schon reichhaltige Erfahrungen gesammelt hat, ist die Bertrandt Projektgesellschaft mbH. Nach Ansicht ihres Projektmanagers Andreas Meyer-Eggers, Preisträger beim Deutschen PM- Award 2004, nimmt die Vernetzung sowohl innerhalb der Unternehmen selbst als auch zwischen industriellen Partnern zu. Für das Funktionieren solcher Netzwerke sind drei Gesichtspunkte ausschlaggebend: ❏ Die Menschen müssen mental bereit sein (oder durch kulturelle Veränderungen bereit gemacht werden), immer mehr Verantwortung in immer weniger festen Strukturen zu übernehmen. Die Anforderungen an sie steigen sowohl im „Fact-Skill“als auch im „Soft-Skill“-Bereich. ❏ Netzwerke lassen sich nur durch Anwendung übergreifender Standardprozesse beherrschen. Geregelte Prozesse erzeugen Vertrauen bei den Beteiligten und helfen, das vorhandene Wissen für ein Projekt zu bündeln, zu pflegen und auszutauschen. ❏ Auf der technologischen Seite erfordern Netzwerke die Sicherstellung von einheitlichen und durchgängigen Kommunikations- und Prozesstools, insbesondere Enterprise-Backbone-Systeme wie SAP R/ 3, Produktdaten-Management-Systeme, CAx-Systeme und Wissensmanagementlösungen. Bestätigt und ergänzt wurden diese Aussagen in Vorträgen von Mitarbeitern von DaimlerChrysler, Hella, Autoliv und EDAG. Eine zunehmende Bedeutung gewinnt auch die Frage, wie Qualität und Zuverlässigkeit in Automotive- Projekten erhöht werden können. Dr. Hubertus Tuczek, Geschäftsführer der Dräxlmaier Group, sieht die Lösung in einem ausgefeilten Simultaneous-Engineering-Prozess. Wichtige Merkmale dieses Prozesses sind GPM-Expertentagung: „TrendsimAutomotive-Projektmanagement“ GünterKittelbergerhatbeiBoschdenProjektmanagementprozessaufBasisdesEFQMunddesCMMIstandardisiert Foto: SiegfriedSeibert ReinhardWagnerbeiderErläuterungdesAblaufsderZukunftswerkstatt Foto: SiegfriedSeibert aktuell projekt M A N A G E M E NT 1/ 20 0 5 49 vorausschauende Planung, Simulationstechniken zum Prüfen und Optimieren der konstruktiven Entwürfe sowie die intensive Synchronisation der technischen Arbeitsinhalte zwischen Autohersteller, Systementwickler und Komponentenlieferanten. Über einen weiter gehenden Ansatz berichtete Günter Kittelberger von der Robert Bosch GmbH. Projektmanagement ist dort einer von mehreren Bausteinen des Produktentstehungssystems. Das Produktentstehungssystem wiederum ist eines von drei auf den operativen Kernprozessen (Produktentstehung, Verkauf/ Marketing und Auftragsabwicklung) aufsetzenden Systemen. In diesen Systemen sind die Bausteine nach der Gliederung der EFQM (European Foundation for Quality Management) beschrieben. Außerdem hat Bosch als eines der ersten Unternehmen in Deutschland das aus dem IT-Bereich stammende CMMI- Modell als Reifegradmodell erfolgreich auf den Automotivebereich übertragen. Was bleibt als Fazit: Tagungen wie diese erfüllen eine immer wichtigere Rolle beim Austausch aktuellen, anwendungsbezogenen PM-Knowhows. Es bleibt zu hoffen, das die Veranstalter sich zu einer Fortsetzung dieses wichtigen „GPM-Schaufensters“ für die Automobilindustrie entschließen und sich Nachahmer für weitere PM-intensive Branchen finden. SiegfriedSeibert,GPM ■ Die Zukunftswerkstatt ist eine innovative Methode, um in einer Gruppe zukunftsbezogene Probleme zu analysieren und konkrete Schritte zu deren Lösung zu erarbeiten. Die Grundeinstellung: Zukunft ist gestaltbar. Dabei sollen durch die Aktivierung möglichst vieler Teilnehmer Lösungen gefunden werden, die auch wirklich umsetzbar sind. In der Zukunftswerkstatt kommen dazu unterschiedliche Moderationsmethoden zum Einsatz. Sie sollen den Dialog zwischen den Teilnehmern anregen und helfen, besonders vielfältige und kreative Lösungsansätze zu erzeugen. Während der GPM-Expertentagung in Darmstadt stand die Zukunftswerkstatt unter dem Motto: „Die Zukunft des Automotive- Projektmanagements gestalten.“ In zwei halbtägigen Workshops erarbeiteten die Teilnehmer, was den Erfolg von Automotive-Projekten in 2010 maßgeblich beeinflussen wird, wie entsprechende Lösungsansätze in diesen Handlungsfeldern aussehen könnten und wie diese umzusetzen seien. In drei Arbeitsgruppen wurden folgende Haupthandlungsfelder bearbeitet: 1. Projektmanagement in vernetzten Strukturen/ im internationalen Kontext, 2. Social Skills/ Kommunikation sowie 3. Standardisierung und Verbesserung des Automotive-Projektmanagements. Im Folgenden sollen exemplarisch die Lösungs- und Umsetzungsaspekte des dritten Handlungsfeldes zusammengefasst werden. Die Frage einer Standardisierung des Automotive-Projektmanagements wurde kontrovers diskutiert. So existiert schon jetzt eine hohe Regelungsdichte in der Automobilindustrie und „weniger ist oft mehr“. Dennoch waren sich die Teilnehmer einig, dass gerade im unternehmensübergreifenden Kontext ein Mindestmaß an Standards die Zusammenarbeit erleichtern kann. Man sollte existierende Standards (VDA 4.3, APQP etc.) vereinheitlichen und stufenweise um die Begrifflichkeiten im Automotive-Projektmanagement sowie um die wichtigsten Schnittstellen zwischen den Prozessabläufen in der Produktentstehung und dem Projektmanagement ergänzen. Projekt-Handbücher legen in unternehmensübergreifenden Automotive-Projekten den jeweils verwendeten Standard fest und geben den Beteiligten die für die Zusammenarbeit nötige Orientierung. Internetbasierte Portale können branchen- und projektspezifische Hilfsmittel (Programme, Formblätter, Checklisten etc.) zur Verfügung stellen und erleichtern so die Herausbildung von Standards. Unternehmensintern existiert eine Vielzahl von individuellen PM-Standards. Weit verbreitet sind Handbücher, Checklisten, Formulare und Verfahrensanweisungen für die Abläufe und die verschiedenen Rollen im Projektmanagement. Darüber hinaus haben die Teilnehmer im Workshop auch über positive Erfahrungen von Moderatoren-Netzwerken berichtet, die das PM-Know-how formell wie informell weiterentwickeln. Auch kontinuierliche Verbesserungsprozesse (KVP) helfen, das Projektmanagement schrittweise an die veränderten Umfeldbedingungen anzupassen. Dynamisch bedeutet hier vor allem, das Projektmanagement an jedem „Gateway“ zu bewerten und entsprechende Optimierungsmöglichkeiten direkt (elektronisch unterstützt) in die jeweiligen Dokumente einzupflegen. Mit Reifegradmodellen, wie z. B. dem CMMI- Modell des SEI bzw. dem „Project Excellence“-Modell der GPM, könnte man die „Reife“ eines Unternehmens in der Anwendung von Projektmanagement feststellen und entsprechende Entwicklungsmaßnahmen (bis hin zur Zertifizierung der Projektmanager) einleiten. In der Automobilindustrie herrscht Nachholbedarf bei der Standardisierung des Projektmanagements. Automobilhersteller und große Zulieferer entwickeln ihre eigenen, unternehmensinternen Standards, eine übergreifende Initiative ist aber noch nicht erkennbar. Die Teilnehmer der Zukunftswerkstatt haben großes Interesse an einer weiteren Vertiefung des Themas gezeigt. Deshalb wird die Fachgruppe „Automotive-Projektmanagement“ der GPM dieses Thema aufgreifen, die Interessen der Branchenvertreter in einem Projekt ab Anfang 2005 bündeln und konkrete Empfehlungen erarbeiten. Interessenten können sich dazu gerne beim Verfasser melden. ReinhardWagner, Euro-Engineering, reinhard.wagner @euro-engineering.de BlickindieDarmstädterZukunftswerkstatt: StandardisierungimAutomotive-PM projekt M A N A G E M E NT 1/ 20 0 5 aktuell 53 Prolog Projektmanagement Georgstraße 76 · 26349 Jaderberg Telefon 0 44 54/ 82 21 · Telefax 0 44 54/ 5 32 www.prolog.de E-Mail info@prolog.de ■ Am 10. 9. 2004 diskutierten auf einer Veranstaltung der GPM-Fachgruppe „Projektvergleichstechnik“ in München zehn Fachleute über Lösungen der Datensammlung für Projektvergleiche in Unternehmen, die wiederholt ähnliche Projekte durchführen. Wenn im Projektmanagement quantitative Beurteilungen der Projektabwicklung als Ganzes erwünscht sind - z. B. bei der Zieldimensionierung und der abschließenden Ermittlung des Grades der Zielerreichung -, sind die Objektivität, Schnelligkeit und Kostengünstigkeit von Projektvergleichen als Beurteilungsverfahren unübertroffen. Ein besonderer Vorzug ist, dass Projektvergleiche auch die relative Effizienz der Projektabwicklung zeigen. Jedes Unternehmen kann sich mit wenig Aufwand für Projektvergleiche eine eigene Erfahrungsdatenbasis einrichten, die ganz den eigenen Bedürfnissen entspricht. Die Veranstaltung trug solche Bedürfnisse und Erfahrungen zusammen und zeigte einfache Lösungswege. Voraussetzung einer eigenen Erfahrungsdatei ist, dass das Unternehmen untereinander ähnliche Projekte durchführt und projekttypische Daten verwendet, z. B. Projektdauer und -kosten, idealerweise auch Qualität und Wirtschaftlichkeit der Objekte sowie Plan- und Istdaten. Einige Schlüsseldaten einer Reihe bisheriger Projekte müssen sich annähernd noch feststellen oder schätzen lassen. Aber welche Projektdaten sind wichtig und archivierungswürdig? Gibt es eine allgemeine Erfahrungsdatenstruktur für Projekte? Wie macht man die abgelegten, ungeordneten Daten bisheriger Projekte nutzbar? Welchen Aufwand verursacht die Bewertung? Was muss bei der Einrichtung einer Erfahrungsdatei beachtet werden? Große Hilfe bei diesen Fragen bietet das kostenlose Excel-Tool COM- PAR der GPM-Fachgruppe Projektvergleichstechnik, weil die Schlüsseldaten einer Projektabwicklung dort bereits vorgesehen und erläutert sind - in der Fachsprache sind es Basismerkmale, Kontrollmerkmale, Projektparameter und Zielgewichte. Diese Schlüsseldaten können flexibel in jedem Unternehmen nach eigenen Bedürfnissen definiert und ausgestaltet werden und bilden den Kern der Erfahrungsdatei. Beim Projektabschluss genügt dann eine einzige Arbeitsstunde, um die wenigen wichtigen Daten - etwa 20 - festzuhalten. COMPAR bietet aber auch genug freie Excel-Spalten, um zusätzliche Hilfsdaten aufzunehmen. Das können z. B. Kalenderdaten, Referenzdaten, Indices oder umzurechnende Nominaldaten sein. Eine Checkliste für Hilfsdaten und eine dazu passende Spalteneinteilung wurden auf dem Fachgruppentreffen vorgestellt. Die Archivierung der Schlüssel- und Hilfsdaten und der rechnerische Projektvergleich finden dann in einem einzigen Excel-Blatt statt, was den Aufbau und die dauerhafte Nutzung der Erfahrungsdatei erleichtert und beschleunigt. Die notwendige Ähnlichkeit der verglichenen Projekte führt nicht zu nennenswerten Schwierigkeiten, weil sie sich aus der Anwendung gleicher Projektparameter praktisch von selbst ergibt. Die ersten Erfahrungsdaten bisheriger Projekte sollten durch eine einzige, projektvertraute Person erfasst werden, die im Unternehmen die oft verstreuten Datenquellen aufspürt, die Daten zusammenträgt, bei Bedarf vereinheitlicht, fehlende Werte schätzt und die ersten Berechnungen ausführt. Dadurch werden schnell die notwendige Vergleichbarkeit der Daten und der wünschenswerte Dateiumfang von mindestens 30 Projekten erreicht. Für die erstmalige Einarbeitung einer Person in COMPAR wurden ein bis zwei Wochen Zeitbedarf genannt. Dabei kann man sich studienhalber zunächst auf ein erstes Projektsample von 5 bis 10 früheren Projekten beschränken, deren Schlüsseldaten in wenigen Tagen zusammengetragen werden können. Der Zeitbedarf späterer Routinevergleiche beträgt nur wenige Stunden und ist unabhängig von der vergrößerten Anzahl der Projekte. Erfahrungsdateien in COMPAR liefern quantitative Bewertungen der Schwere und Einhaltung von Kosten, Termin, Objekt, Qualität, Ablauf, Leistung sowie die zusammenfassende Projektgüte. Dabei bezeichnet die „Schwere“ ein Maß des Schwierigkeitsgrades und ergibt sich aus der COMPAR-Rechnung. Diese Bewertungen der Zielerreichung lassen sich überschneidungsfrei ergänzen durch Analysen der Projektmanagement- Ausprägung - z. B. mit PM DELTA compact -, die zusätzliche Anhaltspunkte für etwaige strukturelle Gründe des besseren oder schlechteren Abschneidens einzelner Gruppen von Projekten der Erfahrungsdatei liefern können. Für das Jahr 2005 wurde eine weitere Veranstaltung der GPM-Fachgruppe ins Auge gefasst. Neue Interessenten können sich per E-Mail vormerken lassen unter „projektvergleichstechnik@GPM-IPMA.de“. Informationen zur Fachgruppe enthält auch die GPM-Homepage unter www.gpm-ipma.de. Erwinv.Wasielewski LösungenderDatensammlungfürProjektvergleiche Projektkosten x x x x Sachumfang des Projekts Beispiel eines Projektvergleichs projekt M A N A G E M E NT 1/ 20 0 5 aktuell
