eJournals

4฀฀ EDITORIAL P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 5฀฀ REPORT ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 F ür einige Minuten, im Mai auf der Bühne des „Deutschen Projektmanagement Forums“ in Würzburg, da leuchten die Augen von Projektleiterin Maria Koutintcheva. Jury-Vorsitzender Alan Harpham hat vor großem Publikum bekannt gegeben, dass das Schweizer Projektteam mit seinem „IT WRAP Program“ den begehrten Projektmanagement Award gewonnen - nein, sich redlich verdient hat. Ein internationales Assessorenteam hatte die Bewerbung der Eidgenossen studiert und das 7,5-Millionen-Euro-Projekt vor Ort in Zürich geprüft. Die Freude im UBS-Team ist groß. Doch schon bald kehrt das angenehm sachliche Understatement Schweizer Bankfachleute zurück. Auf die Frage, was Maria Koutintcheva für die größte Herausforderung ihres Projektes hält, antwortet sie knapp auf dem Forum der GPM: „Die Termingestaltung.“ Dann lässt sie Fakten sprechen und den Zuhörer selbst ermessen, in welch enges Zeitkorsett ihr Projekt geschnürt war. Die Fakten: Ab 4. November 2002 - der Deadline - sollten die 300 Pilot-Nutzer (der später insgesamt 4.000 Nutzer) die neue Kundenberatungs-Software einsetzen. Das war ein enges Zeitfenster vor dem Dezember, in dem die sensiblen Jahresabschlussarbeiten des Instituts geplant sind. Für die Projektplanung bedeutete dies einen überaus straffen Zeitrahmen. Die ersten beiden Monate des Projektzeitstrahls galten der Analyse und Initiierung. Für Januar und Februar 2002 stand die Konzeption auf dem Plan. Bis Ende August musste die Realisierung abgeschlossen sein. Die letzten beiden Monate vor der Deadline blieben für die Tests („hier haben wir sehr, sehr viel und hart gearbeitet“). Komplexe฀Software฀für฀Investmentberatung In Spitzenzeiten sind rund 150 Spezialisten - davon 35 im Kernteam - im Projekt beschäftigt. Ihre gemeinsame Aufgabe war, mit einer Softwarelösung den gesamten Beratungs- und Verkaufsprozess der UBS-Anlageberater zu begleiten. Die Berater sollten alle Daten erhalten, die sie für die Investment-Beratung benötigen. Die Software sollte Schritt für Schritt durch den Prozess führen. Sie sollte den Mitarbeiter beim Kunden mit aktuellen Marktdaten, Investmentnachrichten und Kundendaten versorgen. Sie sollte verschiedene Modelle und Szenarien für Investment-Portfolios durchrechnen sowie für Kunden Anlagestrategien transparent machen. Und sie sollte später ausbaufähig sein, nicht nur Fonds, sondern auch andere Anlagemöglichkeiten umfassen. Dass diese „IPMA฀Award฀Winner“฀2003 Spitzenprojektmanagement฀bei฀Züricher฀Finanzdienstleister฀UBS Oliver฀Steeger Die฀„Deadline“,฀das฀Schlagwort฀der฀Terminplaner,฀scheint฀heute฀manches฀von฀seiner฀ Schärfe฀eingebüßt฀zu฀haben.฀Genug฀Projekte฀leben฀nach฀dem฀ultimativen฀Termin฀munter฀ weiter,฀gerne฀wird฀die฀„Termin-Todeslinie“฀als฀Verhandlungsbasis฀verstanden.฀Nicht฀so฀ bei฀UBS,฀einem฀weltweit฀tätigen฀Finanzdienstleister.฀Das฀Team฀des฀„IT฀WRAP฀Program“฀ wusste: ฀Hinter฀seiner฀Deadline฀-฀dem฀4.฀November฀2002฀-฀gab฀es฀„kein฀rettendes฀Land“฀ mehr.฀Exakt฀ein฀Jahr฀und฀drei฀Tage฀hatte฀das฀Team฀Zeit,฀eine฀komplizierte฀Finanzberatungs-Software฀zu฀liefern.฀Drei฀Tage฀vor฀dem฀Endtermin฀gab฀das฀Team฀Meldung฀an฀die฀ Geschäftsleitung: ฀„Wir฀sind฀fertig.“฀Was฀dem฀Team฀bei฀der฀UBS-Geschäftsführung฀allerhöchste฀Anerkennung฀eintrug฀-฀und฀seitens฀der฀weltweiten฀Projektmanagement-Szene฀ den฀„IPMA฀-฀International฀Project฀Management฀Award“฀für฀das฀Spitzenmanagement.฀Den฀ wiederum฀nicht฀nur฀für฀sein฀präzises฀Zeitmanagement. Projektleiterin฀Maria฀Koutintcheva฀berichtet฀auf฀dem฀„20.฀Internationalen฀Deutschen฀Projektmanagement฀Forum฀2003“฀in฀Würzburg฀über฀ihr฀preisgekröntes฀ Projekt. Foto: ฀Oliver฀Steeger 6฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 7฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Foto: ฀Oliver฀Steeger Software zuverlässig funktioniert, dass die Daten aktuell sind und sicher bearbeitet werden, dass das ganze System geschützt ist - darüber spricht man nicht in einem Schweizer Bankhaus. Das setzt man voraus bei einem solchen „Class-A-Project“. Es geht immerhin um das Geld der Kunden und damit auch um den Ruf der Schweizerischen Bank, die aus der ehemaligen Bankgesellschaft und dem Schweizerischen Bankenverein hervorgegangen und heute mit über 69.000 Mitarbeitern in 50 Ländern präsent ist. Vorbildliches฀Risikomanagement Verständlich, dass die Projektarbeit unter solch einem Zeitdruck höchst wachsam für Risiken macht. Diagnostizierten soeben Branchenexperten wie der Frankfurter Beobachter Kai M. Morscheck (Severn Consulting), dass Risikomanagement in Projekten der Finanzdienstleistung unterentwickelt ist, so tüftelte das Züricher Team ein vorbildliches System zur Risikovorsorge aus. Und es gab ein ganzes Bündel von Unwägbarkeiten und Gefahren: Neben dem engen Terminplan galten beispielsweise die vielschichtige Lösung, die verwendete Technik und auch die Eile, mit der ein Team aus zwölf Nationen zusammengeführt wurde, als Risikofaktor. So entwickelte das Team früh einen eigenen Risiko- Katalog („risc catalogue“), ein Dokument mit 60 bis 70 Seiten. In ihm listete das Team alle Gefährdungen auf und bewertete sie. Wie groß ist der Einfluss eines Risikos auf das Projekt? Wie wahrscheinlich ist es, dass der Risikofall eintritt? „Wir haben diese Faktoren beziffert und die beiden Zahlen dann multipliziert“, erläutert Maria Koutintcheva, „danach hatten wir für jedes Risiko einen Wert, nach dem wir die Liste priorisieren konnten.“ Verzeichnet waren in dem Katalog auch Maßnahmen, die den Gefahren vorbeugen oder die als Notfallplan retten sollten. „Waren einzelne Maßnahmen zur Vorbeugung umgesetzt, verringerten sich natürlich auch Einfluss und Eintrittswahrscheinlichkeit“, kommentiert Maria Koutintcheva das System, das wie ein Barome- Spitzenleistungen฀im฀Projektmanagement฀hinter฀der฀Fassade฀eines฀traditionsreichen฀Schweizer฀Geldinstituts: ฀Ein฀Team฀des฀Züricher฀Finanzdienstleisters฀UBS฀ hat฀sich฀dem฀internationalen฀Benchmarking฀gestellt฀und฀den฀„Projektmanagement-Oscar“฀von฀GPM฀und฀IPMA฀gewonnen. Foto: ฀UBS Für฀die฀Spitzenleistung฀in฀ihrem฀Projekt฀„IT฀Wrap฀Program“฀erhielt฀das฀Team฀des฀Schweizerischen฀Finanzdienstleisters฀den฀ „IPMA฀-฀International฀Project฀Management฀Award“.฀In฀der฀Mitte: ฀Projektleiterin฀Maria฀Koutintcheva,฀links฀Roland฀Brandes,฀ IT฀Solution฀Manager฀Application฀Wrap,฀rechts฀Philipp฀Toggweiler,฀Software฀Entwickler฀Application฀Wrap. 6฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 7฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Anzeige ter stets den Risikodruck auf das Projekt abbildete. Wöchentlich stand das Thema auf der Agenda. In den monatlichen Statusberichten an die Geschäftsführung und Stakeholder gab die Projektleiterin in einem eigenen Kapitel Bericht über Stand und Entwicklung der Risiken. Auch teampsychologisch wusste die Projektleiterin das Team zu entlasten. „Wir haben auf unseren Teambesprechungen regelmäßig die Stimmung getestet“, berichtet sie. Auf einem Flip-Chart mit der alles entscheidenden Frage „Schaffen wir es rechtzeitig? “ konnten die Mitarbeiter Punkte verteilen. Grüne Klebepunkte für „Wir packen’s“, rote für „Wir schaffen’s nicht.“ Maria Koutintcheva: „Ich habe im Laufe des Projekts höchstens zwei oder drei Mal rote Punkte auf dem Papier gesehen.“ Züricher฀Projektteam฀aus฀zwölf฀Nationen Da klingt neben Realitätssinn auch die Begeisterung und der „Wir-schaffen-das“-Optimismus des Teams heraus. Heute hält Maria Koutintcheva die Teambildung für eine weitere große Herausforderung ihres Projekts, eine Bärenaufgabe, die vielleicht sogar andere Aufgaben in den Schatten stellt. „Binnen drei Monaten hat sich unser Kernteam verdreifacht und wuchs auf 35 Mitarbeiter“, berichtet Maria Koutintcheva. Zudem beteiligten sich weitere 115 Business-Fachleute und IT-Spezialisten an dem Projekt. Sie unterstreicht, dass „Menschen der Schlüssel zum Projekterfolg sind“. Wie so häufig: Was die gebürtige Bulgarin im sachlichen Ton über ihr Projekt äußert, deutet eben auf Spitzenleistungen hin. Solche mustergültigen Spitzenleistungen in internationalen Projekten zu entdecken, sie zu dokumentieren und zu prämieren: Dieses Ziel haben sich die Initiatoren des IPMA International Project Management Award zu Eigen gemacht. Seit 1997 lobt die GPM den „Projektmanagement-Oscar“ aus, zuletzt in Kooperation mit der IPMA International Project Management Association. Dem Wettbewerb liegt ein Assessment zugrunde, das Projekte unterschiedlicher Größe und verschiedener Branchen bewertet und untereinander vergleicht. Für den „Projektmanagement-Oscar“ (wie er gerne in Projektmanager-Kreisen genannt wird) hat die GPM seinerzeit ein eigenes Benchmarking-Modell entwickelt. Das „Project-Excellence“-Modell legt die Messlatte für Projektmanagement-Leistungen so hoch, wie es geht. Spitzenleistungen฀gefragt: ฀Benchmarking฀nach฀ „Project฀Excellence“ Handwerkliche Perfektion wird bei „Project Excellence“ vorausgesetzt. Hier geht es nicht um die Pflicht und um die Tatsache, dass ein Projekt gelungen ist. Hier geht es um die Kür - darum, wie gut es gelungen ist und was andere von ihm lernen können. Maximal 1.000 Punkte vergeben speziell ausgebildete Assessoren, die die Bewerbungsunterlagen der Projekte bewerten und 8฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 9฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 in einem Vor-Ort-Besuch prüfen. Diese Maximalpunktzahl gilt allerdings als theoretische Zahl; selbst Spitzenprojekte positionieren sich unter der Höchstzahl. Auffallend ist nach Expertenmeinung der ganzheitliche Ansatz, nach dem das System Projektmanagement-Leistungen und Zufriedenheit der Projektbeteiligten ermittelt. Innere Logik dabei: Die insgesamt neun Kriterien sind in zwei Bereiche aufgeteilt: „Projektmanagement“ und „Projektergebnisse“. Auf beide entfallen jeweils maximal 500 Punkte. Zwei dieser Kriterien sind „Mitarbeiter“ (der Gruppe „Projektmanagement“ zugeordnet) und Mitarbeiterzufriedenheit (den „Ergebnissen“ zugeordnet). Bei dem Kriterium „Mitarbeiter“ wird gefragt, wie Projektmitarbeiter einbezogen, ihre Fähigkeiten erkannt und ihre Potenziale genutzt werden. Bei der Mitarbeiterzufriedenheit gilt es nachzuweisen, wie Mitarbeiter und Führungskräfte das Projekt, die Zusammenarbeit und die Ergebnisse ihrer Arbeit beurteilen. Ein฀„Götti“฀steht฀Mitarbeitern฀Pate Solche Nachweise hat die Schweizer Projektmannschaft dem Assessorenteam geliefert, das die Züricher Bewerbung um den „Projektmanagement-Oscar“ prüfte. Maria Koutintchevas Team rekrutierte sich aus Schweizern, Engländern, Chinesen, Bulgaren, Italienern, Neuseeländern, Australiern, Skandinaviern und Deutschen - eine polyglotte Mischung. Sie galt es zu einer Mannschaft zusammenzuschweißen, auf kurzem Wege an Arbeiten und Aufgaben heranzuführen, ihnen den „Team-Spirit“ ständiger Verbesserung zu vermitteln und sie gleichzeitig auf eine offene Arbeitsatmosphäre mit ausgeprägter Fehlerkultur vorzubereiten. Bei der Mitarbeiterführung ging das Team ebenso sorgfältig wie beim Risikomanagement zu Werke. Beispiel Rekrutierung des Kernteams: Zu den fünfzehn UBS-Mitarbeitern kamen zwanzig Spezialisten, die das Geldinstitut bei Dienstleistern „einkaufte“. Mit „Testaufgaben“ wurde geprüft, ob die externen Spezialisten von fünf Dienstleistern der Aufgabe und dem Projekt gewachsen waren. Drei Wochen arbeiteten die Bewerber probeweise mit, dann entschied das Team. „Die Mitarbeiter, die wir schließlich unter Vertrag nahmen, haben bereits vorher bei dem Dienstleister als Team zusammengearbeitet“, berichtet Maria Koutintcheva, „das war ein großer Vorteil.“ Zudem erhielt jeder neue Mitarbeiter im Team einen „Götti“, einen Paten aus dem bereits bestehenden Team. Er führte den neuen Kollegen heran an die Anforderungen und Ziele des Projekts, an die gebräuchliche Technologie und an die bereits erarbeiteten Zwischenergebnisse. „Der Götti hat den neuen Mitarbeiter gewissermaßen an den Platz im Team begleitet, der am besten zu dessen Erfahrungen, zur Qualifikation und zu den persönlichen Interessen passte“, erläutert die Projektleiterin. Neue Mitarbeiter seien so binnen kurzer Zeit in ihre Aufgabe und ins Team hineingewachsen. So war es auch unproblematisch, die Hierarchien im Team flach zu halten. Das eröffnete den Teammitgliedern die Chance, Lösungen für Probleme rasch umzusetzen - ein nicht zu unterschätzender „Turbogang“ bei Projekten unter Zeitdruck. „Wir haben alle Teammitglieder als wertvolle Teile unserer Projektorganisation und nicht allein als Umsetzer definierter Aufgaben betrachtet“, fügt Maria Koutintcheva an. Dieser achtsame Umgang mit der „Ressource Mensch“ schlug sich auch in einer Befragung nieder, bei der das Team die Zufriedenheit der Mitarbeiter einen Tag nach Projektschluss ermittelte. Auf einer zehnstufigen Skala gab das Team volle Punktzahl beispielsweise den Faktoren „Teamkommunikation“, „Technisches Wissen“, „Identifikation mit dem Projekt und den Zielen“ sowie „Arbeitsatmosphäre“. Auch schnitt keiner der Faktoren im Durchschnitt mit weniger als acht Punkten ab. „Roadmap“฀für฀Stakeholder Ähnlich sorgfältig ging das Team bei der Zieldefinition vor. Auch ihr gilt ein kritisches Augenmerk der Assessoren des „IPMA - International Project Management Award“. Das Kriterium „Zielorientierung“ umfasst die Frage, wie Ziele formuliert, entwickelt, überprüft und umgesetzt werden. Dabei spielen die Informationen, die es über die Anforderungen der Interessengruppen einholt, eine wesentliche Rolle. 320 der 1.000 Höchst- ������� ������� ���� ��� ��������� �������� ���� ��� ��������� ���� ���� ���� ���������� ���� �������� ��������� �������� �������� ���� ������ ���� ������� ����� ������� ������� �������� ������� ���������� ������� ������� ������ �������� ������� ������������� �������� ��������� ������ ��������� ��������� ������ ���� ������ ��������� �������� ������ ������ ������� ����� ����� ����� ������ ������ ������ ������� ������ ������ ������� ������� �� �� ���� ������� ������� ������������ ��������������������� ����������������������� ������ ��������������� ������������ ����������������������������� „Stakeholders฀Roadmap“฀des฀UBS-Projekts; ฀Quelle: ฀UBS 8฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 9฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 punkte entfallen im Modell „Project Excellence“ allein auf den Bereich der Ziele, fast ein Drittel der maximalen Gesamtpunktzahl. Das Schweizer Team listete zunächst 19 Interessengruppen auf, darunter Kundenberater der Bank, Marketingleute und IT-Spezialisten im Hause, Auftraggeber und Sponsoren, Spezialisten für die so genannte „Middleware“ sowie die Kunden- und Fachöffentlichkeit. In Workshops und Interviews nahm das Team die unterschiedlichen Wünsche und Meinungen der Gruppen auf. In einer Grafik ordnete das Team die Stakeholder- Gruppen zunächst nach der „Nähe“ zum Projekt, also in einen „Inner Circle“, in einen „Outer Circle“ und in das „Project Environment“, also das Projektumfeld. Das übersichtliche Schaubild zeichnete zudem die Beziehung und Informationswege unter den Stakeholder- Gruppen nach - alles in allem eine „Roadmap“ der Stakeholder. Das฀Benchmarking-Modell฀„Project฀Excellence“ Spitzenleistungen im Projektmanagement hilft das Modell „Project Excellence“ aufzuspüren und zu bewerten. In neun Kriterien gegliedert, misst es die Leistungen eines Projekts und beziffert die Leistungen in Punkten. Maximal 1.000 Punkte können (theoretisch) erreicht werden. Unter Projektmanagern wird „Project Excellence“ als aufwändigstes Modell gehandelt. Es kann sowohl zur Selbstbewertung genutzt werden als auch für die Bewertung durch eigens ausgebildete, unabhängige Assessoren - wie es bei dem IPMA International Project Management Award geschieht. Die innere Logik des Modells: Spitzenleistungen im Projektmanagement lassen sich sowohl beim Projektmanagement selbst als auch bei den Projektergebnissen erkennen. So haben die Urheber des Modells die neun Kriterien auf eben diese beiden Gruppen verteilt, das „Projektmanagement“ und die „Projektergebnisse“ (die durch gutes Projektmanagement erreicht werden). Es wundert kaum, dass sich Kriterien in beiden Gruppen auch spiegeln können - beispielsweise das Projektmanagement-Kriterium „Mitarbeiter“ auf der Seite der Projektergebnisse unter der Rubrik „Mitarbeiterzufriedenheit“: Hier wird geprüft, ob die Mitarbeiter tatsächlich zufrieden waren mit dem Projekt. Der Bereich „Projektmanagement“ umfasst die Kriterien Zielorientierung (140 Punkte), Führung (80 Punkte), Mitarbeiter (70 Punkte), Ressourcen (70 Punkte) und Prozesse (140 Punkte). Im Bereich „Projektergebnisse“ sind die Kriterien Kundenzufriedenheit (180 Punkte), Mitarbeiterzufriedenheit (80 Punkte), Zufriedenheit bei sonstigen Interessengruppen (60 Punkte) und Zielerreichung (180 Punkte). In dem Modell sind das Management und die Ergebnisse mit jeweils 500 Punkten gleich gewichtet. Weitere Informationen zum Modell unter http: / / www.gpm-ipma.de/ 10-3.htm. Zeitplanung฀des฀UBS-Projekts฀„IT฀Wrap฀Program“; ฀Quelle: ฀UBS 10฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 11฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Ein฀„Baum“฀für฀Ziele Was erwarteten die Zielgruppen von dem Projekt? Als „Herzstück“ aller Anforderungen die Verbesserung des Kundenservices; die Softwarelösung sollte vollautomatisch und flexibel durch die Beratung und den Verkauf führen. Zugleich sollte die Lösung Investment-Strategien anbieten und dabei UBS-Produkte mit Produkten anderer Institute kombinieren. Darin waren sich die Stakeholder einig. Zu den Details indes steuerten die Gruppen unterschiedliche Anforderungen und Zielbeschreibungen bei. Sie zu klären, in Übersicht zu bringen und Konflikte aufzulösen - das war Aufgabe des Teams. In einem „Goal-Tree“ ordnete das Team die Erwartungen und Ziele in Rubriken, ordnete den Rubriken wie in einem Stammbaum „Unterziele“ zu. Dieser „Goal-Tree“ brachte - ähnlich wie das Schaubild zu den Stakeholdern - Übersicht über die Ziele. Auch wurde die Vernetzung deutlich. Nächster Schritt: In einer Tabelle listete das Team die Ziele und Unterziele auf. Dabei legte es bereits wesentliche Parameter fest, um später zu prüfen, inwieweit die Ziele erreicht sind. Es definierte Prüfkriterien („criteria“) sowie Messgrößen („measurement“). Beispiel: Die Softwarelösung sollte flexibel und unkompliziert zu erweitern sein. Als Prüfkriterien galten beispielsweise technische Prüfungen, Tests, Arbeitsabschlüsse oder Kundenbefragungen. Mit diesen „Instrumenten“ prüfte das Team dann die Messgrößen Funktionalität, Brauchbarkeit, Zuverlässigkeit, Effizienz und Flexibilität („measurement“). Zusätzlich ordnete das Team seinen jeweiligen Zielen Stakeholder-Gruppen zu. „Die Stakeholder waren nicht nur an der Zieldefinition stark beteiligt, sondern auch an der Zielkontrolle“, ergänzt Maria Koutintcheva. Mit speziellen Formularen fragte das Team ab, ob die Gruppen ihre angemeldeten Anforderungen erreicht sahen. Später brauchte es seine Liste nur noch abzuhaken. „95 Prozent der Ziele und Anforderungen haben wir abdecken können“, berichtet Maria Koutintcheva - ein Wert, der im Kriterium „Zielerreichung“ eine gute Punktzahl begründete. Prozesse฀im฀Vordergrund Welchen Stellenwert „lupenreines“ Projektmanagement bei dem Schweizer Vorhaben innehatte, lasen die Award-Assessoren auch an den Beschreibungen unter der Rubrik „Prozesse“ ab. Hier beschreiben Teams, wie sie die im Projekt wertschöpfenden Prozesse identifiziert, überprüft und gegebenenfalls verändert haben. Der erste Blick auf die Bewerbungsunterlagen zeigte: Das Team unterschied konsequent zwischen funktionalen Prozessen sowie Management-Prozessen. „Funktionale Prozesse beziehen sich auf die Ziele und richten den Fokus auf das Projekt“, erläutert Maria Koutintcheva, „die Managementprozesse geben an, wie die funktionalen Prozesse zu implementieren sind.“ So listete das Team unter der Überschrift „funktionale Prozesse“ beispielsweise die Spezifizierung der Anforderungen, Risikomanagement, Change-Management-Prozesse, Konfigurationsmanagement, Qualitätssicherung und Freigaben auf. Unter Management-Prozesse fasste es unter anderem Projektplanung, Kommunikation, Controlling, Monitoring und die Startphase. Die Assessoren hoben einige Beispiele für die sorgfältige Gestaltung solcher Prozesse bei dem UBS-Projekt hervor, beispielsweise den Umgang mit dem Risikomanagement. Ähnlich mustergültig verfolgte das Team den erwirtschafteten Wert ihrer Projektarbeit auf einem „earned value chart“. Hier beobachtete es, welchen Wert ihr Projekt bereits erwirtschaftet und was es in die Arbeiten investiert hatte. Seit der „Deadline“ 4. November 2002 ist fast ein Jahr ins Land gegangen. „Wir haben die Pilotierung abgeschlossen“, berichtet Maria Koutintcheva, „jetzt erarbeiten wir für unsere rund 4.000 Nutzer weitere Releases mit neuen Funktionalitäten.“ Im frühen Sommer musste das Team beispielsweise 1.000 elektronische Kundenverträge in das System überführen, migrieren, wie es in der Fachsprache heißt. Anfang Herbst startete es einen Relaunch; nun hilft das System auch bei Aktien und Hedge-Fonds beraten. Das Team ist zusammengeblieben. „Dank der offenen Architektur unserer Systeme bleibt noch einiges zu tun für uns“, weiß die Projektleiterin.  Anzeige 10฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 11฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Trotz฀„Quantensprung“฀noch฀ viele฀Einsparpotenziale PM-Benchmarking-Studie฀nimmt฀Finanzdienstleister฀unter฀die฀Lupe Oliver฀Steeger Die฀bundesdeutschen฀Finanzdienstleister฀müssen฀sparen.฀Auch฀die฀Budgets฀für฀Projekte฀ werden฀nicht฀vom฀Rotstift฀verschont.฀Die฀Institute฀erwägen,฀Projekte฀einzustellen,฀zu฀ verschieben,฀gar฀nicht฀erst฀zu฀starten.฀Nur: ฀Die฀Unternehmen฀tun฀sich฀dabei฀schwer,฀ die฀Projekte,฀ausgerichtet฀an฀ihrer฀Geschäftsstrategie,฀zu฀priorisieren฀und฀zu฀managen.฀ „Hier฀gibt฀es฀häufig฀unerkannte฀Einsparpotenziale“,฀betont฀Kai฀M.฀Morscheck,฀Senior฀ Manager฀bei฀Severn฀Consultancy฀in฀Frankfurt.฀Sein฀Beratungsunternehmen,฀das฀sich฀ auf฀die฀Geldbranche฀spezialisiert฀hat,฀stellt฀eine฀Benchmarking-Studie฀vor,฀in฀der฀die฀ Qualität฀des฀Projektmanagements฀im฀Finanzdienstleistungssektor฀untersucht฀wird.฀Die฀ gute฀Nachricht: ฀Das฀Projektmanagement฀hat฀hier฀in฀den฀letzten฀Jahren฀einen฀gewaltigen฀Sprung฀nach฀vorn฀getan.฀Trotzdem,฀in฀einigen฀Bereichen฀muss฀die฀Branche฀noch฀ Hausaufgaben฀nachmachen. E s ist beeindruckend, welche Entwicklung das Projektmanagement auf dem Finanzdienstleistungssektor genommen hat“, unterstreicht Kai M. Morscheck, Berater und seit zwanzig Jahren selbst Bankfachmann. Sein im Frankfurter Phoenix-Haus residierendes Beratungsunternehmen Severn Consultancy wollte es genauer wissen und derlei Beobachtungen mit Zahlen untermauern. So entwickelte es eine Benchmarking- Studie. 44 präzise formulierte Thesen legten die Consultants Banken, Versicherungen, Bausparkassen und anderen Finanzdienstleistern vor. Im Sinne einer Selbsteinschätzung prüften die Unternehmen, inwieweit diese Thesen gemäß einer fünfstufigen Skala (von „absolut zutreffend“ bis „wenig oder gar nicht zutreffend“) für ihr Haus galten. Auf dieser fünfstufigen Skala schnitten die Fortschrittskontrolle und das Reporting an die Geschäftsleitung mit einem Wert von 2,0 besonders gut ab. Die Projektmanagement-Grundlagen wurden mit einem Wert von 2,33, die Projektorganisation mit 2,35 eingeschätzt. Durchweg im „grünen Bereich“ bewegten sich auch die Werte für die Planung (2,63), für Umfang und Abgrenzung der Projekte (2,53) und Implementierung (2,60). Gutes฀Projektmanagement฀hinter฀der฀Fassade฀der฀Frankfurter฀Banken-Skyline? ฀Das฀Frankfurter฀Beratungsunternehmen฀„Severn฀Consultancy“฀hat฀das฀Projektmanagement฀der฀deutschen฀Finanzdienstleister฀unter฀die฀Lupe฀genommen. Foto: ฀Dresdner฀Bank 12฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 13฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 In der Rubrik „Toolunterstützung als integrativer Bestandteil“ (2,35) fällt die Selbsteinschätzung der Finanzdienstleister, so Kai M. Morscheck, wohl etwas zu positiv aus. Der Frankfurter Branchenkenner: „Hinter dieser Bewertung sehe ich eher den Wunsch als die Realität.“ Deutliche „Ausreißer“ dagegen gab es mit 3,10 beim Risikomanagement und mit 3,06 bei der Qualitätssicherung. Beim Risikomanagement zeigten sich die Autoren der Studie ausdrücklich verblüfft. 39 Prozent der Unternehmen nannten die Thesen zum Risikomanagement für ihre Unternehmen „mehr oder weniger“ oder auch „gar nicht“ zutreffend. „Dies zeigt, dass zumeist kein konsequenter Umgang mit potenziellen Gefahren für ein Projekt erfolgt“, merkt Kai M. Morscheck an (siehe Interview auf Seite 14 f.). Mehr noch, die Autoren der Studie behaupten: „Projektrisiken werden weitgehend ignoriert.“ So führen nur wenige Unternehmen vor dem Projektstart Workshops durch, um Projektrisiken zu ermitteln. Die Hälfte der Unternehmen vertraue ausschließlich auf die Erstellung von Notfallplänen. Diese allein reichen für den Umgang mit Projektrisiken nicht aus. Gerade die Chance, durch Risikomanagement Kosten zu sparen, bleibt vielfach ungenutzt. Ähnlichen Nachholbedarf vermerkt die Studie bei der Qualitätssicherung. Hier fragten die Autoren danach, ob Veränderungen im Projekt kontrolliert, ob Qualitätssysteme eingerichtet und dokumentiert werden und 41฀Finanzdienstleister฀beteiligten฀sich฀an฀Benchmarkingstudie Zwischen Oktober und Dezember 2002 hat Severn Consultancy 41 Unternehmen aus der Finanzdienstleistung zum Projektmanagement befragt. Die Unternehmen haben 44 Thesen auf einer fünfstufigen Skala („absolut zutreffend“ bis “wenig oder gar nicht zutreffend“) bewertet. Den Kriterien lag das „Severn Best Practice Framework für Projektmanagement“ (BPF) zugrunde. Es umfasst acht Elemente als „erfolgskritische Bereiche“ des Projektmanagements: Grundlagen, Organisation, Planung, Risiko-Management, Umfang und Abgrenzung, Qualitätssicherung, Fortschritt und Kontrolle sowie Implementierung (zu den Elementen siehe die oben stehende Grafik. Severn Consultancy führt diese Studie fort. Zehn Unternehmen haben sich nach Jahresende noch an der Studie beteiligt und, so Kai M. Morscheck (Severn Consultancy), die Ergebnisse erhärtet. Mit wachsendem Datenpool will die Frankfurter Beratungsgesellschaft die Ergebnisse innerhalb der Finanzdienstleistungsbranche differenzieren. Denkbar sei, dass kleine Bankhäuser oder Bausparkassen separat untersucht würden. Auch könnten einzelne Gruppen untereinander „antreten“, beispielsweise Tochtergesellschaften einer Großbank gegen ihre Mutterhäuser. Zudem wird derzeit eine branchenübergreifende Benchmarkstudie durchgeführt (Kontakt für Interessenten unter project.assessment@severn.de). Unternehmen aus der Bau- oder der IT-Branche zum Beispiel können dann untereinander oder mit Finanzdienstleistern verglichen werden. ���������������������������������������������������������� ������������������������������������������������ ���� ��� ���� ���������� � ���������������� ������������������������� ����������������������� � ������������������������ � �������������������������� ���� �������� ������� ���������� � ������������� � ����������� � ����������� ����������� � ��������������� ��������������������� ������� � �� ��������� � ��������� ���� ������������� � ����������������� � ������������������ �� ���������� ��������� ��� � ��������������� � ����������� �������������������� � ��������������������� � ��������������� ���������� ����������� ���������� � ������������������������ � ������������������ ������������������� � ������������ ����� �������������� � ����������������� ���������������� ��������� � ���������������� ����� �������� � ���������������������� � ������������������ ��� � ��������� ���� ��������������� � ������������������ � ����������������� ���������� � ������������������ � ����������� ������ � ����������������������� ��������� ������ � ������� ��� �������������������� � ����������������� � ������������ � ������ �������������� � ������������������ ��������������� ���� Das฀Best-Practice-Assessment: ฀Das฀von฀Severn฀entwickelte฀Best-Practice-Framework฀dient฀als฀Standortbestimmung฀und฀ Benchmark฀für฀Projektmanagement฀in฀Unternehmen; ฀Quelle: ฀Severn฀Consultancy฀GmbH,฀Frankfurt฀am฀Main 12฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 13฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 wie die Qualität der Projektergebnisse definiert wird. 38 Prozent der Befragten fanden, dass sie maximal „mehr oder weniger“ Qualitätssicherung praktizierten. Zwar gaben knapp drei Viertel der Unternehmen an, mit einem standardisierten Prozess Veränderungen zu kontrollieren, also Einflüsse auf Umfang, Ziele, Termine und Kosten nachzuhalten. Darüber hinaus bröckelt die Front sehr schnell. Nur 45 Prozent unterstrichen die Thesen zu Qualitätssystemen und Dokumentation, 42 Prozent die These zur Definition und Prüfung der Qualität ihrer Projektergebnisse. „Allerdings, ohne diese qualitätssichernden Maßnahmen ist es schwer, die ursprünglich festgelegten Projektergebnisse zu erzielen“, betonen die Autoren. Noch schlechter in der Bewertung schnitten Thesen ab, die nach der Erfolgskontrolle fragten. Nur die wenigsten Unternehmen (23 Prozent) ermitteln nach Projektende den Nutzen ihres Projekts und stellen ihn dem tatsächlichen Aufwand entgegen. „Die Unternehmen gehen nicht konsequent den letzten Schritt“, befinden die Autoren, „sie überprüfen nicht den Erfolgsbeitrag des Projekts zur Realisierung der Geschäftsstrategie.“ Durch das Versäumnis dieser Erfolgskontrollen würden erhebliche Lernpotenziale und, für die Autoren viel wichtiger, Kostensenkungspotenziale verschenkt. Obgleich die Studie dem Projektmanagement in der Finanzdienstleitung ein insgesamt gutes Zeugnis ausstellt, warnt Severn Consultancy davor, einzelne Elemente des Projektmanagements zu vernachlässigen. Dies weise auf eine inkonsistente Projektmanagement-Methodik hin, die große Gefahren berge. So wolle die Finanzwirtschaft durch Projekte gerade Kostensenkungsprogramme umsetzen. Da wundert es die Autoren der Studie, dass in den Projekten selbst Maßnahmen vernachlässigt werden, die Erfolg und Kosten sichern. Arbeitsalltag฀an฀der฀Münchner฀Börse.฀In฀punkto฀Projektmanagement฀hat฀die฀ Finanzdienstleistungsbranche฀in฀den฀letzten฀Jahren฀Boden฀wettgemacht.฀  14฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 15฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 „In฀einigen฀Bereichen฀noch฀ gravierender฀Nachholbedarf“ Kai฀M.฀Morscheck฀über฀Projektmanagement฀in฀der฀Finanzdienstleistung Oliver฀Steeger Kai฀M.฀Morscheck฀ist฀Co-Autor฀des฀„Severn฀Project฀Assessment฀Benchmarking฀Report฀ 2003“.฀Der฀41-jährige฀Bankfachmann฀und฀Management-Experte฀beobachtet฀die฀Finanzdienstleistungsbranche฀seit฀über฀zwanzig฀Jahren.฀Der฀Frankfurter฀war฀bei฀Commerzbank,฀Hypo- Vereinsbank฀Luxembourg,฀etb,฀KPMG฀Consulting฀sowie฀Brokat฀Technologies฀tätig.฀Heute฀ist฀ er฀Senior฀Manager฀bei฀Severn฀Consultancy฀in฀Frankfurt,฀einer฀Unternehmensberatung,฀zu฀ deren฀Mandanten฀Allianz,฀Dresdner฀Bank,฀Crédit฀Suisse,฀Morgan฀Stanley฀und฀SEB฀gehören. Die Ergebnisse Ihrer Studie scheinen in einigen Punkten überraschend ... Kai M. Morscheck: ... ja, vielleicht. Für den Außenstehenden mag das gelten. Letztlich passen die Ergebnisse aber gut in unsere eigenen Beobachtungen der letzten Zeit. Also nichts Neues unter der Sonne? Kai M. Morscheck: Die Studie erhärtet viele individuelle Beobachtungen. Fakt ist, dass das Projektmanagement auf dem Finanzdienstleistungssektor einen kräftigen Schub bekommen hat und eklatant verbessert wurde. Beispielsweise haben die Bereiche Projektorganisation und Reporting einen hohen Standard erreicht. ... aber? Kai M. Morscheck: In einigen Bereichen herrscht durchaus noch gravierender Nachholbedarf. Dadurch ist das Projektmanagement insgesamt noch nicht konsistent. Welche Bereiche sind dies? Kai M. Morscheck: Wir haben festgestellt, dass beispielsweise Risikomanagement in vielen Projekten zu kurz kommt. Notfallpläne liegen häufig vor, doch gibt es keine systematische Ermittlung von Risiken und entsprechende Vorsorge. Angesichts von strengen Branchenregelungen, wie sie in Basel II verankert sind, wundert dies. Kai M. Morscheck: Ja und nein. Basel II verstärkt den Druck, hier etwas zu tun. Ohne Basel II wäre das Projekt-Risikomanagement noch deutlicher im Argen ... ... was möglicherweise für andere problematische Ergebnisse Ihrer Studie zutrifft? Kai M. Morscheck: ... lassen Sie es mich so sagen: Risiken, aus denen keine Schadensfälle werden, können ebenso leicht ignoriert werden wie entgangene Chancen. Tendenziell zeichnet sich ab, dass sich viele Finanzdienstleister in Scheinsicherheit wiegen, wenn sie ihre Projekte durchführen. Positiv ausgedrückt: Es gibt hohe Potenziale, um die Qualität des Projektmanagements noch weiter voranzubringen und sich dadurch im derzeit schwierigen Umfeld Wettbewerbsvorteile zu sichern. Welche Potenziale könnten das über das Risikomanagement hinaus sein? Kai M. Morscheck: Die Projektpriorisierung ist nicht eindeutig genug. Traditionell stehen in der Finanzdienstleistung viele Projekte begrenzten Ressourcen gegenüber. Früher fehlte es primär an Knowhow-Trägern, heute zudem an Geld. Wir haben kürzlich in einer Workshop-Reihe bei einer Bank eine solche Priorisierung vorgenommen. Mit welchen Ergebnissen? Kai M. Morscheck: Große Projekte, die über lange Zeit scheinbar lebenswichtig erschienen, hatten plötzlich überhaupt keinen Sponsor mehr. Auf andere Projekte, die einzelnen Abteilungsleitern lebenswichtig erschienen, konnte auch verzichtet werden. Einige Abteilungsleiter haben ihre Projekte sogar zugunsten anderer, für die Geschäftsstrategie bedeutsamer, Projekte zurückgestellt. Eben diese Priorisierung gemäß Gesamtstrategie des Unternehmens ... Kai M. Morscheck: ... geschieht noch zu selten. Da kommt noch zu häufig das Signal: „Macht alle Projekte, auch wenn es eigentlich nicht geht.“ Mangels Ressourcen ziehen sich die Vorhaben hin, und die Motivation der Mitarbeiter schwindet. Kai฀M.฀Morscheck฀(Severn฀Consultancy): ฀„Viele฀Finanzdienstleister฀wiegen฀ sich฀in฀Scheinsicherheit,฀wenn฀sie฀ ihre฀Projekte฀durchführen.“ Foto: ฀privat 14฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 15฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Was hat Sie noch an Ihrer Studie überrascht? Kai M. Morscheck: Bemerkenswert finde ich den Sachverhalt, dass die kritische Erfolgsbeurteilung am Ende eines Projektes nicht stattfindet. Wie darf ich das verstehen? Kai M. Morscheck: Viele Finanzdienstleister erarbeiten anfänglich Business Cases und stellen Nutzenerwartungen auf. Nach Projektende aber wird der Business Case nicht mehr angefasst. Nutzen und Aufwand werden nicht mehr betrachtet. Hier gehen Lernchancen und Kosteneinsparungspotenziale verloren. Haben Sie eine Erklärung dafür? Kai M. Morscheck: Wer ein Projekt erfolgreich abschließt, wendet sich möglichst schnell einem neuen Projekt zu. Für Nachbetrachtungen bleibt da keine Zeit. Und wenn das Projekt ungünstig verlief, wird man die Schlussbetrachtung nur zu gerne umgehen? Kai M. Morscheck: Ja. Vielleicht ist dies ganz menschlich. Trotzdem, welchen Sinn macht die Definition eines Business Case, wenn nach Projektende nicht geprüft wird, ob das Ziel erreicht wurde. Sie haben eben von einer Scheinsicherheit gesprochen, auf die sich viele Projektleiter, aber auch ihre Vorgesetzten stützen. Kai M. Morscheck: Ich würde die Situation differenziert beurteilen. Ich halte die erwähnten Punkte für Aufgaben, die von den „Innovatoren“ der Branche als Nachholbedarf erkannt sind und auch in der nächsten Zeit angegangen werden. Die anderen werden nachziehen müssen. Und, wie gesagt, die Branche hat schon einiges erreicht. Wir sprachen eben von der verbreiteten Entwicklung der Business Cases. Vor wenigen Jahren noch war das, was heute Regel ist, die rühmliche Ausnahme. Ihr Urteil weckt den Eindruck, dass es vor fünf oder zehn Jahren schlecht bestellt war um das Projektmanagement in der Finanzdienstleistung? Kai M. Morscheck: Jein. Aber heute sind in den Unternehmen die notwendigen Strukturen für das Projektmanagement geschaffen, und es wurde auf breiter Front eingeführt. Früher hing der Projekterfolg wesentlich deutlicher von der persönlichen Erfahrung des Projektleiters ab. Das heißt, Projektauftraggeber haben sich früher mehr auf ihre Projektleiter als auf das implementierte Projektmanagement verlassen? Kai M. Morscheck: Sagen wir es anders. Die Branche hat bei dem implementierten Projektmanagement aufgeholt. Heute kann sich die Geschäftsführung immer mehr auf beides verlassen, sowohl auf die Kunst erfahrener Projektleiter als auch auf die organisatorischen Strukturen im Hause.  16฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 17฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Projektmanagement-Assessment฀ bei฀Siemens Karl฀Lebsanft,฀Frank฀Westermann Professionelles฀Projektmanagement฀ist฀eine฀Kernkompetenz฀von฀Siemens.฀Ein฀beträchtlicher฀ Teil฀des฀Umsatzes฀wird฀aus฀dem฀Projektgeschäft฀generiert฀-฀bilateral฀zwischen฀Siemens฀ und฀seinen฀Kunden฀vereinbarten฀Leistungen,฀die฀inhaltlich,฀terminlich฀und฀finanziell฀durch฀ Verträge฀fixiert฀sind.฀Beispiele฀für฀den฀Inhalt฀solcher฀Projekte฀sind฀der฀Bau฀von฀Kraftwerken฀und฀Energieverteilungsanlagen,฀Systemen฀des฀öffentlichen฀Personenverkehrs฀und฀der฀ Infrastruktur฀für฀die฀mobile฀Telekommunikation.฀Um฀die฀Kernkompetenz฀„Professionelles฀ Projektmanagement“฀dauerhaft฀zu฀sichern,฀wurde฀die฀firmenweite฀Initiative฀„PM@Siemens“฀ ins฀Leben฀gerufen,฀deren฀Module฀die฀entscheidenden฀Fähigkeiten฀zur฀Projektdurchführung,฀ wie฀beispielsweise฀Vertragsmanagement,฀Projektleiterqualifikation฀und฀Projektcontrolling,฀ adressieren.฀Als฀Hilfsmittel,฀um฀mögliche฀Schwächen฀bei฀der฀Akquisition฀und฀Durchführung฀ von฀Kundenprojekten฀zu฀erkennen฀und฀abzustellen,฀bietet฀sich฀die฀Durchführung฀von฀Projektmanagement-Assessments฀an.฀Das฀vorgestellte฀„Projektmanagement-Assessment“฀analysiert฀auf฀Organisationsebene฀die฀Fähigkeiten,฀Projektmanagement-Kompetenz฀aufzubauen,฀ weiterzuentwickeln฀und฀in฀Kundenprojekten฀erfolgreich฀zur฀Anwendung฀zu฀bringen. 1฀ Prozess฀und฀Prozessbewertung In diesem Kapitel wird erläutert, was im Zusammenhang mit dem Projektmanagement-Assessment unter einem „Prozess“ zu verstehen ist. Davon ausgehend wird gezeigt, warum es notwendig ist, sich mit der Verbesserung der Prozesse des Projektmanagements auseinander zu setzen. 1.1฀ Definierter฀und฀gelebter฀Prozess Jedes Projekt sollte nach einem vorher definierten Prozess realisiert werden. Dafür werden Regeln festgelegt, wo ein gemeinsames Verständnis für den ungestörten Arbeitsfortschritt notwendig ist. Dies betrifft die Zusammenarbeit der Projektteams, den Inhalt, die Reihenfolge und die Ergebnisse der Projektakquisition und -abwicklung. Der Prozess organisiert das Zusammenspiel aller Beteiligten, um das gemeinsam zu erbringende Projektergebnis möglichst gut und effizient zu implementieren. Von einem definierten Prozess wird erwartet, dass die Regeln und Festlegungen, die ihn ausmachen, explizit formuliert und dokumentiert sind. Es gibt eine „Vorschrift“, wie die Zusammenarbeit der Beteiligten erfolgt und welche Ergebnisse diese mit welchen Hilfsmitteln realisieren. Das Projektmanagement-Assessment verwendet folgende Merkmale, um zu entscheiden, ob die Projektarbeit durch einen definierten Prozess geregelt ist: a. Eine explizit formulierte Regelung existiert. b. Die Regelung ist durch eine Rolle mit entsprechender Kompetenz in Kraft gesetzt und damit gültig. c. Die Regelung ist allgemein bekannt. Die Erfahrung zeigt, dass sich in der täglichen Praxis die definierten Regeln und der „gelebte Prozess“ durchaus unterscheiden. Die Gründe sind vielfältig. Ein Grund ist der, dass die Projektmitarbeiter die explizit formulierten Regelungen als nicht praxisgerecht empfinden und sie deshalb im Tagesgeschäft nicht beachten oder sogar bewusst umgehen. Ein anderer Grund ist, dass ursprünglich allgemein akzeptierte Regeln im Tagesgeschäft langsam „in Vergessenheit“ geraten, weil ihre Anwendung weder eingefordert noch überprüft wird. 1.2฀ Prozesse฀sichern฀die฀Projektmanagement- Kompetenz฀der฀Organisation Maßstab für den Erfolg eines Projekts ist letztlich der wirtschaftliche Erfolg. Dazu tragen beispielsweise die Technik, das Domänen-Know-how und der Ausbildungsstand der Mitarbeiter sowie die Qualität der Prozesse bei. Auch (Projekt-)Ergebnisse können auf Dauer nicht besser sein als der Prozess, der sie hervorbringt. Für Produktionsprozesse ist diese Einsicht allgemein anerkannt und wird zunehmend auch für die Durchführung von Projekten akzeptiert. Die Erfahrung zeigt, dass gerade das Know-how zur Projektdurchführung der entscheidende Erfolgsfaktor ist. Dieses Know-how zur Projektdurchführung einer Organisation steckt in den dokumentierten und gelebten Projektmanagement- Prozessen. Das macht diese zu einem besonders wertvollen „Besitz“ der Organisation. Die kontinuierliche Pflege und Weiterentwicklung der Prozesse sind dann naheliegende Forderungen, um das Know-how einer Organisation zu sichern und auszubauen. Die direkte Messung des Beitrags der Prozesse zum Geschäftserfolg ist schwierig, da der Einfluss der anderen entscheidenden Faktoren schwer abzugrenzen ist. Um 16฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 17฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 zu einer Aussage über die Güte der Prozesse zu kommen, ist also eine praktikable Methode erforderlich. Diese muss mit hoher Sicherheit Aufschluss darüber geben, in welchem Zustand sich der untersuchte Prozess befindet und welchen Beitrag er zum Erfolg leistet. Die Methode muss auch zeigen, durch welche Veränderungen ggf. ein höherer Beitrag der Prozesse zum Erfolg zu erreichen ist. Das Projektmanagement-Assessment von Siemens ist eine solche Methode. 1.3฀ Prozessreife BeimProjektmanagement-Assessment wird die „Reife“ der in Kundenprojekten angewandten Prozesse bewertet - also die Reife der Spielregeln, nach denen die Projektbeteiligten ihre Aufgaben erledigen. Als Maßstab der Reife dient dabei das Reifegradmodell für Prozesse (Capability Maturity Model, CMM), das anhand wohldefinierter Kriterien (‚good practices‘) verschiedene Levels der Prozessreife unterscheidet. Organisationen, deren Prozesse unterschiedlichen Levels zuzuordnen sind, verhalten sich qualitativ unterschiedlich in der Art ihrer Aufgabenerledigung - in diesem Fall, wie sie Projekte abwickeln. Höhere Reife bedeutet dabei höhere Sicherheit und größere Erfolgswahrscheinlichkeit. Abb. 1 gibt einen Überblick über die Charakteristika von Organisationen mit unterschiedlichen Reifegraden. Die Wirk- Anzeige Le Bihan Consulting GmbH 1/ 2 Seite quer + 4c (183,5 b × 125 h) � ��������� � ������������ � ��������� � ��������� � ������������ � ���������� ��� ������������������ � ������������������������� � ���������� ��������������� ������������� ������ �������� �������������� ������ �������������� � ������������ ����� ��� ������� ��� ������� � ���������� ��� �������������� ����� �������� ��� ������������ �������� � ���������������� � ����������������� ��� ��� ������������ � ������������������� ��������������� ��������� � �������� ������ ������ ����� ������� �� � ����������������� ���� ��� ������������� � ��������������� ����������������� � ������� �������� ��� ������� �� ������� � ������� ������������ ������������������� � ������ ������������ ������������������� � ������� �������� ��� ������ ����� ������������ Abb.฀1: ฀Charakteristika฀der฀Reifegradstufen; ฀Quelle: ฀Siemens฀AG 18฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 19฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 samkeit dieser Art von Prozessbewertung ist nicht nur bei Siemens vielfach nachgewiesen. Prozess-Assessments mit dem Reifegradmaßstab als Bewertungsskala sind zwar für die Prozesse zur Abwicklung von Kundenprojekten neu, in der Entwicklung von Hardware- und Software-Systemen und auch im Produktmanagement und Service-Geschäft von Siemens sind sie jedoch weit verbreitet (mehr als 300 von der Zentralabteilung der Siemens AG in den letzten 10 Jahren durchgeführte Assessments). Abb. 2 gibt einen Überblick über die unterschiedlichen Prozess-Assessments bei Siemens. 1.4฀ Themengebiete฀des฀Assessments In einem Projektmanagement-Assessment werden alle Themengebiete (Key Process Areas) analysiert, die einen Beitrag zu exzellentem Projektmanagement und darüber hinaus zum Prozessmanagement leisten. Abb. 3 zeigt einen Überblick über diese Themengebiete. Im Themenblock Projektmanagement werden alle Aspekte berücksichtigt, die zur Planung und zum Controlling notwendig sind. Beispiele aus dem Themenspektrum sind Projektberichterstattung, Risikomanagement und die kaufmännischen Verfahren zur Projektabwicklung. Die Themen des zweiten Themenblocks berühren die zeitlich aufeinander folgenden Phasen von der Akquisition über die Angebotsbearbeitung, die Auslegung und das Engineering der zu erstellenden Systeme/ Anlagen bis zu ihrer Erstellung, Inbetriebsetzung und dem Test bei den Kunden. Der Themenblock drei behandelt dann die Fragen der Kompetenzsicherung über Projektgrenzen hinaus wie beispielsweise Ausbildung und Qualifikation, Prozesspflege und Technologieinnovation. 2฀ Grundsätze฀des฀Projektmanagement-Assessments Dieses Kapitel stellt die grundlegenden Prinzipien des Projektmanagement-Assessments vor. Diese Prinzipien prägen die im nächsten Kapitel behandelten Schritte und operationalen Aspekte des Assessments. Sie haben sich durch die Anwendung für verschiedene Prozesse (siehe Abb. 2) über die Jahre gefestigt und sind für den Erfolg der Prozess-Assessments bei Siemens wesentlich. 2.1฀ Konzentration฀auf฀geschäftswirksame฀Verbesserungsmaßnahmen Obwohl auf den ersten Blick naheliegend - Assessment bedeutet im Englischen Bewertung, Beurteilung -, ist der Aspekt der Bewertung bei einem Projektmanagement-Assessment nur zweitrangig; im Vordergrund steht die anschließende Verbesserung der Prozesse. Die Konzentration des Assessorenteams auf die Prozessverbesserung zeigt sich unter anderem am Zeitbedarf, der für die Prozessbewertung auf der einen und für die Definition und Aufbereitung von Maßnahmen zur Prozessverbesserung auf der anderen Seite erforderlich ist. Der überwiegende Anteil am Zeitbedarf für ein Projektmanagement-Assessment entfällt auf die Definition und Aufbereitung von Maßnahmen zur Prozessverbesserung und auf die Strukturierung von Arbeitspaketen, um diese umzusetzen. Die Prozessbewertung, ausgedrückt als Reifegradstufe, bietet der untersuchten Organisationseinheit zusätzlich die Möglichkeit des Vergleichs mit dem industriellen Standard. Das Ziel der Verbesserung wird definiert als Beitrag zum gesteigerten Erfolg der Organisation. Mit Erfolg ist das wirtschaftliche Ergebnis angesprochen, aber auch andere Erfolgsfaktoren wie das Erreichen eines definierten Qualitätsniveaus der Systeme und Anlagen, die Verminderung kundenspezifisch zu entwickelnder Projektanteile oder die Fähigkeit, auf häufig geänderte Anforderungen eines Auftraggebers flexibel zu reagieren. Die im Einzelfall entscheidenden Aspekte sind sehr vielfältig; in vielen Fällen spielt heute der Zeitfaktor die herausragende Rolle. 2.2฀ Kooperativer฀Ansatz Mit einer offenen und kommunikativen Atmosphäre über den ganzen Ablauf und insbesondere für die Diskussions- und Interviewrunden wird angestrebt, mögliche Schranken zwischen dem Assessorenteam und den Teilnehmern der Organisation abzubauen bzw. gar nicht erst entstehen zu lassen. Die Organisation soll das Assessment als „ihre“ Angelegenheit empfinden, als Gelegenheit, über die eigenen Vorgehensweisen nachzudenken und gemeinsam mit dem ���� ��������� ���������� ������� ������ ���������� ��������� ���������� �������� ����������� ���������� ���� ���� ���� �������� ����������� ���������� ���� �������� ���������� Abb.฀2: ฀Prozess-Assessments฀werden฀bei฀Siemens฀seit฀vielen฀Jahren฀erfolgreich฀ angewendet; ฀Quelle: ฀Siemens฀AG � ����������������� ����������� � �������� � ������������������� ����������� � ������������ ������������ ���������� ������� ����������������� � ������������������ �������������� � ������������������ ����������� � ������������������ � ������������������� ���������� ���������� � �������������� ������������������ � ��������������� � ����������������� � ��������� ���������������� � ���������������� ����������� ����������������� Abb.฀3: ฀Themengebiete฀des฀Projektmanagement-Assessments; ฀Quelle: ฀ Siemens฀AG 18฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 19฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Assessorenteam Verbesserungen für alle zu initiieren. Um dies zu erreichen, wird das Assessment immer von einem Team durchgeführt, in dem externe Assessoren (aus der Zentralabteilung Technik) und Vertreter der untersuchten Organisationseinheit zusammenarbeiten. Die internen Assessoren bringen einen umfassenden Überblick ihrer Organisationseinheit und ihrer spezifischen Randbedingungen mit. Durch das gemeinsame Auftreten von externen und internen Assessoren wird die Orientierung der Ergebnisse des Assessments (Feststellungen und Maßnahmen) an den Realitäten der Organisationseinheit erleichtert; dies ist eine wesentliche Voraussetzung für die Akzeptanz der Ergebnisse. 2.3฀ Intensives฀Feedback Mit gemeinsamen Veranstaltungen wird die Akzeptanz für das Assessment generell sowie für die Ergebnisse im Besonderen abgesichert. Im Rahmen dieser Veranstaltungen werden eventuell entstandene Missverständnisse ausgeräumt und ein gemeinsames Verständnis für die im Abschlussbericht dokumentierten Ergebnisse herbeigeführt. Daher ist es wichtig, dass Feedback schon vor der Freigabe des Assessment- Berichts erfolgt. Feedback wird bei einem Projektmanagement-Assessment in abgestufter Detailtiefe an die Teilnehmer der Interviewsitzungen und an das Management gegeben. 2.4฀ Vertraulichkeit Alle Informationen, die den Assessoren während der Untersuchung zur Kenntnis kommen, werden vertraulich behandelt. Vertraulichkeit gilt dabei in verschiedener Hinsicht. Ein Projektmanagement-Assessment macht Feststellungen zu Prozessen und zur Arbeitsorganisation. Informationen über Personen finden keinen Eingang in die Ergebnisse, ein Bezug zwischen Personen und den Feststellungen im Assessment-Bericht wird vermieden. Darüber hinaus behandeln die externen Assessoren das Gesamtergebnis des Assessments vertraulich. Nur die durchführende Organisation selbst ist befugt, die im Abschlussbericht niedergelegten Ergebnisse zu kommunizieren oder zu publizieren - was in der Praxis ganz unterschiedlich wahrgenommen wird. 2.5฀ Getrennte฀Interviews฀mit฀Mitarbeitern฀unterschiedlicher฀Hierarchieebenen Es gehört zu den Prinzipien eines Projektmanagement- Assessments, getrennte Diskussionen mit den Mitarbeitern der verschiedenen hierarchischen Ebenen der Organisationseinheit zu führen. Das hat den Vorteil, die verschiedenen Blickwinkel dieser Gruppen klar getrennt voneinander zu erfassen und gegenüberzustellen. Außerdem wird vermieden, dass Personen höherer hierarchischer Ebenen (Vorgesetzte) die Diskussion dominieren Anzeige Kick Unternehmensberatung GmbH 1/ 2 Seite quer + sw (183,5 b × 125 h) 20฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 21฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 und die Mitarbeiter der unteren Ebenen Aussagen im Widerspruch zu ihren Vorgesetzen zurückhalten. 2.6฀ Anpassung฀an฀das฀spezielle฀Umfeld฀der฀ Organisation Die Siemens AG hat die Arbeitsgebiete Information and Communications, Automation and Control, Power, Transportation, Medical, Lighting sowie das Finanz- und Immobiliengeschäft. Jedes Arbeitsgebiet bietet Produkte, Systeme, Anlagen und Dienstleistungen in zahlreichen Geschäftsfeldern an. Dies ist ein Hinweis auf die heterogenen Märkte und Systemanforderungen sowie die unterschiedlichen Projektgrößen und Erfolgsfaktoren. Das heterogene Umfeld hat Auswirkungen auch auf die Art und Weise, mit der ein Projektmanagement-Assessment erfolgreich und effizient durchgeführt werden kann. Ziel ist immer, mit möglichst geringen Kosten und Belastungen der Mitarbeiter der untersuchten Organisation zum Ergebnis zu kommen. Deshalb wird beim Projektmanagement-Assessment die Durchführungsform - obwohl vom prinzipiellen Ablauf und von den Ergebnissen her immer vergleichbar - an die untersuchte Organisationseinheit angepasst. Kriterien sind dabei die Größe der Organisationseinheit, die Verteilung der Standorte sowie die typischen Projekt- und Organisationsstrukturen. 3฀ Ablauf฀und฀Methodik In diesem Kapitel werden die Schritte des Projektmanagement-Assessments in ihrer zeitlichen Abfolge vorgestellt (siehe Abb. 4) sowie eine Erläuterung gegeben, auf welche Weise die Anforderungen des Reifegradmodells in den Interviewrunden und den Ergebnisberichten abgebildet werden. 3.1฀ Fragenkatalog Zur Analyse der definierten und der gelebten Prozesse wird ein standardisierter Fragenkatalog verwendet. Der Fragenkatalog berührt alle Themen, zu denen im Reifegradmodell Anforderungen formuliert sind, also Aspekte wie Projektplanung oder die vollständige Klärung der Kundenanforderungen. Themen, die im Reifegradmodell im Hinblick auf die spezifischen Anforderungen von Kundenprojekten weniger präzise ausgeführt sind, sind detailliert bzw. ergänzt. Zu jedem Thema sind im Fragenkatalog Fragen formuliert, deren Erfüllungsgrad durch das Assessorenteam beurteilt wird. Ein Beispiel einer solchen Frage aus dem Fragenkatalog ist: „Werden Projektrisiken regelmäßig identifiziert und analysiert? “ In der Regel werden diese Fragen nicht explizit gestellt, und auch eine direkte Antwort auf diese Frage mit Ja oder Nein ist nicht beabsichtigt. Vielmehr nehmen die Assessoren diese Fragen zum Anlass einer Diskussion mit ihren Interviewpartnern, um festzustellen, ob die Anforderungen in Bezug auf Vorgehensweise, Umfang, Form und Angemessenheit des Risikomanagements sowie die verwendeten Hilfsmittel erfüllt sind. Die Fragen des Fragenkatalogs sind zu den in Abb. 3 gezeigten Prozessthemen gebündelt. Diese Struktur hat sich als Checkliste für das Assessorenteam („Sind alle relevanten Themen diskutiert und geklärt? “) bewährt und erleichtert es, den Ablauf des Assessments effizient zu gestalten. Die Zusammenstellung themenbezogener Interviewgruppen (z. B. Mitarbeiter aus Vertrieb und Marketing für das Thema Angebotsbearbeitung, Mitarbeiter aus dem Service für das Thema Inbetriebsetzung) minimiert den Gesamtaufwand. 3.2฀ Assessment-Vorbereitung Um ein Assessment erfolgreich durchzuführen, ist es von besonderer Bedeutung, den Mitarbeitern und insbesondere dem Management als Auftraggeber das richtige Verständnis und eine realistische Erwartungshaltung zu vermitteln. Zur Einstimmung des Managements ist eine Einführung vorgesehen. Die Auswahl der Projekte und der Mitarbeiter, die als Interviewpartner teilnehmen, um einen repräsentativen Eindruck der Prozesse zu vermitteln, ist für die Aussagekraft der Ergebnisse wichtig. Dies setzt ausreichende Kenntnis der Organisation voraus. Die von der Organisation benannten internen Assessoren klären diese Fragen im Vorfeld gemeinsam mit den externen Assessoren und planen die Interviewrunden im Detail. Für alle Beteiligten steht zu Beginn fest, zu welchem Zeitpunkt sie an welcher Aktivität teilnehmen und wer ihre Gesprächspartner sein werden. Die Vorbereitungsphase endet mit einer gemeinsamen Auftaktveranstaltung aller am Assessment Beteiligten. Das Assessorenteam stellt die Grundzüge des Assessments vor, das Management die Erwartungen und Ziele, die mit dem Assessment verbunden werden. Mit einer abschließenden Diskussionsrunde zur Klärung offener Fragen ist der Grundstein für den gemeinsamen Erfolg gelegt. 3.3฀ Interviews฀zur฀Informationsgewinnung Das Assessorenteam erhält Einblick in die Arbeitsweise der Organisation durch Interviews und Dokumentenanalysen. In einem Auftaktinterview mit dem Manage- ������������������ �������������������� ����������������� ����������������� ��������� ���������������� ������������������� ���������������� ������������������� ������������������ ���������� �������� �������������� ��������������� ���������� ���������������� ��������������� ���������� ��������������������� ��� ��� ���� ��� ��� ��� ��� ��������������������������������� ��������������������������������� Abb.฀4: ฀Schema฀des฀Assessment-Ablaufs; ฀Quelle: ฀Siemens฀AG 20฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 21฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 ment werden zu Beginn die Erfolgsfaktoren und evtl. notwendige Veränderungen der Organisation diskutiert, um später die Bedeutung der analysierten Prozesse vor dem geschäftlichen Hintergrund einordnen zu können (siehe Abschnitt 2.1). Die Interviewrunden mit den Projektbeteiligten werden als Gruppen- und als Einzelinterviews durchgeführt. Gruppeninterviews sind zwar vergleichsweise aufwändig, bieten aber den besonderen Vorteil, unterschiedliche Meinungen der Interviewpartner zu Einzelthemen unmittelbar zu erkennen und zu diskutieren. Der intensivste Teil der Informationssammlung bei einem Projektmanagement-Assessment sind Interviews mit den Funktionsträgern der Organisation. „Funktionsträger“ sind Personen, die in den untersuchten Projekten definierte Rollen einnehmen. Solche Rollen sind beispielsweise Projektmanager, Vertriebsverantwortlicher und Projektkaufmann. Die Funktionsträger sind erfahrungsgemäß die Mitarbeiter, die den gelebten Prozess der Organisation am stärksten prägen. Mit ihnen wird deshalb die ganze Bandbreite der Themen anhand des Fragenkatalogs durchgesprochen. Das Assessorenteam ist bestrebt, eine offene Diskussion zu führen, achtet aber darauf, dass im Gesprächsverlauf alle Fragen des Fragenkatalogs beantwortet werden. Um den Erfüllungsgrad der Fragen nach Abschluss der Interviews beurteilen zu können, protokolliert das Assessorenteam den Diskussionsinhalt. In ersten Auswertungen der Gruppeninterviews werden Themen identifiziert, bei denen ein ergänzender Informationsbedarf besteht. Diese Themen werden in Einzelinterviews vertiefend besprochen. Einzelinterviews werden, soweit wie möglich, direkt am Arbeitsplatz der Beteiligten geführt. Damit erhält das Assessorenteam zusätzlich einen realistischen Einblick in die Arbeitsbedingungen und die eingesetzten Hilfsmittel. Bei großen Projektteams werden zusätzliche Interviews mit Mitarbeitern ohne Führungsfunktion aus der Sachbearbeiterebene geführt. Diese Trennung ermöglicht eine bestmöglich an das unterschiedliche Aufgabenspektrum von Funktionsträgern und Mitarbeitern angepasste Diskussionsführung. 3.4฀ Auswertung,฀Absicherung฀und฀Dokumentation฀ der฀Ergebnisse Die im Rahmen der Interviews und Dokumentenanalyse zusammengetragene Information ist die Basis für Statusaussagen über die Projektmanagement-Prozesse der Organisation und für konkrete Maßnahmenvorschläge zur geschäftswirksamen Prozessverbesserung (siehe Abschnitt 2.1). Die Wirksamkeit dieser Ergebnisse hängt wesentlich von ihrer Akzeptanz durch alle Mitarbeiter der Organisationseinheit ab. Deshalb werden die Feststellungen, Bewertungen und Maßnahmen als Ergebnis erst nach Feedback-Veranstaltungen mit den Beteiligten freigegeben. Das erfolgt in ausführlichen Sitzungen mit den Funktionsträgern/ Mitarbeitern und dem Management. Erst danach erfolgt die abschließende Dokumentation der Ergebnisse in schriftlicher Form. In den Feedback-Veranstaltungen mit den Projektbeteiligten sichert das Assessorenteam die Richtigkeit der dokumentierten Feststellungen zum Prozess (Stärken und Schwächen) ab und gewinnt erste Zustimmung für vorgeschlagene Verbesserungsmaßnahmen. Das Management-Feedback dient neben der Informationsweitergabe über die Assessment-Ergebnisse vor allem dem Zweck, Einverständnis mit dem Assessorenteam über die wichtigen Maßnahmenvorschläge zu erzielen. Damit wird erreicht, dass diese bei der Abschlussveranstaltung gemeinsam getragen werden - eine zentrale Voraussetzung, um sie anschließend zügig umzusetzen. 3.5฀ Abschlusspräsentation Mit der zusammenfassenden Präsentation der Kernaussagen durch das Assessorenteam wird das Assessment abgeschlossen. An der Präsentation nehmen alle interviewten Personen, das Management und möglichst auch andere Mitarbeiter der Organisationseinheit teil. 22฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Aufgrund der vorangegangenen Feedback-Sitzungen gibt es für die Beteiligten keine „Überraschungen“ mehr. Obwohl nichts grundlegend Neues gegenüber den Feedback-Runden berichtet wird, hat die Abschlusspräsentation doch eine besonders wichtige Funktion: Sie ist die Überleitung vom Assessment in das nachfolgende Programm zur Maßnahmenumsetzung und bietet Assessorenteam, Management und Mitarbeitern eine Diskussionsplattform zum weiteren Vorgehen. 4฀ Ergebnisse Dieses Kapitel bietet einen Überblick über die Struktur und den Inhalt der Assessment-Ergebnisse, die im Abschlussbericht enthalten sind. Die Ergebnisse sind in der gleichen thematischen Gliederung aufbereitet, in der die Prozessanalyse erfolgt (siehe Abb. 3). Zu jedem Themengebiet werden Feststellungen und Maßnahmenvorschläge formuliert und zusätzlich ein Reifegrad ermittelt. 4.1฀ Stärken-/ Schwächen-Profile,฀ Maßnahmenvorschläge,฀Reifegrade Stärken, Schwächen, Maßnahmen: Ausgangspunkt für die Bestimmung der Prozessreife in Bezug auf die einzelnen Themengebiete sind detaillierte „Stärken-/ Schwächen- Profile“. Sie dokumentieren sowohl die spezifischen Vorteile der Prozesse der Organisation als auch die spürbaren Mängel, die entweder die Effizienz und Sicherheit der Projektabwicklung mindern oder im Extremfall zur Gefährdung der Projektziele führen (siehe Abb. 5). Festgestellte Mängel werden durch Vorschläge ausgleichender Maßnahmen ergänzt. Anregungen für Verbesserungsmaßnahmen entstehen aus zwei Quellen. Zum einen ergeben die erkannten Abweichungen der definierten und der gelebten Prozesse gegenüber den Anforderungen des Reifegradmodells unmittelbar Hinweise auf durchzuführende Veränderungen. Besonders wichtig aber ist in diesem Zusammenhang die praktische Erfahrung des Assessorenteams. Von der Kenntnis der Best Practices des Projektmanagements in unterschiedlichen Umgebungen hängt es wesentlich ab, ob praktisch verwertbare und mit vertretbaren Mitteln realisierbare Maßnahmenvorschläge für die Organisation abgeleitet werden. Themenbezogene Reifegrade: Die Bestimmung der Reifegrade erfolgt auf der Basis des Fragenkatalogs durch das Assessorenteam (vgl. Abschnitt 3.1). Für jede einen bestimmten Anforderungsumfang des Modells repräsentierende Frage wird der Erfüllungsgrad bestimmt. Die Einstufung reicht von „nicht erfüllt“ über „teilweise erfüllt“ und „überwiegend erfüllt“ bis „vollständig erfüllt“. Aus den Erfüllungsgraden der einzelnen Fragen ergibt sich (durch Berechnung mit einem Auswerte-Tool) ein Erfüllungsgrad der Anforderungen des Reifegradmodells entsprechend der Themenstruktur (siehe Abb. 6). Bei der Auswertung der Reifegrade und der Erfüllungsgrade der Anforderungen wird unterschieden zwischen Reife-/ Erfüllungsgrad in Bezug auf den definierten und den gelebten Prozess (vgl. Abschnitt 1.1). Das Beispiel in Abb. 6 zeigt für das Thema Risikomanagement ei- �������������� ��������� ��������� � �������� ������������� �������� �������������� ������ �������� �������������� �������� � ������������������������������������������������������� ��������������������������������� � ������������������������������������������� ����������������� � ��������������������������������������������������� ������������������������������������������ � �������������������������������������������������������� ��������������������������������������������������������� ������������������������������������������������ �������������������������������������������������������� ������������������������������������������� ��������������������������������������������������� ��������������������������������������������������� ������������������������������������������ ���������������������������������������������������� ��������������������������������������������� ����������������� Abb.฀5: ฀Beispiel-Ausschnitt฀eines฀Stärken-/ Schwächen-Profils฀zum฀Risikomanagement; ฀Quelle: ฀ Siemens฀AG �� ��� ��� ��� ��� ���� � ��� � ��� � ��� � ��� � ������� ���������� ������� �������� ����� ������������������������������������ ����� ������������������������������������ ����� ������������������������������������������ ��� ����������������� ��� ��������������������������������������� ����� ���������������� ����� ���������������� ��� ���������������������������������� ������������������������������������������ Abb.฀6: ฀Beispiel฀einer฀Reifegrad-Bewertung฀des฀Themengebiets฀„Planung,฀Steuerung฀und฀Verfolgung“; ฀Quelle: ฀Siemens฀AG 22฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 nen höheren Erfüllungsgrad der Anforderungen (nach rechts verlaufende Balken) für den definierten Prozess als für den praktisch angewendeten. Dies bedeutet, dass sinnvolle definierte Regelungen in diesem Punkt nicht in die Praxis umgesetzt werden. Die senkrechten Säulen im oberen Bildteil repräsentieren die für das Themengebiet Planung, Steuerung und Verfolgung erzielten Reifegrade; die Einstufung ist für den definierten Prozess günstiger als für den praktizierten. Die linke der drei Säulen repräsentiert den Gesamtreifegrad für das Themengebiet, der aus den Resultaten für den definierten und praktizierten Prozess berechnet wird. Abhängig von den Bewertungen der definierten und gelebten Prozesse sowie ihrer Konsistenz kann der Gesamtreifegrad sogar niedriger sein als die beiden Einzelergebnisse (siehe Abb. 6). Die Reifegrade werden im Bereich 1 bis 5 in Schritten von 0,25 ausgewiesen, also beispielsweise 1,25 oder 2,75. Diese feine Einstufung erlaubt eine präzise Einschätzung der Prozessfähigkeit einer Organisationseinheit. Die fein abgestufte Reifegradermittlung erlaubt eine gute Verfolgbarkeit der Fortschritte prozessverbessernder Maßnahmen im Anschluss an das Assessment. Gesamtreifegrad: Als zusammenfassende Beurteilung wird der Gesamtreifegrad der Projektmanagement- Prozesse der Organisation berechnet. Abb. 7 zeigt ein Beispiel der Darstellung. Dieser dient als grundsätzliche Einordnung der Prozessqualität der Organisation (siehe Abb. 1) vor dem Hintergrund der definierten Prozess-Reifegradstufen und signalisiert unmittelbar den Handlungsbedarf. Daneben bietet er ein Mittel des Vergleichs: Welche Reifegrade haben die Prozesse vergleichbarer Organisationen? In vielen Fällen werden über diese Frage Ansatzpunkte zum Erfahrungsaustausch und zur Übernahme bewährter Verfahren von einer Organisation in eine andere initiiert. 4.2฀ Maßnahmenkatalog Alle im Stärken-/ Schwächen-Profil zu den einzelnen Prozessthemen vorgeschlagenen Maßnahmen werden zu einem Maßnahmenkatalog zusammengeführt. Typischerweise enthält er zwischen 50 und 100 Einträgen. Als Orientierungshilfe für die spätere Umsetzung wird für jede Einzelmaßnahme eine erste Einschätzung des Assessorenteams hinsichtlich der Priorität, des geschätzten Umsetzungsaufwands und der voraussichtlichen Umsetzungsdauer bestimmt. Die Priorität der Maßnahmen orientiert sich dabei primär an den spezifischen Erfolgsfaktoren der Organisation, die im Interview mit dem Management festgehalten wurden (vgl. Abschnitt 3.3). Daneben wird der thematische Bezug der Maßnahmen zu den Themengebieten des Assessments festgehalten als Grundlage für die Darstellung eines zusammenfassendes Handlungsbedarfs-Portfolios. 4.3฀ Handlungsbedarfs-Portfolio Das Handlungsbedarfs-Portfolio zeigt im Überblick die Themenbereiche mit besonders hohem Bedarf nach Prozessoptimierungen und liefert die Begründung für die vorgeschlagenen Arbeitspakete des Verbesserungsprogramms (vgl. Abschnitt 4.4). Abb. 8 zeigt ein Beispiel eines Handlungsbedarfs-Portfolios. In übersichtlicher Form ist dargestellt, welche Prozessthemen vordringlich konsolidiert werden müssen, um eine nachhaltige und spürbare Verbesserung für die Organisation zu erzielen. Zur Positionierung der Teilprozesse im Portfolio werden zum einen die „Bedeutung“ der Prozessthemen für den Erfolg der Organisation aufgetragen und zum ��� ���������� ��������� ����������������������� ���������������������� ����� ����������� ����������� � ��� � ��� � ��� � ��� � ������� ����������� ������� ������������� ������� Abb.฀7: ฀Beispiel฀für฀die฀Darstellung฀des฀Reifegrads฀des฀Gesamtprozesses; ฀Quelle: ฀ Siemens฀AG 24฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 anderen der „Handlungsbedarf“ berücksichtigt, der zu einer schnellen Verbesserung der Reifegrad-Bewertung führen würde. Themenbereiche, die unter beiden Maßstäben hohen Handlungsbedarf zeigen, sind beim anschließenden Verbesserungsprogramm vordringlich zu behandeln. Im Beispiel sind dies die Themen im grau hinterlegten Feld des Portfolios. 4.4฀ Arbeitspakete฀zur฀Prozessverbesserung Aus dem Handlungsbedarfs-Portfolio und der Maßnahmenliste werden abschließend Arbeitspakete für ein Prozessverbesserungsprogramm gebündelt. Sie werden um einen ersten Plan zur Maßnahmenumsetzung ergänzt, um die zügige Aufnahme des Verbesserungsprogramms zu ermöglichen. Die Erfahrung zeigt, dass die Erfolgsaussichten um so größer sind, je kürzer der Zeitraum zwischen dem Abschluss des Assessments und dem Beginn der Maßnahmenumsetzung ist. 4.5฀ Start฀eines฀Prozessverbesserungsprogramms Die Ergebnisse eines Projektmanagement-Assessments enthalten detaillierte Informationen darüber, an welchen Stellen im Prozess welche Veränderungen einen Fortschritt für die Organisation erwarten lassen. Wichtige Erfolgsfaktoren für ein Prozessverbesserungsprogramm sind die Art der Planung dieses Vorhabens und die Konsequenz der Umsetzung beschlossener Maßnahmen. Prozessverbesserung erfordert immer zusätzliche Anstrengungen aller Beteiligten. Aufgrund der allgemein hohen Arbeitsbelastung der Mitarbeiter kann deren Motivation zum Erbringen des anfänglichen Zusatzaufwands nur dann hochgehalten werden, wenn das Programm durch das Management der Organisation spürbar gestützt wird. Dies bedeutet insbesondere die Bereitstellung von Ressourcen, die engagierte Teilnahme an entsprechenden Aktivitäten und die Kontrolle des Fortschritts. Als besonders tragfähig hat sich herausgestellt, Prozessverbesserungsprojekte wie „normale“ Projekte zu behandeln. Zu einem erfolgversprechenden Prozessverbesserungsprojekt gehören also insbesondere klare Ziele und eindeutig festgelegte Ergebnisse, eine an den Zielen orientierte Planung, ein adäquates Budget, eine geeignete Projektorganisation und eine regelmäßige Fortschrittskontrolle. 5฀ Erfahrungen Das Projektmanagement-Assessment ist bisher ca. ein Dutzend Mal in unterschiedlichen Geschäftsbereichen verteilt auf Standorte weltweit durchgeführt worden. Ähnlich der umfangreichen Erfahrung in Entwicklungsorganisationen haben sich diese Assessments als ein geeignetes Instrument erwiesen, die Stärken und Schwächen der Projektabwicklung detailliert zu analysieren und konkrete Verbesserungsmöglichkeiten zu identifizieren. Durch die Betrachtung der Prozesse im Zusammenhang mit den Erfolgsfaktoren der Organisation wird die Zielklarheit der Verbesserungsmaßnahmen geschärft. Die Einbindung aller Hierarchieebenen lenkt die notwendige Aufmerksamkeit auf die Bedeutung exzellenter Prozesse - die Sichten von Management und Mitarbeitern werden abgeglichen. Die intensive Diskussion des Assessorenteams mit Management und Mitarbeitern schafft bei einem Projektmanagement-Assessment einen Zuwachs an Prozess- Know-how und Verständnis. Die in den durchgeführten Assessments gesammelten Beispiele und Erfahrungen werden über die Assessorenteams zwischen den Organisationen transferiert.  Literatur [1]฀Lebsanft,฀K.; ฀Westermann,฀F.: ฀Siemens-Projektmanagement-Assessment-Dokumentation.฀20.฀Internationales฀ Deutsches฀Projektmanagement฀Forum฀2003 [2]฀Chrissis,฀M.฀B.; ฀Konrad,฀M.; ฀Shrum,฀S.: ฀CMMI฀-฀Guidelines฀for฀Process฀Integration฀and฀Product฀Improvement.฀ Addison-Wesley,฀2003 [3]฀Kneuper,฀R.: ฀CMMI฀-฀Verbesserung฀von฀Softwareprozessen฀mit฀Capability฀Maturity฀Model฀Integration,฀ dpunkt.verlag,฀2003 [4]฀Paulk,฀M.; ฀Weber,฀C.฀V.; ฀Garcia,฀S.; ฀Chrissis,฀M.฀B.; ฀ Bush,฀M.: ฀Key฀Practices฀of฀the฀Capability฀Maturity฀Model฀ Version฀1.1,฀CMU/ SEI-91-TR-24,฀CMU,฀1991 Schlagwörter Assessment,฀Kundenprojekt,฀Projektmanagement,฀Prozessverbesserung,฀Reifegradmodell ����������������� ��� ������� ����������� ��� ���� �������� �������� ��������� ��� ���������� ������������������� ������� �������������� ��������� �������� ��������� ���������������� ����������������� ��������������� ��� ���������� ���������� ��������� �������� ��� ������������ ���������� ���������������� ����������������������������� ������������� ��������������� ��������� �������������� ������������ � � �� �� �� �� �� � ���� � ���� � ���� � �� ��� �� � �� �� �� �� �� �� � �� � � � ��� Abb.฀8: ฀Beispiel฀eines฀Handlungsbedarfs-Portfolios; ฀Quelle: ฀Siemens฀AG 24฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Autor Karl฀Lebsanft฀studierte฀Mathematik฀ und฀Informatik฀in฀München.฀Er฀ist฀ Senior฀Principal฀Consultant฀und฀Projektleiter฀in฀der฀Abteilung฀Corporate฀ Technology฀der฀Siemens฀AG.฀Er฀hat฀ mehr฀als฀zwanzig฀Jahre฀Erfahrung฀in฀ Software-Engineering,฀Entwicklung฀ und฀Projektmanagement.฀In฀den฀ letzten฀zehn฀Jahren฀hat฀er฀weltweit฀zahlreiche฀Prozess- Assessments฀und฀Risiko-Audits฀kritischer฀Projekte฀mit฀ einem฀Umfang฀von฀bis฀zu฀tausend฀Mitarbeiterjahren฀geleitet.฀Er฀betreut฀als฀Berater฀die฀Durchführung฀von฀Prozessverbesserungsprogrammen฀und฀die฀Einführung฀quantitativer฀Steuerungssysteme฀wie฀Scorecards฀in฀den฀Bereichen฀ der฀Siemens฀AG.฀Seine฀Interessen฀darüber฀hinaus฀liegen฀ in฀den฀Gebieten฀Aufwandsschätzung,฀Prozessmodellierung฀ und฀-simulation฀sowie฀Führung฀und฀Mitarbeiter-Management. Anschrift Siemens฀AG CT฀SE฀3 D-81730฀München Tel.: ฀0฀89/ 6฀36-5฀33฀65 Fax: ฀0฀89/ 6฀36-4฀44฀24 E-Mail: ฀karl.lebsanft@siemens.com Autor Frank฀Westermann฀studierte฀Informatik฀und฀Wirtschaftswissenschaften.฀ Er฀hat฀mehr฀als฀zehn฀Jahre฀Erfahrung฀ als฀Entwickler฀von฀Embedded-Software-Systemen฀und฀als฀Projektleiter.฀ Umfangreiche฀Erfahrung฀hat฀er฀in฀der฀ Abwicklung฀von฀Kundenprojekten฀ speziell฀im฀Nahen฀Osten฀und฀in฀Afrika.฀ Seine฀Arbeit฀in฀der฀Abteilung฀Corporate฀Technology฀der฀ Siemens฀AG฀als฀firmeninterner฀Berater฀umfasst฀die฀Durchführung฀von฀Prozess-Assessments฀weltweit฀und฀die฀Unterstützung฀von฀Verbesserungsprojekten฀in฀den฀Bereichen฀der฀ Siemens฀AG.฀Er฀ist฀aktiv฀an฀der฀Pflege฀und฀Weiterentwicklung฀der฀eingesetzten฀Assessment-Verfahren฀beteiligt.฀Seine฀Interessen฀liegen฀in฀den฀Gebieten฀Qualitätsmanagement฀ und฀der฀Schulung฀und฀Einführung฀von฀Review-Methoden฀ sowie฀dem฀Outsourcing฀und฀Management฀von฀Unterauftragnehmern. Anschrift Siemens฀AG CT฀SE฀3 D-81730฀München Tel.: ฀0฀89/ 6฀36-5฀76฀30 Fax: ฀0฀89/ 6฀36-4฀44฀24 E-Mail: ฀frank.westermann@siemens.com 26฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Softwaremessung,฀ quantitative฀Projektsteuerung฀ und฀Benchmarking Wie฀helfen฀sie฀dem฀Software-Projektmanager? Siegfried฀Seibert Zum฀Benchmarking฀von฀Softwareprojekten฀haben฀quantitative฀Prozessmessungen฀bisher฀ nur฀eine฀geringe฀Verbreitung฀gefunden; ฀zu฀Unrecht,฀wie฀der฀Verfasser฀meint.฀Der฀Anwendungsbereich฀von฀Softwaremessungen฀geht฀dabei฀weit฀über฀das฀Projektbenchmarking฀ hinaus.฀Mit฀ihnen฀kann฀ein฀gravierendes฀Problem฀des฀IT-Projektmanagements฀bekämpft฀ werden: ฀Studien฀zeigen฀regelmäßig,฀dass฀die฀meisten฀IT-Projekte฀ihre฀Termine฀und฀ihre฀ Budgets฀deutlich฀überziehen.฀Quantitative฀Prozessmessungen฀und฀Benchmarks฀können฀helfen,฀die฀Erfolgsbilanz฀anzuheben฀sowie฀Produktivität฀und฀Qualität฀der฀Entwicklungsprozesse฀ zu฀verbessern. W as wollen Kunden und Vorgesetzte von einem Projektleiter gewöhnlich wissen? Sie stellen meist Fragen wie die folgenden:  „Wann ist das System einsatzbereit? … Wird das auch klappen? “  „Wie viele Testzyklen brauchen wir noch? … Ich meine, wie viele genau? “  „Werden wir alle Anforderungen erfüllen? … Wie viele sind schon realisiert? “  „Wir müssen uns auf die fehlerintensiven Module konzentrieren. Welche sind das? “ Kunden und Vorgesetzte interessiert also weniger, wie das Projektmanagement gemacht wird. Sie interessiert in erster Linie, ob die Ergebnisse stimmen und dass gegebene Zusagen eingehalten werden. Softwaremessung฀und฀PM-Assessmentmodelle Dazu braucht der Projektleiter geeignete Instrumente, mit denen er die Projektsituation beurteilen und die weitere Entwicklung abschätzen kann. Projektmanagementbezogene Assessmentsysteme wie das „Project- Excellence“-Modell oder PM Delta der GPM sowie das Project Management Maturity Model (PMMM) von Kerzner und andere verwandte Modelle [1] fordern zwar die Anwendung derartiger Instrumente und Methoden, stellen sie aber nicht bereit. Diese Modelle zeigen auf, wie ein Projekt professionell gemanagt werden soll, konzentrieren sich dabei jedoch auf die indirekten Leitungs- und Unterstützungsprozesse. Die wertschöpfenden Arbeitsprozesse und die Projektergebnisse bleiben außer Betracht oder werden lediglich qualitativ beurteilt. Gerade die wertschöpfenden Prozesse und die Projektergebnisse muss ein Projektleiter aber im Griff haben, wenn er erfolgreich sein will. Dazu ist auf intuitive Abschätzungen wenig Verlass. Selbst wenn sie von erfahrenen Projektleitern kommen, sind sie bei größeren Projekten äußerst unsicher und manipulationsanfällig. Projekt-Aufwandsschätzungen, Assessments und Benchmarks sollten daher immer auch auf quantitativen Daten (Metriken) beruhen. Im Softwarebereich versteht man unter dem Begriff „Metrik“ die Messung der Eigenschaften eines Softwareprodukts und seines Entwicklungsprozesses. In der Unternehmenspraxis sind Metriken noch wenig verbreitet. In den Vereinigten Staaten wenden Metriken nur etwa 15 bis 20 % der Software-Entwickler an [2]. Deutschland ist im internationalen Bereich noch schwächer vertreten. Die auf diesem Gebiet führende „Deutschsprachige Anwendergruppe für Softwaremetrik und Aufwandsschätzung“ DASMA hat nur etwa 50 Mitglieder [3]. Auch in der Projektmanagementliteratur findet man nur selten Titel zu diesem Themengebiet. Wenn sich damit beschäftigt wird, dann von Softwaretechnikern, beispielsweise der Fachgruppe 2.1.10 „Software-Messung und Bewertung“ der Gesellschaft für Informatik GI [4]. Softwaremessung฀im฀Capability฀Maturity฀Model฀CMM Ziel des vorliegenden Beitrags ist es daher, die Relevanz von Softwaremessungen für das Projektmanagement aufzuzeigen. Dabei wird immer wieder auf das Capability Maturity Model CMM Bezug genommen. Das CMM ist ein Katalog von Best Practices, das in fünf aufeinander aufbauende Reifegradstufen unterteilt ist (Abb. 1). Das Modell dient der Verbesserung von Qualität und Leistungsfähigkeit von Software-Entwicklungen. Seit seiner Entstehung Ende der 80er Jahre hat das CMM weltweit eine immer größere Verbreitung gefunden und ist mittlerweile ein Quasistandard zur Zertifizierung von Software-Organisationen geworden. 26฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 In den Best Practices des CMM sind Softwaremessungen ein wichtiger, aber nicht sofort offenkundiger Bestandteil. Auf CMM-Stufe 2 werden im Rahmen der Software-Projektplanung und -verfolgung Produktgrößen-, Aufwands-, Kosten- und Terminschätzungen sowie die Erhebung und Überwachung dieser Messgrößen nach dokumentierten Verfahrensrichtlinien gefordert. Auf Stufe 3 wird gefordert, dass Projektschätzungen auf Basis eigener Erfahrungsdaten vorgenommen werden. Auf Stufe 4 wird ein metrikbasiertes, quantitatives Prozessmanagement gefordert. Spätestens zu der auf Stufe 5 geforderten Prozessverbesserung sind zusätzliche quantitative Benchmarks erforderlich [5]. Im Folgenden sollen Einsatz und Nutzen von SW- Messungen für das Projektmanagement in grober Anlehnung an die Reifegradstufen des CMM erläutert werden. Wichtig dabei ist, dass die metrikbasierten Forderungen auf jeder Stufe in ein aufeinander abgestimmtes Gesamtpaket an Best Practices eingebunden sind. Um฀welche฀Messgrößen฀geht฀es? Um einen Überblick über die wichtigsten Messgrößen zu geben, wird zwischen Produktmetriken und Prozessmetriken unterschieden. Produktmetriken Produktmetriken beziehen sich auf das Ergebnis eines Softwareprojekts, insbesondere dessen Größe, Komplexität und Qualität. Die Produktgröße ist eine unverzichtbare Grundgröße für jede Projektmessung, weil nur durch ihre Berücksichtigung größere und kleinere Projekte miteinander vergleichbar gemacht werden können. Zu ihrer Erfassung gibt es zwei verschiedene Ansätze:  Die technische Produktgröße, gemessen als Anzahl der Befehlszeilen (Einheit KLOC = Kilo Lines of Code).  Die funktionale Produktgröße, gemessen in Funktionspunkten oder damit verwandten Einheiten. Beide Größen sind nützliche Vorhersageindikatoren für den Projektaufwand und lassen sich bei Kenntnis der Programmiersprache ineinander umrechnen („Backfiring“). Vorteile der Befehlszeilen sind ihr höherer Verbreitungsgrad und die Möglichkeit, sie automatisiert zu messen. Demgegenüber können Funktionspunkte bereits zu frühen Projektzeitpunkten durch Auszählung des Lastenhefts ermittelt werden. Außerdem sind sie für einen fachkundigen Kunden einfacher nachvollziehbar als Befehlszeilen. Sie eignen sich daher auch als Abrechnungsgrundlage in Kunden-Lieferanten-Projekten. In verschiedenen Ländern (z. B. Australien, Italien) wird ihre Angabe bei Angeboten für öffentliche Ausschreibungen sogar gefordert. Eine weitere aufwandsbeeinflussende Größenmetrik, die einfach zu bestimmen ist, ist der Seitenumfang der System- und Benutzerdokumentation. Zur Messung der Produktkomplexität wird meist die Anzahl der Schnittstellen zwischen den verschiedenen Systemkomponenten (z. B. Modulen, Klassen, Methoden) verwendet. Ein einfaches Komplexitätsmaß ist beispielsweise die zyklomatische Komplexität nach McCabe, die sowohl für Programm-Module und Systementwürfe als auch für Geschäftsprozessanalysen ermittelt werden kann. Mit Komplexitätsmetriken lassen sich diejenigen Programmteile identifizieren, die besonders fehleranfällig sind. Der Projektleiter gewinnt damit ein Instrument, mit dem er die aufwändigen Code-Inspektionen auf diejenigen Module konzentrieren kann, die davon am meisten profitieren. Weniger komplexe Module können mit einfacheren Mitteln überprüft werden [6]. ���������������� �������������������� ���������� ��������� �������� ������������ ������������� ������������ ������� ���������� ������������ ���������� � �������� ���� ����������������� �������������� ������������� ���������� � ������� ��� �������������� ����������������� �������������� ���������� ���������������� ���������� ������������� ������������ �������� ���������� �������������������������� � ������� ������������� ����������� ������ ������������� ���������� ��������������� ���������� � ������� ������ ������������ ����������� ����������� � ����� ����� ���������� ��������� ������� ���������� ��������� Abb.฀1: ฀Reifegrade฀und฀Best฀Practices฀im฀Capability฀Maturity฀Model฀CMM 28฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 29฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Als Metrik für die Produktqualität wird am häufigsten auf die Fehleranzahl verwiesen, unterteilt nach Fehlerursachen und Fehlerschwere. Als Produktmetrik erfordert sie eine nicht unproblematische Abschätzung der in einem System inhärenten Restfehler. Häufiger werden Fehlermetriken daher als Prozessmetriken in der Systemtestphase eingesetzt. Dabei werden die Anzahl der neuen Fehlermeldungen und die Anzahl der als behoben gemeldeten Fehler im Wochenrhythmus gegenübergestellt. Dies ermöglicht relativ verlässliche Prognosen des Freigabezeitpunkts. Neben Fehlerzählungen und -prognosen werden als Qualitätsmetriken häufig auch Kundenreklamationen und Kundenbefragungen verwendet. Beispielsweise berichtet Cohn [7] über einen Index, bei dem die schwerwiegenderen A- und B-Reklamationen mit der Zeitdauer gewichtet werden, seit der eine Reklamation eingegangen, aber noch nicht behoben ist. Mit diesem Index konnten Reklamationsbearbeitung und Kundenzufriedenheit innerhalb kurzer Zeit deutlich gesteigert werden. Prozessmetriken Prozessmetriken beziehen sich auf Aktivitäten und Instrumente im Software-Entwicklungsprozess. Hierzu zählen zum einen Ressourcenverbrauch, Aufwand, Kosten und Dauer der Projektaktivitäten. Zum anderen zählen hierzu aber auch Metriken zur Verfolgung des Projektfortschritts, der Projektdynamik und des Projektklimas:  Der Projektfortschritt kann verfolgt werden, indem die Anzahl der definierten, entworfenen, codierten, geprüften und getesteten Module oder die Anzahl der fertiggestellten Code-Zeilen und Dokumentationsseiten gezählt werden. Auch die oben erwähnte Verfolgung von Fehlermeldungen oder von Testaktivitäten und von Reviews liefert Indikatoren für den Projektfortschritt.  Die Projektdynamik kann anhand der Anzahl beantragter, genehmigter und realisierter Änderungen gemessen werden.  Zur Verfolgung des Projektklimas kann durch regelmäßige Team- und Stakeholderbefragungen ein Klimaindex ermittelt werden [8]. Software-Metriken฀zur฀Aufwandsschätzung Was kann der Projektleiter nun mit derartigen Softwaremessungen anfangen? Ein erster, wichtiger Anwendungsbereich ist die Verbesserung der Projekt-Aufwandsschätzung. Aufwand, Kosten und Termine von Software-Entwicklungen können auf zwei Wegen geschätzt werden:  Expertenschätzungen der einzelnen Arbeitspakete des Projektstrukturplans.  Parametrische Schätzgleichungen, die eine mathematische Beziehung zwischen Projektaufwand, Projektgröße und anderen Einflussfaktoren herstellen. Während die in Deutschland vorherrschenden Expertenschätzungen bei kleineren Projekten im Vordergrund stehen, dienen parametrische Methoden vornehmlich der Schätzung großer Projekte in frühen Projektphasen. Hier ermöglichen sie bei sorgfältiger Anwendung bessere und schnellere Ergebnisse als Expertenschätzungen, da zu diesem Zeitpunkt noch keine ausgereiften Projektstrukturpläne vorliegen. Bekannte parametrische Schätzsysteme sind beispielsweise COCOMO II, PRI- CE, KnowledgePlan und SLIM. Zur Schätzung von Aufwand und Zeitdauer eines Projekts werden dabei von allen Systemen ähnliche Gleichungen verwendet. Exemplarisch sei dies anhand der COCOMO-Grundgleichung verdeutlicht [9]: Aufwand = PK · KLOC KE · AM, mit  Aufwand in Personenmonaten,  PK = Produktivitätskoeffizient (= 2,94),  KLOC = 1.000 logische Programmbefehle,  KE = Komplexitätsexponent (= 1,1),  AM = Aufwandsmultiplikator (Produkt aus ca. 20 Einzeleinflüssen). Der Aufwandsmultiplikator AM liegt bei mittleren Projekten bei eins und spielt für unsere Betrachtung keine wesentliche Rolle. Auf ihn soll daher nicht weiter eingegangen werden. Der Produktivitätskoeffizient PK und der Komplexitätsexponent KE sind Maße, mit denen die Produktivität einer Softwareorganisation bei zunehmender Projektgröße beziffert werden kann. Die dafür von COCOMO angegebenen mittleren Werte 2,94 und 1,1 wurden durch die statistische Auswertung von rund 160 abgeschlossenen Projekten bestimmt. Ein Anwender der COCOMO-Gleichungen kann zunächst nicht beurteilen, ob in seinem Unternehmen vergleichbare Produktivitätsraten vorliegen. Nur dann wäre die direkte Verwendung dieser Koeffizienten gerechtfertigt. Für eine hohe Schätzgenauigkeit müssen die Koeffizienten der Schätzgleichungen daher an die im Unternehmen vorliegenden Randbedingungen angepasst werden. Dies geschieht durch die als Kalibrierung bezeichnete Auswertung eigener Projektdaten. Kalibrierung฀von฀Schätzgleichungen Mathematisch gesehen sind bei der Kalibrierung der Produktivitätskoeffizient und der Komplexitätsexponent die zu ermittelnden Größen. Die Anzahl der Programmbefehle und der Aufwand sollten für eine Reihe abgeschlossener Projekte durch die Auswertung von deren Istdaten bekannt sein. Mithilfe eines Tabellenkalkulationsprogramms kann dann eine Kalibrierung auch ohne größere mathematische Kenntnisse vorgenommen werden (Abb. 2): Die erhobenen Datenpunkte werden eingegeben und daraus ein x-y-Diagramm mit einer exponentiellen Trendlinie abgeleitet (bei doppellogarithmischer Skalierung eine Gerade). Für diese Trendlinie werden vom Programm die Gleichungskoeffizienten und das statistische Bestimmtheitsmaß ausgewiesen. Fertig ist die eigene parametrische Schätzgleichung. Deutlich฀erhöhte฀Schätzgenauigkeit Welchen Gewinn bringt eine solche Kalibrierung? Bei Siemens zeigte eine Analyse von 60 Projekten mit den Original-COCOMO-Koeffizienten nur in 43 % der Fälle eine Schätzgenauigkeit von ± 20 %. Nachdem die COCOMO-Gleichungen mit siemenseigenen Daten 28฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 29฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 kalibriert waren, lagen 95 % der Fälle innerhalb der 20 %-Bandbreite [10, S. 417]. In Untersuchungen von Jones [2, S. 135 f.] und bei Boeing Information Systems [11] führte der Übergang von intuitiven auf erfahrungsdatengestützte Schätzungen zu ähnlichen Verbesserungen der Genauigkeit. Abb. 3 zeigt die Ergebnisse der Boeing-Studie, bei der 120 Projekte ausgewertet wurden. Die Schätzwerte streuen dabei nicht symmetrisch um die Istwerte. Vielmehr sind die ursprünglichen Schätzwerte niedriger, die späteren Istwerte deutlich höher. Die Unterschätzung des Projektaufwands ist demnach weit verbreitet. Hierin liegt eine der wichtigsten Ursachen der vielbeklagten Termin- und Kostenüberschreitungen von Softwareprojekten. Eine andere Folgerung: Intuitive Expertenschätzungen liefern regelmäßig niedrigere Werte als erfahrungsdatengestützte Schätzungen. Zum einen liegt dies daran, dass Entwickler bei intuitiven Schätzungen meist ihre Produktivität überschätzen. Zum anderen stoßen hohe Schätzungen häufig auf Widerstände bei Management, Vertrieb und Kunden. „Weiche“ intuitive Schätzungen lassen sich dann von diesen Stakeholdern sehr viel leichter nach unten „korrigieren“ als „harte“ erfahrungsdatengestützte Werte. Wenn anhand eigener Daten belegt wird, dass die Produktivität im Vergleich zu den letzten zehn Projekten verdoppelt werden müsste, kann dies nicht mehr so einfach beiseite geschoben werden. Niedrige฀Vorgaben฀sind฀kein฀ Kavaliersdelikt In diesem Zusammenhang sollte auch der in Management und Vertrieb weit verbreitete Irrglaube ad acta gelegt werden, mit zu niedrig angesetzten Planvorgaben die betriebliche Produktivität bis zu ihrem Optimum ausreizen zu können. Zu niedrige Planwerte führen dazu, dass wichtige fachliche, soziale und konzeptionelle Aufgaben in der Startphase vernachlässigt werden, was später zu einem erhöhten „Nacharbeitsaufwand“ führt. Wenn dann der zugesagte Termin nicht eingehalten wird, kommt es zu zusätzlichen Rückfragen des Kunden sowie Analyse-, Planungs- und Krisensitzungen im Unternehmen. Ungerechtfertigter Druck des Managements führt zu Verärgerung und erhöhter Personalfluktuation, und zwar immer zuerst bei den Leistungsträgern im Team. Als Microsoft sein Programm Word für Windows, Version 1.0, entwickelte, wurde auf die Entwickler ein immenser Termindruck ausgeübt. Viele stellten daraufhin codierte Module ohne sorgfältige Prüfung als fertig in die Systembibliothek ein. Folge war, dass die anschließenden Systemtests aufgrund der vielen zu behebenden Fehler viermal so lange dauerten wie vorher bei Microsoft üblich [12, S. 207ff.]. Zu niedrige Projektvorgaben sind also kein „Kavaliersdelikt“, sie sind aufwandserhöhend. Wahrscheinlich hätten viele der auf der linken Hälfte in Abb. 3 gezeigten Projekte mit einem geringeren Aufwand und weniger „atmosphärischen“ Störungen abgeschlossen werden können, wenn sie vorab fundierter geschätzt worden wären. Metriken฀zur฀quantitativen฀Prozess-Steuerung Neben der Kalibrierung parametrischer Gleichungen ist das Haupteinsatzfeld von Softwaremetriken die quantitative Prozess-Steuerung von Projekten. Hiermit soll die aus dem Total Quality Management stammende Statistische Prozessregelung (Statistical Process Control SPC) auf das Projektmanagement übertragen werden. Das Grundprinzip: Bei jedem Arbeitsprozess kann es Abweichungen vom erwarteten Sollwert geben. Als Ursachen dafür kommen die natürliche Streuung einerseits und außerordentliche Einflüsse andererseits in Frage. Die natürliche Streuung entsteht aus einer Vielzahl kleiner, immer wieder vorkommender Einzeleinflüsse. Sie ist relativ gut vorhersehbar. Dagegen treten außerordentliche Einflüsse nur unregelmäßig auf, haben größere Auswirkungen und machen einen Prozess instabil. Bei ihrem Auftreten muss das Management sofort aktiv werden. Bei natürlichen Streuungen sind demgegenüber störende Überreaktionen zu vermeiden. ��������� ���� � � ������� � � �� ��� ����� ������ ������� � �� ��� ����� ����������������������������� ������������������������ Abb.฀2: ฀Kalibrierung฀von฀Schätzgleichungen ����� ���� ����� �������������������������������� ������������������������������������� ���������������������������� ��������������������������������� �������������������������������� ��������������������������� ��������������������������������� ������������� ������������������������������������ ����������������������������� Abb.฀3: ฀Verbesserte฀Schätzungen฀durch฀Erfahrungsdatensammlung 30฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 31฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Mit฀Kontrolldiagrammen฀außerordentliche฀Einflüsse฀ erkennen Durch Kontrolldiagramme können - ähnlich einer Fieberkurve im Krankenhaus - natürliche und außerordentliche Faktoren voneinander unterschieden werden. Im Projektmanagement werden die Grenzen dabei meist bei der ein- oder zweifachen Standardabweichung um den Mittelwert gezogen. Innerhalb dieser Grenzen sind dann nach den Regeln der Normalverteilung rund 68 % bzw. 95 % aller Werte zu erwarten. Abb. 4 zeigt als Beispiel ein Kontrolldiagramm zur Prognose und Verfolgung von Fehlermeldungen. Die historische Erfahrungslinie und deren Bandbreite wurden vorab aus der Auswertung von etwa 25 früheren Projekten gewonnen. Solange bei einem neuen Projekt die Fehlerzahlen innerhalb dieser Bandbreiten liegen, befindet sich der Fehlerverlauf innerhalb der erwarteten natürlichen Streuung. Er ist unter „statistischer Kontrolle“. Außerhalb der Bandbreiten liegen außergewöhnliche Einflüsse vor, deren Ursachen ermittelt werden müssen. Beispielsweise kann die Abweichung des in Abb. 4 dargestellten Projekts viele Ursachen haben. Dazu gehört auch die Möglichkeit, dass das Team keine Fehlermeldungen abgegeben hat oder dass zu wenig getestet wurde. Falls diese Ursachen ausgeschlossen werden können, handelt es sich wahrscheinlich um ein besonders zuverlässiges Softwaresystem. Teilweise können Abweichungen durch Cross-Checks mit anderen Kontrolldiagrammen analysiert werden, andernfalls sind spezielle Ursachenanalysen erforderlich. Das „Manager’s Handbook“ des Software Engineering Laboratory SEL der US-Raumfahrtbehörde NASA enthält rund ein Dutzend Beispiele empfehlenswerter Kontrolldiagramme für Qualitäts- und Projektfortschrittsmetriken [13]. Kontrolldiagramme können aber auch für die klassischen Projektsteuerungsgrößen Termine, Aufwände und Kosten geführt werden. Beispielsweise wird bei Telcordia, einem Abkömmling der Bell Laboratories, auch für die Termineinhaltung ein Kontrolldiagramm geführt. Telcordia ist mit mehr als 3.500 SW-Entwicklern die bisher größte nach CMM Stufe 5 zertifizierte Softwareorganisation weltweit. Das Terminkontrolldiagramm wird aus Microsoft-Project-Daten abgeleitet und dient dazu, Abweichungen von der normalen Termintreue frühzeitig zu erkennen [14]. Lipke [15] berichtet über die Anwendung der statistischen Prozessregelung bei der Arbeitswertanalyse. Daraus lassen sich automatisierte Warnmeldungen erzeugen, wenn Kosten- und Leistungsabweichung aus dem bisher üblichen Rahmen ausbrechen. Metriken฀und฀Benchmarking Mit Kontrolldiagrammen können Projektprozesse zwar innerhalb ihrer natürlichen Streuung vorhergesagt und auftretende negative Abweichungen erkannt und beseitigt werden. Zur substanziellen Verbesserung des Produktivitäts- und Qualitätsniveaus leisten sie jedoch nur einen begrenzten Beitrag. Hierzu besser geeignet sind metrikgestützte Benchmarkinganalysen. Durch Benchmarkinganalysen kann ein Unternehmen erkennen, wo es im Vergleich zu seinen Wettbewerbern ������� ��������� ���������� ����������� ������ ���� ������������� ���������� ������ ��� ����� ���� � � � ������� �������� ��������� ���������� ����������� ��������� ��������� ������� Abb.฀4: ฀Kontrolldiagramm฀zur฀Verfolgung฀der฀Softwarequalität ������������������ ��������������� �������������� ������������������ ���� �������� ������� ������������ ����� ����� ������� ������� ������ ����������� ����� �������� �������� ����������� ������ �� ���� ��� ���� ��� ������� ��� ��������� ����� ���� ��� ��� �� ��� ������� ������������ ��������� Abb.฀5: ฀Struktur฀von฀Benchmarkinganalysen฀[16,฀S.฀56] Abb.฀6: ฀Beispiel฀eines฀Benchmarkingdiagramms฀[16,฀S.฀83] 30฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 31฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 und anderen ähnlichen Unternehmen steht. Neben quantitativen Daten werden dabei auch qualitative Informationen über die Ursachen von Leistungsunterschieden ausgewertet (Abb. 5). Beim Benchmarking vergleicht sich ein Unternehmen sowohl mit dem Durchschnitt als auch mit den Besten seiner Klasse (Abb. 6). Aus der Auswertung sieht das Unternehmen, wie stark und in welchen Bereichen es sich verbessern muss, wenn es zur Spitzenklasse gehören will. Um Unternehmen zu Verbesserungsprogrammen zu veranlassen, sind quantitative Benchmarks wie in Abb. 6 dem Top-Management leichter vermittelbar als abstrakte CMM-, PMMM- oder PM-Delta-Einstufungen. Wenn ein Unternehmen von fünf Funktionspunkten pro Personenmonat auf zehn kommen muss, um mit dem Industriedurchschnitt gleichzuziehen, versteht ein Top-Manager das ohne lange Erklärung. Sammlung฀von฀Benchmarkingdaten Projektbezogene Benchmarkingansätze gibt es im Softwarebereich bereits seit den 70er Jahren. Seither wurden für Vergleiche mit anderen Unternehmen mehrere firmenübergreifende Industrie-Datenbasen aufgebaut, insbesondere für Daten zum Projektaufwand und zur Projektgröße. Am bekanntesten sind  die International Software Benchmarking Standards schiedenen Consulting-Unternehmen die Durchführung kundenindividueller Benchmarkingstudien angeboten. Bekannt sind hier beispielsweise Software Productivity Research, die Standish Group, die Gartner Group und Howard Rubin Associates. Abb. 7 zeigt den typischen Ablauf einer solchen Studie. Benchmarkingstudien bedürfen eines sorgfältigen Vorgehens und kommen normalerweise nicht ohne Vor- Ort-Besuche zur Datenerhebung und Prozessanalyse aus. Hauptproblem ist die Konsistenz der erhobenen Benchmarking-Daten: In verschiedenen Unternehmen werden Größen wie Lines of Code, Personenmonate oder Fehlerzahl häufig ganz unterschiedlich ermittelt. Beispielsweise erfassen Unternehmen den Projektaufwand oft nur lückenhaft und ungleichmäßig. Dies betrifft u. a. die Fragen,  welche Projektaktivitäten im Aufwand enthalten sind und welche nicht,  wie viele Stunden pro Monat normalerweise gearbeitet wird,  ob die Stunden von Supportpersonal und oberem Management in die Projektkosten eingerechnet wurden oder nicht und  wie unbezahlte Überstunden behandelt werden. Zusätzlich sind nicht alle Arten von Softwareprojekten direkt miteinander vergleichbar. Die Produktivität in einem technisch geprägten Projekt für öffentliche �������� ������� ���������� ��������� ���������� ����� ������������� �������� � ������������� �������� � ������������� �������� � ������������ �������� ������� ���������� ����������� ��������� ����������� �������������� ��������� ����������� ���������� Abb.฀7: ฀Ablauf฀von฀Benchmarkingstudien฀[16,฀S.฀56] Anzeige Group (ISBSG, gesprochen „Ice- Bags“) [17],  das Data & Analysis Center for Software (DACS) des amerikanischen Department of Defense [18] und  Datenbasen von Anbietern kommerzieller Tools zur Software-Aufwandsschätzung, insb. KnowledgePlan und SLIM [19]. Die genannten Datenbasen wurden primär zur Kalibrierung von Aufwandsschätzsystemen eingerichtet. Zur fundierten Festlegung von Verbesserungsmaßnahmen sind ergänzende projektspezifische Datenerhebungen und qualitative Analysen erforderlich. Hierzu wird von ver- 32฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 33฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Auftraggeber ist aufgrund der umfangreichen Dokumentationsanforderungen eine ganz andere als bei einem Web-Projekt für einen mittelständischen Kunden. Auch zwischen kleinen und großen Projekten gibt es erhebliche Produktivitätsunterschiede. Projekte müssen somit zumindest hinsichtlich der Art und der Größe des Projekts klassifiziert werden, um sinnvolle Vergleiche anstellen zu können. Nutzen฀von฀Softwaremessungen Wie ist nun der Einsatz von SW-Metriken insgesamt zu beurteilen? Empirische Erkenntnisse können aus der großen Zahl von Untersuchungen zu CMM-Verbesserungsprogrammen gewonnen werden [20]. Aus Platzgründen sei hier lediglich auf zwei Untersuchungen näher eingegangen: Eine Auswertung der Function- Point-Datenbank von Jones und eine Untersuchung auf Basis der COCOMO-Datenbank. Zum Einsatz von Projektmanagementmethoden in der Softwareentwicklung wertete Jones die Daten von rund 600 Unternehmen aus, die Mehrzahl davon Großunternehmen mit mehr als 1.000 Software-Mitarbeitern [2, S. 93]. Abb. 8 zeigt zusammengefasst die Auswirkungen unterschiedlicher Management-Instrumente auf die Termineinhaltungswahrscheinlichkeit. Aus dieser Grafik ergeben sich folgende Erkenntnisse:  Durch metrikbasierte Aufwandschätztools und eine systematische Projektverfolgung steigt die Termineinhaltungswahrscheinlichkeit stärker an als durch die Verwendung von Planungstools wie MS Project.  Einen noch stärkeren positiven Einfluss hat allerdings ein systematisches Qualitätsmanagement. Darunter fallen intensive Design- und Code- Inspektionen, umfangreiche Tests und automatische Fehlerverfolgungssysteme. Das Diagramm bezieht sich auf mittelgroße industrielle Projekte im Umfang von 80 bis 100 Personenjahren. Bei kleinen Projekten von einem Personenjahr ist die Erfolgswahrscheinlichkeit um 35 Prozentpunkte höher als in Abb. 8. Diese Projekte können damit auch ohne Metriken mit traditionellen PM-Methoden (im Diagramm: „Nr. 1 und 2 gemeinsam“) erfolgreich gemanagt werden. Auch die geringe Schwankungsbreite auf CMM-Stufe 3 bei der Boeing-Untersuchung (Abb. 3) ist nicht allein auf die erfahrungsdatengestützten Aufwandsschätzungen zurückzuführen. Mindestens ebenso wichtig ist, dass auf dieser Stufe durch unternehmensweit definierte Prozesse eine hohe Konstanz der Abläufe realisiert wird. Die bisher fundierteste, offen gelegte Untersuchung zu den Produktivitätsauswirkungen von CMM-Programmen wurde von Clark anhand einer Stichprobe aus 161 Projekten der COCOMO-II-Datenbasis vorgenommen [21]. Bei der Stichprobe nahmen die SW-Projektkosten auf den einzelnen CMM-Stufen um folgende Prozentsätze ab:  Stufe 2 (n = 108 Projekte): 2 % (bei kleinen Projekten) bis 5 % (bei großen Projekten) niedriger als Stufe 1 (n = 6),  Stufe 3 (n = 23): 2 bis 5 % niedriger als Stufe 2,  Stufe 4 (n = 18): 4 bis 15 % niedriger als Stufe 3 und  Stufe 5 (n = 6): 7 bis 25 % niedriger als Stufe 4. Hieraus können folgende Schlussfolgerungen abgeleitet werden:  Bei großen Projekten (größer als 500 KLOC) ist der Kostensenkungseffekt wesentlich höher als bei Kleinprojekten (10 KLOC). Dieses Ergebnis bestätigt nochmals die Aussage, dass SW-Metriken weniger ein Instrument für Kleinprojekte als vielmehr für mittlere und große Projekte sind.  Auf den Stufen 2 und 3 sind die beobachteten Kostensenkungen geringer als auf den Stufen 4 und 5. Für die quantitative Prozess-Steuerung und quantitative Benchmarkings kann damit ein wichtiger Produktivitätssteigerungseffekt belegt werden. Andere Studien und Fallstudien [20] zeigten durchweg noch wesentlich höhere Produktivitätseffekte, sind allerdings methodisch und empirisch weniger fundiert. Hauptprobleme฀und฀Ausblick Natürlich sind mit der Anwendung von SW-Metriken auch Probleme verbunden, die vermieden werden sollten. Das gravierendste Problem liegt darin, dass Mitarbeiter ihr Verhalten auf gewünschte Messergebnisse hin ausrichten. Wenn beispielsweise festgelegt wird, dass alle codierten Prozeduren ab einer bestimmten zyklomatischen Komplexität einem Review unterzogen werden müssen, könnten viele Programmierer versuchen, unter der festgelegten Grenze zu bleiben. Vielleicht wird dadurch die Code-Komplexität in Einzelfällen auch verringert. Häufig wird von den Betroffenen jedoch nur manipuliert, um das als lästig empfundene Review zu vermeiden. Um solche kontraproduktiven Effekte zu vermeiden, sind zwei Punkte zu empfehlen:  Unter allen Umständen verhindern, dass Metriken zur Mitarbeiterbeurteilung verwendet werden und persönliche Konsequenzen für die Betroffenen nach sich ziehen, egal ob bewusst oder unbewusst.  Innerhalb eines Metriksystems eine zweite Metrik verfolgen, die das durch die erste Metrik geförderte Verhalten nivelliert. Aus dem letzten Punkt darf sich allerdings keine „Metrik-Inflation“ entwickeln. Vielmehr sollten Metriksysteme immer nur wenige, sorgfältig ausgewählte �� �� �� �� �� �� �� �� �� �� �� �� � �� �� �� �� �� �� �� �� �� ��� ���������������������������������������� ������������������������������������������ ���������������������������������� ������������������������������������� ������������������������������������� ��������������������� ��������������������� ��������������������� ��������������������� ������������������������ ������������������������ ��������������������������� �������������������������������������������������������������� ���������������������������� ������������������������������ Abb.฀8: ฀SW-Projektplanungstools฀und฀Projekterfolg 32฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 33฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Messgrößen enthalten, mit denen die Informationsbedürfnisse der Stakeholder am besten abgedeckt werden. Um einen Eindruck zu geben, wie dies aussehen könnte, zeigt Abb. 9 das seit Jahren mit Erfolg laufende Metrikprogramm des NASA-SEL. Die Messgrößenerfassung erfolgt dabei in wöchentlichen, 14-tägigen und monatlichen Intervallen. Nur wenige Größen werden dabei automatisiert erfasst. Software-Prozess-Steuerung฀in฀Echtzeit Das NASA-System entstand Anfang der 90er Jahre. Inzwischen ist die Entwicklung jedoch wesentlich weiter. Auf CMM-Stufe 4 oder 5 zertifizierte indische Unternehmen haben Prozess-Steuerungssysteme aufgebaut, die Metriken in Echtzeit verfolgen. Die Teams führen dabei alle Projekttätigkeiten ohne Ausnahme mit automatisierten, webgestützten Workflowsystemen durch. Diese Workflowsysteme bereiten unmittelbar nach den Aktionen der Benutzer die daraus resultierenden Metriken auf. Manager, Kunden und benachbarte Teams können den Projektfortschritt dann ohne Zeitverzug „Realtime“ in ihrem Webbrowser verfolgen. Sobald eine Anforderung kreiert, geändert oder genehmigt ist, können die anderen Benutzer dies sehen. Sobald ein Review abgeschlossen ist, werden die gefundenen Fehler in die Fehlerverfolgung und Fehlerstatistik aufgenommen und die Kontrolldiagramme zur Prozess-Steuerung aktualisiert [23]. Warum sind diese fortschrittlichen Prozess-Steuerungssysteme gerade in Indien entstanden? Die meisten der großen indischen Softwarefirmen machen ihr Geschäft mit Auftragsentwicklungen für europäische und amerikanische Kunden. Hierbei müssen sie eine immense Vertrauensbarriere überwinden: Ihre Auftraggeber wissen nicht, ob sie sich bei termin- oder qualitätskritischen Aufträgen wirklich auf die 10.000 km entfernten Projektteams verlassen können. Für den Auftraggeber zugängliche, webgestützte Steuerungssysteme haben wesentlich geholfen, diese Akzeptanzbarriere zu überwinden und gleichzeitig das Projektmanagement zu verbessern. IT-Organisationen, die keine ähnlichen Systeme aufbauen, könnten bald ernsthafte Wettbewerbsnachteile erleiden. Fazit Insgesamt sollte mit diesem Artikel der Nutzen von Metrikprogrammen herausgearbeitet und ein Überblick zu deren Anwendung und Auswertung gegeben werden. Es sollte nicht aufgezeigt werden, wie Metriksysteme im Detail funktionieren oder wie bei deren Einführung am besten vorzugehen ist. Hierzu sei dem Leser die weiterführende Literatur zu diesem Thema empfohlen, beispielsweise das Software Measurement Guidebook des Software Engineering Laboratory der NASA [24].  Abb.฀9: ฀Metrik-System฀des฀Software฀Engineering฀Laboratory฀der฀NASA฀[22,฀ S.฀17฀ff.] Literatur [1]฀Schelle,฀Heinz: ฀Das฀aktuelle฀Stichwort: ฀Benchmarking.฀In: ฀Projektmanagement฀aktuell฀14,฀2003,฀Heft฀2,฀S.฀29-32 [2]฀Jones,฀T.฀C.: ฀Estimating฀Software฀Costs.฀New฀York,฀McGraw-Hill,฀1998 [3]฀Bundschuh,฀M.: ฀Die฀Function฀Point฀Methode฀im฀praktischen฀Einsatz฀bei฀ Softwareprojekten.฀In: ฀Schelle,฀H.; ฀Reschke,฀H.; ฀Schnopp,฀R.; ฀Schub,฀A.฀(Hrsg.): ฀ Loseblattsammlung฀„Projekte฀erfolgreich฀managen“,฀13.฀Aktualisierung,฀Kapitel฀ 4.6.9,฀Köln฀1994฀ff.฀sowie฀www.dasma.de,฀12.฀7.฀2003 [4]฀ivs.cs.uni-magdeburg.de/ sw-eng/ us/ giak/ ,12.฀7.฀2003 [5]฀Paulk,฀Mark฀C.; ฀Curtis,฀Bill; ฀Chrissis,฀Mary฀Beth; ฀Weber,฀Charles฀V.: ฀ Capability฀Maturity฀Model฀for฀Software,฀Version฀1.1.฀Software฀Engineering฀Institute,฀CMU/ SEI-93-TR-24,฀DTIC฀Number฀ADA263403,฀February฀1993,฀ www.sei.cmu.edu/ publications/ documents/ 93.reports/ 93.tr.024.html,฀15.฀7.฀2003 [6]฀Steinmetz,฀A.฀H.: ฀Management฀von฀mittleren฀Softwareprojekten.฀In: ฀Ottmann,฀R.; ฀Grau,฀N.฀(Hrsg.): ฀Projektmanagement฀-฀Strategien฀und฀Lösungen฀für฀ die฀Zukunft.฀Tagungsband฀zum฀17.฀Deutschen฀Projektmanagement-Forum฀im฀ Oktober฀2000฀in฀Frankfurt,฀S.฀139-154 [7]฀Cohn,฀M.: ฀A฀Measured฀Response: ฀Useful฀Metrics฀to฀give฀managers฀the฀ numbers฀to฀back฀up฀project฀hunches.฀In: ฀The฀Software฀Testing฀and฀Quality฀ Engineering฀Magazine,฀September/ October฀2002,฀www.stqemagazine.com/ featured.asp? id=24,฀1.฀7.฀2003 [8]฀Raeder,฀A.: ฀Projekt฀„Euro฀Basis฀Standard“.฀In: ฀Ottmann,฀R.; ฀Grau,฀N.฀(Hrsg.): ฀ Projektmanagement฀-฀Strategien฀und฀Lösungen฀für฀die฀Zukunft.฀Tagungsband฀ zum฀17.฀Deutschen฀Projektmanagement-Forum฀im฀Oktober฀2000฀in฀Frankfurt,฀ S.฀59-70 [9]฀Seibert,฀S.: ฀Aufwandsschätzung฀von฀Softwareprojekten.฀Vieweg,฀Wiesbaden,฀erscheint฀Anfang฀2004 [10]฀Burghardt,฀M.: ฀Projektmanagement: ฀Leitfaden฀für฀die฀Planung,฀Überwachung฀und฀Steuerung฀von฀Entwicklungsprojekten.฀3.฀Auflage,฀Publicidis฀MCD,฀ München฀1995 [11]฀Vu,฀J.฀D.: ฀Process฀Improvement฀Journey฀(From฀level฀1฀to฀Level฀5).฀Keynote- Presentation฀at฀SEPG฀2001,฀www.processgroup.com/ john-vu-keynote2001.pdf,฀ 15.฀7.฀2003 [12]฀McConnell,฀S.: ฀Rapid฀Development: ฀Taming฀Wild฀Software฀Schedules.฀ Microsoft฀Press,฀Redmond,฀Wash.฀1996 [13]฀NASA฀Software฀Engineering฀Laboratory฀(Hrsg.): ฀Manager’s฀Handbook฀ for฀Software฀Development.฀Revision฀1,฀Document฀SEL-84-101,฀Greenbelt,฀ NASA฀Goddard฀Space฀Flight฀Center,฀NASA,฀Maryland฀November฀1990,฀ sel.gsfc.nasa.gov/ website/ documents/ online-doc/ 84-101.pdf,฀12.฀7.฀2003 [14]฀Pitterman,฀B.: ฀Telcordia฀Technologies: ฀The฀Journey฀to฀High฀Maturity.฀In: ฀ IEEE฀Software,฀July/ August฀2000,฀S.฀89-96 [15]฀Lipke,฀W.: ฀Statistical฀Process฀Control฀of฀Project฀Performance.฀ Bereich Messgrößen Quellen Häufigkeit Projektschätzungen •฀ Schätzung฀der฀erwarteten฀Gesamtzahl฀der฀ Befehlszeilen฀und/ oder฀฀Funktionspunkte฀(neu,฀ modifiziert,฀wiederverwendet) •฀ Schätzung฀der฀erwarteten฀Gesamtzahl฀Module •฀ Schätzung฀von฀erwartetem฀Aufwand/ Kosten •฀ Schätzung฀der฀erwarteten฀Meilensteintermine Manager Monatlich Ressourcenverbrauch •฀ Personenstunden฀(gesamt,฀nach฀Aktivitäten) •฀ Rechnernutzung •฀ Kosten฀(gesamt,฀nach฀Aktivität,฀disponiert) Entwickler Automatisiert Controller Wöchentlich฀ Wöchentlich Monatlich Projektfortschritt •฀ Anzahl฀Anforderungen฀(spezifiziert,฀noch฀ offen,฀Änderungen,฀Rückfragen) •฀ Module฀(entworfen,฀codiert,฀geprüft,฀getestet) •฀ Anzahl฀Befehlszeilen฀(kumuliert) •฀ Tests฀(durchgeführt,฀bestanden) Manager Entwickler Automatisiert Entwickler 14-tägig 14-tägig Wöchentlich 14-tägig Fehler/ Änderungen •฀ Anzahl฀Fehler฀(nach฀Kategorie฀und฀Schwere) •฀ Anzahl฀Änderungen฀(nach฀Kategorie) •฀ Quellcode-Änderungen Entwickler Entwickler Automatisiert Fallweise Fallweise Wöchentlich 34฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 35฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 In: ฀CrossTalk,฀March฀2002,฀S.฀15-18,฀www.stsc.hill.af.mil/ crosstalk/ 2002/ 03/ lipke.pdf,฀12.฀7.฀2003 [16]฀Jones,฀T.฀C.: ฀Software฀Assessments,฀Benchmarks฀and฀ Best฀Practices.฀Addison-Wesley฀2000 [17]฀www.isbsg.org.au,฀12.฀7.฀2003 [18]฀www.dacs.dtic.mil/ databases/ sled.html,฀12.฀7.฀2003 [19]฀www.spr.com฀und฀www.qsm.com,฀15.฀7.฀2003 [20]฀Vgl.฀hierzu฀das฀Verzeichnis฀entsprechender฀Studien฀auf฀ der฀Website฀des฀Software฀Productivity฀Consortium,฀http: / / www.software.org/ Library/ ROIofPI.asp,฀15.฀7.฀2003 [21]฀Clark,฀B.฀K.: ฀Effects฀of฀Process฀Maturity฀on฀Development฀Effort.฀Working฀Paper,฀Center฀for฀Software฀Engineering฀CSE,฀University฀of฀Southern฀California฀USC,฀Los฀Angeles฀1999,฀sunset.usc.edu/ ~bkclark/ Research,฀12.฀7.฀2003 [22]฀NASA฀Software฀Engineering฀Laboratory฀(Hrsg.): ฀ Recommended฀Approach฀to฀Software฀Development.฀ Revision฀3,฀Document฀SEL-81-305,฀Greenbelt,฀NASA฀ Goddard฀Space฀Flight฀Center,฀Maryland฀June฀1992,฀ sel.gsfc.nasa.gov/ website/ documents/ online-doc/ 81- 305new.pdf,฀12.฀7.฀2003 [23]฀Yourdon,฀E.: ฀Managing฀Projects฀With฀Visible฀Processes.฀In: ฀Computerworld,฀June฀12,฀2000,฀www.yourdon.com/ articles/ 0006cw.html,฀15.฀7.฀2003.฀Ähnliche฀Funktionalitäten฀bietet฀auch฀das฀Projekt-Workflowtool฀Livelink,฀ www.opentext.com,฀15.฀7.฀2003 [24]฀NASA฀Software฀Engineering฀Laboratory฀(Hrsg.): ฀Software฀Measurement฀Guidebook,฀Revision฀1,฀Document฀ NASA-GB-001-94,฀Greenbelt,฀NASA฀Goddard฀Space฀Flight฀ Center,฀NASA,฀Maryland฀June฀1995,฀sel.gsfc.nasa.gov/ website/ documents/ online-doc/ 94-102-N.pdf,฀12.฀7.฀2003 Schlagwörter Aufwandsschätzung,฀Metrikprogramme,฀Quantitative฀ Prozess-Steuerung,฀Quantitatives฀Benchmarking,฀Software-Messung Autor Dr.฀Siegfried฀Seibert,฀Diplom- Wirtschaftsingenieur,฀ist฀Professor฀ für฀Betriebswirtschaftslehre,฀insbesondere฀IT-Projektmanagement฀und฀ Unternehmensführung,฀am฀Standort฀ Dieburg฀der฀Fachhochschule฀Darmstadt.฀Schwerpunkt฀seiner฀externen฀ Trainings-฀und฀Beratungstätigkeit฀ist฀ die฀Software-Kostenschätzung.฀Darüber฀hinaus฀verfügt฀ er฀über฀eine฀langjährige,฀leitende฀Industriepraxis฀in฀der฀ Automobil-Zulieferindustrie.฀Seit฀mehreren฀Jahre฀arbeitet฀ er฀im฀Programmkomitee฀der฀GPM-Jahreskongresse฀mit.฀ Im฀Vorstand฀der฀GPM฀ist฀Siegfried฀Seibert฀für฀das฀Ressort฀ Publikationen฀zuständig. Anschrift Fachhochschule฀Darmstadt Fachbereich฀Wirtschaft฀(Campus฀Dieburg) Max-Planck-Str.฀2 D-64807฀Dieburg E-Mail: ฀s.seibert@fh-darmstadt.de 34฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 35฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Mängel฀bisheriger฀Studien Befriedigende vergleichende Studien der am Markt verfügbaren Software sind, wie oben schon betont, höchst selten. Wer Rat sucht, wird auf viele Mängel stoßen. Einige dieser Mängel sollen einleitend kurz dargestellt werden, um die Studie von Ahlemann daran zu spiegeln:  Das Angebot ist sehr unübersichtlich, die Versionen folgen schnell aufeinander. Einmal angestellte Marktanalysen werden nicht aktualisiert und veralten deshalb rasch.  Eine einsichtige Kategorisierung der Software fehlt in der Regel. Aus dem Lebensweg eines Projekts bzw. eines Programms von der ersten Idee bis zum Abschluss und zur Entlastung des Projektbzw. des Programm-Managers wird für die Softwareunterstützung zumeist nur ein kleiner Ausschnitt (meist die detaillierte Planung und Kontrolle mit Netzplantechnik) gewählt.  Daraus resultiert, dass häufig nur Programmsysteme untersucht werden, deren Kern die Unterstützung der Netzplantechnik ist.  Umfangreiche Kriterienkataloge mit z. T. über 600 Einzelmerkmalen (Zahl der einplanbaren Vorgänge und Zahl der einem Vorgang zuordenbaren Einsatzmittelarten, um nur zwei Beispiele zu nennen) lassen den potentiellen Benutzer den „Wald vor lauter Bäumen“ nicht mehr sehen und erschweren ihm eher die Entscheidung für ein Programmsystem, als dass sie ihm helfen.  Eigenschaften, die für die Praxis zumeist völlig irrelevant sind (einem Vorgang können z. B. bis zu 100 Einsatzmittelarten zugeordnet werden, oder für jeden Vorgang kann ein anderer Kalender definiert werden), werden mangels Vertrautheit mit der Praxis hoch bewertet.  Dass es für die Software verschiedene Zielgruppen gibt, wird nicht berücksichtigt. Natürlich muss auch der Verfasser dieser Studie mit dem Problem der Aktualisierung fertig werden. Nach seiner Auskunft ist eine turnusmäßige Neuauflage des Marktvergleichs geplant. Die฀Vorzüge฀des฀Modells฀von฀Ahlemann Die weiter oben angeführten Kritikpunkte berücksichtigt Ahlemann in folgender Weise:  In Form des so genannten M-Modells wird eine alles in allem einsichtige Kategorisierung und eine Zielgruppenorientierung geboten.  Auf umfangreiche Kriterienkataloge wird verzichtet. Stattdessen wird klugerweise folgendermaßen vorgegangen: “In contrast to other project management market studies, we have concentrated on a mediumlevel comparison of the systems. For example, you will not find any information about the time-scale of Gantt charts in this study.” Die Begründung, der man nur zustimmen kann, lautet: “We believe that such information is of limited use for companies that are in a early phase of a software selection process.” Das Ziel der Studie lautet: “In this study, project management systems are compared by their functionality to support the overall life cycle of projects and their ability to provide all levels of management with the information relevant to manage not only one but dozens or hundred of projects.” (Die Hervorhebung durch Fettdruck erfolgte durch den Rezensenten). Da das M-Modell nach Ansicht des Berichterstatters richtungsweisend für weitere Arbeiten und von hohem Neuheitsgrad ist, soll es im Weiteren sehr detailliert behandelt werden. Für die Bewertung der einzelnen Prozess-Schritte des M-Modells, die unten dargestellt werden, werden folgende Klassifikationen vergeben: Kein * keine Funktionen: keine Software(SW)-Unterstützung in diesem Bereich, Benchmarking฀von฀PM-Software Vergleichende฀Analyse฀der฀Universität฀Osnabrück Heinz฀Schelle Die฀folgende฀kritische฀Darstellung฀basiert฀auf฀den฀nachstehend฀zitierten฀Studien.฀Nach฀ Meinung฀des฀Berichterstatters฀sind฀die฀Arbeiten฀von฀Ahlemann฀ein฀ganz฀erheblicher฀ Fortschritt฀in฀der฀bislang฀eher฀unzureichenden฀Behandlung฀des฀Themas฀„Software฀zur฀ Unterstützung฀des฀Projektmanagements”.฀Ahlemann,฀F.: ฀Comparative฀Market฀Analysis฀of฀ Project฀Management฀Systems.฀University฀of฀Osnabrück.฀Chair฀of฀Business฀Administration/ Organization฀and฀Information฀Systems.฀Herausgeber: ฀Prof.฀Dr.฀Hoppe,฀http: / / www.pmstudie.de฀(Die฀Studie฀wurde฀im฀Januar฀2003฀abgeschlossen.)฀Ergänzend฀wurde฀folgende฀ Publikation฀für฀die฀Besprechung฀hinzugezogen: ฀Ahlemann,฀F.: ฀Das฀M-Modell฀-฀Eine฀konzeptionelle฀Informationssystemarchitektur฀für฀die฀Planung,฀Kontrolle฀und฀Koordination฀von฀Projekten฀(Projekt-Controlling),฀Januar฀2003.฀Soweit฀Ahlemann฀hier฀deutsche฀Termini฀anbietet,฀ wurden฀sie฀für฀die฀Übersetzung฀der฀Begriffe฀der฀Hauptstudie฀verwendet. 36฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 37฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 * Basisfunktionen: begrenzte SW-Unterstützung in diesem Bereich, ** hohe Funktionalität: erhebliche Unterstützung in diesem Bereich, *** nahezu vollständige Funktionalität: vollständige oder fast vollständige Unterstützung. Projekt,฀Projektprogramm฀und฀Projektportfolio Weiter verwendet der Autor in einer durchgängigen Hierarchie die Begriffe „Projekt“, „Programm bzw. Projektprogramm“ und „Projektportfolio“. Projektprogramme sind eine Zusammenfassung von Projekten, die eine übergeordnete Organisationseinheit verantwortet. Projekte können dabei funktional (z. B. alle Vorhaben der EDV-Abteilung) oder nach der Zielsetzung (z. B. alle Projekte zur Entwicklung, Fertigung und Markteinführung einer neuen Generation von PKWs) zusammengefasst werden. Alle Programme einer Strategischen Geschäftseinheit bilden ein Projektportfolio, das die Strategie dieser SGE implementieren soll. Mit dieser Begriffsbildung unterscheidet sich Ahlemann von Lomnitz, der als wesentliches Merkmal eines Programms, das aus mehreren Projekten bzw. Teilprojekten besteht, genauso wie bei Projekten die zeitliche Begrenzung sieht. Wählt man als Beispiel für ein Programm die schon erwähnte Entwicklung, Fertigung und Einführung eines neuen PKW-Modells, so ist das Programm beendet, wenn das Modell vom Kunden erworben werden kann. Das Projektportfolio erneuert sich dagegen zumindest bei starker Projektorientierung einer Firma ständig durch Beenden bzw. Abbruch von Vorhaben und Aufnahme neuer Projekte. Zielgruppen฀von฀Projektmanagementsoftware: ฀Führungsebenen Der hierarchischen Orientierung folgend werden Projekt, Programm und Projektportfolio drei verschiedenen Führungsebenen zugeordnet. Das Projektportfolio wird der Strategischen Geschäftseinheit (Vorstands- oder Geschäftsführerebene) zugewiesen. Sie hat die Aufgabe, den Projektmix so zu gestalten, dass er mit der gewählten Strategie in Einklang steht (Strategisches Management). Aufgabe der mittleren Führungsebene ist die Planung und Kontrolle des Projektprogramms (Hauptabteilungen oder Abteilungen). Die Koordination solcher Programme wird durch Projekt- oder Programmbüros übernommen. Die Aufgabe auf der mittleren Führungsebene nennt Ahlemann Taktisches Management. Mit dem Operativen Management sind Projektmanager und Projektcontroller beauftragt. Phasen฀und฀Prozess-Schritte Im Lebenszyklus eines Projekts werden auf hoher Abstraktionsebene die Phasen „Initiierung“, „Vorbereitung“, „Durchführung“ und „Abschluss“ unterschieden. Im M-Modell werden diese Phasen in weitere Prozess-Schritte unterteilt. Da die Definitionen des Autors vom üblichen Sprachgebrauch zum Teil abweichen, werden sie, soweit notwendig, wörtlich zitiert.  Gewinnung von Projektideen  Ideenbewertung: Erstes Screening bzw. danach detaillierte Analyse z. B. nach einem vorliegenden Projektplanungsmodell mit technischer und wirtschaftlicher Bewertung einschließlich Risikobetrachtung sowie mit einem ersten groben Zeitplan  Portfolioplanung: Hier wird - so der Verfasser - auf der Ebene der Unternehmensführung „über die Umsetzung von Projekten (Programmen und Portfolios) zur Realisierung der strategischen Zielsetzung entschieden. Somit ist die Strategiefindung mit abschließender Strategiedefinition notwendige Voraussetzung für die Portfolioplanung.“  Programmplanung: Auch hier soll der Autor zitiert werden: „Sobald die Projektprogramme durch die SGE-Führung freigegeben sind, kann die Programmplanung einsetzen. Die Programmplanung verfeinert die in der Bewertungsphase angefertigten Beschreibungen der Projektprogramme und wandelt dabei insbesondere die Personal- und Sachmittelbedarfe in konkrete Ressourcenzuordnungen um. Sofern Programme noch nicht ��������� ��������������� ���������� ���������������������������������������������������� ������������������������������ ���������������������������� �������� �������� �������� �������� ������� �������� ���� ���������� ���� ���������� ��������� �������� ��������� ����������� ������� �������� ������� ����������� ������� �������� ������� ����������� ������� ����������� ������� ����������� ���������� �� �������� Das฀M-Modell 36฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 37฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 in Einzelprojekte überführt wurden, findet diese Überführung statt.“  Projektplanung: Hiermit ist die detaillierte Projektplanung gemeint, die schon seit den Anfängen des Projektmanagements durch entsprechende Software unterstützt wird.  Projektkontrolle  Programmkontrolle: „Die Daten aus der Projektkontrolle münden verdichtet und angereichert in der Programmkontrolle. Aufgabe der Programmkontrolle ist die Koordination der einzelnen Projekte sowie das standardisierte Reporting an die Führungsebene.“  Portfoliokontrolle: „Auf der höchsten Ebene werden auch die Daten der Programmkontrolle verdichtet und bilden die Datenbasis für die Portfoliokontrolle. Die Portfoliokontrolle führt den aktuellen Stand der Programme und Projekte und die aktuelle strategische Stoßrichtung der Unternehmung zusammen und bewirkt - falls erforderlich - eine Korrektur der strategischen Ausrichtung der Programme und Projekte.“  Programmabschluss: „Wird ein Programm als Ergebnis der Portfoliokontrolle abgebrochen oder erreicht es sein vorgesehenes Ende, so erfolgt der Programmabschluss.“  Projektabschluss: „Der Projektschluss umfasst die Sicherung der Projektergebnisse und die Erfolgsrechnung.“ Innerhalb der einzelnen Prozess-Schritte werden weitere Funktionen (functionality) unterschieden, die eine subjektive Gewichtung enthalten. Bei der verbalen Beschreibung wird jeweils gesagt, welche Ausprägung keinem, einem, zwei oder drei Sternen entspricht. Prozess-Schritte฀und฀Funktionen Gewinnung von Projektideen:  Kreativitätstechniken (10 %)  System zum Sammeln von Vorschlägen der Mitarbeiter (30 %) (Betriebliches Vorschlagswesen)  Klassifikation von Ideen und Projekten (60 %) Ideenbewertung:  Workflowsystem zur Unterstützung des Prozesses der Ideenbewertung durch mehrere Instanzen (10 %)  Schätzung der erforderlichen Ressourcen zur Realisierung (35 %) (Aufwandsschätzung)  Risikobeurteilung (20 %)  Kostenschätzung und Rentabilitätsanalyse (35 %) Portfolioplanung:  Bewertung des Beitrags eines einzelnen Projekts oder Programms zur Strategie der Organisation (33 %)  Unterstützung bei der Projektauswahl (33 %)  Messung der Zielerreichung (33 %) Programmplanung:  Projektvorlagen (15 %). Damit sind Standards wie z. B. ein Standard-PSP gemeint, den man aus einem Katalog auswählen kann. So kann z. B. erzwungen werden, dass Projekte nach einem einheitlichen Schema geplant und durchgeführt werden.  Zeitplanung (25 %)  Einsatzmittelplanung (25 %)  Management der Zulieferer und Unterauftragnehmer (10 %)  Budgetierung (25 %) Projektplanung:  Projektstrukturplanung (25 %)  Qualitätsplanung (15 %)  Terminplanung auf der Grundlage der Netzplantechnik (25 %)  Risikomanagement (15 %)  Kostenplanung (20 %) Projektkontrolle (im englischen Text: Project Controlling):  Issue Management, am ehesten wohl mit Änderungsmanagement bzw. Konfigurationsmanagement übersetzt (20 %). Darunter fällt aber auch das, was in der angelsächsischen Literatur Action Item Control genannt wird.  Qualitätskontrolle (quality controlling) (10 %)  Management der Reisekosten (10 %) und sonstiger Ausgaben, die von Projektmitarbeitern vorgenommen wurden  Stundenerfassung (30 %)  Projektbegleitende Kostenüberwachung (30 %) Programmkontrolle:  Projektstatusberichterstattung (30 %)  Budgetkontrolle (30 %)  Auditierung des Budgets (10 %). Der englische Ausdruck lautet Project Auditing. Der Autor versteht darunter im Gegensatz zur laufenden Kontrolle des Projektbudgets die detaillierte Überprüfung der Projektparameter Zeit, Kosten, Qualität etc. „in depth“ mit dem Ziel, Probleme zu identifizieren, die den Programmerfolg gefährden könnten.  Projektüberwachung (30 %). Im englischen Text findet sich derAusdruck „project monitoring“. Hier ist Funktionalität gemeint, die über das statische Berichtswesen weit hinausgeht. So ist es beispielsweise möglich, interaktiv und Ad-hoc-Auswertungen über Projekte anzufertigen. Portfoliokontrolle: Hier gibt es keine weitere Unterteilung. Nach Ahlemann gilt grundsätzlich die gleiche Funktionalität wie bei der Portfolioplanung. Programmabschluss:  Wissensmanagement (80 %)  Projektmetriken (20 %) Projektabschluss:  Testmanagement (30 %). Im englischen Text heißt es „Acceptance/ Testing Management“.  Bewertung des Projektpersonals (20 %)  Beendigung des Projekts (50 %). Der englische Ausdruck lautet „Project Closure“. Wie aus dem M-Modell zu ersehen, gibt es sozusagen phasenübergreifend noch folgende weitere Funktionsgruppen, die das Projektmanagement unterstützen. Auch sie werden in den Softwarevergleich einbezogen. Personalmanagement (Personal Information Management):  Auf den jeweiligen Benutzer zugeschnittene Startinformationen über das Projekt (40 %). Im deutschsprachigen Raum wird hier vielfach der Begriff „Projekt-Portal“ verwendet; er bezeichnet einen personalisierten Start-Bildschirm mit allen Informationen, die den individuellen Mitarbeiter betreffen.  Stakeholdermanagement (30 %). Im englischen Text lautet der Ausdruck „Contact management“. Nach 38฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 39฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Angaben des Verfassers soll mit dieser Funktion das Management der Stakeholder unterstützt werden.  Persönlicher Terminkalender (30 %) für das Selbstmanagement Unterstützung der Teamarbeit (Team Collaboration):  Dokumentenmanagement (50 %)  Automatisches Versenden von Mitteilungen, wenn z. B. ein Termin überschritten wurde (20 %)  Unterstützung von Besprechungen (10 %)  Unterstützung von Diskussionsrunden zu einem bestimmten Thema (5 %)  Unterstützung von Chatting (5 %)  Unterstützung von Abstimmungen und Befragungen (5 %)  Datenbanken (5 %). Ahlemann versteht darunter speziell „table-like structures with configurable columns and an infinite number of rows.“ Das ist eine Spezialfunktionalität einiger Anbieter, beliebige andere Daten zu den Projekten in strukturierter Form abzulegen. Administration/ Konfiguration:  Zugangskontrolle in Multi-User-Software (40 %)  Definition von Berichtsformaten (25 %)  Definition von Formularen (15 %)  Definition von „Views“ für Benutzergruppen (15 %)  Unterstützung von Umrechnung in verschiedene Währungen (5 %) Schnittstellen, um das Projektmanagementsystem in das Unternehmen zu integrieren:  Datenbankschnittstellen (30 %)  Schnittstellen zu MS-Project (25 %)  Datenexport/ -import (15 %)  Schnittstellen zu anderen Anwenderprogrammen (15 %). Gemeint sind „Programmierschnittstellen“, d. h. Schnittstellen, die es Programmierern erlauben, auf die PM-Software zuzugreifen, z. B. um sie mit SAP zu koppeln.  Integration von Systemen wie Outlook (10 %). Ahlemann spricht hier von Personal Information Managers (PIM).  Directory Services (5 %). Gemeint ist Software, die Informationen über alle Arten von Einsatzmitteln verwaltet. Weitere Eigenschaften (Miscellaneous):  Benutzerfreundlichkeit (20 %)  Online-Hilfe (15 %)  Sicherheit (20 %)  Suchfunktionen (15 %)  Möglichkeit des Durchspielens von verschiedenen Szenarien (10 %). Im Text heißt es: Baselining-/ Scenario Techniques. Die Funktion „Baselining“ bedeutet, dass es möglich ist, für spätere Analysen, z. B. für die Meilensteintrendanalyse, Basispläne zu definieren.  Unterstützung von mehreren Sprachen (10 %)  Unterstützung des Arbeitens in verschiedenen Zeitzonen (10 %). Gruppen฀von฀untersuchter฀Software฀(Cluster) Für den Vergleich der Systeme zur Unterstützung des Projektmanagements hat der Verfasser fünf Gruppen definiert, da er mit Recht betont, dass nur ein Vergleich innerhalb der Gruppen Sinn macht. Auch bei dieser Clusterbildung, die natürlich nicht ganz trennscharf sein kann, wurde Pionierarbeit geleistet. Hier die Unterscheidung:  Planungsorientierte Multi-Projektmanagementsysteme (PMS) mit ausgeprägten Funktionen für Termin- und Einsatzmittelplanung (Beispiele: ACOS Plus 1, Primavera P3e-Project Planner for the Enterprise).  Prozessorientierte Multi-Projektmanagementsysteme mit Konzentration auf Qualitäts- und Prozessmanagement. Das Ziel dieser PMS ist es, im Rahmen eines weitgehend standardisierten Projektmanagements das Qualitäsmanagement und den Workflow zu unterstützen (Beispiele: Project Insight, Alpha Project Line).  Ressourcenorientierte Multi-Projektmanagementsysteme mit dem Schwerpunkt auf der Einsatzmittelplanung und dem Ziel, einen Ressourcenpool zu verwalten, Einsatzmittel Projekten zuzuordnen und ihre Verwendung zu kontrollieren. (Beispiel: resSolution).  Umfassende Projektmanagementsysteme (bei Ahlemann: Enterprise Project Management Systems). Systeme dieser Art unterstützen das Projektmanagement über den ganzen Lebensweg eines Projekts oder Programms. Konsequenterweise gehört deshalb die Portfolioplanung im Sinne des Verfassers dazu (Beispiele: PPMS, Artemis Portfolio, Project and Resource Management Solution).  Plattformen zur Unterstützung der Zusammenarbeit im Projekt (Project Collaboration Platform). Systeme dieser Art leisten wenig Hilfe beim Multi- Projektmanagement, bieten aber eine webbasierte Plattform für die Zusammenarbeit von in der Regel dislozierten Projektteams. Nicht untersucht wird „spezifisch funktionale Software“ (Dworatschek). Dazu zählen z. B. Programme zur Kostenschätzung wie etwa PRICE H oder PRICE S oder Software zur Bewertung von Projektrisiken. Bewertungsalgorithmus Für die Bewertung innerhalb der oben definierten Gruppen wurde folgender Algorithmus entwickelt: N = N w spi sp pi i f p ⋅     + = ∑ 1 1 2 Dabei ist in der Terminologie der Arbeit N sp das Ergebnis der Bewertung des Prozess-Schrittes p und der Software s. Ein Prozess-Schritt ist z. B. die Ideenbewertung; f p ist die Anzahl der Funktionen für den Prozess- Schritt p; N spi ist das Bewertungsresultat für die Software s, den Prozess-Schritt p und die Funktion i (entspricht der Zahl der Sterne) und w pi ist das Gewicht der Funktion. Ahlemann erläutert den Algorithmus an folgendem Beispiel: Prozess-Schritt „Ideengewinnung“: Kreativitätstechniken (10 %): ** System zum Sammeln von Vorschlägen der Mitarbeiter (30 %) : * 38฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 39฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Klassifikation von Ideen und Projekten (60 %): *** Aggregiertes Bewertungsergebnis: (2*)*0,1 + (1*)*0,3 + (3*)*0,6 = 2,3*. Der Prozess-Schritt erhält abgerundet 2 Sterne. Wichtig ist in diesem Zusammenhang, dass auf eine Gesamtaggregation der Bewertung zu einer Gesamtpunktzahl verzichtet wurde, da solche Gesamtpunktzahlen mit Recht für nicht wirklich aussagefähig erachtet werden. Bewertete฀Software Nach der beschriebenen Bewertungsprozedur werden nun, jeweils innerhalb der definierten Cluster, 28 Produkte bewertet. MS-Project ist nicht dabei. Nach fernmündlicher Auskunft des Verfassers ist Microsoft angeschrieben worden, hat sich dem Produktvergleich aber nicht gestellt. Das wohl am meisten verbreitete Produkt ist deshalb nur in der Rubrik „Additional Products“ ohne Bewertung zu finden. In dieser Auflistung sind 71 (! ) Programmsysteme aufgeführt. Es werden dort nur die Anbieter, die Anschrift, Telefon- und Faxnummer bzw. E-Mail und Webadresse genannt. Zusammenfassende฀Bewertung Die Arbeit von Ahlemann setzt auf einem von der Theorie weitgehend vernachlässigten Gebiet Maßstäbe. Zukünftige Produktvergleiche werden sich an dieser Studie, die zugleich zeigt, wie kompliziert die Produktlandschaft in den letzten Jahren geworden ist, messen lassen müssen. Das M-Modell, das neben einer Zielgruppenorientierung auch den gesamten Lebenszyklus eines Projekts von der ersten Idee bis zum Abschluss betrachtet, bietet einen überzeugenden Rahmen für die Analyse. Man muss dem Verfasser bei seiner Unterscheidung von Projekt, Projektprogramm und Projektportfolio nicht unbedingt folgen, sie ist aber mit seiner Einteilung in drei Schichten der Führung konsistent. Auch bei der Unterscheidung einiger Funktionen gibt es, wie nicht anders zu erwarten, gewisse Unschärfen. Schließlich sind Zweifel anzumelden, ob die Unterstützung durch Software wirklich überall auf dem Lebensweg eines Projekts Sinn macht. Diese Bedenken gelten vor allem für die frühen Phasen, in denen die Projektbewertung vorgenommen und die Projektauswahl getroffen wird. Die Auswahl von Projekten ist unlöslich mit Macht- und Prestigefragen verbunden. Dem Einsatz von Algorithmen, die den optimalen Projektmix bestimmen, sind deshalb nach Meinung des Rezensenten enge Grenzen gesetzt. Freilich darf man dem Autor nicht zum Vorwurf machen, dass er auch solche Funktionen betrachtet und bewertet. Schließlich werden sie ja von einigen Softwareherstellern angeboten. Wer die Produktstudie aus Osnabrück gelesen hat, hat auf dem Gebiet des Vergleichs von Projektmanagement-Software seine Unschuld verloren und wird den herkömmlichen Analysen, wie sie insbesondere in den verschiedenen Fachzeitschriften zu finden sind, höchst skeptisch gegenüberstehen. Und das ist gut so!  Benchmarking฀zum฀Projektmanagement฀in฀Russland  Wie steht es um das Projektmanagement der europäischen Nachbarländer? Seit einigen Jahren führt die PRO- JEKTMANAGEMENT GROUP der Wirtschaftsuniversität Wien gemeinsam mit der IPMA International Project Management Association internationale Benchmarking-Studien durch. Sie vergleicht die Kompetenz so genannter „Projektorientierter Gesellschaften“ (POS) (vgl. Projektmanagement aktuell 2/ 2002). Jetzt stellte die PROJEKT- MANAGEMENT GROUP Ergebnisse für die Region Moskau (Russland) vor. Die Ergebnisse: Starke Kompetenzen fanden die Fachleute beim Projektmanagement selbst und beim Programm- Management. Auch beim Projektmarketing schnitt das osteuropäische Land überdurchschnittlich ab. Weniger gut wurden die Bereiche Portfolio-Management und Projektorientierte Organisation beurteilt. „Dieses Assessment und Benchmarking hat nicht nur einen wissenschaftlichen Zweck“, bemerken die Autoren der Studie, „es trägt auch dazu bei, Projektmanagement in Russland zu fördern und zu vermarkten.“ So hatte sich auch der russische Projektmanagement-Verband SOVNET an dem Assessment beteiligt. Das Assessment wurde in zwei Stufen durchgeführt. Im ersten Schritt hatten Forscher von SOVNET sowie Moskauer Universitäten ein Benchmarking der PM Services in der Region Moskau vorgenommen. In einem zweiten Schritt erarbeiteten 25 Projektmanagement-Experten aus verschiedenen Branchen Konsensergebnisse zur Bewertung der PM Praxis. Dabei knüpften die Fachleute auch ein persönliches Kontaktnetz für den künftigen Erfahrungsaustausch. Weitere Informationen: Projektmanagement GROUP der Wirtschaftsuniversität Wien, Martina Huemann, E-Mail: martina.huemann@wu.wien.ac.at. Informationen zum Benchmarking-Projekt der Wirtschaftsuniversität Wien mit Download-Möglichkeit der Studien: http: / / www.wu-wien.ac.at/ pmg/ pos/ index.html. Schlagwörter Benchmarking,฀Projektmanagement,฀Software Autor Prof.฀Dr.฀Heinz฀Schelle,฀geb.฀1938,฀war฀Inhaber฀einer฀ Professur฀für฀Betriebswirtschaftslehre฀mit฀besonderer฀ Berücksichtigung฀des฀Projektmanagements฀an฀der฀Fakultät฀für฀Informatik฀der฀Universität฀der฀Bundeswehr฀München.฀Er฀ist฀einer฀der฀Gründer฀der฀GPM,฀war฀von฀1979฀bis฀ 1998฀Mitglied฀des฀Vorstands฀und฀ist฀heute฀Ehrenvorsitzender฀der฀Gesellschaft฀und฀Mitglied฀des฀Kuratoriums. Anschrift Münchner฀Straße฀1 D-82496฀Oberau E-Mail: ฀h.schelle@gaponline.de 44฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 45฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Leserbriefe Systemisches฀Projektmanagement฀-฀Eine฀Gratwanderung฀ zwischen฀Chaos฀und฀Ordnung Eine฀Stellungnahme฀zu฀dem฀Artikel฀„Neuorientierung฀oder฀Glasperlenspiel? “฀in฀Projektmanagement฀aktuell,฀ Heft฀2/ 2003,฀von฀Christian฀Eisenschink 1฀ Einführender฀Sachverhalt Der Artikel „Neuorientierung oder Glasperlenspiel? “ von Günter Drews in „Projektmanagement aktuell“ (2/ 2003) kritisiert die Ansätze der Systemtheorie und bezweifelt darüber hinaus den Nutzen einer theoretischen und praktischen Integration systemorientierter Ausprägungen in das Projektmanagement. Die nachfolgenden Ausführungen, deren Umfang durch eine Restriktion der Herausgeber gekennzeichnet war, positionieren die Drews’schen Entgegnungen zur Systemtheorie und zeigen die potentiellen Erkenntnisgewinne von systemischen Ansätzen im Projektmanagement. Zudem sollen Impulse entstehen, die Rolle ökonomischer Erkenntnisse in die Diskussion um „Neue Wege im Projektmanagement“ einzubringen. 2฀ Theoretische฀Bausteine 2.1฀ Theoriedynamik฀durch฀Konzepttransfers Drews negiert die systemorientierten Ansätze durch Zitate von Anthony Giddens, Jürgen Habermas etc., die eine Übertragung naturwissenschaftlicher Erkenntnisse auf die Gesellschaftstheorie in Frage stellen. Jedoch steht die Diskussion von Konzepttransfers zwischen wissenschaftlichen Disziplinen seit einigen Jahren nicht mehr im Zentrum der Betrachtung. Die Nutzenerhöhungen übertreffen in den meisten Disziplinen die möglichen Nachteile etwaiger inkonsistenter Analogieschlüsse. „Evolutiv belohnt wird nicht Vollkommenheit, sondern Effektivität. Für evolutiven Erfolg maßgebend ist nicht pure Qualität, sondern ein vertretbares Kosten-Nutzen- Verhältnis“ [1, S. 278]. Bereits im letzten Jahrhundert konnten Konzepttransfers, insbesondere auch innerhalb der Naturwissenschaften, zur Entwicklung der Theorien und des technischen Fortschritts beitragen. Als prominente Beispiele können die Übertragung von Konzepten der Informatik auf die Molekularbiologie und Gentechnologie sowie auf die Gehirnforschung genannt werden [2, S. 437]. Zudem können auch Übertragungen naturwissenschaftlicher Konzepte in den Gesellschaftsbzw. Wirtschaftswissenschaften Erkenntniszuwächse generieren, wie z. B. die Blutkreislaufanalogie von F. Quesnay (1694- 1774) [3, S. 43], die die Grundlagen für die moderne volkswirtschaftliche Gesamtrechnung bereitstellte. Quesnay übertrug als homöopathischer Arzt auch die Hippokratischen Gedanken auf die Wirtschaft, wodurch sich die Vorstellung der Selbstheilungskräfte der Wirtschaft entwickelte [4, S. 33]. Diese Ansätze wurden für die Ausarbeitung des Konzeptes einer (selbst organisierten) Marktwirtschaft verwandt. Die aufgezeigten Beispiele belegen die Erkenntnisfähigkeit interdisziplinären Handelns, die die Grundlage für die Evolution in den einzelnen Disziplinen darstellt. 2.2฀ Auflösung฀von฀Theoriepolaritäten Die Errungenschaften durch erfolgreiche Konzepttransfers bewirkten in manchen einzelnen Disziplinen synergetische Lösungen, so dass die im letzten Jahrhundert noch vorherrschenden Polaritäten aufgelöst wurden (z. B. Mikro- und Makroökonomie, Angebots- und Nachfragepolitik, …). Drews versucht aber u. a. durch den Giddens’schen Ansatz, der die Systemtheorie ablehnt, mit alten Mustern die systemtheoretischen Ansätze im Projektmanagement zu kritisieren. Die tradierten Gedanken eines einseitigen Rationalismus, der lediglich dem Handeln Vorschub leistet, können in einem komplexen und dynamischen Projektumfeld nicht das alleinige Instrument sein. Der Drews’sche Gedanke, alles sei machbar und kontrollierbar, basiert auf mechanischem Denken und ignoriert die Irreversibilität als ein zentrales Merkmal von Projekten. Die heutigen komplexen Projektanforderungen benötigen tendenziell sowohl die handlungsorientierte Einflussnahme als auch die Bildung von Strukturen. Insbesondere eignet sich für das Projektmanagement die duale Sichtweise aus Planung (Geist) und Umsetzung (Handeln) sowie aus Chaos (z. B. Kreativität) und Ordnung (z. B. Kontrolle). Nur durch die situationsspezifische gewichtete Berücksichtigung beider Merkmale können die Projektziele erreicht werden. Die Verknüpfung zwischen diesen scheinbaren Polaritäten ist das System, das sich durch Heterogenität der 46฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 47฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Individuen (z. B. im Projektteam) und deren notwendige Interdependenzen auszeichnet, um das Projektziel zu erreichen. Die Systemtheorie stellt keinen verengten Blickwinkel dar, wie Drews glaubt, sondern das Fundament für das Verständnis der dualen Betrachtung und somit für die Erzeugung von Vielfalt. Die alten Griechen bezeichneten die innewohnende Kausalität des Ausgleichs von Gegensätzen mit Logos und Adam Smith verwandte für die „ewige Kunst“, die „Gutes aus Bösem schafft“, den Term „invisible hand“ [5, S. 54-55]. Zu Recht verweist daher Saynisch darauf, dass die Systemtheorie als Supertheorie [6, S. 19] aufgefasst werden kann, da ihr evolutionäre Prinzipien zugrunde liegen [7, S. 66]. Daher stehen die dargestellten realen Ausprägungen der Begriffspaare während der Projektdauer in einem wechselseitigen rekursiven Verhältnis. 2.3฀ Selbstorganisation฀und฀Teamgedanke Neben der Irreversibilität spielt im Projektmanagement das Merkmal der Neuartigkeit von „außergewöhnlichen Vorhaben“ (Projekte) eine wichtige Rolle. Um unter derartigen Rahmenbedingungen die Projektziele zu erreichen, sind häufig Kreativität, Mut zu neuen Ansätzen und Spekulation notwendig, welche die Differenz zur traditionellen Linienorganisation darstellen sollen. Dabei kommt der Heterogenität (z. B. im Projektteam) sowie den Interdependenzen zwischen den Projektakteuren eine große Bedeutung zu, da sich in jedem Projektteam weitgehend eine Projektkultur entwickelt, die sich in einem Bewusstsein des Systems ausdrückt. Dieses „Entwickeln“ des Teams und der Lösungen vollzieht sich durch „Trial-and-Error“-Prozesse, die auf Bewegung und dem bereits angeführten Ausgleich von Gegensätzen durch die „unsichtbare Hand“ beruhen. Die damit verbundenen Prozesse sind durch die Erkenntnisse der Wirtschaftswissenschaften transparent geworden, so dass aufgrund der Selbstorganisation der Projektakteure marktwirtschaftliche Ansätze im Rahmen des Projektmanagements praktiziert werden (z. B. via Open-Space-Methode). Jedoch werden im Projektmanagement die Akteure nicht wie auf der volkswirtschaftlichen Makroebene selektiert, sondern es findet speziell ein Wettbewerb der Ideen statt, der auf der Basis der Kommunikation ausgetragen wird. So wie Kommunikation durch Kommunikation reproduziert wird [8, S. 50], können Gedanken sich durch Gedanken ohne Eingriff einer übergeordneten Instanz und ohne expliziten „Bauplan“ selbst organisieren. Dadurch findet eine Selektion von Gedanken statt, die entscheidende Rolle spielt aber die Sprache, welche die potentielle Anschlussfähigkeit des Projektes an die Innovation gewährleistet. Drews wertet diesen Sachverhalt („Meist wird Altbekanntes in einem neuen Jargon wiederholt.“) ab und erkennt nicht, dass neue Begriffsbildungen und die Anwendungen in der Praxis zu Veränderungen in der Gesellschaft und in den Unternehmen führen können. Wenn Drews mit Hilfe des Zitats von Malik die Antwort auf die Frage vermisst, „was sich eigentlich wie selbst organisiert“, dann ist die Vermutung erlaubt, ob die Prinzipien (selbst organisierten) marktwirtschaftlichen Denkens und Handelns wirklich verstanden und auch angewandt werden wollen. Somit ist die von Drews artikulierte Kritik der Selbstorganisation auch eine Kritik am Markt und der Freiheit der Individuen. Drews schreibt den Akteuren keine Selbstbestimmungsfähigkeit zu, da Selbstorganisation meist dazu führe, dass auf altbekannte Lösungsansätze zurückgegriffen werde und der Einzelne Gesetzmäßigkeiten unterworfen sei, die sich hinter seinem Rücken durchsetzten. Die mangelnde Zuneigung zur marktwirtschaftlichen Selbstorganisation im Projektteam unterstreicht Drews durch seine Präferenz für die Ansätze Giddens, die das Handeln der Akteure vor die Struktur, d. h. das Subjekt vor das Objekt rücken [9], was in dieser einseitigen Darstellung der Zusammenhänge gegen bewährte Methoden des Projektmanagements verstößt (siehe Kapitel 3). Der theoretische Kern von Drews folgt dem mechanischen Vorbild, dass Veränderungen nicht aus sich selbst heraus entstehen, sondern äußere Ursachen benötigen, die das System impulsieren [10, S. 105]. An dieser Stelle zeigt sich, dass Drews eine vollständig andere Vorstellung von Unternehmensführung hat, die auf monolaterale Vorgaben des Managements ausgerichtet ist („… die Teilnehmer dürfen selbst argumentieren, was das Management entschieden hat.“). Diese hierarchische Denkweise ist (leider) in manchen Unternehmen noch vorzufinden, aber es geht in dieser Diskussion auch um die Gesolltheit der Ansätze. Daher können die mechanistisch fundierten Ansätze nicht bejaht werden, da Projekte einen interdisziplinären Charakter haben, und system- und chaostheoretische Ansätze aus theoretischen sowie praktischen Überlegungen die Einbeziehung der Projektumwelt fördern [10, S. 109]. 3฀ Praktische฀Konsequenzen฀systemorientierter฀ Ansätze 3.1฀ Projektstart Im Projektmanagement spielt die Planung (Geist) eine dominante Rolle, welche „die gedankliche Vorwegnahme zukünftigen Handelns durch Abwägen verschiedener Handlungsalternativen und Entscheidung für den günstigsten Weg“ [11, S. 128] darstellt. Daher kommt der Bestimmung der Anfangsbedingungen beim Projektstart eine in der Praxis inzwischen größtenteils unbestrittene Bedeutung zu [12, S. 43-44]. In der Anfangsphase eines Projektes ist die Strukturbildung der „hard facts“ sowie die Berücksichtigung der „soft facts“ gleichermaßen relevant. Die Vorgabe eines Strukturrahmens ist als Orientierung wesentlich, damit die Projektakteure selbst organisiert das Projektziel verfolgen können. Selbstorganisation bedingt Interdisziplinarität und Selbstbestimmung nach dem Motto aufgeklärter Individuen „Habe Mut, dich deines eigenen Verstandes zu bedienen (sapere aude)“. 3.2฀ Projektsteuerung Viele Controller beziehen die Aspekte des Projektmanagements 2. Ordnung, das die „weichen Faktoren“ berücksichtigt, in der Praxis bereits ein, so dass die auf alten Mustern rein handlungsorientierten Ansätze von Drews den Sachverhalt verkürzen. Das Projektcontrolling ist ein geeignetes Beispiel, um die im Theorieteil 46฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 47฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 aufgezeigte Dualität zwischen Planen und Handeln zu demonstrieren. Die lernende Organisation ist keine theoretische Spekulation, sondern vielfach schon systemorientierte Realität. 3.3฀ Projektabschluss Drews Befürchtung, dass durch die Selbstorganisation sich die Projekte über die Projektdauer hinaus aufrechterhalten, zeigt die Entweder-Oder-Denkweise, d. h. entweder (autoritär) Handeln oder (eigenbestimmte) Selbstorganisation. Wie bereits an anderer Stelle gezeigt, kommt insbesondere beim Projektmanagement ein Sowohl-als-auch-Ansatz zum Tragen. Je nach Projektsituation ist ein Stop or Go notwendig, das von der Fähigkeit und dem Bewusstsein des Projektleiters abhängt, zwischen Chaos und Ordnung zu agieren. Projekte können sich i. d. R. nicht verselbständigen, da deren Realisation von begrenzten und zu Beginn des Projektes definierten Ressourceninputs abhängig ist, aus denen Outputs (z. B. Teilaufgaben) resultieren. Zudem ist das Ziel im Bewusstsein der Projektakteure verankert, so dass das Sein bzw. der Projektabschluss realisiert wird. Wenn dadurch kein weiteres Ereignis entsteht, hört das System auf zu existieren. Derartige Systeme sind daher geschlossen und offen zugleich [13, S. 64-65] 4฀ Ausblick Die Drews’schen Fallbeispiele sind ungeeignet, quasi als empirische Instanz anhand von einzelnen Fällen die Übertragung und Interpretation systemorientierter Ansätze in das Projektmanagement zu falsifizieren, da die Grundstruktur des intendierten Gedankengebäudes nicht tangiert wird. Dies kann ihm aufgrund der vermuteten Restriktion des Umfangs nicht vorgeworfen werden. Daraus ergibt sich aber trotzdem die Hoffnung, dass empirische Studien zu dieser Thematik durchgeführt werden, um die diskutierten Theorien und Hypothesen zu überprüfen.  Literatur [1]฀Vollmer,฀G.: ฀Wieso฀können฀wir฀die฀Welt฀erkennen? ฀-฀Zur฀ Evolution฀des฀Erkenntnisvermögens.฀In: ฀Fischer,฀E.฀P.; ฀Wiegandt,฀K.฀(Hrsg.): ฀Evolution฀-฀Geschichte฀und฀Zukunft฀des฀ Lebens.฀Frankfurt฀am฀Main,฀2003,฀S.฀274-300 [2]฀Becker,฀E.; ฀Jahn,฀T.; ฀Wehling,฀P.: ฀Revolutionäre฀Inszenierungen฀-฀Konzepttransfers฀und฀Wissenschaftsdynamik.฀ In: ฀PROKLA฀88,฀Chaos฀und฀Selbstorganisation,฀Zeitschrift฀ für฀kritische฀Sozialwissenschaft,฀Berlin,฀September฀1992,฀ S.฀434-450 [3]฀Kolb,฀G.: ฀Geschichte฀der฀Volkswirtschaftslehre: ฀dogmenhistorische฀Positionen฀des฀ökonomischen฀Denkens,฀ München,฀1997.฀Kolb฀merkt฀an,฀dass฀drei฀Jahre฀vor฀Veröffentlichung฀des฀„Tableau฀economique“฀durch฀Quesnay฀ein฀ Einnahmen-Ausgaben-Modell฀des฀Staates฀mit฀einer฀Analogie฀zur฀Blutzirkulation฀von฀Justi฀vorgestellt฀wurde.฀Sowohl฀ Quesnay฀als฀auch฀Justi฀fundierten฀ihre฀Erkenntnisse฀auf฀ organisch-biologischen฀als฀auch฀mechanistisch-physikalischen฀Analogien. [4]฀Meran,฀J.: ฀Wirtschaftsphilosopie,฀Kurseinheit฀1: ฀Wirtschaftsethik.฀FernUniversität฀-฀Gesamthochschule฀-฀in฀ Hagen,฀1993 [5]฀Binswanger,฀H.฀C.: ฀Die฀Glaubensgemeinschaft฀der฀Ökonomen.฀München,฀ 1998 [6]฀„Supertheorien฀sind฀Theorien฀mit฀universalistischen฀(und฀das฀heißt฀auch: ฀ sich฀selbst฀und฀ihre฀Gegner฀einbeziehenden)฀Ansprüchen.“฀Luhmann,฀N.: ฀Soziale฀Systeme.฀Frankfurt฀am฀Main,฀1987 [7]฀Saynisch,฀M.: ฀Systemtheorie฀und฀Systembegriff฀-฀Zur฀koevolutiven฀Entwicklung฀von฀Systemtheorie฀und฀Projektmanagement฀sowie฀zur฀Systematik฀und฀ Anwendung฀des฀Systembegriffes฀im฀Projektmanagement.฀In: ฀Lange,฀D.; ฀Saynisch,฀M.฀(Hrsg.): ฀Neue฀Wege฀im฀Projektmanagement.฀Stuttgart฀2002,฀S.฀63-78 [8]฀Luhmann,฀N.: ฀Die฀Wirtschaft฀der฀Gesellschaft.฀Frankfurt฀am฀Main,฀1994 [9]฀Giddens,฀A.: ฀Die฀Konstitution฀der฀Gesellschaft.฀Frankfurt฀am฀Main/ New฀York,฀ 1997 [10]฀Dopfer,฀K.: ฀Evolutionsökonomie฀in฀der฀Zukunft: ฀Programmatik฀und฀Theorieentwicklung.฀In: ฀Hanusch,฀H.; ฀Recktenwald,฀H.฀C.฀(Hrsg.): ฀Ökonomische฀Wissenschaft฀in฀der฀Zukunft.฀Düsseldorf฀1992,฀S.฀96-125 [11]฀Wöhe,฀G.: ฀Einführung฀in฀die฀Allgemeine฀Betriebswirtschaftslehre.฀1975 [12]฀Steeger,฀O.: ฀Professioneller฀Projektstart฀-฀Kein฀netter฀ „Lehrbuch-Luxus“,฀ Projektmanagement฀aktuell,฀Köln,฀1/ 2003, ฀S.฀43-44 [13]฀Bode,฀O.฀F.: ฀Systemtheoretische฀Überlegungen฀zum฀Verhältnis฀von฀Wirtschaft฀und฀Politik: ฀Luhmanns฀Autopoiesekonzept฀und฀seine฀exemplarische฀ Anwendung฀auf฀Fragen฀wirtschaftspolitischer฀Steuerungsmöglichkeiten.฀Marburg,฀1999 Autor Dr.฀rer.฀pol.฀Dipl.-Volkswirt฀Univ.฀Christian฀Eisenschink฀ist฀als฀freiberuflicher฀ Trainer,฀Berater฀und฀Autor฀tätig.฀Seine฀Schwerpunkte฀liegen฀in฀den฀Bereichen฀ Controlling/ Strategie,฀Projekt-,฀Risiko-฀und฀Zeitmanagement฀sowie฀der฀System-฀ und฀Chaostheorie.฀Zudem฀leitet฀er฀die฀GPM-Regionalgruppe฀Regensburg. Anschrift Benzstr.฀4 D-93077฀Bad฀Abbach Tel./ Fax: ฀0฀94฀05/ 49฀89 E-Mail: ฀Chr.Eisenschink@t-online.de 40฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 41฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 ������� ������� -Praxisbericht Ein฀pragmatisches฀Werkzeug฀für฀Auditierung฀und฀Benchmarking฀von฀Projekten฀und฀ Projektmanagement฀in฀Unternehmen Gerhard฀Hab Den฀Reifegrad฀und฀die฀Qualität฀des฀Projektmanagements฀in฀Projekten฀und฀im฀Gesamtunternehmen฀objektiv฀zu฀beurteilen฀ist฀ein฀schwieriges฀Unterfangen.฀Die฀Software฀PM-Delta฀ Compact,฀die฀seit฀Anfang฀dieses฀Jahres฀in฀der฀zweiten฀Version฀von฀der฀GPM฀herausgegeben฀wird,฀bietet฀dafür฀eine฀gute฀Basis.฀Im฀folgenden฀Beitrag฀wird฀über฀den฀Einsatz฀dieses฀ Tools฀beim฀internen฀und฀externen฀Benchmarking฀berichtet. PM-Delta฀Compact: ฀Anwendung Wie bei jedem vergleichbaren System müssen erst mal Stammdaten eingegeben werden und damit wird auch die Ablage der generierten Daten und Auswertungen definiert. Das System ist nach den 19 Kompetenzfeldern des PM-Kanon gegliedert (siehe Abb. 1). Zu jedem Kompetenzfeld gibt es einen Katalog von Fragen, die mit ja bzw. nein beantwortet werden können oder als nicht relevant „ausgeklammert“ werden (siehe Abb. 2). Darüber hinaus können auch ganze Kompetenzfelder ausgeklammert werden, wenn z. B. bei einem Software-Projekt das Thema Logistik überhaupt keine Rolle spielt. Wenn ein Kompetenzfeld bearbeitet ist, wird über die Menüsteuerung ins nächste Kapitel gewechselt. Am Bildschirm sind bereits die Ergebnisse der bearbeiteten Bereiche als Balken sichtbar (siehe Abb. 3). Den Gesamtablauf der PM-Delta-Compact-Anwendung zeigt Abb. 4. Im Zentrum der Arbeit mit PM-Delta Compact steht das Interview bzw. die Selbstbewertung. Das Gespräch selbst gibt schon sehr viel Aufschluss über die PM- Kompetenz des Interviewpartners. Offene Punkte und Unklarheiten können notiert werden und in den späteren Bericht einfließen. Sind alle Fragen beantwortet, liefert PM-Delta Compact eine automatische Auswertung in Form der bereits erwähnten „Spinnennetz-Grafik“ und Aussagen zu den Stärken und Verbesserungspotenzialen des Projektmanagements (siehe Abb. 5). Diese Aussagen basieren auf hinterlegten Textkonserven, die mit einer ausgeklügelten Datenbank-Funktionalität, je nach Beantwortung der spezifischen Fragen, zugeordnet werden. Die gedruckte Auswertung ist relativ detailliert und erstreckt sich über 5-10 Seiten, je nach Schriftgröße und Layout. D. h., dass für das Management dann eine entsprechende Zusammenfassung erstellt werden muss. Wie bei jeder Softwarelösung, so gibt es auch bei PM- Delta Compact noch Potenzial für Verbesserungen und Weiterentwicklung, das in einer nächsten Version umgesetzt werden kann. Im Folgenden die wesentlichen Verbesserungspotenziale aus meiner Anwendungserfahrung: ��������������������������������� ��� ����������������������� ��� ������� ���� ���������������� ��� ������������������������ ��� ���������������� ��� �������������� ������������� ��� ����������� ��� �������� ��� ������������������� ��� ������������� �� �������������� �� �������������� �� ������������ �� ������������������ �� ������������������ �� ���������������������� ���������� �� ������������������������ �� ������������������� �� ������������������ ��� ���������������� Abb.฀1: ฀PM-Elemente฀nach฀DIN Abb.฀2: ฀PM-Delta-Maske฀„Fragen฀beantworten“ ������� ������� 40฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 41฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3  Erzeugung der Spinnennetzgrafik in einem austauschfähigen Grafikformat (jpeg, bmp o. Ä.)  Ergänzung der Fragen und Bewertungen um aktuelle PM-Themengebiete (die leider im PM-Kanon auch zu wenig berücksichtigt sind) wie:  Methoden der Personalauswahl und Teambesetzung  Teamentwicklung  Personalentwicklung in Projekten (Qualifizierung, Coaching …)  Karriere im PM und Vergütungsmodelle  Auditierung und Zertifizierung von Projektpersonal und PM  Führungsaufgaben und -kompetenz des Projektleiters  Zusammenarbeit und Spielregeln zwischen Projekt und Linie  PM-Office und weitere PM-Supportfunktionen  PM-Gremien und PM-Kultur Trotz aller Verbesserungsmöglichkeiten möchte ich PM- Delta Compact aber einen guten Reifegrad attestieren. Das System ist auch ohne große Schulung gut bedienbar und deckt die wesentlichen PM-Themen ab. Für eine erste Einschätzung des Projektmanagement-Reifegrades und für ein schnelles Benchmarking leistet das Instrument sehr gute Dienste. Anwendungsbeispiel฀1: ฀Internes฀Benchmarking In einem mittelgroßen Unternehmen der Automobilbranche soll das Projektmanagement verbessert werden. Die Projektleiter, das Personalwesen und die Organisationsabteilung sind sich einig, jetzt muss aber noch das Top-Management überzeugt werden. Ohne Rückendeckung von „oben“ und entsprechende Mittel lässt sich ein Veränderungsprozess zum „projektorientierten Unternehmen“ nicht erfolgreich realisieren. In dieser Situation war es sehr hilfreich, mit Hilfe von PM-Delta Compact ein internes Benchmarking der Projektmanagement-Anwendung in den einzelnen Geschäftsbereichen durchzuführen. Ausgangspunkt für das interne Benchmarking des Projektmanagements war die Auditierung einzelner Projekte oder Projektmanagement- Organisationen in den verschiedenen Geschäftsbereichen. Dazu wurde mit den jeweiligen Projektleitern bzw. PM- Beauftragten ein 1-2-stündiges Interview auf der Basis von PM-Delta-Compact geführt. Mit Hilfe der Spinnennetzgrafik, die das Tool automatisch erzeugt, war auf den ersten Blick zu erkennen, in welchen der 19 PM-Kompetenzfelder Handlungsbedarf besteht (siehe Abb. 6). Auf der Grundlage dieser Erkenntnisse konnten dann konkrete Handlungsfelder definiert und mit dem Management vereinbart werden. Gegenüber den Mitarbeitern und Führungskräften im Unternehmen wurde damit auch die Legitimation für notwendige Veränderungen geschaffen. Anwendungsbeispiel฀2: ฀Benchmarking฀Studie฀zum฀ Reifegrad฀des฀Projektmanagements฀in฀Unternehmen฀ einer฀bestimmten฀Branche฀und฀Region Um Unternehmen für die Weiterentwicklung ihrer PM- Kompetenz und -Prozesse zu sensibilisieren, ist eine Benchmarking-Studie gut geeignet. Aktuell arbeite ich an einer solchen Studie. PM-Delta Compact ist dabei ein hilfreiches Instrument. In 1bis 2-stündigen Interviews bei den betroffenen Unternehmen kann deren „Profil“ er- Abb.฀3: ฀PM-Delta-Menü฀mit฀Bewertungsstatus ��������� ��������������� ������������� ��������������� �������������� ������ ��������� ������������ ��������� ������������� ������������������������������� ������������������ ��������� ��������������� ����������������� ������� ���������������� �������������� ��������� ����������������� �������� ����������������� ����������� ����������������� ��������� �������������� ��������� ������������� ��������� �������������� ����������������� �������������� ��������� ������������� ��������� ��������� ������������ ����������� Ist unser PM ok? Was können wir verbessern? Abb.฀4: ฀Ablauf฀PM-Delta-Anwendung Abb.฀5: ฀PM-Delta-Auswertung ������� ������� 42฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 43฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 PM-Delta Benchmarking intern ��������� ���� ���������� ���������� ���������� ��������� Abb.฀6: ฀Beispiel฀„Internes฀Benchmarking“฀mit฀PM-Delta Bewertungen der Aussagen zur Studie 1. Stärken des Projektmanagement Ziele (Stärken) • Mit der systematischen Erfassung der Projektziele wird die erste unverzichtbare Voraussetzung für den Projekterfolg geschaffen. • Die Zuständigkeiten für die Festlegung von Projektzielen sind geregelt. • Durch fixierte Regeln für die Zielfindung erreichen Sie ein gemeinsames Verständnis aller Projektbeteiligten über die Ziele. • Kreativitätstechniken können für die Zielfindung hilfreich sein. • Durch Integration von Kosten-, Termin- und Qualitätsvorgaben sichern Sie eine ganzheitliche Projektbearbeitung. • Mit der Dokumentation der Ziele schaffen Sie sich eine wichtige Arbeitsgrundlage. • Die regelmäßige Überwachung der Kosten-, Termin- und Qualitätsvorgaben während der Projektrealisierung ist Voraussetzung für das Erreichen der Projektziele. • Die Ermittlung der Stakeholder und ihrer Ziele ist wesentlich für den Projekterfolg. • Nur die vollständige Ermittlung der Stakeholder ermöglicht die Identifikation aller Anforderungen. • Durch gezielte Information der Stakeholder über den Projektfortschritt halten Sie das Interesse Ihrer Promotoren wach. • Rechtzeitige Zieldefinition vermeidet Störungen in der Projektrealisierung. • Die Beschreibung dessen, was nicht Projektziel ist, fördert den Abstimmungsprozess zwischen Projektteam und Auftraggeber. • Die Festlegung und Abstimmung der Rahmenbedingungen bilden u. a. die Basis für die Abgrenzung der Kompetenzen des Projektteams zu denen des Auftraggebers. • Durch Berücksichtigung der Zielbeziehungen erschließen Sie Synergieeffekte und vermeiden Zielkonflikte. • Durch lösungsneutrale Zielformulierung erhalten Sie sich die Freiheitsgrade für optimale Lösungen. • Durch operationale Zielvorgaben stellen Sie eine Richtschnur für alle nachfolgenden Projektprozesse bereit. • Systematische Erfassung der Interessenlage aller Stakeholder ermöglicht eine sichere Akzeptanz des Projektes. Strukturierung (Stärken) • Die Projektstruktur bietet eine wichtige Basis als Ordnungsmittel und Kommunikationsgrundlage für das gesamte Projektmanagement. • Durch direkte Ableitung der Projektstruktur aus dem Auftrag bzw. den Projektzielen wird deren Erfüllung bestmöglich unterstützt. • Eine Methodik zur Projektstrukturierung ermöglicht die Anwendung von Standards, damit eine raschere Bearbeitung und Vergleichbarkeit von Projekt zu Projekt. • „Mehrdimensionale Projektstrukturierung“ gilt als Indiz für „hohes Niveau“ des PM- Systems. • Durch die Erarbeitung und Verwendung von Standard-PSP sichern Sie Rationalität und Qualität der Projektstrukturierung. • Durch Spiegelung am Auftrag sichern Sie die Vollständigkeit der Projektstruktur. • Durch genaue Projektabgrenzung schaffen Sie eine klare Schnittstelle zwischen Projekt und Projektumgebung. • Die Projektstruktur bildet das Inhaltsverzeichnis über alle Arbeitspakete. Abb.฀7: ฀Beispiel฀Deckblatt฀„Benchmarking-Studie“฀mit฀PM- Delta Abb.฀8: ฀Beispiel฀Stärken-฀und฀Verbesserungspotenziale- Auswertung฀mit฀PM-Delta,฀Teil฀1 42฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 43฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 stellt werden. Anonymisiert lassen sich die Ausprägungen der unterschiedlichen Unternehmen gegenüberstellen und Unterschiede aufzeigen. Die teilnehmenden Unternehmen erhalten neben ihrem „Profil“ in Form der Spinnennetzgrafik die Textauswertung in Form von Stärken und Verbesserungspotenzialen (Auszüge siehe Abb. 7, 8, 9). Dadurch haben sie auch einen unmittelbaren Nutzen aus der Studie. Allerdings müssen sowohl die Grafik als auch die Texte noch layoutmäßig bearbeitet werden. Das System stellt keine formatierte Dateiausgabe zur Verfügung (nur txt). Die Grafik lässt sich derzeit nur als Druckdatei erzeugen und muss für eine elektronische Weiterverarbeitung mit einem pdf-Writer generiert werden. Diese „Nacharbeit“ muss in Kauf genommen werden. Dafür ist PM-Delta Compact ja auch, was den Preis angeht, eher „Shareware“.  • Mit der vorgesehenen Wartungsbzw. Instandhaltungsdokumentation wird die Wahrung bzw. Wiederherstellung der Betriebsbereitschaft gut gesichert. • Mit der vorgesehenen Benutzerbzw. Anwenderdokumentation wird das Betriebsrisiko deutlich vermindert. • Die gesicherte Archivierung der Ist-Dokumentation unterstützt erheblich den gesamten Betrieb in der Nutzungsphase durch die Möglichkeit, auf Informationen schnell und gezielt zugreifen zu können. • Mit der Retrievalmöglichkeit für die gesamte Ist-Dokumentation ist aus Dokumentationssicht die höchste Betriebssicherheitsstufe erreicht. • Durch die durchgängige Einhaltung von Normen und Standards ist die Dokumentation so personenunabhängig wie möglich erstellt und damit auch lesbar für Dritte, denen die Konventionen bekannt sind. 2. Verbesserungspotenziale des Projektmanagement Ziele (Verbesserungspotenziale) • Bei Zieländerungen sollten die Stakeholder informiert werden, damit sie an Entscheidungen über den weiteren Projektablauf - je nach Kompetenz - mitwirken können. • Steuergremium und Projektteam sollten die gleiche Sicht aller Projektziele haben. Dazu gibt das Steuergremium die Projektziele frei. Strukturierung (Verbesserungspotenziale) • Zwischen den Elementen der Projektstruktur können Beziehungen bestehen. Diese sollten beschrieben werden, um den Betroffenen die Abstimmung zu ermöglichen. • Die Arbeitspaketbeschreibungen sollten so gestaltet sein, dass sie sowohl für interne als auch für externe Auftragsvergabe nutzbar sind. • Die rechtzeitige Abstimmung der Projektcodierung wäre sehr hilfreich für die Zusammenarbeit mit Auftraggeber und Auftragnehmern. Organisation (Verbesserungspotenziale) • Zur Durchführung von Aufgaben sollten die Projektmitarbeiter definitiv mit den erforderlichen Befugnissen ausgestattet werden. • Damit Projektteam und Steuergremium ihre gegenseitigen Erwartungen abgleichen können, sollten die Aufgaben und die Befugnisse des Steuergremiums festgelegt und beschrieben sein. • Jede Projektteamsitzung sollte eine Tagesordnung haben, um einen strukturierten und straffen Ablauf zu sichern. Personalmanagement (Verbesserungspotenziale) • Systematische Personalauswahlverfahren sind die Voraussetzung für die bestmögliche Personalausstattung eines Unternehmens. Sie können sowohl innerbetrieblich im Personalbereich oder als Dienstleistung durch eine Personalberatung bereitgestellt werden. • Durch eine projektbezogene Führungsvereinbarung können eindeutig punktuelle Arbeitsergebnisse vereinbart werden gegenüber der dauerhaften Delegation von Aufgaben innerhalb einer „normalen“ Abteilung. • Mit einem systematischen Personalmanagement können sowohl „Stillstandszeiten“ als auch von den Fähigkeiten und Fertigkeiten fehlerhafte Personalzuordnungen verringert werden. • Mit einer Potenzialanalyse und systematischer Personalentwicklung können Mitarbeiter zielgerichtet für Projektmanagement qualifiziert werden. Abb.฀9: ฀Beispiel฀Stärken-฀und฀Verbesserungspotenziale- Auswertung฀mit฀PM-Delta,฀Teil฀2 Schlagwörter Benchmarking,฀PM-Benchmarking,฀PM-Delta,฀Projektanalyse,฀Projektaudit,฀ Projektmanagement-Analyse,฀Projektmanagement-Reifegrad,฀Projektmanagement-Studie,฀Qualität฀des฀Projektmanagements Autor Gerhard฀Hab,฀Dipl.-Wirtschaftsingenieur,฀geb.฀1964,฀verh.,฀ 2฀Kinder,฀wohnt฀in฀Augsburg.฀Er฀hat฀10฀Jahre฀Industrieerfahrung฀in฀verschiedenen฀Controlling-฀und฀Projektmanagementpositionen฀(Entwicklung,฀Konstruktion,฀Datenverarbeitung,฀Sparte,฀Vertrieb,฀Projekt฀…)฀in฀der฀Automobilzulieferindustrie.฀Seit฀1998฀begleitet฀er฀Unternehmen฀als฀ Berater฀und฀Coach฀mit฀dem฀Schwerpunkt: ฀„Umsetzung฀von฀ Projektmanagement-Prozessen“.฀Sein฀Lieblingsthema฀ist฀ das฀„projektorientierte฀Unternehmen“.฀Als฀Seminarleiter฀trainiert฀er฀Projektleiter฀ und฀Nachwuchskräfte฀in฀PM-Themen.฀Er฀ist฀Lehrbeauftragter฀für฀Projektmanagement฀an฀der฀FH฀München,฀Gastdozent฀für฀PM฀an฀der฀Universität฀Augsburg.฀ Im฀Rahmen฀der฀GPM฀leitet฀er฀die฀Regionalgruppe฀Augsburg฀und฀die฀Fachgruppe฀ Automotive-Projektmanagement฀und฀hat฀im฀Jahr฀2001฀das฀PM-Forum฀Augsburg฀ gegründet.฀Seine฀Firma฀hab.projekt.coaching฀hat฀ihren฀Sitz฀in฀Augsburg. Anschrift hab.projekt.coaching Werner-Heisenberg-Str.3 D-86156฀Augsburg Tel.: ฀08฀21/ 4฀44฀88฀44 Fax: ฀08฀21/ 4฀44฀88฀49 E-Mail: ฀gerhard.hab@hab-projekt-coaching.de Internet: ฀www.hab-projekt-coaching.de 44฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 45฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Projektbenchmarking Diskussionsbeitrag฀zum฀„Aktuellen฀Stichwort“฀von฀H.฀Schelle฀in฀Projektmanagement฀aktuell฀2/ 2003,฀ S.฀29-32฀von฀Wolfgang฀Schallehn Heinz Schelle hat für das Projektbenchmarking eine Fülle interessanter Informationen zu den wichtigsten Benchmarkingmodellen zusammengestellt. Die Beziehungen der einzelnen Modelle untereinander konnten im „Aktuellen Stichwort“ nur angedeutet werden. Und das GPM-Produkt PM-Delta Compact wurde wohl aus Sorge um den Verdacht der Eigenwerbung gar zu knapp dargestellt. Wie wichtig für die Praxis die Beziehungen von PM-Delta Compact zu anderen Modellen sind, soll nachfolgend verdeutlicht werden. Zuvor: Das ursprüngliche PM-Delta ist ein Auditierungssystem, das ein PM-System mittels offener Fragen diagnostiziert, analog einem QM-Audit (die Unterschiede wurden in Projektmanagement aktuell 1/ 99 diskutiert). Für ein Benchmarking unmittelbar geeignet ist erst das daraus abgeleitete Software-Tool PM-Delta Compact. Dieses erstellt die Diagnose eines PM-Systems anhand von etwa 300 geschlossenen Fragen - und liefert eine nach den Elementen der DIN 69 904 strukturierte Punktbewertung als Grundlage für ein aussagestarkes Benchmarking. Mit der Aussage „PM-Delta fragt nicht nach dem Projekterfolg.“ charakterisiert Heinz Schelle den Unterschied zum Modell „Project Excellence“. Das ist zwar formal korrekt, aber wohl gar zu missverständlich. Ganz im Gegenteil: PM-Delta Compact ist auf den Projekterfolg fokussiert! Die direkte Frage nach dem Projekterfolg führt immer dann zu einer befriedigenden Antwort, wenn das Projektergebnis im Rahmen der geplanten Kosten und Termine erreicht wurde. Aber im Falle des Misserfolges führt sie leicht zu Fehlinterpretationen. Die Standardrezepte:  Projektergebnis unbefriedigend? → Ausführungsteam austauschen!  Termine überschritten? → Terminmanagement verfeinern!  Kosten überschritten? → Kostencontrolling verschärfen! führen oft sogar von einer Lösung weg. Tatsächlich liegen die Ursachen von Misserfolgen meist in ganz anderen Systemkomponenten wie z. B. Zieldefinition, Strukturierung, Ressourcenmanagement, Änderungsmanagement, Vertrags- und Claimmanagement, Risikomanagement und Dokumentation. Oft sind die Mängel schwer lokalisierbar und miteinander verwoben. PM-Delta Compact bietet mit seiner ganzheitlichen Herangehensweise schon für die Analyse unklarer Misserfolgssituationen eine unersetzliche Hilfe. Der eigentliche Nutzen liegt jedoch im prospektiven Einsatz. Ob es um die weitere Verbesserung eines erfolgreichen PM-Systems geht oder um die Reaktion auf Alarmsignale oder um den Aufbau eines neuen PM-Systems - immer zeigt PM-Delta Compact die Stärken wie auch die Verbesserungspotenziale des Systems in Grafik- und Textform übersichtlich auf. Vollkommen Recht hat Heinz Schelle mit dem Hinweis, dass Realität und Sollvorstellungen bei der Diagnose unterschieden werden müssen. Hierzu empfehlen die Autoren von PM-Delta Compact bei jeder Gelegenheit, zu kritischen Projekten zwei Bewertungen parallel vorzunehmen: einmal gnadenlos mit ausnahmslos gesicherten JA-Antworten, zum anderen optimistisch mit allen gewünschten JA-Antworten. Natürlich kann PM-Delta Compact weder vor Irrtum noch vor Selbstbetrug schützen, aber ein realistisches Bild erhält der interessierte Nutzer auf diese Weise ganz gewiss. Unbestreitbar ist, dass die so wichtigen „weichen Faktoren“ mit einem solchen System nur „weich“ erfasst werden können. Die Fragenbereiche Organisation und Kommunikation z. B. können formal alle Bedingungen erfüllen und trotzdem unbefriedigend funktionieren. Insofern ist die Aussagefähigkeit von PM-Delta Compact natürlich begrenzt. Eine diesbezügliche Erweiterung des Fragenkataloges ist jedoch vorgesehen. Übrigens erfüllt PM-Delta Compact die folgenden allgemeinen Anforderungen Schelles an Benchmarking-Systeme in vorbildlichem Maße:  Anwendbarkeit mit geringem Zeitaufwand von 2-4 Stunden für jede Bewertung,  unterschiedliche Wichtung der Einzelfragen,  Entwicklungsfähigkeit durch die Datenbankorganisation des Fragenkataloges. Als repräsentatives Anwendungsbeispiel sei das Ingenieurbüro Vössing genannt. Dessen PM-Office hat die 30 wichtigsten Projekte mit PM-Delta Compact bewertet. Primäres Ziel war dabei, auf hohem Niveau ein einheitliches Projektverständnis zu sichern. Bei allen(! ) einzelnen Projekten wurden Verbesserungspotenziale erschlossen. Ein weiterer unmittelbarer Effekt ist die Verbesserung der internen Kommunikation. Das komfortable „interne Benchmarking“ zeigte überraschende Unterschiede zwischen den einzelnen Projekten auf. Es soll durch turnusmäßige weitere Anwendung auch den kontinuierlichen Verbesserungsprozess im Unternehmen unterstützen und dokumentieren. Abschließend sei betont, dass PM-Delta Compact nicht nur für sich allein anzuwenden ist, sondern auch mit anderen Benchmarking-Modellen hervorragend zusammenwirkt: Von der Interpretation der Ergebnisse der Projektvergleichstechnik bis zur Vorbereitung der Bewerbung für den PM-Award nach dem Modell „Project Excellence“ liefert PM-Delta Compact eine substanzielle hilfreiche Unterstützung.  50฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 51฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3  Unter dem Motto „Nutzen und Grenzen von Microsoft Project? “ fand am 25. und 26. Juni in Heidelberg eine Expertentagung statt. Veranstaltet wurde die Tagung von der GPM Deutsche Gesellschaft für Projektmanagement e.V. und der TWT AG (Technologie und Wissenstransfer der Fachhochschule München) in Zusammenarbeit mit Campana & Schott Realisierungsmanagement GmbH (Frankfurt). Knapp 100 Fachleute aus Industrie, Dienstleistungsunternehmen und öffentlichen Organisationen erhielten einen Überblick über alle Facetten des PM-Tools und nahmen jede Menge praktischer Anregungen mit. So auch das Fazit der Organisatoren Prof. Dr. Hasso Reschke und Dr. Eric Schott: „Wir haben es in den beiden Tagen geschafft, 20 Erfahrungsberichte vorzustellen, intensiv zu diskutieren und in vielen Gesprächen zu vertiefen.“ Am Programm beteiligte Unternehmen waren unter anderem BASF, Campana & Schott, Dresdner Bank, Miele, Siemens und Vaillant Hepworth. Auf überdurchschnittliches Interesse stieß die Frage, wie MS-Project optimal in die Arbeit des Project Offices eingebunden und wie Routinetätigkeiten bei Projektplanung und -abwicklung mit dem in MS- Project integrierten Projektportal unterstützt werden können. Auch das Zusammenspiel von MS-Project als Planungsfrontend, SAP PS als Projektführungssystem und Lotus Notes zur Abwicklung des Berichtswesens wurde beleuchtet. Weitere Kernthemen waren der Einsatz von MS-Project zum Multiprojektmanagement und zum Ressourcenmanagement. Mit Spannung verfolgt wurde auch die Präsentation des neuen Microsoft Office Project 2003. Campana & Schott unterzog die neuen Funktionen einer ersten Evaluierung. Darin einbezogen waren auch Funktionalitäten wie der Project Portfolio-Analyzer und der Project Portfolio-Modeler, mit denen die Frage „Was passiert mit dem Portfolio, wenn sich neue Projekt-/ Ressourcensituationen ergeben? “ geklärt werden kann. MS-Project im länderübergreifenden Einsatz Exemplarisch für die vielen inte- GPM-Expertentagung: ฀Was฀bringt฀Microsoft฀Project฀2002? ressanten Einzelbeiträge sei hier der Erfahrungsbericht von Achim Lingenfelser, Entwicklungscontroller bei SEW-Eurodrive, herausgegriffen. Microsoft Project unterstützt in seinem Aufgabenbereich vorwiegend den Produktentwicklungsprozess langlaufender Großprojekte mit hoher Komplexität. Als besondere Herausforderung stellte sich dabei der standort- und länderübergreifende Einsatz und die Überwindung damit verbundener Sprach- und Systembarrieren dar. SEW konnte mit Hilfe spezifischer MS-Project-Templates eine starke Standardisierung der Planungsprozesse erreichen. Dabei wird der komplette Entwicklungsprozess mit sämtlichen Produkten abgebildet. Die standardisierte Kommunikation über eine einheitliche Plattform und einen zentralen Datenbank-Server ermöglicht, dass die übergeordnete Projektplanung am Hauptsitz der Firma und die dezentrale Feinplanung in den verschiedenen Produktionswerken/ Standorten und übrigen Abteilungen ohne Umwege in einem Masterplan zusammenfließen. Am Ende (ent-)steht eine gemeinsame und stets aktuelle Entscheidungsgrundlage bei gleichzeitiger Autonomie der werkspezifischen Planungen durch die Teilprojektleiter. Dadurch erhöht sich die Transparenz für die beteiligten Interessengruppen. Resultat: Der Planungs- und Kom- Dr.฀Christophe฀Campana: ฀„Hinter฀MS- Project฀steht฀eine฀anspruchsvolle฀ Technologie,฀mit฀der฀multinationale฀ und฀heterogene฀Projektumgebungen฀ immer฀besser฀abgebildet฀werden฀ können.฀Die฀Vielfalt฀der฀Möglichkeiten฀ kann฀bei฀unsachgemäßer฀Handhabung฀ aber฀auch฀zu฀Überforderung฀und฀mangelnder฀Akzeptanz฀führen.“ munikationsaufwand zwischen der Entwicklung und den einzelnen Werken hat sich wesentlich verringert. In Folge hat sich auch der Arbeitsaufwand für den Projektleiter beim Erstellen des Masterplans auf ein Minimum reduziert, da die Teilprojektplanungen direkt an den Ort des Geschehens „ausgelagert“ werden. Projektleiter Lingenfelser kann sich aufgrund des geringen Initialaufwandes für die Planung neuer Produkte über eine hohe Akzeptanz bei den Kollegen freuen. Kritisch ist jedoch der Pflegeaufwand: „Es bleibt angesichts von 3.000 Vorgängen abzuwarten, ob bestimmte Details im Projektplan wirklich sinnvoll sind, oder ob wir an der einen oder anderen Stelle nicht auf Details verzichten können, die den Aufwand gigantisch in die Höhe treiben,“ meint Lingenfelser abschließend. Fazit und Ausblick Die Erfahrungsberichte anderer Firmen zeigten tendenziell, dass bei der Installation der Software und bei der Einrichtung des Project Servers stets einige trickreiche Klippen zu meistern sind, bevor die eigentliche produktive Projektarbeit beginnen kann. Hier kann ein versierter Fachmann helfen Zeit, Kosten und Akzeptanzverluste zu minimieren. Bei der Einführung von MS-Project muss den Anwendern besonderes Augenmerk gewidmet werden, damit die Akzeptanz erreicht und sichergestellt wird. Direkt aus den USA kam Melinda Curtis, Product Manager Microsoft Project in der Microsoft-Zentrale. Sie berichtete über aktuelle Weiterentwicklungsaktivitäten für die Version 2003 und über längerfristige Strategien. Ihre Zielrichtung: MS Project soll Projekt- und Multiprojektmanagement mit den Komponenten Kapazitätsplanung, Kostenplanung, Information und Dokumentation, Berichtswesen, Risikomanagement und Portfoliomanagement umfassend unterstützen. Dass es auf diesem Wege noch genügend Arbeit zur Optimierung gibt, wurde von den Experten signalisiert. Die Ergebnisse der Tagung wurden von Dr. Campana zusammengefasst: Hinter der Serveranwendung von MS-Project steht eine anspruchsvolle Technologie, mit 50฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 51฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 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 der multinationale und heterogene Projektumgebungen immer besser abgebildet werden können. Das System verlangt vom Anwender, dass er sich vor dessen Einführung genau überlegt, wofür er es einsetzen will: Die Vielfalt der Einsatzmöglichkeiten und die unterschiedlichsten Ansichten und Berechtigungen in MS-Project führen bei zu großzügiger Handhabung sonst schnell zu Überforderung und mangelnder Akzeptanz. Im Laufe der Tagung kam jedoch auch deutlich heraus, dass es nicht reicht, sich mit dem PM-Tool allein zu beschäftigen; Themen wie PM- Kultur, unterschiedliche PM-Umfelder sowie Akzeptanz von Projektmanagement und Widerstände gegen Neuerungen sind mindestens genauso wichtig. Eine schriftliche Zusammenfassung der Evaluation und die vollständige Tagungsdokumentation sind erhältlich bei Frau Iris Belz/ Campana & Schott Realisierungsmanagement GmbH, Tel.: 0 69/ 97 78 83-0 oder belz@campana-schott.de. Norbert฀Hillebrand  Unter dem Motto RISIKO - QUALITÄT - ERFOLG steht der „Expertentag IT-Projektmanagement“, der am Freitag, dem 21. 11. 2003, in Stuttgart stattfinden wird. Wichtigste Leitthemen der 3 Vorträge und 6 Workshops werden Erfolgs- und Misserfolgsfaktoren bei IT-Projekten sein. Unter anderem referieren Prof. Heinz Schelle über Risikomanagement, Helmut Strohmeier über die Anatomie des Projekterfolgs und Petra Geipel über Konfliktmanagement in IT-Projekten. In den Workshops wird u. a. über Gründe für das Scheitern von Projekten (und wie es vermieden werden kann), über die Architektur von Projekten und IT-Systemen und die damit verbundenen Qualitätsaspekte diskutiert. Organisiert wird der ganztägige Erfahrungsaustausch als Non-Profit-Veranstaltung (geringer Kostenbeitrag) durch das Steinbeis-Transferzentrum IT-Projektmanagement mit Unterstützung durch die GPM Region Stuttgart. Mehr unter www.stz-itpm.de/ expertentag.html. Am folgenden Samstag, dem 22. November, findet ebenfalls in Stuttgart ein Workshop der bundesweiten Fachgruppe IT-Projektmanagement der GPM und der GI (Gesellschaft für Informatik e. V.) statt. In dieser verbandsübergreifenden Fachgruppe sollen die PMbezogenen Arbeiten und Erfahrungen von GI- und GPM-Mitgliedern zusammengeführt und zu neuen Ansätzen weiterentwickelt werden. Im Workshop steht die Präsentation und Diskussion folgender Fachgruppenthemen im Vordergrund: Berufsbild des IT-Projektmanagers, Erfolgsfaktoren für IT-Projekte, Interdisziplinäre IT-Prozessmodelle. Interessierte Mitstreiter aus beiden Verbänden sind dazu gerne willkommen. Informationen und Anmeldung: Andreas.Frick@ExperTeam.de. IT-Projektmanagementwochenende฀am฀21.฀und฀22.฀November฀in฀Stuttgart interPM฀2004: ฀Call฀for฀Papers  Vom 26. bis 27. März 2004 findet in Glashütten/ Taunus die interPM 2004 zur „Zukunft des Projektmanagement durch interdisziplinäre Ansätze“ statt. Die Konferenz, veranstaltet von der GPM Deutsche Gesellschaft für Projektmanagement und der GI Gesellschaft für Informatik e. V., möchte Vertreter unterschiedlicher Berufsgruppen aus Theorie und Praxis in den Dialog über die Zukunft des Projektmanagements bringen. Ziel ist es, die Perspektiven, Ansätze und Konzepte verschiedener Disziplinen zum Projektmanagement (z. B. Betriebs- und Ingenieurwissenschaften, Soziologie, Psychologie, Informatik, Beratungs- und Bildungsinstitutionen, PM-Schulen und -verbände) einander gegenüberzustellen, um diese zu diskutieren, zu reflektieren und zu verbinden mit dem Ziel, etwas „Neues“ entstehen zu lassen. Die interPM 2004 bietet ein Forum für Fachleute aus Wissenschaft und Praxis, die die Grenzen der eigenen Disziplin überschreiten und andernorts praktizierte Arbeitsformen auffinden wollen, um diese in der eigenen Arbeit umzusetzen Als Key-Note-Speaker konnte bereits Prof. Dr. Dr. h. c. Frederic Vester gewonnen werden. Die Veranstalter bitten um die Einreichung von Beiträgen zu den nachfolgenden Themen aus Praxis und Forschung:  Grundsatzbeiträge zur interdisziplinären Arbeit und zur Innovationsforschung  Interdisziplinäre und integrierte Projektmanagementansätze 54฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 55฀฀ GPM฀INTERN ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 GPM-Mitglieder: ฀ 3.468 Davon฀Firmenmitglieder: ฀ 170 Teilnehmer฀am฀Lehrgang฀„Projektmanagement-Fachmann“: ฀ 4.878 Durch฀PM-Zert฀vergebene฀Projektmanagement-Zertifikate฀insgesamt: ฀ 2.525 ฀+ +++ +++ +++ +++ +++ + ฀+ +++ +++ +++ +++ +++ + Jubiläum: ฀GPM฀bildete฀4.000฀Projektmanagement-Fachleute฀aus  Projektmanagement-Praxis und die Theorie lagen für Karin Eyssen von der DFS Deutschen Flugsicherung nahtlos beieinander: Durch „Learning by doing“ vertiefte sich die angehende Projektmanagement- Fachfrau in das Handwerkszeug, mit dem Profis komplizierte Vorhaben „stemmen“. Noch während ihrer halbjährigen Ausbildung zur Projektmanagement-Fachfrau plante die DFS-Mitarbeiterin ihr eigenes Projekt und startete damit ihr „Gesellenstück“. „Das ging von der Ausbildung nahtlos über in den Arbeitsalltag“, berichtet Karin Eyssen. Was sie erst erfuhr, als sie jetzt ihr Zertifikat erhielt: Sie war die viertausendste Absolventin der Ausbildung zum Projektmanagement- Fachmann (Fachfrau), der gründlichen „PM-Lehre“ mit 120 Stunden. „Wir verzeichnen in den letzten Jahren für dieses Angebot einen regelrechten Boom“, erklärt Roland Ottmann MBA, GPM-Vorstandsvorsitzender und dort zuständig für die Qualifizierung angehender Projektmanager. Seit rund zehn Jahren werde der Lehrgang bundesweit angeboten. Erst vor zwei Jahren habe die GPM den zweitausendsten Absolventen gemeldet. „Die Teilnehmerzahlen steigen nahezu exponentiell“, meint Ottmann. An Karin Eyssens Lehrgang, den GPM-Trainer Stefan Derwort (Projektforum Freiburg) für die Deutsche Flugsicherung in Langen durchführte, beteiligten sich bis Jahresmitte 14 weitere DFS-Mitarbeiter. In dem Unternehmen ließen sich bislang insgesamt 57 Projektmanager bei der GPM qualifizieren. Der Lehrgang gilt als einer der umfassendsten berufsbegleitenden Ausbildungswege für Projektmanagement. Mit ihm hat die GPM auf die steigenden Anforderungen an Projektmanager reagiert. Neben den Grundlagen und der Methodik gilt heute bekanntlich soziale Kompetenz als Schlüsselqualifikation im Projektmanagement. „Projektmanager müssen motivieren und kommunizieren können“, erklärt Roland Ottmann, „beispielsweise erlangen Konfliktmanagement und Teamführung zunehmende Bedeutung.“ Auch müssen, so ergänzt Trainer Stefan Derwort, Projektleiter Qualitätsmanagement beherrschen, Verträge abschließen, Risiken ihres Vorhabens kalkulieren, das Berichtswesen im Projekt managen und ihre Arbeiten dokumentieren können - ein ganzes Bündel von Qualifikationen. So setzt sich der GPM-Lehrgang derzeit aus 39 separaten Trainings- Bausteinen zusammen. Ein Übungsprojekt sowie ein reales Transferprojekt, das jeder Teilnehmer während des Lehrgangs vorbereitet, sichern den Lernerfolg. Bundesweit hat die GPM rund 70 Trainer für den Lehrgang ausgebildet und lizenziert. Ein Konzept, das bei der Deutschen Flugsicherung gut ankommt. „Wer heute bei uns Projektleiter werden will, muss durch diesen Lehrgang gehen“, betont Werner Langenbecker, technischer Leiter des Geschäftsbereichs Tower, „das ist eine eiserne Regel.“ Personalleiterin Dr. Martina Rautenschlein fügt an: „Dann brauchen wir uns keine Sorgen zu machen, ob unsere Projektfachleute genügend qualifiziert für ihre Arbeiten sind.“ Zufrieden über den Lehrgang äußern sich die Absolventen, die gemeinsam mit „Jubilarin“ Karin Eyssen ihr Zertifikat erhielten. DFS-Projektmanager Tim Meinlschmidt hebt hervor, dass im Lehrgang der theoretische Lehrstoff im günstigen Verhältnis zur Bearbeitung von Fallbeispielen steht. „Aber der Lehrgang ist damit auch sehr zeitaufwändig.“ Ralf Ulbrich zieht Nutzen aus der einheitlichen Projektmanagement-Sprache, die er im Lehrgang erlernt hat. Er hat festgestellt: „Arbeite ich mit anderen Projektmanagern beispielsweise von Lieferanten zusammen, können wir uns besser verständigen.“ Mitarbeiter฀der฀„DFS฀Deutsche฀Flugsicherung“฀ließen฀sich฀von฀der฀GPM฀zu฀Projektmanagement-Fachleuten฀ausbilden.฀Jubiläum฀für฀die฀GPM: ฀Die฀DFS-Gruppe฀ machte฀das฀vierte฀Absolventen-Tausend฀voll.฀GPM-Vorstandsvorsitzender฀Roland฀Ottmann฀MBA฀(ganz฀links)฀gratulierte฀den฀frisch฀gebackenen฀Projektmanagern฀in฀Langen. Foto: ฀GPM 56฀฀ GPM฀INTERN P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 57฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3  Was ein Projektmanager heute alles können muss - darauf angesprochen, neigt Klaus Pannenbäcker zu unorthodoxen Antworten. Keine Frage, solide Ausbildung und Projekterfahrung bringen im Unternehmen voran. Dann das große „Aber“: Da ist noch was, eine Eigenschaft, die der ehemalige Vorstand der GPM und IPMA- Mann „personality“ nennt, jene unabdingbare und doch häufig verkannte Ausstrahlung. Ein Projektmanager, der vorwärts kommen will, muss den Eindruck hinterlassen, dass er - je komplizierter ein Projekt ist - der bessere Mann für dieses Vorhaben ist. Er muss unbekannte Wege gehen können. Er muss werben, charmant umschmeicheln, messerscharf argumentieren, standhaft präsentieren, eindrucksvoll repräsentieren, unkompliziert zupacken können. Und er muss ein sympathischer Typ sein, jemand, der kontaktfreudig und unkompliziert ist, nicht schulmeisterlich, schon gar nicht unnahbar, um Gottes Willen nicht arrogant. „In den USA prüft man bei der Personalauswahl auch schon mal, ob der Projektmanager eine gute Story lustig erzählen kann“, reportiert Klaus Pannenbäcker aus den Staaten. Erstaunlich, Klaus Pannenbäckers Kollegen und Mitstreiter neigen zu der Meinung, dass dieses Profil vor allem auf ihn selbst, den „alten Hasen“ des Projektmanagements, zutrifft. Recht geben sie ihm allemal: Diese „personality“, die er mit kurzen Worten und Sätzen skizziert, könnte im Projektmanagement wirken. Vielleicht sogar, wie sie bei Klaus Pannenbäcker gewirkt hat. Eine gewisse Umtriebigkeit muss der ehemalige Siemens-Mann bereits Mitte der Sechziger bewiesen haben. Der studierte Elektro- und Refa-Ingenieur wurde 1967 aufgefordert, im Hause Siemens einen Vortrag über Netzplantechnik zu halten, von der man damals in den USA viel sprach. Pannenbäcker beließ es nicht bei dem einzelnen Vortrag. Auf den ersten Weltkongressen des IPMA-Vorläufers „Internet“ tauchte er auf, informierte sich in Wien und Amsterdam über die bemerkenswerten Planungstools der Amerikaner. 1969 dann - Klaus Pannenbäcker war zur Siemens Kraftwerk Union gewechselt - beauftragte ihn ein weitsichtiger Vorstand, das Project Office für die damals rund zwölftausend KWU-Mitarbeiter aufzubauen. Das Office sollte nach seinen Vorschlägen unter anderem für die großen Kraftwerksprojekte Projektpersonal bereitstellen. „Da gab es im Wesentlichen drei Gruppen“, berichtet Klaus Pannenbäcker. Zum einen fähige Assistenten für Projektleiter, die von Terminplanungen, Berichteschreiben, Tabellenkalkulationen entlasten sollten. Dann Assistenten für Linienvorgesetzte, die bei der Ressourcenverteilung nach den Forderungen der termingerechten Projektbearbeitung aushalfen. Und drittens Software-Spezialisten, die die seinerzeit umfangreichen Programme für Netzwerkplantechnik schrieben. Hier entstand der Kontakt zu einer Siemens-Stelle in München „und mit ihr“, so Klaus Pannenbäcker, „meine Freundschaft mit dem in der GPM bekannten Professor Heinz Schelle.“ Ein Punkt der Project-Office-Strategie war: Nach drei Jahren wurden die Assistenten selbst Projektleiter. „Das war training on the job“, berichtet Klaus Pannenbäcker. Und auch erste Ansätze von Multiprojektmanagement habe es in diesem Office gegeben. Damit griff Pannenbäcker gewissermaßen der Zukunft voraus. Als er ab Mitte der achtziger Jahre über das Konzept für den entstehenden Lehrgang „Projektmanagement-Fachmann“ und Mitte der neunziger Jahre über die Zertifizierung nachdachte, warf er einen Seitenblick auf sein KWU-Modell. Auch das spätere Zertifizierungssystem habe davon profitiert. Dass ein Projekt-Fachmann von der Assistenz bis zum Multiprojektmanager verschiedene Stufen durchlaufen muss, dass er durch „learning by doing“ Erfahrungen sammeln, dass es eine Art beruflicher Entwicklung für Projektpersonal geben muss - all dies war in dem Project Office aus alten Siemens-Tagen vorgezeichnet. Als das Zertifizierungsmodell reif war, zertifizierte er denn auch die ersten Projektleiter - seinerzeit gemeinsam mit den anderen Ur-Assessoren Dr. Ulrich Wolff, Dr. Erhard Motzel und Professor Sebastian Dworatschek. Ur-Assessor? „Ja, die allerersten Assessoren, die andere Projektleiter zertifizieren und selbst nicht zertifiziert wurden“, erklärt Klaus Pannenbäcker in der ihm üblichen Zuspitzung, „also die Assessoren ohne Eltern.“ Später stieß er die Zertifizierung hauptsächlich in Osteuropa an, in Russland, Kroatien, Island, Slowenien sowie in der Ukraine und in der Slowakei. „Anders als in Deutschland wollten wir in diesen Ländern erst die Zertifizierung etablieren und dann die entsprechende Ausbildung anbieten“, erklärt Pannenbäcker. Was sich durchaus lohnt: Schon ist der Wissensspeicher des Projektmanagement-Fachmanns beispielsweise ins Ungarische übersetzt. Womit sich der Projektmanagement-Fachmann peu à peu zu einem Exportartikel „made in Germany“ entwickelt. Derzeit bereitet die GPM unter Pannenbäckers Federführung eine englische Version vor. „Ich habe 1980 Siemens verlassen und mich mit einem eigenen Unternehmen selbstständig gemacht“, berichtet er, „da lag es nahe, die Selbstständigkeit mit Arbeiten im und für einen Verband zu untermauern.“ Elf Jahre bestimmte Klaus Klaus฀Pannenbäcker: ฀KWU-Erfahrung฀für฀die฀GPM Was฀macht฀einen฀guten฀Projektmanager฀aus? ฀Klaus฀Pannenbäcker,฀ langjähriger฀Aktiver฀in฀GPM฀und฀ IPMA: ฀„Projektmanager฀müssen฀sich฀ verkaufen฀können,฀am฀besten฀auch฀ auf฀Englisch.“฀ Foto: ฀privat 56฀฀ GPM฀INTERN P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 57฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Pannenbäcker im Vorstand mit über den Weg der GPM. Zwischen 1983 und 1994 widmete er sich fast jedem Ressort, hielt sich nur von den Vereinsfinanzen fern. In dieser Zeit entwickelte er federführend den „Projektmanagement-Fachmann“ und zog Professor Sebastian Dworatschek und Professor Heinz Schelle zu den Arbeiten hinzu. 1992 bereits - zwei Jahre, bevor er aus dem GPM-Vorstand ausschied - rückte er in die Führungsriege der IPMA vor. Zunächst wachte er als Vice President über die Finanzen, war Präsident, wechselte dann als Chairman ins „Council of Delegates“ und arbeitete bis 2000 als Vice President für Qualifizierung und Zertifizierung. Nochmals zur Ausgangsfrage: Was, Klaus Pannenbäcker, muss ein Projektleiter nun können? „Das, was ich gesagt habe“, betont er, „er muss sich verkaufen können, am besten auch auf Englisch.“ Polyglott-sympathischer Typ, unorthodoxer Wegesucher, Herausforderer, Methodenmeister und charmanter Verkäufer - das alles ist einem doch nicht in die Wiege gelegt. „Das ist ja zunächst mal Wunsch“, meint er, „und Wünsche fordern zur Erfüllung immer 150 Prozent.“ So bleibt’s wenigstens spannend … Oliver฀Steeger  Kooperation und „gütliche Einigung“ statt Rechtskampf bis aufs Messer: Im Streitfall schont Mediation Projektressourcen und macht aus Konfliktparteien wieder Partner. Fragt sich nur, weshalb die deutsche Wirtschaft die im angelsächsischen Raum selbstverständliche Mediation so wenig akzeptiert und selten nutzt. Projektmanagerin und Mediatorin Christine Schmidt ermutigt ihre Kollegen, die Mediation einzusetzen - nicht nur bei Rechtsstreitigkeiten. Jüngst hat sie eine eigene GPM-Fachgruppe zur Mediation gegründet; Interessenten können sich unter Tel.: 0 83 31/ 92 64 74 oder E-Mail: cgschmidt@web.de anmelden. Mediation ist in Deutschland seit fast 15 Jahren bekannt. Viele reden darüber, doch in der Unternehmenspraxis ist sie kaum verbreitet. Von der Projektmanagement-Praxis ganz zu schweigen … Christine Schmidt: Ich glaube nicht, dass sich das so pauschal sagen lässt. Bei rein rechtlichen Konflikten gewinnt Mediation in Deutschland an Bedeutung, allerdings recht schleppend - wobei es da auch Branchenunterschiede gibt. Und im Projektmanagement? Christine Schmidt: Leider haben wir keine konkreten Zahlen. Bekannt ist der Einsatz der Mediation in Bau- und Anlagenbauprojekten. Ich persönlich schätze, dass Mediation im Projektmanagement - beispielsweise in Softwareprojekten - als Begriff bekannt ist, nicht aber als nützliches Verfahren. Auch mögen Vorbehalte eine starke Rolle spielen. Verbirgt sich dahinter ein Mentalitätsproblem? „Wir฀wollen฀Vorbehalte฀gegen฀die฀Mediation฀in฀der฀Wirtschaft฀abbauen“ Christine Schmidt: Möglicherweise. Ich meine, in Deutschland ist man eher geneigt, die Konfliktlösung an einen Dritten zu delegieren, an einen Schlichter oder Richter. Der Gedanke, mit Hilfe und Zutun eines Mediators selbst offen und konstruktiv, aktiv und eigenverantwortlich den Konflikt zu bearbeiten, um eine für beide Seiten befriedigende Einigung zu erzielen - dieser Gedanke scheint eine enorme Hürde zu sein. Haben Sie eine Erklärung dafür? Christine Schmidt: Vielleicht erscheint es viel leichter, auf Standpunkten und Rechtspositionen zu verharren als Interessen offen zu legen und einen Konsens zu finden. Nun meinen Sie, dass die Mediation besonders im Projektmanagement erstaunliche Erfolge erzielen kann … Christine Schmidt: Ja, da kann Mediation ihre Vorteile voll ausspielen. Welche Vorteile? Christine Schmidt: Zunächst einmal, Projekte stehen unter starkem Erfolgsdruck. Konflikte sind beinahe vorprogrammiert … … und diese Konflikte binden Zeit, Energien und Ressourcen. Christine Schmidt: Richtig. Mediation ist ein Verfahren zur Konfliktlösung, das aufwändige juristische Verfahren vermeiden hilft. Sie ist vergleichsweise kostengünstig, spart Zeit und bringt gute, also nachhaltige und zufrieden stellende Ergebnisse. Was auch wichtig ist: Die Mediation ist vertraulich. In dem Mediationsverfahren wird nichts öffentlich. Nach dem Verfahren - vorausgesetzt, es wurde erfolgreich beendet - können die Konfliktparteien in der Regel ihre Geschäftsbeziehungen aufrechterhalten. Die Kontrahenten werden wieder zu Freunden? Christine Schmidt: So weit würde ich nicht gehen. Aber im Gegensatz beispielsweise zum Gerichtsverfahren, bei dem alle Rechtspositionen und Ansprüche aus der Vergangenheit erörtert werden, hat die Mediation einen anderen Ansatz. Sie ist auf die Zukunft ausgerichtet. Sie setzt auf Kooperation. Sie konzentriert sich auf die Interessen, Wünsche und Erwartungen der Konfliktparteien. Aufgabe des Mediators ist es, die Parteien im Dialog zu halten, ihnen zu helfen, dem Konflikt auf den Grund zu gehen und die Beziehungsebene ins Spiel zu bringen. Wir sprechen bislang nur von den klassischen Rechtsstreitigkeiten.