eJournals

4฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 D as Wolfsburger Zahlenwerk zum Stand des Projektmanagements in Deutschland spricht eine klare Sprache. Achtzehn Monate lang wurden dafür vorliegende Untersuchungen analysiert, 60 Experten qualitativ und 250 Experten quantitativ befragt. Ein graues Bild, das sich abzeichnet. Wenig durchdringt Projektmanagement die Gesamtunternehmen. Mager sind Kenntnisstand und Unterstützung der Top-Manager. Rar sind Karrieremodelle für Projektpersonal. Einmal mehr bekräftigt die Studie das, was Experten seit Jahren bemängeln und rügen. Auch gibt die Studie den Visionen beispielsweise von einem projektorientierten Unternehmen kaum Nahrung. Statt strategischer Weitsicht dominieren ganz andere Überlegungen, Projektmanagement einzuführen. Hier haben die Experten von Volkswagen Coaching ProjektManagement gemeinsam mit dem renommierten Institut für Projektmanagement und Wirtschaftsinformatik in Bremen unter Prof. Sebastian Dworatschek und dem EMS (European Marketing Specialists) in London ganz andere Motoren für Projektmanager aufgefunden: Termindruck, Komplexität der Aufgaben, hohe Projektzahl, Qualitätsforderungen und Marktdruck bereiten Projektmanagement in Unternehmen den Weg. So wird sich Projektmanagement weiter in den bislang angestammten Bereichen durchsetzen, beispielsweise in der Forschung und Entwicklung und auf klassisch technisch geprägten Feldern. Kernpunkte der Studie: Erstens: Projektmanagement ist nur dort erfolgreich, wo es von den Vorgesetzten unterstützt wird. Strategische฀Potenziale฀des฀ Projektmanagements฀häufig฀ ungenutzt Volkswagen฀Coaching฀ProjektManagement฀legt฀Studie฀vor Oliver฀Steeger Wo฀steht฀das฀Projektmanagement฀in฀Deutschland,฀in฀welche฀Richtung฀weist฀der฀Trend? ฀ In฀einer฀umfangreichen฀Studie฀haben฀die฀Experten฀von฀Volkswagen฀Coaching฀Projekt- Management฀Stand฀und฀Trend฀des฀Projektmanagements฀in฀Deutschland฀untersucht฀ -฀und฀kommen฀zu฀interessanten฀Ergebnissen.฀Ihr฀Fazit: ฀Nach฀wie฀vor฀klafft฀eine฀Lücke฀ zwischen฀den฀theoretischen฀Möglichkeiten฀und฀der฀Praxis฀in฀Unternehmen.฀Von฀einer฀an฀ Projektmanagement฀ausgerichteten฀Managementkultur฀sind฀die฀meisten฀Unternehmen฀ weit฀entfernt.฀Stattdessen฀Pragmatismus฀und฀Ad-hoc-Lösungen: ฀Projektmanagement,฀so฀ scheint’s,฀ist฀in฀erster฀Linie฀ein฀Werkzeug,฀das฀erst฀dann฀in฀die฀Hand฀genommen฀wird,฀wenn฀ es฀eng฀wird. Für฀63฀Prozent฀der฀befragten฀Experten฀aus฀der฀Automobilbranche฀steht฀fest: ฀Ohne฀das฀Top-Management฀geht฀es฀bei฀der฀Einführung฀von฀Projektmanagement฀nicht.฀Die฀Unterstützung฀„von฀oben“฀gilt฀hier฀ als฀wichtigster฀Erfolgsfaktor. Foto: ฀VW 5฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Rund 56 der Befragten nannten die Unterstützung durch das Top-Management als wichtigstes Schlüsselelement für die Verbreitung von Projektmanagement. Bei der konkreten Einführung von Projektmanagement gilt dann auch die Unterstützung durch Vorgesetzte als zweitwichtigstes Element. Nur die umfassende und frühzeitige Information über die Einführung galt den Experten als noch dringlicher. Zweitens: Führungskräfte wissen zu wenig über das Potenzial von Projektmanagement. Nur knapp zwölf Prozent der Befragten stellten für ihr Unternehmen fest, dass Projektmanagement auf allen Hierarchieebenen - also auch auf der Top-Ebene - vorhanden ist. Drittens: Projektmanagement wird nur unzureichend als Methode gesehen, um Projekte unternehmerisch zu steuern. Die meisten Unternehmen greifen zu Projektmanagement, weil ihre Projekte zunehmend komplexer, der Termindruck stärker und die Konkurrenz größer wird. Die eigentlichen Vorteile des Projektmanagements - Transparenz, bessere Steuerung und aktivere Kontrolle - spielen eine untergeordnete Rolle. Auch nur sehr verhalten beurteilt wird der Umstand, dass Projektmanagement mehr Unternehmertum in Projekte und Organisation trägt. Viertens: Die meisten Unternehmen gehen Projektmanagement nicht strategisch an. Nur etwas mehr als die Hälfte der Befragten gaben an, dass Projektmanagement in die strategische Unternehmensführung integriert ist. Weshalb฀führen฀Unternehmen฀ Projektmanagement฀ein? ฀-฀ Ein฀„Ranking“฀der฀wichtigsten฀Gründe  Die zunehmende Komplexität der Projekte spielt die größte Rolle für die Entscheidung, in Unternehmen Projektmanagement einzuführen. Fast 60 Prozent der 250 befragten Experten nannten die Komplexität als wichtigsten Auslöser. Bei Unternehmen mit einer Größe von mehr als 5.000 Mitarbeitern erreichte der Wert fast 68 Prozent.  Der Zeitdruck bei Projekten gilt als zweitwichtigster Grund, zu Methoden und Vorgehensweisen des Projektmanagements zu greifen. Fast die Hälfte der Befragten, rund 48 Prozent, nannten den Zeitdruck als wichtigen Grund. Dies erläuterten viele Experten hauptsächlich durch die erhöhten Anforderungen der Auftraggeber und Kunden.  Die steigende Projektzahl nannten rund ein Drittel als Grund (rund 34 Prozent). Hier zeichnet sich ab, dass Unternehmen zunehmend komplexe Aufgaben im Projekt bearbeiten. Auch ein gesellschaftlicher Wandel wirkt hinein. Qualifizierte Mitarbeiter suchen Verantwortung und zusätzliche Aufgaben - und wenden sich Projekten zu.  Qualitätsfragen fielen bei rund 27 Prozent ins Gewicht, dicht gefolgt von Marktdruck und Konkurrenzdruck (rund 26 Prozent) als Hauptgrund.  Vergleichsweise unbedeutsam schneiden die Motivation der Mitarbeiter und das Modernitätsimage ab (beides knapp sieben Prozent). Schlusslicht bildet der Vorstandswechsel (4,4 Prozent), der die Wendung zum Projektmanagement auslöst. Dennoch gilt hier: In einigen Fällen waren Veränderungen in Vorstand und Geschäftsführung treibende Kraft, um in Unternehmen Projektmanagementkultur zu verbreiten. Traditionelle฀Branchen฀bewerten฀im฀Gegensatz฀zur฀Automobilbranche,฀Telekommunikation฀und฀IT฀den฀Erfolg฀der฀ Einführung฀von฀Projektmanagement฀nicht฀so฀günstig. Foto: ฀Bayer Stellten฀die฀Studie฀„Stand฀und฀Trend฀des฀Projektmanagements฀in฀Deutschland“฀ vor: ฀Professor฀Sebastian฀Dworatschek฀(rechts)฀und฀Karsten฀Schmidt. Foto: ฀Oliver฀Steeger 6฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Fünftens: In bundesdeutschen Unternehmen herrschen „Insellösungen“ für Projektmanagement vor. Ernüchternd: Rund ein Drittel der befragten Unternehmen gaben dem Projektmanagement eine zentrale Funktion als Organisationsform auf Unternehmensebene. Dagegen organisieren mehr als achtzig Prozent aller Befragten ihr Projektmanagement situativ und projektabhängig. Sechstens: Standardisierte oder individuelle Lösungen? Unternehmen haben den Nutzen von Projektmanagementstandards noch nicht ausreichend erkannt. Nur knapp ein Viertel der Befragten bewerteten ihr Projektmanagement als unternehmensweit standardisiert. Eine Ausnahme bildet hier die IT-Branche, in der 40 Prozent der Befragten verstanden haben, wie bedeutsam die Standardisierung ist. Siebtens: Es gibt wenige Beispiele für Personalentwicklung der Projektmanager. Ein Drittel der Befragten konnten fassbare Programme für Personalentwicklung und Karrierekonzepte nennen. Und nur knapp 15 Prozent bewerteten Wie฀kann฀die฀Einführung฀von฀Projektmanagement฀gelingen? In der Studie dominierten Unternehmen, die Projektmanagement durchaus erfolgreich eingeführt haben. Die meisten Befragten nannten die Einführung in ihrem Unternehmen „sehr erfolgreich“ (knapp 13 Prozent), „erfolgreich“ (knapp 42 Prozent) oder „recht erfolgreich“ (knapp 33 Prozent). Damit sind fast 90 Prozent der Experten mit dem Ergebnis zufrieden. Nur 3,6 Prozent bewerteten die Bemühungen als „nicht erfolgreich“. Was den Studienautoren auffiel: In der IT-Dienstleistung/ Softwarebranche nannte jeder vierte Experte die Einführung als „sehr erfolgreich“, im großen Mittelstand allerdings schlossen sich nur knapp neun Prozent dieser Meinung an. Welche Schlüsselfaktoren helfen bei der Einführung? Mit Abstand am häufigsten genannt wurde die Unterstützung durch das Top-Management (knapp 56 Prozent). Dies sei, so die Studienautoren, eine klare Botschaft. Jeder Versuch, Projektmanagement ohne umfassende, aktive Rückendeckung durch das Top-Management einzuführen, scheine nur sehr geringe Erfolgsaussichten zu haben. Mehr noch: Je größer das Unternehmen ist, desto mehr ist diese Unterstützung aus der Chefetage nötig. Knapp 62 Prozent der Experten aus Unternehmen mit mehr als 5.000 Mitarbeitern nennen die Promotion seitens des Top-Managements dringend geboten, dagegen schließen sich nur etwa die Hälfte der Befragten aus kleineren Unternehmen bis fünfhundert Mitarbeiter dieser Meinung an. Weniger häufig genannte Erfolgsfaktoren sind der fachgerechte Methodeneinsatz (knapp 38 Prozent) und die Qualifizierung in Trainings und Lehrgängen (rund 33 Prozent). Nur selten tauchten die Organisationsstruktur (fast 14 Prozent) und eine fortschrittliche Software (7,6 Prozent) als Erfolgsfaktoren auf. Nächste Frage: Welche Prioritäten setzen Projektmanager bei der Einführung von Projektmanagement? Mehr als die Hälfte der Befragten sprechen sich für die umfassende und frühe Information, für die Unterstützung durch Vorgesetzte und für umfassende Schulungen aus. Mitarbeiter während der Konzeption einzubeziehen und geringer Zeitdruck spielen eine vergleichsweise untergeordnete Rolle und werden nur von etwa einem Drittel der Befragten als Erfolgsfaktor genannt. Basis der Untersuchung waren 250 Befragte, teilweise war Mehrfachnennung möglich. Quelle: „Stand und Trend des Projektmanagements in Deutschland“, Studie der „Volkswagen Coaching GmbH ProjektManagement“ in Kooperation mit IPMI, Universität Bremen, und EMS (European Marketing Specialists) Ltd., London. Die Studie wurde im Juni 2002 vorgestellt. Die฀IT-Branche฀hat฀bei฀der฀Einführung฀die฀Nase฀vorn: ฀Rund฀ein฀Viertel฀aller฀PM-Experten฀aus฀dieser฀ Branche฀bewerten฀den฀Schwenk฀zum฀Projektmanagement฀als฀sehr฀erfolgreich. Foto: ฀SAP฀ 7฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 ihre Karrieremöglichkeiten im Projektmanagement als sehr gut. Achtens: Zwischen dem Aufwand bei Schulungen (Quantität) und der Anwendung im Projektmanagement (Qualität) gibt es kaum Korrelationen. Im Klartext: Zwischen Theorie und Praxis klafft eine Lücke. Experten geben erhebliche Unterschiede zwischen der Theorie und dem praktizierten Projektmanagement an. Signifikant: Nur jeder zweite Befragte hatte Projektmanagementausbildungen, die länger als acht Tage dauerten, aufzuweisen. Neuntens: Eine unternehmensweite Projektmanagementkultur gilt als Basis für erfolgreiches Projektmanagement. Interessant: Rund zwei Drittel aller Befragten bewerteten Projektmanagementkultur als Element ihrer Unternehmenskultur. Doch nur rund zwölf Prozent meinten, dass Projektmanagement in ihrem Unternehmen alle Ebenen durchdrungen habe. Projektmanagement wird vom Top-Management eher operativ gesehen. Oder aber, so die Autoren der Studie, nur ansatzweise verstanden.  Im฀Fokus: ฀Die฀Studie฀„Stand฀und฀ Trend฀des฀Projektmanagements฀ in฀Deutschland“ Achtzehn Monate lang haben Wissenschaftler Daten gesammelt, ausgewertet und in einem fingerdicken Band zusammengetragen. Differenziert in die Branchen „Automobil“, „Telekommunikation“, „IT-Dienstleistungen/ Software“ und „Traditionelle“ macht die Studie Bestandsaufnahme. Zusätzlich trennten die Autoren ihre Daten in kleinere, mittlere und große Unternehmen auf. „Diese Differenzierung erlaubt eine individuelle, auf das eigene Unternehmen zugeschnittene Vergleichbarkeit“, betont Karsten Schmidt von VW Coaching ProjektManagement. So gebe sie Führungskräften im Bereich Projektmanagement Handlungshilfen sowie Kriterien und Vergleichsdaten für unternehmenseigene Audits. Nützlich dabei: Fragebögen, Leitfaden und Datenbestand sind dem Wolfsburger Zahlenwerk angehängt. Hier können Fachleute eigene Daten erheben und mit dem Material abgleichen. Die Studie „Stand und Trend des Projektmanagements in Deutschland“ kostet EUR 300. Weitere Informationen: Volkswagen Coaching ProjektManagement, Karsten Schmidt, Tel.: 0 53 61/ 8 97- 35 61, Karsten. Schmidt@volkswagen.de Die฀neue฀Projektmanagementstudie฀fokussiert฀neben฀der฀Automobilbranche,฀der฀ traditionellen฀Industrie฀und฀dem฀IT-Sektor฀auch฀die฀Telekommunikation. Foto: ฀Nokia 8฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Mit Ihrer Studie haben Sie eine Bestandsaufnahme des deutschen Projektmanagements vorgelegt. Was hat Sie zu dieser Studie motiviert? Karsten Schmidt: Es ging uns in erster Linie darum, das Verständnis von Projektmanagement, die Erfolgsfaktoren und quasi die aktuelle Situation des Projektmanagements zu ermitteln. Gibt es da Bedarf? Karsten Schmidt: Aber ja. Praxiserfahrungen haben gezeigt, dass mehr Kenntnisse über die Realität von Projektarbeit notwendig sind, da Projektmanagement in Deutschland unterschiedlich eingesetzt und gestaltet wird. Abstimmungen zwischen Lehre und Praxis erscheinen notwendig, um die aus diesem Spannungsfeld entspringenden Fragen zur Umsetzung von Projektmanagement zu klären. Des Weiteren benötigen wir diese Informationen für unsere Projektmanagementberatung. Die Frage war hier, was müssen wir wie auf dem Markt für Projektmanagementdienstleistungen anbieten. Und? Sie haben Antworten auf diese Fragen gefunden? Karsten Schmidt: Antworten vielleicht nicht, aber viele wichtige Informationen. Wir können beispielsweise nachweisen, dass einerseits zwischen dem Anspruch an Projektmanagement aus Wissenschaft und Lehre, andererseits der Projektmanagementpraxis in Unternehmen zum Teil eine große Lücke klafft. Dieses Ergebnis ist nicht neu. Eine alte Vermutung scheint damit bestätigt zu werden. Karsten Schmidt: Richtig. Aber wir haben differenzierte Informationen bekommen. Wir können sagen, dass die Idee von einer breit angelegten Projektmanagementkultur, die sich als umfassender Führungsansatz in Unternehmen durchsetzt, eine Vision ist. In der Praxis sieht es um den Stellenwert von Projektmanagement anders aus. Dort wird Projektmanagement häufig eingesetzt, wenn es in einem Projekt eng wird. Also die blanke Not treibt zum Projektmanagement? Projektmanagement als Feuerwehrinstrumentarium? Karsten Schmidt: Das lässt sich mit Sicherheit nicht so verallgemeinern. Aber ein gewisser Druck gehört offenbar dazu, dass Projektmanagament zum Zuge kommt. Wir haben vier Treiber für Projektmanagement festgestellt. Sich schnell ändernde Märkte, erhöhte Anforderungen an die Flexibilität eines Unternehmens, Komplexität von Vorhaben und starker Termindruck - das sind die Motoren für Projektmanagement. Projektmanagement wird also nicht proaktiv eingeführt, im Sinne einer vorsorgenden Maßnahme? Karsten Schmidt: Der Impuls kommt aus zwei Richtungen. Zum einen fürchten Führungskräfte um ihre Marktposition und drängen deshalb auf den Einsatz von Projektmanagement. Das ist durchaus proaktiv. Im฀Gespräch: ฀Karsten฀Schmidt฀ von฀Volkswagen฀Coaching฀ ProjektManagement Foto: ฀Oliver฀Steeger „Projektmanagement฀meist฀erst,฀ wenn฀es฀kriselt“ Projektmanagement-Experte฀Karsten฀Schmidt,฀VW฀Coaching฀ProjektManagement,฀ bestätigt฀Lücke฀zwischen฀Theorie฀und฀Praxis Oliver฀Steeger Nicht฀alle฀Tage฀wird฀eine฀so฀umfangreiche฀Studie฀zum฀Thema฀Projektmanagement฀vorgestellt.฀Grund฀genug฀für฀Projektmanagement฀aktuell,฀mit฀dem฀Initiator฀der฀ab฀Seite฀4฀vorgestellten฀Studie฀Kontakt฀aufzunehmen. Redakteur฀Oliver฀Steeger฀sprach฀mit฀Karsten฀Schmidt฀von฀„Volkswagen฀Coaching฀Projekt- Management“฀über฀Ergebnisse฀und฀Perspektiven฀der฀Studie,฀die฀seit฀Juni฀2002฀unter฀dem฀ Titel฀„Stand฀und฀Trend฀von฀Projektmanagement฀in฀Deutschland“฀vorliegt. 9฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Häufig kommt aber auch das Signal aus konkreten Projekten, quasi reaktiv auf Probleme in den Vorhaben. Welche Erfolgsfaktoren haben Sie für Projektmanagement ermittelt? Karsten Schmidt: Hier haben uns die Ergebnisse nicht sonderlich überrascht. Sie haben uns wiederum bestätigt. Fast die Hälfte der Befragten gaben an, dass Projektmanagement nur erfolgreich funktionieren kann, wenn das Top-Management dahinter steht und es unterstützt. Diese Unterstützung ist der wichtigste Erfolgsfaktor. Projektmanagement benötigt kräftigen Rückenwind aus den Chefetagen - das ist in der Tat nicht überraschend … Karsten Schmidt: Nein, es ist aber ein wichtiges Signal, das Management stärker beispielsweise in die Projektkommunikation, in die Ausbildung und in die Prozesse einzubeziehen. Auch das Projektmarketing sowie die gezielte Ausbildung der Top-Führung erhalten im Licht dieses Ergebnisses einen neuen Stellenwert. Welche weiteren Erfolgsfaktoren sind noch bedeutend für Projektmanagement? Karsten Schmidt: Auch hier gibt es keine Überraschungen, sondern wichtige Bestätigung. Saubere, vernünftige Methodik und ausreichende Qualifizierung spielen eine große Rolle. Einbindung des Top-Managements, Methodik und Qualifizierung - was heißt dies für die Dienstleistungen von VW Coaching ProjektManagement? Karsten Schmidt: Unsere Dienstleistung ruht auf drei Säulen, der Beratung, Projektmanagement in konkreten Projekten und der Projektqualifizierung, die sowohl Projektleiter als auch Führungskräfte und Mitarbeiter umfasst. Wir wurden durch die Studie bestätigt, dass wir damit die Bedürfnisse des Marktes gut abdecken. Welche Studienergebnisse haben Sie überrascht? Karsten Schmidt: Die reine Projektmanagementsoftware hat offenbar keine Priorität. Nur drei Prozent rechnen sie zu den Erfolgsfaktoren. Software ist damit unwichtig? Karsten Schmidt: Nein, wir haben das Ergebnis hinterfragt. Heute kommt kein Projekt ohne spezielle Software aus. Doch scheint die Bedeutung der reinen Software nicht so groß zu sein. Aber die Methode, die von der Software abgebildet wird, hat hohe Priorität. Welchen Schluss ziehen Sie daraus? Karsten Schmidt: Für uns ist klar: Die Projektmanagementsoftware darf die Methode nicht verordnen. Bei komplexen Projekten kann dies zu erheblichen Problemen führen. 10฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Konkret? Karsten Schmidt: Entscheidend ist, dass die Software nach der Methode ausgewählt wird. Hier sind also Vielfalt und Unterordnung der Software unter die individuelle Projektmanagementmethode gefordert … Welche Ergebnisse haben Sie noch überrascht? Karsten Schmidt: Die Aussagen zur Reifeentwicklung des Projektmanagements in Unternehmen. Man geht gerne davon aus, dass Projektmanagement, wenn es einmal eingeführt ist, sich fast automatisch entwickelt und dabei reift. Genau diese Strategie geht nicht auf? Karsten Schmidt: Nein, offenbar nicht in dem erhofften Umfang. Das Rezept, dass sich Projektmanagement von einer Insel her über das gesamte Unternehmen verbreitet, scheint nicht zwangsläufig zu funktionieren. Was schlagen Sie für die Projektmanagementeinführung vor? Karsten Schmidt: Zumindest für große Unternehmen und Konzerne muss das Prinzip der Vielfalt gelten. Die Methodik, die für Forschungs- und Entwicklungsabteilungen gilt, muss nicht zwangsläufig beispielsweise für Organisationsprojekte geeignet sein. Sehe ich das richtig? Bedeutet dies den Abschied von einem unternehmensweit gültigen, einheitlichen Projektmanagementstandard? Karsten Schmidt: Nein, das nicht. Doch ist unter einem einheitlichen Dach die Balance zwischen Standardisierung und individueller Anpassung für einzelne Bereiche zu schaffen. Das heißt …? Karsten Schmidt: Es sollten Standards für das Projektmanagement definiert werden, die als strategische und operative Leitlinien dienen. Auf dieser Grundlage können für jeden Bereich detailliertere Vorgehensweisen entwickelt werden, die wiederum für jedes Projektprogramm spezifiziert werden. Konkret, was bedeutet dies für einen unternehmensweit gültigen Patentprozess für Projektmanagement? Karsten Schmidt: Größere Unternehmen und Konzerne sollten zumindest Vorsicht walten lassen bei einer einheitlichen Festschreibung zu „strenger“ Projektmanagementregularien. Es ist erforderlich, einen Rahmen vorzugeben. Dieser muss aber einzelnen Organisationseinheiten genügend kreativen Spielraum lassen. Ihre Studie haben Sie im Juni letzten Jahres erstmals vorgestellt. Eine umfangreiche Broschüre ist erschienen, die demnächst auch über den Buchhandel zu beziehen ist. Sind damit Ihre Forschungsarbeiten abgeschlossen? Karsten Schmidt: Die Studie wird auch auf Englisch erscheinen, das ist sicher. Möglicherweise werden wir auch das deutsche Projektmanagement mit dem Projektmanagement Japans, Frankreichs oder der USA vergleichen. Hier werden wir unseren Fokus auf interkulturelle Aspekte lenken. Weitere Informationen zur Studie „Stand und Trend von Projektmanagement in Deutschland“ bei Volkswagen Coaching ProjektManagement, Karsten Schmidt, Tel.: 0 53 61/ 8 97-35 61, Karsten.Schmidt@volkswagen.de  11฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 D a macht sich Resignation breit. „Ich weiß wirklich nicht mehr, wie ich mit meinem Team umgehen soll.“ Der Düsseldorfer Projektleiter - soeben mit seinem ersten Projekt betraut - will seine Mitarbeiter nicht autoritär führen, wie er es von seinem Geschäftsführer her kennt. Aber auch nicht die weiche Linie eines ehemaligen Vorgesetzten fahren. Zwischen den Stühlen sitzend, erlahmt er. Das Projekt bleibt stecken. Erst ein Coach hilft dem Bauingenieur, die verfahrene Situation zu ordnen: Der Projektleiter entwickelt eine eigene Vision für seinen Führungsstil. Und er lernt, sie im Arbeitsalltag umzusetzen. „Ich wusste zwar, wie ich es nicht machen wollte“, erklärt er hinterher, „wie ich aber meine Mitarbeiter motivieren und steuern will, zu dieser Erkenntnis bin ich im Coaching gekommen.“ Coaching. Eine große Hilfe. Vor allem aber noch ein Tabu-Thema unter Projektmanagern. Nach Einschätzung der Coaching-Expertin Ulrike Wikner werden die meisten Projektleiter von ihren Chefs zum Coaching geschickt. Nur die wenigsten folgen ihrem eigenen Impuls, die Hilfe unabhängiger Experten anzunehmen und ihre Berufspersönlichkeit weiterzuentwickeln. Sich in die Hände eines Coachs zu begeben, das heißt, persönliche Schwächen zu bekennen, das Macher-Image anzukratzen, neidvollen Kollegen Munition für Intrigen und Geschwätz zu geben. Coach? Besser nicht, auch wenn es besser wäre. Dagegen sind Projektmanagement-Berater und Consultants mit ihren klaren Fachempfehlungen weitgehend akzeptiert. Es schmückt, sich verantwortungsbewusst Kompetenz ins Haus und Team zu holen. Nicht aber Coachs. Denn die Coach-Szene scheint auf den ersten Blick eine merkwürdige Branche zu sein, eine Sammlung von Paradiesvögeln, von Lebensberatern und Motivations-Entertainern, Sektierern, Paktierern und Parvenüs. Coaching entströmt der säuerliche Geruch des Pseudo-Therapeutischen, des Laberns und Lamentierens - derweil es im Projekt an allen Ecken und Enden brennt. Bestenfalls verschenkte Zeit, schlimmstenfalls einem Scharlatan auf den Leim gegangen. Coaching฀für฀Projektmanager฀-฀ noch฀immer฀ein฀„Tabu-Thema“ Die฀meisten฀Projektleiter฀werden฀vom฀Chef฀„geschickt“ Oliver฀Steeger Nur฀wenige฀Projektmanager฀reden฀offen฀darüber: ฀„Coaching“฀ist฀in฀der฀Projektmanagement-Branche฀mit฀einem฀Tabu฀belegt.฀Offen฀darüber฀sprechen,฀sogar฀die฀Zusammenarbeit฀ mit฀einem฀Coach฀bekennen? ฀Das฀gilt฀als฀Eingeständnis฀eigener฀Schwäche.฀Lieber฀Zähne฀ zusammenbeißen,฀Ärger฀im฀Projekt฀schlucken,฀die฀neue฀Position฀irgendwie฀ausfüllen,฀Konflikte฀mit฀Team฀und฀Vorgesetzten฀aussitzen,฀die฀eigene฀Karrierentwicklung฀zurückstellen.฀ Doch฀wer฀sich฀hat฀coachen฀lassen,฀der฀ändert฀seine฀Meinung.฀Im฀Idealfall฀saß฀er฀einem฀ Spezialisten฀gegenüber,฀der฀sowohl฀etwas฀vom฀Coaching฀als฀auch฀vom฀Projektmanagement฀ versteht. Experte฀für฀Projektmanagement,฀Branche฀-฀und฀ Coaching Da ist was dran. „Coaching ist inzwischen zu einem Containerwort mutiert“, klagt Markus Rasche von B+B Unternehmensberatung, „es handelt sich um einen Begriff, der mit sehr unterschiedlichen Inhalten gefüllt werden kann.“ In der quietschbunten Coaching-Szene die Spreu vom Weizen zu trennen ist selbst für Insider keine Freude. Als Faustregel gilt: Der Coach sollte Experte für Coaching und den Beruf des Klienten sein, sollte zudem etwas von dessen Wirtschaftszweig verstehen, sollte sich ständig weiterbilden und selbst bei Kollegen Supervision in Anspruch nehmen. So betrachtet, Erreichbar฀und฀verschwiegen฀-฀erfahrene฀Projektmanagement-Coachs฀bleiben฀ im฀Hintergrund. Foto: ฀Nokia฀ 12฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 bleibt nach der Trennung von der Spreu wenig Weizen übrig. Es verwundert kaum, dass Projektmanager ihre Spitzen-Coachs mit Empfehlung befreundeten Kollegen weiterreichen. Coaching tut nämlich Not. „Viele Führungskräfte erhalten in ihrer hohen Position keine Rückmeldung auf ihre Arbeit“, meint Coaching-Expertin Ulrike Holzberger, „doch Rückmeldung ist wichtig, um das eigene Tun zu reflektieren.“ Diese „Feedback-Lücke“ füllt der Coach aus - und gibt seinem Klienten Halt. Hat ein Projektleiter einmal Coaching in Anspruch genommen, ändert er mitunter rasant seine Meinung über diese Hilfemöglichkeit. Manche bitten zu Beginn des Coachings um absolute Verschwiegenheit - und machen am Ende selbstbewusst bekannt, wie hilfreich das Coaching war. Sie haben (immer einen kompetenten Coach vorausgesetzt) mit vielen Vorurteilen aufgeräumt. Vorurteil Nummer eins: „Jeder wird von meinem Coaching erfahren.“ Stimmt nicht! Der Klient muss sich keineswegs als „Problemfall“ im Unternehmen outen. Gutes Coaching geschieht leise, hinter verschlossenen Türen. Ulrike Wikner betont beispielsweise, dass die Arbeit zwischen Klient und ihr bestenfalls den Vorgesetzten noch etwas angeht. „Selbst die Berichte, die ich an den Vorgesetzten als Auftraggeber weiterleite, stimme ich mit dem Klienten ab“, erklärt sie. Ihr Ziel sei, dem Klienten transparent zu halten, was sie mit dem Auftraggeber über ihn austausche. Ulrike Wikner: „Das fordert auch Vertrauen durch die Auftraggeber! “ Vorurteil Nummer zwei: „Coachs wissen nichts von meinem Job.“ So nicht haltbar. „Experten-Coachs“, die sich auf Projektmanagement spezialisiert haben, kennen sich mit den Problemen der Projektleiter aus. Sie waren Hilfe฀suchen,฀um฀eigene฀Grenzen฀zu฀überwinden฀-฀das฀Coaching฀setzt฀sehr฀pragmatisch฀an. Foto: ฀Nokia฀ Coaching-Expertin฀Ulrike฀Wikner: ฀„Beim฀Coaching฀geht฀es฀ um฀verbreitete฀Aufstiegsprobleme฀von฀Projektmanagern.“ Foto: ฀privat 13฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 selbst in Unternehmen beschäftigt, arbeiten im günstigen Fall als Projektmanagement-Trainer, manchmal sogar als Assessoren für Projektbewertungen. Ihre Hilfe ist, so erstaunt es Klienten, verblüffend praxisnah. Vorurteil Nummer drei: „Coaching bringt keine Ergebnisse.“ Alles nur warmherzige Seelenmassage, die gut tut und nicht weiterführt? Falsch, gute Coachs packen das Problem bei den Hörnern und unterstützen den Projektleiter, seine Lösungen für das Problem zu finden. Sie sind es sogar, die auf Lösungen drängen, wenn der Klient am liebsten die Decke über den Kopf ziehen würde. Vorurteil Nummer vier: „Coaching-Erfolge lassen sich nicht nachprüfen.“ Kompetente Coachs besprechen Ziele und überprüfen mit dem Klienten, ob Coaching-Meilensteine erreicht wurden, ob der Prozess und die gemeinsame Arbeit stimmen, ob der Aufwand im Rahmen bleibt und ob die Ergebnisse den Erwartungen entsprechen. „Da gibt es viele Parallelen zur Vorgehensweise im Projektmanagement“, weiß Ulrike Wikner. Die klassische „Soll/ Ist“- Analyse klingt an, ein Vergleich, den die Expertin durchwegs gelten lässt. Techniken฀aus฀dem฀Spitzensport Das Business-Coaching wurzelt im Coaching des Spitzensports. Profi- Athleten ergänzen das körperliche Training mit mentalem Coaching, um Leistungsblockaden abzubauen, Ängste zu überwinden, persönliche Erfolgsstrategien zu entwickeln - oder auch Erfolge zu verkraften. Nicht anders im Projektmanagement. Wachsende Herausforderungen lösen häufig das Coaching aus. Am Anfang steht die Ahnung, so wie bislang nicht weitermachen zu können. Über Jahre sind Projektleiter gut gefahren mit ihrer Führung, mit ihrem Arbeitsstil, mit ihrer Wenn฀der฀Vorgesetzte฀zum฀ Coaching฀schickt฀… Das Projekt hakt. Und plötzlich klopft der Vorgesetzte dem Projektleiter auf die Schulter: „Sie brauchen einen Coach …“ Das kann ein wohlmeinendes Hilfeangebot sein. Aber auch ein Warnschuss - nach dem Muster: „Junge, das ist deine letzte Chance.“ Was immer sich der Vorgesetzte und Auftraggeber von dem Coaching verspricht: Coachs ergreifen bedingungslos Partei für ihren Klienten. Die Berufspersönlichkeit des Klienten soll wachsen. So ist der Coach nicht verlängerter Arm des Vorgesetzten, um dem Klienten unliebsame Botschaften zu überbringen oder ihn nach dem Willen des Vorgesetzten zu formen. „Es kommt natürlich vor, dass Auftraggeber dies wünschen“, erklärt Ulrike Wikner, „seriöse Coachs lehnen diese Aufträge allerdings ab.“ - Wie gehen Coachs in der Praxis vor? 1. Auftragsklärung: Das erste Gespräch, in dem Aufgabe und Ziel geklärt werden, findet unter sechs Augen statt: Klient, Auftraggeber und Coach. Dann wird der Coach nochmals mit seinem Klienten sprechen und prüfen, ob dessen persönliche Ziele mit den Auftragszielen übereinstimmen. Gibt es hier Differenzen, sollte nochmals eine Dreier-Abstimmung mit dem Auftraggeber stattfinden. 2. Zielvereinbarung: Obwohl ein Coach von dem Vorgesetzten beauftragt wurde, steuert der Klient die Vorgehensweise. Seine Ziele und die Entwicklung seiner Berufspersönlichkeit bestimmen die Coaching-Sitzungen. Er gibt Ziele vor, er findet seine Wege dorthin, und er bewertet auch abschließend den Coaching-Prozess. 3. Verschwiegenheit: Vertrauen ist der Rohstoff für Coachings, seriöse Coachs wissen dies und sichern Verschwiegenheit zu. Sogar die Zwischenberichte und Endberichte an den Auftraggeber stimmen sie mit dem Klienten ab. Wichtig: Der Klient sollte für sich prüfen, ob er Vertrauen zu dem Coach fassen kann und will. Hier entscheidet - neben den Referenzen und dem Qualifikationsprofil - auch das Bauchgefühl über die Wahl des Coachs. Bestleistungen฀inklusive: ฀Viele฀Techniken฀und฀Grundideen฀ des฀Coachings฀stammen฀aus฀dem฀Spitzensport. Foto: ฀Siemens฀ 14฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Selbstorganisation oder mit ihrem Auftreten gegenüber Projektgebern und Kunden. Die Herausforderungen wuchsen, das Unternehmen wandelte sich. Plötzlich helfen die alten, persönlichen Erfahrungen, Verhaltensweisen, Techniken und Werte nicht mehr weiter. Resignation greift um sich, die Projektleiter fühlen sich den Aufgaben nicht mehr gewachsen, nicht mehr fit für den Job. Probleme entstehen. Typische฀Aufstiegsprobleme „Das sind verbreitete Aufstiegsprobleme“, weiß Ulrike Wikner. Da ist etwa der IT-Projektleiter, der in seinem neuen Unternehmen Organisationsprojekte führen muss. Da ist der versierte Projektassistent, der zum Manager eines strategisch wichtigen Vorhabens berufen wird. Da ist der Projektleiter, der plötzlich mit einem unkooperativen, aber notwendigen Experten im Team nicht klarkommt. Da ist der Projektleiter, der zwar Teams vor Ort, aber nicht weltweit verteilte, virtuell arbeitende Teams führen kann. Hier greifen „Experten- Coachs“ mit einem Mix aus individueller Beratung, persönlichem Feedback und praxisorientierter Umsetzungs-Begleitung ein. Ein Coach fragt nach den Problemen und hilft dem Klienten, genau zu erfassen, wo der Schuh drückt. Dann der Gegencheck: Wo soll es hingehen? Wie sollte es sein? Wo ist die Vision? Gerne greifen Coachs dann zu der „Wunderfrage“. Nehmen wir an, der Klient erwacht am nächsten Morgen, und wie durch ein Wunder sind die Probleme beseitigt. Was hat sich verändert? Wie läuft es jetzt im Projekt? Was hat sich ereignet? Das ist das Ziel, und der Weg, der zwischen dem Problem und dem Ziel liegt - das ist die Aufgabe. Breites฀Methodenarsenal฀für฀Lösungen In der Praxis verfügen gut ausgebildete Coachs über Gesprächstechniken, um diese Erkenntnisse wachzukitzeln und dem Klienten zur Klarsicht zu verhelfen. Sie betrachten Probleme nicht nur als quälendes Hindernis, das Arbeitsenergie wie ein Staubsauger absorbiert. Probleme sind Hinweise darauf, sich weiterzuentwickeln, an sich zu arbeiten. Keine „Defizite“, nicht einmal ein Alarmsignal. Sondern Aufforderungen, „Denkzettel“ für eine Aufgabe. „Gewissermaßen sind diese Probleme Geschenke“, pointiert Ulrike Wikner die Perspektive. Drei Methoden bieten sich an, diese „Aufgaben“ zu lösen. Die systematisch-analytische Methode leitet an, Probleme umfassend auf bislang unentdeckte Lösungen hin zu betrachten. - Bei der intuitiv-kreativen Methode stellt der Coach ungewöhnliche, mitunter paradoxe Fragen. Er versucht, die Intuition des Klienten zu wecken und kreative Strategien für die Problemlösung zu entwickeln. Noch anders gehen Coachs mit der sinnlich-gestalterischen Methode vor: Beschäftigung mit Kunst oder gestalterisches Tun soll alle Sinne ansprechen. In der intuitiven Phase tritt das „ratlose“ logische Denken zurück. Die schöpferisch arbeitende Gehirnhälfte kommt zum Zuge und stößt mitunter Aha-Einsichten an, so, als hätten sie bislang nur unbewusst geschlummert. „Coachs gehen davon aus, dass ihre Klienten über alle Ressourcen verfügen, um ihre Probleme zu lösen“, fügt Ulrike Wikner an. Wie฀den฀Coach฀auswählen? Coaching setzt ein tiefes Vertrauensverhältnis zwischen Klient und Coach voraus. Hier muss der Bauch „sprechen“. Mit Zeugnissen und Referenzen lässt sich dies nicht abprüfen. Aber: Bei der Vorauswahl helfen die Unterlagen, um sich ein Bild von Kompetenz und Qualifikation des Coachs zu machen. Hier sollten Klienten die Messlatte hoch hängen. Vorsicht bei „Coachs“, die sich mit einem Bauchladen voller Arbeitsfelder zwischen Kinderpädagogik und philosophischer Beratung empfehlen. Spezialisierung ist wichtig! Ausbildung: Ein guter Coach weist eine abgeschlossene Coaching-Ausbildung nach. Mit regelmäßiger Weiterbildung hält er sich auf dem Laufenden. Zusätzlich begibt er sich in die so genannte Supervision durch Kollegen und arbeitet hier an seiner eigenen Weiterentwicklung. Branchenwissen: Gute Coachs haben sich auf Branchen oder Wirtschaftszweige spezialisiert. Zudem ist Spezialisierung auf bestimmte Personengruppen - Führungskräfte oder Frauen - sinnvoll. Für Projektmanager ist es wichtig, dass er Experte für Projektmanagement ist. Er sollte eine Projektmanagement-Ausbildung nachweisen, in Projekten gearbeitet haben und möglicherweise auch als Assessor Projekte bewerten können. Trainerwissen: Das „Expertencoaching“ verknüpft Coaching mit Expertenwissen. Hier lohnt es sich, nach Traningsnachweisen des Coachs zu fragen. So kann er beispielsweise dem Projektmanager Moderation als Hilfsmittel für Besprechungen empfehlen - und ihn zugleich in diese Technik einführen. Hilfreich dabei: Der Coach kann unter Umständen Widerstände gegen neue Techniken und Methoden abbauen und ihn Mut für die bislang abgelehnten Wege schöpfen lassen. Und wenn es nicht auf Anhieb „klappt“, wird der Coach ihn weiterhin betreuen, Teilerfolge würdigen und neue Fragen beantworten. Spezialisierung auf Coaching-Themen: Manche Coachs haben sich zusätzlich auf bestimmte Probleme festgelegt, beispielsweise Versagensängste oder Aufstiegsprobleme. Auch eine Spezialisierung auf bestimmte Methoden (NLP, Organisationsaufstellung) ist denkbar. Kommunizieren,฀steuern,฀delegieren,฀kontrollieren,฀präsentieren฀-฀Coaching฀hilft฀ Projektmanagern,฀die฀Führungsaufgaben฀besser฀zu฀bewältigen. Foto: ฀Nokia฀ 15฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Den฀Blick฀fest฀auf฀Lösungen So verwundert es kaum, dass viele Coaching-Sitzungen mit konkreten To-dos enden, um neue Wege auszuprobieren. Erfahrene Coachs arbeiten radikal lösungsorientiert. Ursachen für ein Verhalten spielen nur eine Rolle, wenn sie das Problem beheben helfen. Das Ziel des Coaching beschreibt Ulrike Wikner als Ergänzung der Handlungsoptionen: „Klienten sollen nach dem Coaching zwischen mehreren Wegen wählen können, ihre Aufgaben zu lösen.“ Dazu zähle der bislang beschrittene Weg und mindestens eine neue Option. Besser noch mehrere Möglichkeiten. Beispiel: Bei Projektbesprechungen fehlte es bislang an nötiger Arbeitsdisziplin. Über Wochen hat der Projektleiter die Zügel schleifen lassen. Jetzt wählt er zwischen zwei zusätzlichen Optionen - nämlich der Möglichkeit, dass sich das Team Regeln für ein Miteinander gibt oder er selbst einzelne Mitarbeiter machtvoll zur Raison ruft. Aus฀eingefahrenen฀Bahnen฀ausbrechen Erweiterung der Handlungsmöglichkeiten - auf diese abstrakt klingende Formulierung bringen denn auch viele Coachs das Ziel ihrer Arbeit. Die Coaching-Strategie eröffnet damit ein weites Feld. Doch auch hier sind die Grenzen schnell erreicht. So kann Coaching eine Psychotherapie nicht ersetzen oder beispielsweise nicht bei Alkoholproblemen helfen - auch wenn manche Manager das Coaching als verdeckte Analyse „missbrauchen“ wollen. Ulrike Wikner: „Coachs analysieren nicht die Ursachen der Probleme oder spüren nicht den Ursachen in der Kindheit oder Jugend nach.“ Sie sehen den Klienten als reife Person. Und eben dies müssen sie sein. „Anderenfalls empfehle ich therapeutische Hilfe“, meint Ulrike Wikner. Informationen für Coaching-Einsteiger und Coaching-Fachleute findet man auch im Internet-Portal www.coaching-magazin.de. Entspannt฀und฀aufs฀Projektziel฀gerichtet฀arbeiten฀-฀Coaching฀hilft฀auch,฀mit฀ blockierendem฀Stress฀bewusster฀umzugehen. Foto: ฀Siemens  16฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 GPM฀erwartet฀rund฀500฀Experten฀ zum฀Forum „20.฀Internationales฀Projektmanagement฀Forum฀2003“฀(14.฀bis฀17.฀Mai฀2003) Die฀Vorbereitungen฀laufen฀auf฀Hochtouren: ฀Vom฀14.฀bis฀17.฀Mai฀2003฀findet฀das฀„20.฀Internationale฀Deutsche฀Projektmanagement฀Forum฀2003“฀der฀GPM฀in฀Würzburg฀statt.฀Unter฀dem฀ Leitwort฀„Projektmanagement฀-฀Führungskonzept฀für฀die฀Zukunft“฀erwartet฀die฀GPM฀rund฀ 500฀Projektmanager,฀Vorstände,฀Führungskräfte฀und฀Projektmanagement-Nachwuchs.฀Mit฀ einem฀umfangreichen฀Programm฀aus฀hochwertigen฀Vorträgen,฀Präsentationen฀und฀Workshops฀will฀die฀GPM฀auf฀ihrem฀Forum฀den฀Fachaustausch฀und฀Wissenstransfer฀zwischen฀ Experten฀aus฀Industrie,฀Verwaltung฀und฀Wissenschaft฀fördern.฀So฀werden฀die฀Fachleute฀ Trends฀und฀Zukunftschancen฀im฀Projektmanagement฀erörtern฀sowie฀neue฀und฀bewährte฀ Methoden฀und฀Werkzeuge฀vorstellen฀und฀diskutieren.฀ G PM-Vorstand und Projektleiter Otto Zieglmeier spricht derzeit mit renommierten Keynote-Speakern. „Sie werden die besondere Bedeutung des Projektmanagements als ganzheitliches Konzept für Führung und Management unterstreichen“, erklärt er. Als Höhepunkt des Forums gilt der Award-Gala-Abend am 15. Mai 2003, auf dem der „IPMA International Project Management Award“ verliehen wird (weitere Informationen zum Award unter www.pm-award.de). Zudem steht die Verleihung des „Deutschen Hochschul-Studienpreis Projektmanagement“ am 14. Mai 2003 auf dem Programm, der im Rahmen des Programms „Wissenschaft und Jugend“ (Young Crew) vergeben wird. Ein Empfang in der Kellerhalle der historischen Würzburger Feste Marienberg rundet den Kongress ab. Fachlich setzt das Programmkomitee Schwerpunkte bei Multiprojektmanagement, Projektmanagement in der Unternehmensstrategie, Soziale Kompetenz von Projektpersonal mit Modellen zu Beurteilung und Entwicklung der Kompetenz sowie Karriere im Projektmanagement. Auch Projektbenchmarking, Projektmarketing, Wissensmanagement in Projekten und Projektmanagement bei Fusionsprojekten. Zudem stellen sich auf einer gesonderten Ausstellung Projektmanagement- Dienstleister vor. So plant das Programmkomitee eine Ausstellungsfläche von rund 400 Quadratmetern direkt vor der Haupthalle. „Wir arbeiten am Programm und laden Referenten sowie Aussteller herzlich zur Teilnahme ein“, erklärt Otto Zieglmeier. Dem Programm-Komitee haben sich in diesem Jahr angeschlossen: Prof. Dr. Heinz Schelle (Chairman), Gilles Caupin, Alan Harpham, Prof. Dr. Nino Grau, Dr. Dietmar Lange, Roland Ottmann, Prof. Dr. Siegfried Seibert und Otto Zieglmeier. 17฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Oscar-reif: ฀„…฀and฀the฀winner฀is“ Eine Award-Gala wie sie von Oscarverleihungen bekannt ist: Mit einem „... and the winner is“ wird auf dem „20. Internationalen Projektmanagement Forum 2003“ (14. bis 17. Mai 2003 in Würzburg) der „IPMA International Project Management Award“ für exzellente Projektleistungen verliehen, der begehrte „Projektmanagement-Oscar“ von GPM und IPMA. Derzeit bereiten sich internationale Teams auf den Wettbewerb um Spitzenleistungen im Projektmanagement vor. Am 15. Mai 2003 wird die Jury die Spannung auf dem Forum in Würzburg lösen (Informationen zum Forum unter www.pm-forum03.de). Bereits ausgebildet sind die Assessoren für die diesjährige Awardrunde. 44 Assessoren aus dreizehn Nationen haben sich speziell schulen und trainieren lassen. Mit den Ergebnissen zeigten sich die Trainer (Professor Dr. Nino Grau, Dr. Martina Huemann [Österreich], Alan Harpham [UK], Dr. Olaf Pannenbäcker und Otto Zieglmeier) hochzufrieden. Sie signalisierten bereits im November: Die nächste Runde kann starten. Bewerbungen liegen bereits vor, nach dem Abgabetermin am 6. Januar haben die Assessoren ihre Arbeit aufgenommen. Der Oscar der GPM hat seit 1997 international einen hervorragenden Ruf erworben. Bis 2000 verlieh die GPM ihn als „Deutscher PM Award“, danach als „Internationaler Deutscher PM Award“, seit dem 16. IPMA World Congress on Project Management als „IPMA International PM Award“. Weitere Informationen: www.pm-award.de sowie www.pm-forum03.de. Interessenten können über pm-award@gpm-ipma.de Kontakt mit dem PM Award-Office aufnehmen. Weitere Informationen: www.pm-forum03.de sowie www.pm-award.de. Kontakt zu Projektleiter Otto Zieglmeier unter pmforum03@gpm-ipma.de oder unter Tel. 09123/ 987975.  18฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN IT-Projektmanagement฀in฀der฀ modernen฀Softwareentwicklung Karsten฀Hoffmann Die฀SW-Entwicklung฀nach฀dem฀Wasserfall-Modell฀basiert฀auf฀klaren฀Festlegungen฀zum฀ Projektablauf฀und฀zu฀der฀zu฀schaffenden฀Funktionalität.฀Sie฀birgt฀in฀der฀Regel฀jedoch฀höhere฀ Risiken,฀ist฀unbeweglicher฀und฀ergibt฀nicht฀selten฀eine฀unbefriedigende฀Produktqualität. Mit฀dem฀Spiralmodell฀und฀dessen฀erfolgreicher฀Umsetzung฀in฀zahlreichen฀Projekten฀steht฀ ein฀agilerer฀SW-Entwicklungsprozess฀zur฀Verfügung.฀Dieser฀kommt฀der฀objektorientierten฀ Vorgehensweise฀sehr฀entgegen฀(Generalisierung฀-฀Spezialisierung).฀Richtig฀angewandt฀ hilft฀eine฀solche฀Vorgehensweise,฀technische฀und฀kaufmännische฀Risiken฀zu฀vermindern.฀ Außerdem฀ermöglicht฀sie฀eine฀höhere฀Flexibilität฀hinsichtlich฀kurzfristiger฀Änderungen,฀ ein฀einfacheres฀Qualitätsmanagement,฀ein฀leichteres฀Controlling฀und฀eine฀gleichmäßigere฀ Auslastung.฀Risiken฀bestehen฀hier฀hinsichtlich฀klarer฀Festlegungen฀und฀eines฀damit฀verbundenen฀eindeutigen฀Vertragsmodells฀(Festpreis). Auch฀wenn฀sich฀in฀den฀praktisch฀etablierten฀Entwicklungsprozessen฀Elemente฀beider฀ Basismodelle฀kombinieren,฀verlangen฀heutige฀Anforderungen฀die฀stärkere฀Berücksichtigung฀des฀iterativen฀Moments฀und฀ein฀entsprechend฀gestaltetes฀IT-Projektmanagement. Typische฀Probleme฀bei฀heutigen฀IT-Projekten Entwicklungsprojekte im IT-Bereich gibt es seit Jahrzehnten, seit über 20 Jahren werden sie durch systematische Projektmanagement-Methoden begleitet. Dennoch leiden viele, insbesondere größere IT-Projekte immer wieder an bekannten „Krankheiten“:  Die Kosten für die Projektdurchführung werden höher als geplant. Insbesondere in den letzten Phasen Realisierung und Test treten plötzlich deutlich höhere Aufwände zutage.  Der Fertigstellungstermin wird überzogen. Im günstigeren Fall betrifft dies nur firmeninterne Abläufe, die nun erst später mit Hilfe des neuen Systems abgewickelt werden können, im ungünstigen Fall gehen durch die spätere Inbetriebnahme Kundenumsätze verloren oder es drohen sogar Vertragsstrafen.  Die erstellte Software hat nicht die gewünschte Qualität. Dies äußert sich z. B. in (zu) hohen Fehlerraten, der Instabilität des Systems, wenig benutzerfreundlichem Dialogverhalten oder auch in einer nicht akzeptablen Performance. Ein anderes Problem ist die oft inaktuelle Funktionalität: Die Software enthält Funktionen, die so gar nicht mehr benötigt werden, es fehlen aber Funktionalitäten, deren Anforderung sich erst im letzten halben Jahr ergeben hat.  Das fertige IT-System bedarf höherer Aufwände für Administration und Pflege als zunächst erwartet. Die Übernahme des Systems in einen normalen „Tagesbetrieb“ gelingt oft nicht ohne markante zusätzliche Betreuungsaufwände in einer Übergangsphase. Insgesamt sind die Beteiligten oft nicht glücklich mit dem erzielten Resultat. Die Fachabteilung des Auftraggebers ist enttäuscht, da sie nicht das bekommen hat, was sie längst erwartet hatte, die Geldgeber streiten mit dem Auftragnehmer um die Schuld für Zusatzkosten, der Auftragnehmer selbst hat wieder mal „draufgezahlt“. In noch schlimmeren Fällen kommt das neue System gar nicht zum Einsatz, nach langem Streit haben nur noch die Juristen das Sagen, der Projektleiter wird entlassen, ein „Sanierer“ versucht vielleicht noch zu retten, was zu retten ist, Millionenbeträge müssen einfach abgeschrieben werden. Durch solche und ähnliche Erfahrungen verfestigt sich beim Management der Eindruck, IT-Projekte seien teuer und lohnen sich nicht. Zukünftige Projekte werden nur noch genehmigt, wenn ein früher Return on Investment überzeugend nachgewiesen werden kann. Aber auch die Gründe für die typischen Probleme insbesondere umfangreicher IT-Projekte sind vielen bekannt. So ist es in einem Projekt mit neuer Technologie und neuen Partnern sehr schwer, die Aufwände bereits zu Beginn genau abzuschätzen; technische Risiken werden oft erst (zu) spät erkannt; QS-Maßnahmen werden nur solange sauber eingehalten, solange das Budget noch im Lot ist - beim ersten Zeitverzug oder bei Stundendefiziten wird oft als Erstes bei den QS-Maßnahmen eingespart, oft werden die Anwender auch zu wenig einbezogen; zur Erhöhung der Aktualität der Anforderungen wird zwar oft ein Change-Request- Verfahren etabliert, doch dieses soll nur in Ausnahmen benutzt werden, da es ja zusätzliche Kosten verursacht; die Administrationsaufwände sind in ihrem Umfang erst zu erkennen, wenn das neue System (zumindest in einer ersten Version) vorliegt. Viele der genannten Schwächen resultieren aus der für die Software-Entwicklung gewählten Vorgehensweise, die das Auftreten o. g. „Krankheiten“ sehr wahrscheinlich werden lässt. Stattdessen bedarf es eines Soft- 19฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 ware-Entwicklungsmodells, das in kurzen Zeiträumen Gestalt, Kosten, Aufwände, Risiken etc. sichtbar und abschätzbar werden lässt - ein iteratives Entwicklungsmodell. Klassische฀Vorgehensweise: ฀Das฀Wasserfallmodell Firmen, die Software entwickeln (gleich, ob die IT-Abteilung eines großen Anwenders oder ein Systemhaus), haben sich meist dafür ein Regelwerk geschaffen, in dem u. a. das Vorgehensmodell festgelegt und beschrieben ist. Abb. 1 zeigt ein solches Phasenmodell, bei dem die Entwicklung des IT-Systems nacheinander die sechs beschriebenen Phasen Vorstudie, Grobkonzeption, Feinkonzeption, DV-Konzeption, Realisierung und Test sowie Einführung durchläuft. In jeder Phase werden bestimmte Ergebnistypen erarbeitet, die zur Grundlage der Begutachtung und Bewertung am Ende der Phase herangezogen werden (dies bildet meistens einen Meilenstein). Bei Mängeln hinsichtlich Vollständigkeit der Ergebnistypen oder auch deren Qualität wird gegebenenfalls eine Nacharbeit verlangt. Erfolgt die Freigabe für die nächste Phase, so bilden die erarbeiteten Ergebnisse den Input für die nächste Phase. Dieses Phasenmodell wird deshalb auch „Wasserfall-Modell“ genannt, da die Ergebnisse jeder Phase den Input für die nächste Phase ergeben. Abhängig von der Projektgröße und dem eingesetzten Personal kann der „Durchlauf“ des gesamten Wasserfalls zwar manchmal auch nur einige Monate dauern, bei Projekten > 1 Mio. EUR liegt er in den meisten Fällen jedoch deutlich über einem Jahr. Charakteristika฀des฀Wasserfallmodells Wichtigstes Merkmal des Wasserfall-Modells ist es, im Feinkonzept - dies umfasst u. a. das Daten- und Funktionsmodell - alle fachlichen Details des zu realisieren- Abb.฀1: ฀Firmenbeispiel: ฀Phasen฀in฀der฀strukturierten฀Systementwicklung 20฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN den Systems exakt festzulegen. Diese Festlegung bildet eine eindeutige Bezugsbasis für die Realisierung, für den Test („Test erfolgt gegen die Feinspezifikation“), für die Abnahme und die Gewährleistung. Häufig ist die Feinspezifikation auch Vertragsgrundlage für die zu einem Festpreis zu erbringende Leistung - dabei sind unterschiedlichste Bezeichnungen möglich, vom Pflichtenheft über die Leistungsbeschreibung bis zum Soll- oder Feinkonzept. Diese eindeutige Festlegung kann in vielen IT-Projekten ein deutlicher Vorteil sein. Der Vorteil der klaren Festlegung für das zu realisierende System kann aber auch zum Nachteil werden: Die Fachabteilung muss sich zum Zeitpunkt der Erstellung der Feinspezifikation eindeutig festlegen. Dies bedeutet auch, dass der vorgesehene Umfang des gesamten Projektes mit der Erarbeitung des Feinkonzepts festgelegt werden muss. Dauert die Umsetzung des Feinkonzepts bis zum realen Einsatz z. B. ein Jahr, so sind die Festlegungen dafür also entsprechend früh vorzunehmen. Es wird meist ein so genanntes Change-Request-Verfahren etabliert, durch das spätere Änderungen noch in den Systemumfang aufgenommen werden können, was jedoch in der Regel Mehraufwände zur Folge hat. Ist die Menge der Änderungen groß, so wird es schwer, entsprechende Nacharbeiten (möglichst) sauber in das Feinkonzept einzubetten, entsprechend sind die DV- Umsetzung, die Realisierungsarbeiten, die Testpläne etc. zu verändern. Bei einigen Projekten führt dies zu deutlichen Verzögerungen, da ein Teil des Teams statt in der Programmierung nun wieder in konzeptioneller Arbeit gebunden ist. Ein weiteres Merkmal in vielen Entwicklungsrichtlinien nach dem Wasserfallmodell ist, dass die Art der DV-Umsetzung erst mit dem Ende des Feinkonzepts festgelegt wird. Der Vorteil dieser Vorgehensweise liegt darin, dass die zu diesem Zeitpunkt aktuellen Versionen von Werkzeugen, Middleware oder anderer System-Software benutzt werden können. Eine frühere Festlegung hätte stattdessen möglicherweise ein Nachrüsten (Update, neues Produkt etc.) zur Folge. Auf der anderen Seite besteht die Gefahr, dass Mängel in der gewünschten IT-Umgebung erst zu diesem späten Zeitpunkt erkannt werden; dieses stellt bei manchen Projekten ein erhebliches Risiko dar. Ein weiterer Nachteil dieser Vorgehensweise ist, dass die mit einer Plattform verbundenen technologischen Möglichkeiten keinen Niederschlag in der Spezifikation von Anwendungsdetails finden. Manche Funktionalität ist mit bestimmten Plattformen „leicht“ zu haben, sprich mit wenig Aufwand zu realisieren. Um die genannten Nachteile zu vermeiden, werden in vielen Projekten Prototypen entwickelt. Durch richtige Prototyp-Definition („vertikaler Prototyp“) gelingt es, die technischen Bedingungen der neuen IT-Plattform auszuprobieren und damit eventuelle Probleme frühzeitig zu entdecken. Durch so genannte Oberflächen-Prototypen kann die Fachabteilung oft leichter erkennen, welche Möglichkeiten das vorgesehene IT-System in seinen Bearbeitungsmasken bietet. Dies hilft, wirtschaftlich effektive Formen der Realisierung für angedachte Funktionalitäten zu erkennen und zu finden. Bleibt die Frage, ob die entwickelten Prototypen in die zukünftige Realisierung des Systems Eingang finden, und falls nicht, wer die durch Prototyp-Erstellung entstehenden Mehraufwände trägt (der Auftraggeber verlangt dies im Falle technischer Prototypen oft vom Auftragnehmer, da dieser für die gewählte Systemarchitektur in der Regel verantwortlich ist). Für die Softwareentwicklung nach dem Wasserfallmodell lassen sich einige weitere Nachteile benennen:  Die erste Hälfte der Entwicklungsarbeiten konzentriert sich fast ausschließlich auf Dokumente. Feinkonzepte von 500 oder gar 1.000 Seiten werden von Fachabteilungen aber nicht immer mit großer Sorgfalt gelesen. Dagegen würde eine frühe erste Version „zum Anfassen“ den Beteiligten der Fachabteilung nicht nur zeigen, wie das neue System etwa aussehen wird, es würde - gerade bei ersten erkannten Mängeln - auch die Sinne für die genauen Formulierungen im Feinkonzept schärfen.  Mängel auf Grund einer falschen Spezifikation, auch solche grundsätzlicher Art, werden oft erst in der Testphase (am Ende der Realisierung) entdeckt. Eine frühe „erste Version“ macht dies in der Regel sichtbar.  Der Erarbeitungsprozess in jeder der sechs beschriebenen Phasen wird nur jeweils einmal durchlaufen. Dadurch entsteht wenig Prozesssicherheit und, da erste Erarbeitungen fast immer lückenhaft sind, auch eine geringere Produktqualität. Dies gilt insbesondere für Teams, in denen auch weniger erfahrene Systementwickler sitzen, und für Projekte, die mit neuen Technologien arbeiten.  Die durch das Wasserfallprinzip erzwungene zeitliche Verteilung der Projektarbeit über die sechs Phasen macht es schwerer, Teams für bestimmte Tätigkeiten (z. B. Programmierer, Testteams, Konzeptersteller) gleichmäßig auszulasten. Auch ist eine „Parallelisierung“ ihrer Tätigkeiten kaum möglich.  Die Integration des neuen IT-Systems in eine bestehende Umgebung geschieht häufig erst ganz am Schluss. Eine frühere Integration wird auch deshalb gescheut, weil neben der Vermeidung von Mehraufwänden die Fehlerbeseitigung innerhalb des eigenen Systems im Vordergrund steht. Dadurch kommt es am Ende häufig zu einer so genannten „Big-Bang-Integration“, die nicht selten Abb.฀2: ฀Wasserfall-Modell ������� ������ �������������� ���� ������� ����� Ergebnisse Pflichtenheft Daten- und Funktionsmodell Programme ausgetestete Programme System in Betrieb Vorstudie 21฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 mit großen Rückschlägen zu kämpfen hat. Dies, da sich zum Beispiel zeigt, dass die vereinbarten Schnittstellen von Nachbarsystemen nicht der Zusage entsprechen, die Kommunikation zwischen den Systemen gestört ist und vieles andere mehr.  Da jede Phase nur einmal durchlaufen wurde, wird nicht gelernt, mit Änderungen umzugehen. So werden Änderungsanforderungen oft nur lückenhaft in alle bestehenden Ergebnistypen eingepflegt. Das Arbeiten mit Erweiterungen und Veränderungen wurde nicht oder nur wenig „geübt“. Insgesamt ist das „Re-Engineering“ kaum gelernt worden, so dass im Ergebnis eine Software entstanden ist, die schwer zu warten und zu pflegen sein wird. Durch Prototyping, frühe Testintegrationen, erweiterte QS-Maßnahmen, gut ausgebildete Projektteams und einige andere Maßnahmen können o. g. Schwächen teilweise kompensiert werden. Es sollte jedoch deutlich geworden sein, dass diese Defizite viel mit dem Prinzip des Wasserfallmodells zu tun haben, also durch das Modell immanent gegeben sind. Zur฀objektorientierten฀Entwicklung฀passt฀das฀Spiralmodell Seit Ende der 80er Jahre haben sich objektorientierte Methoden zur Softwareproduktion entwickelt und verbreitet. Mitte der 90er wurde aus der Vielfalt unterschiedlicher OO-Methoden durch die Unified Modelling Language (UML) eine einheitliche Plattform geschaffen, die sich inzwischen als Quasi-Standard in der objektorientierten Softwareentwicklung etabliert hat. Das Prozessmodell in der Objektorientierung ist in der Regel ein anderes als in der so genannten strukturierten Programmierung: Kern des Prozesses von objektorientierter Analyse und Design sind das Auffinden und Definieren von Objektklassen, in denen die gewünschten Daten und Funktionalitäten enthalten sind. Dieser Prozess der Klassenmodellierung wird immer wieder durchlaufen, wobei sich der Fokus der Untersuchung allmählich vom Groben („Generalisierung“) zum Feinen („Spezialisierung“) verlagert. Auf diese Weise wird eine immer weiter gehende Klassenbibliothek aufgebaut, die als Kern des zu schaffenden DV-Systems das wichtigste Ergebnis des Entwicklungsprozesses darstellt. Aus diesem Grund passt das Wasserfallmodell nicht sonderlich gut zur objektorientierten Software-Entwicklung. Stattdessen wurde das so genannte Spiralmodell als neues Prozessmodell zur SW-Entwicklung „erfunden“ [1]. Beim Vorgehen nach dem Spiralmodell entstehen in regelmäßigen Abständen nacheinander neue Versionen des zu erstellenden DV-Systems. Dazu werden jeweils insgesamt vier Phasen (Analyse, Design, Konstruktion und Test) durchlaufen, so dass am Ende der Testphase jeweils eine neue Version des zu erstellenden Systems zur Verfügung steht. Abb.฀3: ฀Objektorientierte฀SW-Entwicklung 22฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN Charakteristika฀des฀Spiralmodells Bei Entwicklung nach dem Spiralmodell wird mit den wichtigsten Geschäftsobjekten und Geschäftsvorfällen begonnen. Das Zentrum der Spirale soll im fachlichen Kern des neuen DV-Systems angesetzt sein. Nach Analyse der wichtigsten Geschäftsvorfälle (in Form so genannter „Use Cases“) werden durch das OO-Design die zugehörigen Fachobjekte definiert. Die Konstruktionsphase umfasst das Programmieren der entsprechenden Klassen, die schließlich in der Testphase einem ausführlichen Anwendungstest unterzogen werden. Auf diese Weise entsteht mit der ersten Version eine „kleine Ausgabe“ des neuen DV-Systems, und auch die Fachabteilung und die zukünftigen Anwender können durch diese Version einen frühen Eindruck dessen gewinnen, was das fertige System in etwa zu bieten hat. So lässt sich eine bessere Kommunikation mit der Fachabteilung bzw. den Endkunden erreichen und alle Beteiligten erhalten dadurch einen konkreten Bezug zu fachlichen oder auch technischen Fragestellungen. Dies hilft, Missverständnisse hinsichtlich Begriffen, technischen Gegebenheiten, Vorstellungen etc. drastisch zu reduzieren. Wird mit den wichtigsten Prozessen und Objekten begonnen, so kommt eine solche Vorgehensweise auch der 80: 20-Regel entgegen, die viele Systementwickler kennen: 80 % der mit dem DV-System zu erledigenden Aufgaben werden durch Funktionen abgedeckt, die mit etwa 20 % der Aufwände für die Systemerstellung verwirklicht werden. Für die restlichen 20 % der Funktionen (zumeist Spezialfälle, die selten zum Tragen kommen) werden dagegen 80 % der Aufwände benötigt. Ziel des Spiralmodells ist es also, das neue DV-System zu entwickeln durch Schaffung mehrerer Versionen, die aufeinander aufbauen. Auf diese Weise wird jede einzelne Phase des SW-Entwicklungsprozesses schon sehr früh zum ersten Mal durchlaufen, und alle Beteiligten gewinnen eine größere Sicherheit sowohl hinsichtlich möglicher technischer Probleme als auch hinsichtlich der tatsächlichen Form des späteren DV-Systems. Für die Strukturierung dieses kontinuierlichen Aufbauprozesses spielen die einzelnen Versionen als „große“ Meilensteine eine wesentliche Rolle. Die Planung und Vorgehensweise innerhalb einer einzelnen Version entsprechen im Wesentlichen dem Wasserfallmodell, oft eben angepasst an die Randbedingungen der objektorientierten Softwareentwicklung (z. B. vier statt sechs Phasen, wie oben beschrieben). Die Entwicklung in Versionsschritten bedeutet auch, dass für eine Version Ergebnisse der Vorversion wiederverwendet, erweitert und gegebenenfalls auch verändert werden. Die Erweiterung eines Zwischenprodukts erhöht die Prozesssicherheit, denn die Beteiligten wissen bei einer zweiten oder dritten Version besser, was wie beschrieben werden muss und auf welche Ergebnisse zum Beispiel besonderer Wert gelegt wird. Dies führt insgesamt zu einer besseren Ergebnisqualität. Durch dieses Vorgehen finden auch Veränderungen an bereits erarbeiteten Zwischenprodukten leichter Eingang in den Entwicklungszyklus. Jedoch ist zu beachten, dass auch bei einer zyklischen, iterativen Entwicklung Änderungen Mehraufwände erzeugen, wenn auch in geringerer Höhe als beim Wasserfallmodell. Die Weiterarbeit an Zwischenprodukten führt insgesamt zu einer höheren Kompetenz des Re-Engineerings, die für die Wartung und Pflege eines „lebendigen“ DV-Systems unbedingt vorhanden sein muss. Die Software, die auf diese Weise entwickelt wird, wächst also mit jeder neuen Version in ihrem Umfang. Bei der Definition von Versionen bzw. Versionsumfängen werden neben technischen Aspekten insbesondere Einsatzaspekte berücksichtigt. So kann eine frühe Version zu Demonstrations- und Schulungszwecken eingesetzt werden. Versionen, in denen alle dafür wichtigen Teilfunktionalitäten umgesetzt sind, können für einen Pilotbetrieb oder für einen eingeschränkten Kundenkreis bereits eingesetzt werden usw. Aufwändige Funktionalitäten für Spezialfälle werden meistens erst mit höheren Versionen verwirklicht. Ob deren Verwirklichung sich wirklich lohnt, kann im Lichte des Nutzens von frühen Versionen viel besser entschieden werden. Hier hat das Management also auch die Chance, die Entwicklung bei einer bestimmten Version X erstmal zu stoppen - ein Verfahren, das beim reinen Wasserfallmodell nicht denkbar ist. Auch ein „Design to Cost“ ist beim Spiralmodell viel eher möglich, da die Risiken und zu erwartenden Aufwände nach spätestens zwei oder drei Versionen viel genauer abgeschätzt werden können. Abschließend die Zusammenstellung wichtiger Vorteile des Spiralmodells:  Jede Phase des Entwicklungsprozesses wird früh zum ersten Mal ausprobiert. Dies hilft, technische Mängel von verwendeten Produkten, mangelndes Knowhow u. Ä. früh zu erkennen, und bietet so frühe Korrekturmöglichkeiten. Die wiederholten Entwicklungsschritte verbessern die Prozess- und damit die Produktqualität.  Das frühe Vorliegen von Zwischenprodukten des Entwicklungsprozesses erlaubt frühzeitige und zeitnahe QS-Maßnahmen. Ein kontinuierliches QS- Management lässt sich bei diesem Verfahren auf einfache Weise implementieren (die hohen Aufwände für das oft monatelange Testen des Systems nach einer ������� ������� ��������������� ��������������� ��������� ��������� ���������� ���������� ����� ��� � ��������� ��������� ������� Abb.฀4: ฀Spiralmodell 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Gesamterstellung können damit drastisch reduziert werden).  Eine erste Version steht früh zur Verfügung. Das frühe Zeigen von ersten Ergebnissen hilft, die Kommunikation mit dem Endkunden zu verbessern, Missverständnisse auszuräumen und technische Risiken frühzeitig abzuschätzen.  Tiefere Funktionalitäten für Sonderfälle lassen sich später klären. Dies gibt den Fachabteilungen mehr Zeit zur Klärung, den Entwicklern mehr Sicherheit und dem Management die Chance, über das JA oder NEIN zu speziellen Funktionalitäten erst später zu entscheiden. Die Möglichkeit zu späteren Erweiterungen erleichtert im Übrigen auch der Fachabteilung die Freigabe bzw. Abnahme von frühen Versionen!  Ergänzungs- und Änderungswünsche lassen sich auf effizientere Art einbringen. Dies vergrößert die Chancen, zeitnah das zu implementieren, was die Anwender wirklich brauchen.  Der gesamte Entwicklungsprozess lässt sich besser steuern. Verschiedene Entwicklergruppen (Konzeptionierer, Programmierer, Testteams) können gleichmäßiger ausgelastet werden. Über die Versionsplanung werden frühe Teileinsätze, die Beschleunigung der Entwicklung durch Übereinanderschieben von Versionen oder auch die Streckung von Aufwänden eher ermöglicht. Durch die Elemente des Spiralmodells lässt sich insgesamt ein agilerer Entwicklungsprozess definieren, der den häufigen Änderungsanforderungen in einer schnelllebigeren Welt eher genügen kann. Prozessorganisation฀mit฀dem฀Spiralmodell Es gibt viele Möglichkeiten, das Spiralmodell in die praktische Arbeit umzusetzen. Eine der Möglichkeiten ist in Abb. 5 gezeigt. Der vorangestellte Zyklus 0 dient dazu, eine frühe Vorstellung des neuen IT-Systems zu erhalten. Diese Basis kann auch durch ein bereits bestehendes System oder ein Versuchsprojekt (Vorprojekt) als Vorbild gebildet werden. Der Zyklus 0 ist optional; ist er nicht vorgesehen, muss sehr früh ein Architektur- Prototyp o. Ä. definiert und erarbeitet werden. Denn die im ersten Zyklus zu erarbeitenden Use Cases orientieren sich in der Regel an der Basis-Architektur des zu schaffenden IT-Systems (d. h., die Art der zu definierenden Use Cases steht in einer gewissen Abhängigkeit von der Basis-Architektur). Es ist wichtig, in dieser frühen Phase ggf. die Unterstützung von erfahrenen IT-Architekten zu suchen. Diese wird insbesondere zur Schaffung eines ersten zufrieden stellenden Beispiels benötigt. Die Länge der Zyklen ist u. a. von der Projektgröße abhängig; je kleiner der vorgesehene Gesamtumfang ist, umso kürzer sollten auch die Zyklen sein. Als Anhaltspunkt seien zwei Beispielprojekte (jeweils knapp 1 Mio. EUR) genannt, bei denen mit Zykluslängen von etwa 3 Monaten gute Erfahrungen gemacht wurden. Jedoch kann die zu wählende Zykluslänge von zahlreichen weiteren Faktoren abhängen. Nach dem Prinzip der rollierenden Planung werden innerhalb eines Zyklus - also einer Version - die einzelnen Aufgaben (bzw. die damit verbundenen Arbeitspakete) genau durchgeplant. Jedes Unternehmen (bzw. jede Entwicklungsabteilung innerhalb eines Unternehmens), das Softwareentwicklung nach dem Spiralmodell betreibt, entwickelt erfahrungsgemäß eine eigene Ausgestaltung des dabei benutzten Entwicklungsprozesses. 1995 wurde UML als standardisierte Methode von objektorientierter Analyse und Design ������� ����������� ������� ���������� �������� � ������������������ ������������������� ������ ����������������� ������������������ ������� ������� � ��������� ���������������� ������� ���������� �������������������� ����������� ���������������� ����������������� ��������������� �������� ������ ������������� ����������� �������� ������������� ������� ������� ������������������ ������������ ������������ ������� ������ ������� ������ ������������������������������������� ������������������������������� �������� ���������� ���������������������� �������� ��� ������������� ���������� ���������� � � � � � � � � � � � � � � � � � � � � Abb.฀5: ฀Organisation฀des฀SW-Entwicklungsprozesses฀in฀Zyklen 24฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN entwickelt und - verbunden mit Gründung der Fa. Rational - mit dem Werkzeug Rational Rose auf den Markt gebracht. Erst 1999 wurde endlich auch ein entsprechendes Prozessmodell publiziert, der Rational Unified Process (siehe Abb. 6) [2], [4]. In diesem Prozessmodell werden sechs so genannte Kern-Workflows definiert, mit deren Hilfe das neu zu schaffende IT-System entwickelt werden soll (GP-Modellierung, Anforderungsanalyse, Design, Implementierung, Test und Auslieferung). Zusätzlich werden drei unterstützende Workflows definiert, u. a. Konfigurationsmanagement und Projektleitung. Die über die horizontale Achse aufgetragenen Iterationen (Versionen) werden in vier Phasen aufgeteilt (Definition, Entwurf, Konstruktion, Einführung), bei denen die Phasenbezeichnung das Hauptgewicht der Arbeit der jeweiligen Version ausdrücken soll. Die Kurven zu jedem Workflow stellen die jeweiligen Aufwände dar. Bei genauer Betrachtung ist zu erkennen, dass der Buckel der größten Aktivität im Vergleich der sechs Workflows allmählich von links nach rechts wandert. In dieser Verlagerung der jeweiligen Hauptaktivität von der GP-Modellierung in der ersten Phase bis zur Auslieferung in der letzten Phase ist die „Spur“ des Wasserfallmodells zu erkennen. Der Unified Process zeigt - im Unterschied zum reinen Wasserfallmodell - klar an, dass schon mit der ersten Version auch mit Realisierungsarbeiten begonnen wird. Bleibt kritisch anzumerken, dass der Autor die Aktivitätskurve im unterstützenden Workflow „Projektleitung“ anders sieht als im Beispiel angedeutet (nämlich eher gleichmäßig verteilt als gezackt). In der Praxis hat sich in vielen Unternehmen ein Software-Entwicklungsprozess (mehr oder minder klar) herauskristallisiert, der meistens Elemente des Spiralmodells mit Elementen des Wasserfallmodells kombiniert [3]. So ist das V-Modell eine Weiterentwicklung des Wasserfallmodells unter Hinzunahme iterativer Elemente. Ist eine Auswahl oder Modifizierung möglich, so sollte abhängig von der Projektaufgabe das eine oder andere Moment (Wasserfall oder Spirale) stärker betont werden. Beispiel 1: Auftragsprojekt (Festpreis) für eine einmalige Entwicklung mit klassischer Programmiersprache, gleiche Basisarchitektur wie ein ähnliches Projekt, das als Beispiel vorliegt, ausführliches Pflichtenheft liegt vor, keine Änderungen und keine Weiterentwicklung vorgesehen  Betonung Wasserfall. Beispiel 2: Entwicklungsprojekt (gemeinsam) einer neuen Anwendung mit objektorientierter Entwicklung wie z. B. Java, Zielarchitektur noch offen, genaue fachliche Beschreibung fehlt noch, Weiterentwicklung ist auf jeden Fall vorgesehen  Betonung Spiralmodell. Managementaufgaben฀bei฀der฀SW-Entwicklung Im Folgenden werden einzelne Managementaspekte bei der Softwareentwicklung beleuchtet, die insbesondere unter Verwendung des Spiralmodells Geltung haben. Projektplanung฀und฀Ressourcen-Management Die wichtigsten Meilensteine im zeitlichen Ablauf sind die Versionen. Es ist darauf zu achten, trotz solider Entwicklungsarbeit möglichst früh eine erste Version zu erreichen („keine Angst vor Lücken oder Fehlern“). Die folgenden Versionen sollten etwa gleiche Umfänge haben, da dies der gleichmäßigen Auslastung des Teams, der Prozess- und Terminsicherheit jedes Einzelnen und dem einfacheren Controlling entgegenkommt. Ein wichtiger Aspekt der Strukturierung insbesondere größerer Projekte ist die „intelligente Bildung“ von Komponenten. Unter Komponenten werden in diesem Zusammenhang eigenständige Teilsysteme verstanden, die alleine testbar und lauffähig sind. Für jede Komponente sind sowohl die von ihr benötigten als auch die von ihr gebotenen Dienstleistungs-Schnittstellen exakt festzulegen - diese Festlegungen haben quasi Vertrags- Abb.฀6: ฀Rational฀Unified฀Process฀(RUP)฀als฀Beispiel฀für฀ein฀spiralförmiges฀Prozessmodell ������ ���� ����������� ���������� ������� ������������ ���������� ������ ��������������� ������������� �������������� ��������������� ���� ������������ ������������������ ���������� �������������� �������������� ���������� �������������� ��������� ������������� ��������� ��������� ��������� ���������� ��������� �������������� ������� �������������� ���������� ��������� �������������� ������� �������������� ������ ��� ��������� � ����������������� ������ ��� ��������� � ����������������� ����������������������� ��������������������� ����������������������� ��������������������� ������� ���������� ���������������������� ��� ���������� ������� ���������� ���������������������� ��� ���������� ���������������� ��������������� ������������������� ����� ������ ���������������� ��������������� ������������������� ����������� 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 charakter. Die „richtige“ Komponentenbildung ist eine Aufgabe für erfahrene IT-Architekten - von einer weiteren Erörterung dieses wichtigen Problems wird hier jedoch abgesehen. Einem Entwicklungsauftrag liegt entweder bereits ein vorgesehenes, festes Budget zugrunde oder es ist früh festzulegen, welches Budget benötigt werden wird und welche Leistung dafür zu erwarten ist. Oft wird ein Gesamtbudget - gegebenenfalls für einen ersten Entwicklungsabschnitt - festgelegt, mit dem ein bestimmter Funktionsumfang in einer bestimmten Zahl von Versionen realisiert werden soll. Für die Feinplanung der Versionen ist hinsichtlich Termintreue meist der Grundsatz „Termin vor Funktionsumfang“ etabliert. Dies bedeutet, dass der Fertigstellungstermin einer Version auf jeden Fall eingehalten werden sollte, notfalls an der Funktionalität kleine Abstriche gemacht werden. Die Verpflichtung zu unbedingt notwendigen Funktionen kann durch Festlegung von MUSS-Funktionalitäten erfolgen, an SOLL- und KANN-Funktionalitäten einer Version wird gegebenenfalls gekürzt. Die Aufwandsschätzungen (Soll) und -erfassungen (Ist) sollen in regelmäßigen Abständen (Ist täglich, Rest-Soll wöchentlich) erfolgen. Geschieht dies bereits während der Erstellung der ersten Version, ist mit wachsender Versionsnummer eine umso größere Sicherheit und Genauigkeit im Controlling zu erwarten. Diese oft deutlich bessere Beherrschung der Aufwandsabschätzung auch heiklerer Aufgaben wie Gesamttest oder Systemintegration ist eine der offensichtlichen Vorteile der iterativen Entwicklung. Die Entwicklungsschritte innerhalb einer Version erfolgen zeitlich hintereinander; die Analysephase einer zweiten Version kann jedoch schon beginnen, kurz nachdem die Analysephase der ersten Version beendet (und qualitätsgesichert! ) ist. Ähnlich können die Designer bereits an der neuen Version arbeiten, während die vorige noch im Test ist. Die zeitliche Verzahnung einzelner Entwicklungsschritte auch zwischen zwei Versionen ist also möglich - eine „Übertreibung“ an dieser Stelle geht allerdings zu Lasten der zeitlich noch möglichen Rückkopplungen aus der Vorversion und wirkt damit qualitätsmindernd. Insgesamt hilft die o. g. Verzahnung, die verschiedenen Gruppen des Entwicklungsteams gleichmäßiger auszulasten, außerdem kann sie helfen, sehr enge zeitliche Vorgaben für das Gesamtsystem durch Überlagerung der Versionen eher erfüllen zu können. Risiko-Management Das Anstreben einer raschen ersten Version zwingt die Entwickler, alle für eine erste Version des Systems benötigten Teile früh zusammenzumontieren. Dies hilft, technische Probleme zeitig zu erkennen, so dass auch mangelhaftes Know-how, falsche oder fehlende Hersteller-Dokumentation, fehlende System-SW (Treiber, …) und vieles mehr früh erkannt werden. Entsprechende Korrekturmaßnahmen können früh erfolgen und vielerlei Formen haben wie z. B. Nachschulungen, Hinzuziehen weiterer Experten, Veränderung der Basisarchitektur usw. Auch ein früher Projektstopp kann eine der Alternativen sein, die gegebenenfalls helfen können, viel Geld zu sparen! Insgesamt schafft eine frühe Version in der Regel mehr Sicherheit und ein geringeres späteres Risiko für alle Beteiligten. Der Projektmanager muss sein Team anhalten, zwischen zwei Polen der SW-Entwicklung den richtigen Mittelweg zu finden: Sorgfältige Entwickler, insbesondere in modernen Technologien, versuchen oft sehr grundsätzliche Lösungen zu finden (z. B. Design Patterns), deren Umsetzung allerdings möglicherweise eine Menge Zeit benötigt. „Schlampige“ Entwickler versuchen dagegen gelegentlich, bestimmte technische Probleme durch Hintertürchen oder Tricks zu umgehen, ohne das eigentliche Problem zu fokussieren. Auch in frühen Versionen müssen Teile der eigentlichen technischen Probleme bereits gelöst werden, andererseits sind manche „Generallösungen“ oder Frameworks in der Nachbetrachtung oft um einiges umfangreicher als unbedingt nötig. Aufgrund des richtigen Mittelwegs kann eine effektive wirtschaftliche Entwicklung erreicht werden, die durch kontinuierliches Qualitätsmanagement und gelegentliche kritische Selbstreflexion begleitet werden sollte. Bei richtiger Prüfung kann der Auftraggeber eine frühe erste (oder zweite) Version umfangreich nutzen:  Entspricht die erkennbare Oberfläche den Erwartungen der Fachabteilung bzw. Anwender? Ist hinsichtlich Dialogverhalten, Performance oder Zuverlässigkeit die richtige Tendenz zu erkennen?  Liefern die Dienstleistungs- Schnittstellen das Gewünschte? Ist ein Zusammenspiel oder eine Integration mit anderen Systemen schon möglich?  Wird durch die ersten Versionen deutlich, dass organisatorische Veränderungen oder erweiterte Schulungsmaßnahmen für die zukünftigen Anwender notwendig sind?  Welche administrativen Arbeiten müssen an der frühen Version bereits erfolgen, welche weiteren sind erkennbar? Wie funktioniert das System-Management für das neue System?  Lässt sich eine frühe Version für Messen oder andere vertriebliche Einsätze nutzen? Könnte eine Vorversion für einen ausgewählten Anwenderkreis neue Kunden binden (oder auch abschrecken! )? Die Beachtung dieser und weiterer Fragen hilft dem Auftraggeber, unvermeidbare Risiken früh zu erkennen und unnötige Risiken zu vermeiden. Qualitätsmanagement Für die Qualität der zu entwickelnden Software ist ein ständiges prozessbegleitendes Qualitätsmanagement unverzichtbar. Gerade 26฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN eine iterative Vorgehensweise ermöglicht kontinuierliche QS-Maßnahmen, erfordert diese aber auch. Gut bewährt haben sich viele kleine Reviews, die innerhalb jedes Versionszyklus am Ende der Erstellung jedes Dokuments bzw. Artefakts (Diagramm, Sourcecode, Programm usw.) durchgeführt werden. Solche Reviews benötigen oft nur 2 oder 4 aufmerksame Stunden eines oder zweier Reviewer, deren Ergebnis protokolliert und zunächst mit dem Projektleiter besprochen wird. Dieser entscheidet über durchzuführende Nachbesserungsarbeiten, ggf. die Veranlassung eines erneuten Reviews (Re-Review) und klärt diese Punkte mit dem verantwortlichen Entwickler. Durch zeitnahes Nachbessern wird vermieden, dass entdeckte Qualitätsmängel in die nächsten Bearbeitungsschritte durchschlagen. Durch kleine Reviews schon innerhalb des ersten Entwicklungszyklus wird für die zweite Version bereits eine Menge gelernt. Die Prozessqualität und damit auch die Ergebnisqualität steigt normalerweise in der Folge mit jeder neuen Version. Alle Beteiligten wissen, worauf es besonders ankommt und welche fehlerkritischen Stellen besonderer Aufmerksamkeit bedürfen. Dies lässt sich ergänzen um Hinweise, wo die Mitarbeiter genauere Aussagen erwarten und die Artefakte also zu verbessern sind. Erfahrungsgemäß sind kontinuierliche kleine QS-Maßnahmen wirtschaftlicher als die Vernachlässigung der QS während des Entwicklungsprozesses, um dann am Ende einen entsprechend langen Zeitraum mit umfangreichen Tests vorzusehen. Der größte Gewinn für die Qualität entwickelt sich durch die Rückkopplung, durch das Lernen aus Fehlern; genau dies ist bei einer Untergewichtung prozessbegleitender QS-Maßnahmen kaum möglich. Im iterativen Prozess gelingt es leichter, konstruktive QS-Maßnahmen („verhütende“ Maßnahmen vor dem jeweiligen Entwicklungsschritt) und analytische QS-Maßnahmen (prüfende Maßnahmen am entwickelten Produkt) intelligent miteinander zu verschränken. Denn aus gefundenen Fehlern lassen sich in der Regel leicht Maßnahmen entwickeln, die solche Fehler in Zukunft vermeiden helfen. Gerade für den wiederholten Entwicklungszyklus ist die Einführung z. B. von Metriken zur systematischen Qualitätsmessung mit geringem Erhebungsaufwand möglich. Ein weiteres Qualitätsmerkmal ist durch die frühe Existenz einer Kundenversion gegeben. Diese erlaubt ein direktes Kunden-Feedback, durch das insbesondere auch Einfluss auf die Ausgestaltung der weiteren Versionen genommen werden kann. Bei richtig angelegten effektiven Rückkopplungsprozessen hilft dies, ein IT-System zu erarbeiten, mit dem sich die Kundenseite vollständig identifiziert. Schließlich erlaubt es der frühe Rückkopplungsprozess, die Existenzberechtigung der Einzelergebnisse des SW-Entwicklungszyklus zu überprüfen. Erfahrungsgemäß werden in gut ausgearbeiteten Entwicklungsprozessen eine größere Anzahl von Artefakten (in der Hauptsache Dokumente) erzeugt. Kritisch zu prüfen ist jedoch, mit welchen Artefakten tatsächlich gearbeitet wird. Ist jedes Diagramm notwendig, soll heißen, gibt es einem Designer, Entwickler oder Tester notwendige Anhaltspunkte für seine nächsten Arbeitsschritte? Diese kritische Frage resultiert aus der Erfahrung, dass einige Ergebnisse lediglich aus Gründen der Vollständigkeit erarbeitet werden. Benutzt sie niemand zur Weiterarbeit, so sind sie im Erarbeitungsprozess auch nicht unbedingt erforderlich. Also kann aufgrund der Erfahrungen aus den ersten zwei Versionen entschieden werden, welche Artefakte wirklich notwendig sind. Dies hilft, den Produktionsprozess schlank zu halten, was in der Regel die Qualität der tatsächlich zu erarbeitenden Artefakte erhöht. Change-Management Neue technische Möglichkeiten, organisatorische Änderungen durch Fusionen, Abspaltungen oder Outsourcing, der Ruf nach neuen Kundendienstleistungen oder auch neuen Märkten: Dies alles sind Faktoren, die Änderungsanforderungen an IT-Systeme verlangen. Dies wirkt nicht nur auf bestehende, sondern auch auf solche IT-Systeme, die gerade erst im Entstehen sind. Die zügige Berücksichtigung wechselnder Anforderungen erfordert ein effektives Change-Management, das bereits kurz nach Projektstart installiert sein sollte. Durch einen iterativen Entwicklungsprozess wird das Einüben eines effektiven Change-Managements gefördert (Kritiker meinen, diese Möglichkeiten verführen dann auch zu mehr Änderungen; dies ist aber das grundsätzliche Problem von gewachsenen Freiheiten, die natürlich auch missbraucht werden können). Auch im Spiralmodell erzeugen Änderungen an bereits Abb.฀7: ฀Qualitätsmanagement฀im฀Spiralmodell฀-฀der฀Review-Zyklus Milestone ����������� ����������� ��� ������ ��� ������ ������ ������ ������ ������ ���� ������ ���� ������ ������ ������ ������ ������ ��� ������ ��� ������ ���� ������ ���� ������ ��������� ������ ��������� ������ ����������� ����������� Quelle: ARS NOVA ����������� ����������� � ������������������������������������������������������ � ���������������������������������������������������������������� � ����������������������������������������������������������� � ���������������������������������������������������������������� �������������������������������������������������������� 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 erstellten Konzepten, Modellen oder Programmen einen Mehraufwand. Jedoch ist dieser in der Regel deutlich geringer, da die Auswirkungen solcher Änderungen meist weniger „erstellten Bestand“ betreffen und außerdem die Ausprägung von Spezialisierungen oft erst in höheren Versionen erfolgt. Die Versionierung verfolgt u. a. das Prinzip, mit steigender Versionszahl vom Allgemeinen zum Speziellen zu kommen. Aus dieser Sicht ist die Erweiterung eines Programms in Form der Berücksichtigung eines Spezialfalles einer der Standardfälle in der iterativen Entwicklung. Deshalb wird das dazu notwendige Procedere früh ausprobiert und gelernt, so dass das Change-Management ein natürlicher Bestandteil der iterativen Entwicklung wird. Dieser Umstand kommt insbesondere der späteren Wartung und Pflege des fertig erstellten Programms zugute. Gewachsene Möglichkeiten des Change-Managements erlauben dem Projektmanagement insgesamt eine flexiblere Vorgehensweise. Es gelingt damit eher, relativ schnell zu einer tragfähigen ersten Lösung zu kommen, die je nach den dann bestehenden Randbedingungen im Projektumfeld eingefroren, erweitert oder verändert werden wird. Es kommt außerdem zu einem größeren Vertrauen in den zukünftigen Entwicklungsprozess (eine ganz andere Mentalität hat sich oft in Organisationen mit „Wasserfallmodell-Kultur“ entwickelt: „Wenn wir schon die Projektfreigabe endlich bekommen haben, dann muss in das Pflichtenheft alles rein, was wir seit 2 Jahren und für die nächsten 2 Jahre wünschen.“). Ständige฀Verschlankung฀als฀Daueraufgabe Für ein neues Projekt wird in vielen Unternehmen auf eine bereits bestehende Entwicklungsumgebung zurückgegriffen. Es kommen dann so genannte Frameworks zum Einsatz, die z. B. bei objektorientierter SW-Entwicklung aus Klassenbibliotheken bestehen, in denen eine Vielzahl von Systemfunktionen bereits verwirklicht sind. Für den Entwicklungsprozess wird in der Regel eine Menge von Artefakten (oder Ergebnistypen) vorgeschrieben, die im Laufe des Entwicklungsprozesses erzeugt werden sollen. Für beide Aspekte gilt es zu überprüfen, was im neuen Projekt tatsächlich übernommen werden soll; Verschlankung ist hier das zentrale Stichwort. Gerade zu Beginn ist kritisch zu prüfen, welche Artefakte wirklich gebraucht werden und erstellt werden müssen (siehe entsprechenden Abschnitt unter Qualitätsmanagement). Wiederverwendung ist in der Objektorientierung ein wichtiges Ziel. Aber auch für den Entwurf und die Erstellung von Klassen gilt es genau abzuwägen, welche Vorarbeiten wieder verwendet werden sollen oder müssen. Je größer der „Rucksack“ ist, mit dem eine neue fachliche Entwicklung bereits beginnt, umso größer der Aufwand, die damit eingebrachten Elemente kennen zu lernen (um sie auch einsetzen zu können), zu pflegen und weiterzuentwickeln. Auch in der Güterproduktion müssen solche Verschlankungsprozesse immer wieder durchlaufen werden, um schlagkräftige Produkte mit hoher Qualität zu erhalten. Eine ähnliche Haltung muss Daueraufgabe des Projektmanagements im SW-Entwicklungsprozess sein, dies gilt gerade für iterative Entwicklungsmodelle. Denn hier ist einerseits die Gefahr groß, im Projekt unnötigen Ballast aufzuhäufen, andererseits ist aber auch die Chance gegeben, beim Überarbeiten einer Version „auszumisten“. Beim „eXtreme Programming“ (XP), ein besonders extremes iteratives Entwicklungsverfahren, wird dieser Prozess als so genanntes „Refactoring“ immer wieder - oft täglich - durchgeführt. Das Ringen um Verschlankung ist eine Managementaufgabe, die sich in vielen Aufgabenfeldern - auch außerhalb der IT - stellt (auch dabei gibt es natürlich Übertreibungen). Für die iterative SW-Entwicklung ist dies ebenfalls sehr angeraten, hilft es doch, den Entwicklungsprozess effektiv und damit auch agil zu halten. Vertragsprobleme฀und฀andere฀Risiken฀beim฀Spiralmodell Vorteil des Wasserfallmodells ist es, nach Abnahme des Feinkonzepts eine klare und saubere Grundlage zu haben, die oft Basis eines Realisierungsvertrages (mit Festpreis) ist. Bei unklaren Formulierungen im Feinkonzept oder dem Auftreten von Change Requests kann es jedoch zu Unstimmigkeiten und einem „Nachverhandeln“ der Aufwände kommen. Beim Spiralmodell liegt eine klare Beschreibung über den Inhalt einer Version erst dann vor, wenn die entsprechenden Entwurfs- und Designdokumente erarbeitet sind. In der Vorplanung können zwar wesentliche Funktionalitäten grob beschrieben werden, doch dieses taugt nicht als „wasserfeste“ Vertragsgrundlage. Vielmehr müssen sich Auftraggeber und Auftragnehmer darüber im Klaren sein, dass die Vereinbarungen zum Umfang einzelner Versionen jeweils erst innerhalb des Entwicklungszyklus festzulegen sind. Durch Vorgabe von MUSS-Funktionen kann der Auftraggeber gewisse Sicherheiten erreichen, doch das Gelingen des Projekts ist wesentlich von einer vertrauensvollen Zusammenarbeit während des Entwicklungsprozesses abhängig. Um wirtschaftliche Rahmenbedingungen zu setzen, wird häufig ein Budget festgelegt, in dessen Rahmen eine bestimmte Anzahl von Versionen mit definierten Mindestfunktionalitäten zu realisieren sind. Aufgabe der Projektplanung ist es, eine entsprechende Versionsplanung mit anschließenden Feinplanungen umzusetzen. Die „Vertragsphilosophie“ bekommt mit dem Spiralmodell eine andere Ausrichtung. Im Spiralmodell sichert der Auftragnehmer zu, mit seiner Vorgehensweise effektiv und transparent das neue DV-System zu entwickeln. Der Auftraggeber „kauft“ den Entwicklungsprozess ein, weniger ein fertig bestimmtes Werk. Für die erfolgreiche Projektdurchführung ist eine enge Mitarbeit des Auftraggebers notwendig, denn nur gemeinsam kann eine Win-win-Situation erzielt werden. An dieser Stelle darf nicht verschwiegen werden, dass das iterative Vorgehen eine stärkere Mitwirkungs- und Entscheidungspflicht des Auftraggebers erfordert. Kommt dieser - wenn auch nur über kurze Zeiträume - seinen Pflichten nicht nach, kann dies den Entwicklungsprozess erheblich behindern. Im positiven Fall erwirkt diese Mitwirkung ein zielgerichtetes und effektives Arbeiten im Sinne aller Wünsche des Kunden. Deshalb ist auf Kundenseite ein effektives Informations- und Entscheidungsmanagement notwendig, um die Vorteile des iterativen Modells tatsächlich zu nutzen. 28฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN Durch Festlegungen während der jeweils zu erarbeitenden Version kann im Spiralmodell jedoch genauso eine vertragliche Grundlage geschaffen werden, auf deren Basis eine Systemabnahme (für die Version) und eine Gewährleistungspflicht vereinbart werden können. Auch diese Vereinbarungen müssen iterativ geschlossen werden. Insgesamt gibt es auf diesem Gebiet noch wenig Erfahrungen. Offensichtlich gilt jedoch, je besser die Vertrauensbasis, umso leichter sind die Hürden bei den vertraglichen Regelungen zu überwinden. Insbesondere der steuerbare iterative Prozess kann helfen, dieses Vertrauen aufzubauen. Ausblick Zum Schluss eine vielleicht etwas gewagte weiter gehende Betrachtung: Es lassen sich Parallelen finden zwischen der SW-Produktion nach dem Wasserfallmodell und der Taylorisierung in der materiellen Produktion. Für bestimmte Situationen („Massenproduktion“, starre Festlegungen) können beide durchaus jeweils die effektivste Organisationsform sein. Je individueller und auf wechselnde Kundenbedürfnisse zugeschnitten jedoch die SW-Produktion erfolgen soll, umso eher scheint eine iterative Entwicklungsmethode angeraten zu sein. Eine Parallele zur „post-fordistischen“ Produktion ist auch hier zu erkennen. Iterative Entwicklungsmethoden verlangen mehr Feedback, erzwingen daher auch eine bessere Zusammenarbeit verschiedener beteiligter Gruppen auf Seiten des Entwicklerteams und des Kunden 1 . Insgesamt schaffen iterative Methoden eine größere Abwechslung in der SW-Entwicklungsarbeit (im Sinne von job enrichment). Sie erfordern eine kontinuierlichere Tätigkeit von Seiten des Projektmanagements und einen intensiveren Abstimmungsprozess mit dem Kunden. Auch wenn es auf diesem Gebiet bisher noch wenig ausgereifte Erfahrungen gibt, werden zurzeit neue Wege ausprobiert (z. B. XP), ist also noch vieles zu lernen und zu optimieren. Hierfür und für den vermehrten Einsatz von iterativen und rückkoppelnden Prozessen spielt soziale Kompetenz eine wachsende Rolle - ein Trend, der nicht nur für das IT-Projektmanagement gilt.  Literatur [1]฀Boehm,฀B.฀W.: ฀A฀Spiral฀Model฀of฀Software฀Development฀ and฀Enhancement.฀IEEE฀Computer,฀21(5); ฀S.฀61-72,฀1988 [2]฀Kruchten,฀P.: ฀Der฀Rational฀Unified฀Process.฀Addison฀ Wesley,฀München฀1999 [3]฀Reinhold,฀M.: ฀Rational฀Unified฀Process฀2000฀versus฀ V-Modell฀’97.฀Gesellschaft฀für฀Informatik,฀8.฀Workshop฀der฀ Fachgruppe฀5.1.1.฀Glashütten/ Taunus฀(Hessen)฀7.-8.฀März฀ 2001 [4]฀Versteegen,฀G.: ฀Projektmanagement฀mit฀dem฀Rational฀ Unified฀Process.฀Springer,฀Berlin฀u.฀a.฀2000 Schlagwörter IT-Projektmanagement,฀iterative฀SW-Entwicklung,฀Softwareentwicklung,฀Spiralmodell,฀SW-Entwicklungsprozess,฀Wasserfallmodell Autor Dr.฀Karsten฀Hoffmann฀ist฀als฀freiberuflicher฀Coach฀und฀ Berater฀auch฀für฀größere฀IT-Projekte฀tätig.฀Er฀hält฀außerdem฀Seminare฀zu฀modernen฀DV-Architekturen฀und฀zum฀ IT-Projektmanagement.฀Nach฀dem฀Diplom฀in฀Mathematik฀ promovierte฀er฀im฀Bereich฀Fertigungstechnik.฀Während฀ 10฀Jahren฀Tätigkeit฀bei฀einer฀IT-Unternehmensberatung฀ sammelte฀er฀zahlreiche฀Projekterfahrungen.฀Er฀lebt฀und฀ arbeitet฀im฀Raum฀Stuttgart,฀ist฀seit฀1999฀selbständig฀und฀ seither฀auch฀Mitglied฀der฀GPM.฀Seit฀1.฀1.฀2003฀leitet฀er฀das฀Steinbeis-Transfer- Zentrum฀IT-Projektmanagement฀in฀Stuttgart.฀ Anschrift Steinbeis-Transfer-Zentrum฀IT-Projektmanagement Gorch-Fock-Str.฀1 D-70619฀Stuttgart Tel.: ฀07฀11/ 47฀26฀26 Fax: ฀07฀11/ 4฀79฀26฀28 E-Mail: ฀KHoffmann@hitpm.de 1 So berichten Entwickler, die mit eXtreme Programming arbeiten, dass ehemalige Programmier-Einzelkämpfer durch Einsatz von XP zunächst zu neuen Formen der Teamarbeit gezwungen werden müssen, sich jedoch bald das soziale Klima im Team deutlich verbessert. 29฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Quo฀vadis,฀ Bau-Projektmanagement? 12฀streitbare฀Thesen฀zum฀derzeitigen฀Stand฀des฀Projektmanagements฀im฀Bauwesen฀ in฀Deutschland Dietmar฀Marohn Die฀Bauwirtschaft฀ist฀seit฀einiger฀Zeit฀von฀einer฀starken฀Rezession฀betroffen,฀ein฀Ende฀ist฀ nicht฀so฀richtig฀in฀Sicht.฀Um฀andere฀Branchen฀macht฀diese฀Rezession฀auch฀keinen฀Bogen,฀ doch฀scheint฀es,฀als฀ob฀dort฀wesentlich฀mehr฀und฀intensiver฀auf฀Projektmanagement฀als฀ Methodik฀für฀effektive฀Geschäftsprozesse฀zurückgegriffen฀wird,฀als฀dies฀im฀Bauwesen฀der฀ Fall฀ist.฀Sicher฀lässt฀sich฀eine฀schlechte฀Auftragslage฀allein฀nicht฀mit฀den฀Methoden฀des฀ Projektmanagements฀bekämpfen.฀Die฀weit฀verbreitete฀Ablehnung฀und฀Skepsis฀von฀Projektmanagement฀gerade฀im฀Bauwesen฀am฀Anfang฀des฀21.฀Jahrhunderts฀müssen฀einem฀aber฀ dennoch฀stark฀zu฀denken฀geben. Z unächst sei erst einmal definiert, was hier unter Bau-Projektmanagement verstanden sein soll: das Management von Projekten der Entwicklung, Planung, Errichtung und/ oder Betreibung von Gebäuden und/ oder Anlagen der technischen Infrastruktur sowie der Raum-, Regional- und Stadtplanung (nachfolgend Bau-PM oder Bau-Projekte genannt). Insofern werden Begriffe wie Immobilienmanagement, Facility-Management, Raumordnungsmanagement u. a. m. hier mit eingeschlossen. Die nachfolgenden Thesen stellen derzeit häufig anzutreffende Probleme beim Umgang mit Projektmanagement in (zumeist mittelgroßen) Bau-Projekten dar. Einige Lösungsansätze werden aufgezeigt. These฀1: ฀Bauprojekte฀können฀sowohl฀interne฀als฀ auch฀externe฀Projekte฀sein.฀Der฀interne฀Charakter฀ der฀Projekte฀wird฀häufig฀übersehen฀oder฀unterschätzt. In der in Abb. 1 gezeigten Portfolio-Übersicht werden die feinen Differenzen in der Art von Bauprojekten deutlich. Obwohl allgemein Bauprojekte zu externen Projekten gezählt werden, ist diese Zuordnung ein wenig zu global. Das Projektergebnis (das Bauwerk) kann sowohl für einen Dritten (externe Projekte) oder für den Eigenbedarf (interne Projekte) bestimmt sein. Der Anteil von eigenen und fremden (externen) Projektmitarbeitern ändert daran nichts. Selbst der Extremfall, bei dem ein Kunde bei einem Generalübernehmer oder Bauträger ein schlüsselfertiges Gebäude inkl. Planung bestellt, stellt für den Kunden ein internes Projekt dar: Es müssen durch den Kunden der Leistungsumfang und die Qualität definiert, Kosten und Termine vereinbart, Verträge verhandelt, die Finanzierung gesichert werden u. a. m. Insofern unterscheidet sich auch der eben geschilderte Neubau-Prozess vom Kauf einer bestehenden Immobilie. Letzteres stellt kein Projekt dar. Es scheint vielleicht übertrieben, einem Käufer eines Reihenhauses erklären zu wollen, dass er ein internes Projekt betreibt, jedoch wird dies sehr schnell bei größeren Projekten einleuchten, bei denen z. B. ein neues Produktionsgebäude entstehen soll. Diese Erkenntnis wird oft genauso übersehen oder ignoriert wie die Besonderheit der externen Projekte, die darin liegt, dass diese auch einen internen Charakter haben, ein internes Moment. Jedes (Bau-)Projekt besteht aus Teilprojekten, die jeweils von verschiedenen Gruppen, darunter ggf. auch externe Gruppen, bearbeitet werden. Diese externen Gruppen (Architekten, Statiker, Baufirmen etc.) müssen das ihnen übertragene Teilprojekt zu „ihrem“ Projekt machen. Damit das (Teil-)Projektergebnis extern weitergereicht werden kann, muss es erst einmal zu einem internen Projektergebnis werden. Daraus wird deutlich, dass die Anwendung von PM-Methoden nicht nur Sache eines ggf. eingeschalteten Projektsteuerers ist, sondern im entsprechenden (Teil-)Umfang Sache aller (externen) Projektbeteiligten. Dies müssen noch viele Planungsbüros und Baufirmen verinnerlichen. These฀2: ฀Die฀Akzeptanz฀von฀PM฀ist฀im฀Bauwesen฀in฀ Deutschland฀unterentwickelt฀und฀konzentriert฀sich฀ ausschließlich฀auf฀Großprojekte. Es geht hier nicht darum, bei jedem Projekt einen (externen) Projektsteuerer einzusetzen. Bei kleineren Projekten reicht es völlig aus, wenn die Erkennntnisse der 1. These beherzigt werden. Es geht darum, dass Projektmanagement noch zu häufig als nutzlose Geldausgabe für überflüssige Leistungen, gewissermaßen als Arbeitsbeschaffungsmaßnahme für eine in den letzten 10 bis 15 Jahren entstandene Gilde von theoretischen Besserwissern angesehen wird, die sowieso nur 30฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN die Kosten für eine ansprechende Bauwerksgestaltung streichen und damit der natürliche Feind der Architekten sind. „Wir sind bisher auch ohne PM ausgekommen“, „Die PM-Ergebnisse sind sowieso nur Theorie, in der Baupraxis muss operativ entschieden werden“, „Wenn mit dem Architekten eine Bonus-Malus-Regelung bezüglich der Einhaltung der Kosten vereinbart wird, kann man auf PM-Leistungen verzichten“. Solche und ähnliche Argumente kann man leider noch allzu oft besonders bei mittelgroßen Bauvorhaben zu hören bekommen. Darin spiegelt sich die noch große Unkenntnis über Umfang, Inhalt und Nutzen von Bau-PM-Leistungen wider (siehe auch These 3). Mitunter wird auch die Übertragung von PM-Leistungen an einen (externen) Projektsteuerer als Entthronung des Architekten angesehen. Dabei ist dies doch nur das Ergebnis der Notwendigkeit einer Arbeitsteilung in einem immer komplizierter werdenden Bauprozess. Der Verfasser konnte z. B. eine Erweiterung eines Schulgebäudes in Norditalien mit einem Umfang von ca. 1 Mio. Euro besichtigen, bei der ein externer Projektsteuerer eingesetzt wurde. Bei diesem Bauvolumen wäre es in Deutschland undenkbar, einen Bauherrn zum Nachdenken über den PM-Einsatz zu bewegen! Es ist falsch, die Frage nach Einsatz eines (externen) Projektsteuerers von einem bestimmten Schwellenwert des Bauvolumens abhängig zu machen. Einzig der Grad der Komplexität, die zur Verfügung stehende Zeit und das Budget können diese Frage beantworten. So kann es z. B. auch bereits bei einer Umbaumaßnahme kleineren Bauvolumens bei laufendem Betrieb mit vielleicht auch noch verschiedenen Nutzern erforderlich sein, einen (externen) Projektmanager einzusetzen. These฀3: ฀Die฀Kenntnis฀dessen,฀was฀als฀Bau-Projektsteuerungsleistungen฀abverlangt฀werden฀kann฀bzw.฀ muss,฀ist฀bei฀vielen฀Auftraggebern฀unterentwickelt. Die Leistungsbilder der „klassischen“ Planungs- und Bauleistungen sind allgemein weiter und besser verbreitet, als dies beim PM-Leistungsbild der Fall ist. Dass es eine HOAI (Honorarordnung für Architekten und Ingenieure) gibt, in der die Leistungen bzw. Aufgaben der Planer beschrieben sind, ist noch bekannt (einmal abgesehen davon, dass die Teile der HOAI zur Vergütung dieser Leistungen immer unbekannter werden). Die Kenntnis der Existenz einer AHO (Ausschuss der Verbände und Kammern der Ingenieure und Architekten für die Honorarordnung e. V.) und deren Inhalt mit präzise beschriebenen Handlungsbereichen und Leistungsphasen für Bau-PM-Leistungen jedoch fehlen vielfach. Hinzu kommen nebulöse Vorstellungen über den Zweck von Bau-PM, das in erster Linie keine Planungs-, sondern eine Koordinations- und Steuerungsleistung darstellt, die nur voll wirksam werden kann, wenn sie direkt und unabhängig dem Bauherrn bzw. Auftraggeber unterstellt ist. Die gemeinsame Vergabe von Planungs- und Projektsteuerungsleistungen an ein und dasselbe Büro ist so unsinnig, dass man auch gleich darauf verzichten kann. Dies darf aber keinesfalls mit den Aussagen der These 1 verwechselt werden. Dort geht es um den Einsatz von Projektmanagement als Methode, hier um den Einsatz von Projektmanagement als (externe) Leistung. Projektrealisierung erfolgt mit … … vorwiegend eigenem Projektteam z. B.: Ein Bauträger baut ein Wohngebäude zum Verkaufen. z. B.: Ein Bauträger baut ein Wohngebäude zum Vermieten. … vorwiegend fremdem Projektteam z. B.: Ein Bauträger baut ein Gewerbeobjekt für ein anderes Unternehmen. z. B.: Ein Bauträger baut für den Eigenbedarf ein Wohn- und Geschäftshaus. extern intern Projektart Der Kunde des Projektergebnisses ist … … ein anderes Unternehmen/ anderer Käufer. … das eigene Unternehmen. Abb.฀1: ฀Charakter฀von฀Bauprojekten 31฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 These฀4: ฀Bau-Projektmanagementleistungen฀werden฀ -฀wie฀andere฀Planungsleistungen฀auch฀-฀einem฀ Preisdumping฀unterworfen,฀bei฀dem฀letztlich฀einzig฀ und฀allein฀die฀Qualität฀leidet. Preiswettbewerb ist das eine. Dies kann aber nicht so weit gehen, dass eine Luxuslimousine zum Preis eines Kleinwagens erwartet wird. Ein anderer Fall scheint aber im Bauwesen viel verbreiteter zu sein: In Unkenntnis des Auftraggebers über den Qualitätsunterschied zwischen der Luxuslimousine und dem Kleinwagen ist keine monetäre Vorstellung über den Wert der eingekauften Ware (bzw. Leistung) vorhanden, da auch keine Vorstellungen über die Soll-Qualität vorhanden sind. Man will eben ein Auto, aber worauf geachtet werden muss, ist unklar (siehe These 3). These฀5: ฀Projektsteuerungsleistungen฀werden฀zu฀ spät฀beauftragt. Ebenfalls aus Unkenntnis über das Wesen und den Inhalt von Bau-Projektmanagement erfolgt mitunter ein zu später Einsatz von PM-Leistungen. Wenn das Kind erst einmal in den Brunnen gefallen ist (z. B. während der Realisierungsphase), kann man mit PM-Methoden allenfalls Schaden begrenzen. Gerade die vorausschauende Betrachtungsweise bzgl. eventueller Ereignisse oder Risiken ist zu einem derartigen Zeitpunkt kaum noch möglich. Aber auch der Einsatz eines Projektmanagers nach abgeschlossener Genehmigungsplanung und vor Baubeginn wird nur ein PM-Rudiment werden können. Die gesamte Problematik der Festlegung von Qualität und Zielen, Definitionen, Schnittstellen, Strukturbildungen u. a. m. in der Projekt-Start-Phase kann dann kaum noch behandelt werden, weil der Projektmanager vor vollendeten Tatsachen steht und sein Eingriff nur noch begrenzt etwas bewirken kann. These฀6: ฀Aus฀falsch฀verstandener฀Kostenminimierung ฀ werden฀von฀Auftraggebern฀Bau-PM-Leistungen฀in฀ notwendige฀und฀überflüssige฀Teilleistungen฀unterteilt.฀Nur฀die฀„notwendigen“฀Teilleistungen฀werden฀ beauftragt. Mitunter erscheinen Bau-PM-Leistungen dem Laien als ganz banal oder werden mit anderen betriebswirtschaftlichen Leistungen verwechselt. So besteht das Informations- und Dokumentationsmanagement eben nicht nur aus Faxe versenden und Pläne abheften. Eine Projektbuchhaltung ist eben nicht Teil der betrieblichen Buchhaltung, da schon allein die Buchhaltungssoftware gar nicht als Projektbuchhaltung geeignet und entwickelt ist. Terminplanung ist eben nicht nur die zeitliche Planung des Bauablaufes. Die Terminplanung der Bauplanung wird auf wenige Meilensteine reduziert, Zwischentermine zur Kontrolle des (Planungs-)Leistungsstandes sind daher nicht möglich. Und so geschieht dann, was häufig geschieht: Der Bau beginnt mit Plan- Vorabzügen, freigegebene Ausführungspläne kommen verspätet, teure und zeitaufwändige Rückbauarbeiten werden erforderlich. Projektmanagementleistungen sind nun einmal komplexe, ineinander greifende Leistungen, die nicht einfach nach Belieben „gekappt“ werden können. Wenn dies geschehen soll oder muss, dann ist sehr intensiv über das Legen der Schnittstellen nachzudenken, um das restliche PM-Leistungsgebilde nicht zu einem behinderten Torso werden zu lassen. Dies wird dann meist in der Praxis übersehen oder nicht intensiv genug betrieben. These฀7: ฀Auftraggeber฀erbringen฀Teilleistungen฀des฀ Bau-PM฀und฀sind฀hierfür฀oftmals฀völlig฀unzureichend฀ qualifiziert. Zweifelsohne ist es möglich, nur Teilleistungen extern zu beauftragen. Nur müssen die Schnittstellen wohl überlegt werden, was ohne Kenntnis des gesamten Bau-PM-Leistungsumfanges und seiner Zusammenhänge schlecht bewerkstelligt werden kann. Für die beim Auftraggeber verbleibenden Teilleistungen müssen genauso PM-Fachleute zum Einsatz kommen wie bei einer externen Beauftragung. Es bedarf dann weiterhin eines „Supervisors“, der die mitunter divergierenden Einzellösungen der Teilleistungen als Kompromiss zu einer Gesamtlösung führt. Hier sei an das magische Dreieck Kosten - Qualitäten - Termine erinnert. Diesen Supervisor gibt es aber in den wenigsten Fällen, so dass Fehlentscheidungen oder fehlende Entscheidungen dann das Ergebnis sind. These฀8: ฀Der฀Projektsteuerungsmarkt฀im฀Bauwesen฀ ist฀mehr฀als฀in฀anderen฀Branchen฀von฀selbst฀ernannten฀Projektmanagern฀überfüllt,฀die฀über฀unzureichende฀Management-Kompetenzen฀verfügen. Es schaudert einen, was alles für Büros, Unternehmensberatungen etc. von sich behaupten, Projektmanagementleistungen anzubieten. Wer einige Jahre in der Baubranche mit der Entstehung von Bauwerken beschäftigt war, hat sicher gute Voraussetzungen, ein Bau-Projektmanager zu werden, ist es damit aber automatisch noch nicht. Vor allem bei methodischen Grundlagen und sozialen Kompetenzen besteht akuter Weiterbildungsbedarf. Einerseits sind hier die Weiterbildungsmaßnahmen der GPM vorbildlich. Die Existenz des PM-Kanons, der gewissermaßen die Struktur der PM-Kompetenzen und des PM-Wissens darstellt, fehlt in ähnlicher Weise für andere Ausbildungsrichtungen. So ist z. B. nur nebulös formuliert, welche Kompetenzen einen Architekten oder einen Gutachter auszeichnen. Der PM-Kanon ist aber nur die Grundlage. Baufachliche Kompetenzen über rationelle Grundrisslösungen, wirtschaftliche Bauweisen, Bautechnologien u. a. m. können nicht ausgeklammmert werden. Hierauf brauchte in der Vergangenheit wenig Augenmerk gelegt zu werden, weil der Projektmanager sich aus der Berufspraxis herausqualifizierte. Seit einigen Jahren stimmt dies aber nicht mehr, da zunehmend Universitäten und Hochschulen PM-Studiengänge anbieten. Die Absolventen dieser Studiengänge verfügen sicher über gute PM-Kompetenzen, aber logischerweise noch über wenig baufachliche Kompetenzen. Andererseits wird im Bauwesen wesentlich weniger als in anderen Branchen Wert auf PM-Qualifikationen gelegt. Dazu ein Beispiel: In welcher Ausschreibung für Bau-PM-Leistungen wurde als Voraussetzung der Abschluss zum PM-Fachmann verlangt? Ob der Ab- 32฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN schluss zum PM-Fachmann das alleinige Gütekriterium für Bau-Projektmanager sein kann und soll, sei jedoch einmal dahingestellt. Es ist klar umrissen, wann ein Architekt sich als solcher bezeichnen darf - nicht zu verwechseln mit der unscharfen Definition der Kompetenzen. Ob diese Zugangsvoraussetzungen noch zeitgemäß sind, sei auch einmal dahingestellt. Aber es ist erst einmal eine Hürde definiert, um den Status Architekt zu bekommen. Im Fall der Zulassung zum öffentlich bestellten Gutachter ist die Hürde noch höher. Für (zumindest) Bau-Projektmanager gibt es gar keine Hürde. Es muss hier der Weg zu einem allgemein anerkannten „Gütesiegel“ für Bau- PM-Leistungen, sinnvollerweise gestaffelt wie bei der IPMA-Zertifizierung von Projektmanagern, gefunden werden. These฀9: ฀Auf฀Grund฀fehlender฀Akzeptanz,฀unzureichender฀Qualifizierungen฀und/ oder฀mangelnder฀ Kompatibilität฀der฀Arbeitsmittel฀können฀PM-Methoden฀und฀-techniken฀nur฀begrenzt฀und฀nur฀bei฀wenigen฀Ausnahmeprojekten฀in฀zeitgemäßem฀Umfang฀ eingesetzt฀werden. Die Planungs- und Projektsteuerungsbüros sind alle mit Computern und entsprechender Software ausgestattet (sofern es sich um qualifizierte Büros handelt). Der Austausch unter den Büros geschieht vielfach schon digital. Der Dokumentenaustausch mit Bauherrren erfolgt derzeit noch zu 99 % in Papierform! Mit großen Plänen wird nicht nur in der Baubranche gearbeitet, hinsichtlich des Übertragungsmediums liegt die Baubranche gegenüber anderen Branchen um Jahrzehnte zurück. Die Nutzung des Internets als zentraler Informationsspeicher wird nicht nur hartnäckig in der Baubranche negiert, auch die Bereitschaft, gemeinsam an einem Projekt im Internet zu arbeiten, beschränkt sich auf das Versenden von E-Mails. Andererseits erschweren die heillose Vielfalt von teilweise sehr teurer Software, der unterschiedliche Grad an Hardware-Ausstattung und die völlig unterentwickelte Definition von Datenaustausch-Standards die Akzeptanz einer verstärkten Digitalisierung von Informationen. Die DXF-Schnittstelle zum Datenaustausch von CAD-Zeichnungen ist völlig unzureichend und fehleranfälllig. Einen Standard zum Austausch von z. B. Terminplanungssoftware gibt es überhaupt nicht. Hier kann man nur hoffen, dass die Projektbeteiligten zufällig über die gleiche Software verfügen, was in der Praxis einem Sechser im Lotto gleichkommt. Schließlich kommen noch juristische Probleme der Echtheitserkennung von Originalen hinzu. Zwar ist die elektronische Unterschrift technisch bereits möglich, in der von Gerichtsprozessen gebeutelten Baubranche aber juristisch allgemein nicht sanktioniert! These฀10: ฀Bau-Projekte฀sind฀auf฀Grund฀spezifischer฀ nationaler฀oder฀regionaler฀Baugesetzgebung฀nur฀in฀ wenigen฀Ausnahmefällen฀internationale฀Projekte.฀ Dies฀führt฀zu฀einer฀überdurchschnittlich฀starken฀ Negierung฀der฀sozialen฀Komponenten฀in฀Projekten. Die zunehmende Internationalisierung von Projekten zwingt Projektmanager, ihre sozialen Kompetenzen zu erweitern, um soziale Konflikte aus dieser Internationalisierung im Umgang mit den verschiedenen Kulturen im Prozess zu beherrschen oder zu bewältigen. Bauprojekte sind selten internationale Projekte. Die Komplexität der Planungen sowie die teilweise sogar regional unterschiedlichen Baugesetzlichkeiten führen dazu, dass z. B. die in anderen Branchen praktizierte Projektbearbeitung „mit der Sonne um den Erdball“ kaum Einzug hält. Damit entfällt aber auch scheinbar der Zwang, sich mit sozialen Kompetenzen auseinander setzen zu müssen. Neuere Managementerkenntnisse auf diesem Gebiet, Erkennntnisse der Mitarbeiterführung, Motivationsmethoden u. a. m. haben offenbar überall, aber kaum im Bauwesen Einzug gehalten. Die Methode, die hier weit verbreitet ist, lautet: „Haut den Lukas! “ Nicht wenige Bauprojekte führten z. B. von Ablaufstörungen über soziale Konflikte zu eklatanten Projektkrisen! Letztlich wurde das Projekt mit viel Kraftaufwand abgearbeitet, das Ziel wurde aber nicht erreicht. Die Anwendung sozialer Kompetenzen wird allzu häufig noch als „Schwäche“ des Projektmanagers oder „Verrat“ an den Interessen des Bauherrn angesehen. Dass diese sozialen Kompetenzen jedoch Teil des Projekterfolges sind, hat sich erst begrenzt herumgesprochen. These฀11: ฀Vor฀allem฀deutschen฀Projektmanagern฀ wird฀ein฀starkes฀Harmoniebedürfnis฀nachgesagt.฀ Dies฀ist฀für฀Bau-Projektmanager฀bei฀Projekten฀in฀ Deutschland฀wegen฀der฀weit฀verbreiteten฀„Streitwut“฀ein฀unabdingbares฀Erfordernis. Wahrscheinlich wird in keiner Branche so viel gestritten wie in der Baubranche. Obwohl allgemein der „Nutzen“ von gerichtlichen Bauprozessen auf Grund des hohen Kostenaufwandes, der langen Prozessdauer und des ungewissen Ausganges von vielen (Gerichts-)Prozessbeteiligten angezweifelt wird, Einfluss auf mögliche Vermeidung von unnötigen gerichtlichen Streiten hat dies offenbar nur wenig. Umso mehr muss Augenmerk auf das Vermeiden oder außergerichtliche Schlichten von Konflikten besonders durch die Bau-Projektmanager gelegt werden. Hier zeigt sich wieder die Notwendigkeit der Beherrschung sozialer Kompetenzen, aber auch von Mediationstechniken, die erst seit kurzer Zeit vorsichtig auch Einzug im Bauwesen halten. These฀12: ฀Die฀Anwendung฀von฀PM-Wissen฀bei฀Bau- Projekten฀ist฀in฀den฀letzten฀Jahren฀stehen฀geblieben. Während in anderen Branchen die Vorteile moderner IT-Verfahren zur Verbesserung der PM-Methoden genutzt werden, scheint im Bauwesen das „Wir können schon alles“-Syndrom umzugehen. Es gibt noch richtige weiße Flecken auf der Bau-PM-Landkarte: die Anwendung von PM-Methoden in der Raum-, Regional- und Stadtplanung z. B. zur Verkürzung der extrem lang gewordenen Bearbeitungs- und Genehmigungszeiten von (regionalen) Raumordnungsplänen. Strukturierungsmethoden, Stakeholder-Analysen, Risikoanalysen und Terminmanagement sind hier potentielle Anwendungsfälle. Aber auch Spezialdisziplinen wie das Facility-Management oder das Immobilienmanagement bedürfen der 33฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 noch stärkeren Integration von PM-Methoden sowie der Erreichung deren allgemeiner Akzeptanz. Lösungsansätze Es ist sicher nachvollziehbar, dass hier weder vollständige noch allheilende Lösungsansätze aufgezeigt werden können. Wichtig erscheint zukünftig, das Augenmerk auf folgende Ansätze zu richten:  verstärkte Qualifizierung von Projektmanagern für interne Projekte. Hier hat u. a. auch die öffentliche Hand (Bauämter, Staatsbauämter, Straßenbauämter) einen erheblichen Nachholbedarf;  verstärkte Publikation der wesentlichen Bau-PM- Inhalte, deren Nutzen und Anwendungsmöglichkeiten zur Qualifizierung von potentiellen Bauherren auf diesem Gebiete: Es reicht also nicht aus, nur die Fußballmannschaft zu trainieren und die Vereinsleitung weiß gar nicht, was Fußball ist!  Schaffung eines „Gütesiegels“ für Bau-PM-Leistungen und Definition von Qualitätsanforderungen für Bau-Projektmanager;  neben der Qualifizierung von Baufachleuten zu Projektmanagern muss verstärkt auch eine Weiterbildung von Projektmanagern zu Baufachleuten erfolgen;  verstärkte Zuwendung zur anwendungsorientierten Forschung zur Erhöhung des PM-Wissens im Bauwesen;  Verstärkung der Fachgrupppenarbeit in der GPM. Hier sei auf die neu gegründete GPM-Fachgruppe „PM am Bau“ hingewiesen.  Schlagwörter Berufsstand,฀Forschungsbedarf,฀PM฀im฀Bauwesen,฀PM- Akzeptanz,฀PM-Methodenvorrat,฀PM-Qualifikation Autor Dr.-Ing.฀Dietmar฀Marohn,฀Architekt,฀geb.฀1958; ฀Studium฀Stadt-฀und฀ Gebietsplanung฀an฀der฀Bauhaus- Universität฀Weimar,฀Promotion฀über฀ mehrkriteriale฀Entscheidungsfindung฀ in฀der฀Stadt-฀und฀Gebietsplanung.฀ Tätigkeit฀als฀Referatsleiter฀Hochbau฀ bei฀der฀Telekom,฀Abteilungsleiter฀Projektmanagement฀bei฀der฀De.Te.Bau,฀Niederlassungsleiter฀ bei฀der฀IPRO฀Dresden.฀Seit฀1997฀selbständig฀als฀Projektsteuerer,฀Architekt฀und฀Gutachter.฀Gründungsmitglied฀der฀ GPM-Fachgruppe฀„PM฀im฀Bau“. Anschrift MAROHN฀+฀Partner freie฀Architekten฀und฀Ingenieure Bruhl฀9 D-99423฀Weimar Tel.: ฀0฀36฀43/ 5฀92฀52 Fax: ฀0฀36฀43/ 5฀92฀55 E-Mail: ฀d.marohn@heusle.de 34฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN Ex฀occidente฀lux? Kritische฀Bemerkungen฀zum฀PMBOK฀Guide฀2000฀Edition฀[1] Heinz฀Schelle Nach฀einer฀knappen฀Darstellung฀des฀Inhalts฀und฀der฀Systematik฀des฀PMBOK฀werden฀die฀ wesentlichen฀Vorzüge฀und฀Mängel฀der฀Publikation฀herausgestellt.฀Kritisiert฀werden฀vor฀ allem฀die฀überstrapazierte฀Prozessorientierung,฀das฀Fehlen฀wichtiger฀Themen,฀die฀weitgehende฀Vernachlässigung฀organisationspsychologischer฀Aspekte฀und฀die฀Behandlung฀von฀in฀ der฀Praxis฀erfolglosen฀Ansätzen฀des฀Operations฀Research. D er PMBOK Guide gehört wohl zu den am meisten zitierten Projektmanagementbüchern der Welt. Durch die aggressive Expansionspolitik des Project Management Institute of America (PMI) wird er immer weiter verbreitet. Vielen gilt er sozusagen als heiliges Buch des Projektmanagements. In der Literatur kann man nur wenige kritische Äußerungen über diese Publikation finden. Könnte es sein, dass es der Projektmanagement-Bibel genauso geht wie den Werken der deutschen Klassiker? Sie werden viel gerühmt, aber wenig gelesen. Im Folgenden werden zunächst die einzelnen Kapitel kurz charakterisiert. Wenn auch bereits hier auf kritische Anmerkungen nicht vollständig verzichtet werden kann, soll eine Detailkritik erst in einem zweiten Teil erfolgen. Sofern es für ein einzelnes Teilgebiet keinen entsprechenden deutschen Ausdruck gibt, wird auf eine Übersetzung verzichtet. Was ist der Zweck des Guide? Er soll - so seine Verfasser - den Wissensbestand auf dem Gebiet Projektmanagement darstellen, der „allgemein akzeptiert wird“, was selbstverständlich nicht bedeutet, dass alles, was beschrieben wird, auch in allen Projekten angewandt wird. Der Guide soll dagegen kein Lehrbuch im üblichen Sinn sein. Das schließt natürlich nicht aus, dass er von vielen so interpretiert und benutzt wird. Es kann auch kein Alibi dafür sein, dass wesentliche Themen so gut wie nicht behandelt wurden. Um den Punkt der Akzeptanz und somit der Anwendbarkeit vorweg zu nehmen: Wer das Werk bis zur letzten Seite gelesen hat, dem kommen bei vielen Passagen erhebliche Zweifel an der Praktikabilität. Aber darüber später mehr. Was฀ist฀ein฀Projekt฀und฀was฀versteht฀man฀unter฀Projektmanagement? Das PMI fasst sich bei der Definition, was unter einem Projekt zu verstehen ist, etwas kürzer als die DIN 69 901 und definiert: „A project is an temporary endeavor undertaken to create a unique product or service.“ Das ist sicher eine brauchbare Begriffsbestimmung, die viele Probleme vermeidet, wenngleich man sich, genau so wie bei der DIN-Norm, gewünscht hätte, dass der Aspekt der Arbeitsteilung berücksichtigt worden wäre. Da dies nicht geschehen ist, ist es durchaus konsequent, dass nach Meinung des PMI auch dann ein Projekt vorliegt, wenn nur eine Person daran beteiligt ist; eine sehr problematische Sichtweise, weil nach meiner Auffassung Projektmanagement immer und zwingend die Koordinierung von Aktivitäten umfasst, die von verschiedenen Aufgabenträgern mit dem Zweck der Erfüllung eines gemeinsamen Ziels arbeitsteilig ausgeführt werden. Im Gegensatz zur einschlägigen DIN-Norm wird bei der Bestimmung des Terminus „Projektmanagement“ nicht auf den Führungsaspekt abgestellt, der im Grunde die oben angesprochene Arbeitsteilung impliziert. Das PMI versteht unter Projektmanagement „the application of knowledge, skills, tools and techniques to project activities to meet project requirements.“ Kurzer฀Überblick฀über฀den฀Inhalt฀des฀Guide,฀vorerst฀ weitgehend฀ohne฀kritische฀Kommentare Section I, 1 Einführung: Hier werden grundlegende Begriffe definiert und die Beziehungen der Disziplin „Projektmanagement“ zu anderen Disziplinen herausgearbeitet. Section I, 2 Das Projektmanagement-Umfeld (Project Management Context): Mit dem Terminus „Context“ ist nicht nur das gemeint, was darunter in Deutschland im Rahmen der Projektumfeldanalyse (= Stakeholderanalyse) und in der International Competence Baseline (ICB) der International Project Management Association (IPMA) verstanden wird. Der Abschnitt behandelt vor allem Vorgehensmodelle (Phasen, Phasenergebnisse, Beispiele für Vorgehensmodelle), Stakeholder und die verschiedenen Formen der Aufbauorganisation. Dabei wird zwischen funktionaler Organisation, schwacher, ausgewogener (balanced) und starker Matrix und totaler Projektorganisation (projectized) unterschieden. Außerdem wird sehr knapp auf verschiedene Führungsstile und die Aufgaben des Managements wie Führung (leadership), Kommunikation etc. eingegangen. Section I, 3 Projektmanagement-Prozesse (Project Management Processes): Hier wird zwischen Projektmanagement-Prozessen und produktorientierten Prozessen unterschieden. Projektmanagement-Prozesse „descri- 35฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 be, organize and complete the work of the project.“ Produktorientierte Prozesse „specify and create the project’s product.“ Innerhalb der Projektmanagement-Prozesse wird differenziert nach  initiierenden Prozessen (Projektgenehmigung oder Freigabe einer Phase);  Planungsprozessen (Definition von Projektzielen und Bestimmung der optimalen Aktionsfolge, um diese Ziele zu erreichen);  Ausführungsprozessen (Koordination des Einsatzes von Personal und anderen Ressourcen, um die Pläne auszuführen);  Kontrollprozessen, mit denen sichergestellt wird, dass die Ziele erreicht werden. Diese Prozesse schließen die Abweichungsanalyse und eventuelle Steuerungsmaßnahmen ein;  abschließenden Prozessen mit dem Ziel der Akzeptanz des Projekt- oder des Phasenergebnisses. Die verschiedenen Prozesse werden dann in ihren Interaktionen anschaulich, aber natürlich etwas vereinfachend dargestellt. Den Planungsprozessen werden unterstützende Prozesse (facilitating processes), z. B. Qualitätsmanagement, zur Seite gestellt. In diesem Kapitel wird dann auch die Systematik zur Beschreibung eines Prozesses eingeführt. Sie wird in den späteren Kapiteln konsequent durchgehalten und trägt viel zur Klarheit bei, wirkt aber in einigen Kapiteln (insbesondere Kapitel 9), wie noch auszuführen sein wird, sehr gekünstelt und überstrapaziert. Jeder Prozess wird durch folgendes Schema erläutert: Input (Dokumente oder Objekte, die dokumentierbar sind)  Werkzeuge und Techniken, mit denen der Input in einen Output transformiert wird  Output (Dokumente oder Objekte, die dokumentierbar sind) als Ergebnis des Prozesses. Vor allem mit Hilfe der Input-Output-Relation werden die Schnittstellen zwischen den einzelnen Prozessen bzw. Prozesskategorien spezifiziert. Section II, 4 Project Integration Management: Der Begriff wird im deutschen Sprachraum kaum verwendet. Der Guide versteht darunter alle Prozesse, die erforderlich sind, um die verschiedenen Elemente des Projekts zu integrieren. Der Terminus „Element“ wird allerdings nicht näher erläutert. Ein wichtiges Ergebnis des Integrationsmanagements, zu dem auch die Projektfortschrittskontrolle und das Konfigurationsmanagement gezählt werden, ist eine umfassende Projektplanung, die die Planungsparameter einbezieht. Section II, 5 Project Scope Management: Auch für diesen Begriff gibt es in der deutschen Sprache keine allgemein akzeptierte Entsprechung. Zum Teil wird er in der Literatur recht nichts sagend mit Umfangsmanagement übersetzt. In der International Competence Baseline finden sich zum Begriffspaar „Content“ und „Scope“ die deutschen Ausdrücke „Inhalt“ und „Leistungsbeschreibung“. Die Verfasser des Guide verstehen unter Project Scope Management alle Prozesse, die sicherstellen, „that the project includes all the work required and only the work required, to complete the project sucessfully.“ Am klarsten wird der Terminus „scope“, wenn man sich an die Definition von „scope planning“ hält. Innerhalb dieser Definition heißt es: „… a written scope statement that includes the project justification, the major deliverables and the project objectives.“ Ein wichtiges Resultat des Scope Management ist der Projektstrukturplan. Benutzt man deutsche Begriffe, so ist ein weiteres Ergebnis das Pflichtenheft. Section II, 6 Ablauf- und Zeitplanung (Project Time Management): In diesem Kapitel werden Ablauf- und Zeitplanung im Detail dargestellt. Dabei erstaunt, dass sich die Amerikaner - wie auch in den meisten Lehrbüchern aus den Vereinigten Staaten - immer noch nicht ganz von der wenig leistungsfähigen Vorgangspfeilnetztechnik trennen können. Könnte die Tatsache, dass die viel leistungsfähigere Vorgangsknotennetztechnik, die natürlich ebenfalls erläutert wird, nicht in den USA, sondern in Frankreich entwickelt wurde, der Grund dafür sein? Section II, 7 Projektkostenmanagement (Project Cost Management): Hier wird in die Teilaspekte „Einsatzmittelplanung“, „Kostenschätzung“, „Kostenbudgetierung“ und „Kostenkontrolle“ untergliedert. Fragen der Ressourcenplanung für das gesamte Projektportfolio werden explizit nicht behandelt. Bei der Kostenschätzung wird nicht ganz sauber zwischen  parametrischen Modellen,  Kostenschätzung durch Analogieschluss und  Bottom-up-Schätzung unterschieden. Die Kostenschätzung mithilfe von Kennzahlen und Kennzahlensystemen wird zutreffend unter die parametrischen Modelle subsumiert. Viel klarer als die obige Klassifikation wäre freilich die Einteilung in  Schätzmethoden mit expliziter und  Schätzmethoden ohne explizite Berücksichtigung der Kosteneinflussgrößen gewesen. Dann hätte man auch mühelos die nicht ausdrücklich erwähnten verschiedenen Ansätze der Expertenbefragung untergebracht. Section II, 8 Qualitätsmanagement (Project Quality Management): Das Kapitel ist angesichts der Bedeutung des Themas außerordentlich kurz und sehr hausbacken geraten. Die Entwicklung der letzten 15 Jahre ist an diesem Teil offensichtlich spurlos vorübergegangen. Wenn man schon im Detail auf Ishikawa- und die nun wirklich nicht mehr sonderlich neuen Paretodiagramme eingeht, dann hätte man wenigstens einige Stichworte für neuere Ansätze wie QFD und in Verbindung damit Target Costing, für Projektbenchmarking im Allgemeinen und im Besonderen für Reifegradmodelle und produktorientierte Qualitätsmodelle im IT-Bereich spendieren können. Section II, 9 Project Human Resource Management: Für diesen Begriff gibt es in der deutschen Literatur ebenfalls keine exakte Entsprechung. Vielleicht könnte man ihn mit „Personalwirtschaftliche Aspekte des Projektmanagements“ umschreiben. Allerdings passt dann die Projektaufbauorganisation nur sehr bedingt dazu. Behandelt werden neben diesem Problembereich  Personalrekrutierung und  Teamentwicklung. Der außerordentlich geringe Raum, der vor allem dem Teamaufbau zugestanden wurde, ist enttäuschend. Section II, 10 Project Communication Management: Zu diesem Kapitel, das mit dem deutschen Begriff „Be- 36฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN richtswesen“ nur unzureichend überschrieben werden könnte, gehören  die Planung des Berichtswesens und der Kommunikation mit den Stakeholdern,  die Verteilung der Information (information distribution),  die Projektfortschrittsberichterstattung (performance reporting) und  der formale Abschluss einer Phase oder eines Projekts. Bei dieser alles andere als systematischen Kategorisierung überrascht vor allem die Behandlung des Projektabschlusses, der offenbar sehr verengt vor allem als Problem der Berichterstattung gesehen wird („generating, gathering and disseminating information to formalize a phase or project completion“). Verwunderlich ist in diesem Zusammenhang auch, dass dem Projektabschluss kein eigenes Kapitel gewidmet wurde. Verwunderlich und geradezu fahrlässig schließlich, dass zwar der Earned-Value-Ansatz, der aus den frühen 60er-Jahren stammt, im Rahmen des Unterkapitels „Performance Reporting“ ausführlich erläutert wird, aber mit keinem Wort auf seine Problematik, vor allem bei Projekten mit hohem Neuheitsgrad bzw. mit immateriellen Zwischenergebnissen, hingewiesen wird. Section II, 11 Risikomanagement in Projekten (Project Risk Management): Im Gegensatz zu anderen Kapiteln wird das Thema, dem gegenwärtigen Trend folgend, ausführlich, aber in sehr konventioneller Weise behandelt. Section II, 12 Beschaffungsmanagement in Projekten (Project Procurement Management): Das Thema der Beschaffung, das im Projektmanagement-Fachmann der GPM leider viel zu kurz kommt, umfasst die Unterpunkte  Beschaffungsplanung (Was ist wann zu beschaffen? ),  Solicitation Planning (Festlegung der geforderten Produkteigenschaften und Bestimmung möglicher Beschaffungsquellen),  Solicitation (Ausschreibung, Einholen von Angeboten etc.),  Contract Administration (Vertragsmanagement) und  Contract Closeout (Abschließende Arbeiten der Vertragsabwicklung). Der PMBOK schließt mit einigen Anlagen, darunter einem Glossar. Kritik Bei der Bewertung der „Bibel des Projektmanagements“ wurde berücksichtigt, dass kein umfassendes Lehrbuch vorgesehen war. Die folgenden kritischen Bemerkungen lassen sich zunächst kurz so zusammenfassen: 1. Die außerordentlich starke Prozessorientierung hat zur Folge, dass wichtige Themen vernachlässigt oder, um das in Grenzen durchaus nützliche Schema Input- Tools and Techniques-Output um jeden Preis durchzuhalten, in ein Prokrustesbett gezwängt werden. 2. Neuere Entwicklungen in der Disziplin bleiben weitgehend unberücksichtigt. Der PMBOK spiegelt im besten Fall den Wissensstand der frühen 80er-Jahre wider. Allerdings war man, wie die Proceedings der Tagung zeigen, schon auf dem Weltkongress 1979 in Garmisch-Partenkirchen erheblich weiter. Organisationspsychologische Aspekte (heute auch mit dem Ausdruck „Soft factors“ umschrieben) kommen viel zu kurz. 3. Der Guide enthält eine Menge akademischen Plunder, der vorwiegend aus den Elfenbeintürmen der Disziplin „Operations Research“ an das Tageslicht gezerrt wurde. Zu 1.: Die starke Prozessorientierung, die sich in unserer Disziplin immer mehr breit macht - z. B. jetzt auch in der neuen Version der ISO 9000: 2000 -, ignoriert völlig den simplen Sachverhalt, dass der interne oder externe Kunde mehr an der Produktals an der Prozessqualität interessiert ist. Folgerichtig werden deshalb z. B. erfolgversprechende Ansätze zur Systematisierung und Operationalisierung von Leistungszielen, insbesondere im IT-Bereich, und Fragen der Umsetzung von Kundenwünschen in technische Produktziele ignoriert. Zynisch könnte man sagen: Als wir die Projektziele aus dem Auge verloren hatten, verdoppelten wir unsere Anstrengungen, die Prozesse zu beschreiben. Geradezu groteske Auswirkungen hat das Überstreifen der Zwangsjacke „Prozessorientierung“ im Kapitel 9 (Project Human Resource Management). Einem Organisationspsychologen müssen sich die Haare sträuben, wenn er zum Thema „Teamentwicklung“ das in Abb. 1 dargestellte Schema, das absichtlich nicht übersetzt wurde, sieht. Was soll man sich z. B. unter dem „Tool“ oder der „Technique“ „General management skills“ vorstellen? Das Fürchten könnte man lernen, wenn man dann den folgenden Satz liest: „Reward and recognition systems are formal management activities that promote or reinforce desired behaviour.“ Da hört man doch die Hunde Pawlows laut bellen und sieht ihren Speichel tropfen. Zu 2.: Wer sich aus dem Guide Aufschlüsse über neuere Entwicklungen verspricht, wird alles in allem sehr enttäuscht werden. Zwar kann man auf S. IX ein Lippenbekenntnis zu einigen aktuellen Themen Input Tools and Techniques Output 1. Project staff 2. Project plan 3. Staffing management plan 4. Performance plan 5. External feedback 1. Teambuilding activities 2. General management skills 3. Reward and recognition systems 4. Collocation 5. Training 1. Performance improvement 2. Input to performance appraisals Abb.฀1: ฀Prozessschema฀für฀Teamentwicklung 37฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 (Zusammenhang zwischen Projektmanagement und Unternehmensstrategie und Project Office) lesen, das war es aber dann auch. Zu folgenden Stichwörtern gibt es so gut wie keine nützliche Information:  Projektauswahl und Unternehmensstrategie,  Projektbenchmarking,  Multiprojektmanagement und Programmmanagement,  Kompetenzmodelle für Projektpersonal,  Lernen aus Projekten und  Projektorientierte Organisation. Auch über Innovationen auf dem Gebiet der Rechnerunterstützung (z. B. Groupware für dislozierte Projektteams) ist nichts zu lesen. Unverständlich ist auch, warum das Thema der Akzeptanz von Projektmanagement, das z. B. im Reifegradmodell von Kerzner mit Recht eine überragende Rolle spielt und das ich selbst angesichts der auch in den USA zu registrierenden Anwendungslücke für ein Kernthema halte, nicht bearbeitet wurde. Man muss es schließlich als Armutszeugnis betrachten, wenn dem riesigen Gremium, das an der Erstellung des „Neuen Testaments“ beteiligt war, zum Begriff „Program“ nur folgende Definition einfällt: „A group of related projects managed in a coordinated way. Programs usually include an element of ongoing work.“ Diese Begriffbestimmung ist nicht nur für praktische Zwecke unbrauchbar, sondern auch ein Widerspruch zur Definition des Terminus „Projekt“ zu Beginn des „Guide“. Dort wird nämlich aus guten Gründen jedes normative Element vermieden, das beim „Programm“ plötzlich durch den Zusatz „coordinated“ eingefügt wird. Selbstverständlich kann ein Projektportfolio oder ein Programm auch dann vorliegen, wenn es keine koordinierenden Aktivitäten gibt. Dass man ein Programm sehr wohl präzise von einem Projektportfolio unterscheiden kann, hat G. Lomnitz in seinem Buch „Multiprojektmanagement. Projekte planen, vernetzen und steuern“ (Landsberg/ L. 2001) überzeugend gezeigt. Zu 3.: Verstreut über den ganzen Text finden sich viele Hinweise auf Verfahren aus dem Operations Research, so z. B. im Kapitel 4 (Ablauf- und Zeitplanung) auf die stochastische Variante von PERT (Beta-Verteilung der Vorgangsdauern), auf GERT, auf die unsäglich einfältigen Modelle zur kostenminimalen Projektdauerverkürzung, auf Monte-Carlo-Simulation und auf Heuristiken zur optimalen Zuweisung von Einsatzmitteln, im Kapitel 11 (Risikomanagement) auf die Entscheidungsbaumanalyse und im Kapitel 5 (Scope Management) auf Modelle der linearen und ganzzahligen linearen Optimierung und AHP (Analytical Hierarchy Process). Liest man die entsprechenden Ausführungen, glaubt man sich um viele Jahre zurückversetzt, als noch die Apostel des Operations Research ihr Unwesen ungestraft in unserer Disziplin treiben konnten. Es müsste sich doch, wenn es selbst deutsche Ordinarien langsam kapieren, auch in den USA z. B. herumgesprochen haben,  dass man das sehr komplizierte Problem der optimalen Zusammensetzung des Projektportfolios nicht mit linearer oder ganzzahliger linearer Optimierung lösen kann,  dass es aus sehr guten Gründen, vorsichtig gesagt, so gut wie keinen praktischen Einsatzfall für stochastische Netzplantechniken wie GERT gibt,  dass die heuristischen Verfahren zur optimalen Zuweisung von Einsatzmitteln zu Vorgängen eines Netzplans gescheitert sind, weil die Ressourcenplanung auf Vorgangsebene ein Irrweg war und die Algorithmen zu wenig „Intelligenz“ hatten,  dass die Modelle zur kostenminimalen Verkürzung der Projektdauer auf geradezu absurden und völlig unrealistischen Prämissen basieren und  dass Entscheidungsnetztechnik möglicherweise ein probates Mittel ist, um Studenten zu quälen, dass sie in realen Entscheidungssituationen aber keine Rolle spielt. Das kann man sogar in nicht sonderlich praxisnahen deutschen BWL-Lehrbüchern nachlesen. Zusammenfassende฀Schlussbewertung Auch auf die Gefahr hin, dass mir vorgeworfen wird, als GPM-Mitglied Partei zu sein, sage ich: Der Guide ist ein gut-, z. T. überstrukturiertes, aber inhaltlich antiquiertes und deshalb schlechtes Buch, das den Namen „Führer“ nicht verdient und das nicht mehr in unsere Zeit passt. Wichtige Themen werden nahezu ignoriert. Die sture Prozessorientierung versperrt den Blick auf andere Ansätze und wirkt an manchen Stellen fast peinlich. Die in einer Reihe von Passagen deutlich spürbare OR-Gläubigkeit mutet in einem für Praktiker geschriebenen Leitfaden sehr befremdend an und birgt darüber hinaus die Gefahr, dass Anfänger in die Irre geleitet werden. Warum das Werk so misslungen ist, kann man nur ahnen. Beim Zählen der Personen, die mitgewirkt haben und denen deshalb gedankt wird (Advisory Group: 6; Update Project Team: 8; Contributors: 12; Reviewers: ca. 150), kommt einem allerdings das Sprichwort „Viele Köche verderben den Brei“ in den Sinn. Kommen wir auf die eingangs gestellte Frage zurück: Ex occidente lux? Kommt aus dem Westen wirklich die Erleuchtung für das systematische Management von Projekten? Kann der PMBOK für uns ein Vorbild sein? Man könnte mit Remarque antworten: „Im Westen nichts Neues.“ Noch deutlicher gesagt: Lassen Sie die Finger von diesem Buch, wenn Sie nicht, z. B. bei einer Kooperation mit einer amerikanischen Firma, mehr oder weniger dazu gezwungen werden. Für Fortgeschrittene lohnt sich die Lektüre nicht, für Anfänger ist sie verwirrend. Wegen der schon zu Beginn erwähnten aggressiven Expansionspolitik des PMI ist trotzdem zu befürchten, dass der Guide immer weiter verbreitet wird. Schade, denn unsere Disziplin hätte ein besseres „Heiliges Buch“ verdient. Wenn es stimmt, dass die verkaufte Auflage bei einer Million liegt, dann ist das erschreckend. Die mehrmals zitierte International Competence Baseline der IPMA ist zwar nicht ganz mit dem PMBOK vergleichbar und auch nicht völlig frei von Mängeln, schlägt aber, was Qualität und Aktualität betrifft, das Produkt des PMI um Längen. Die Erfahrung lehrt aber leider, dass sich bessere Qualität nicht immer auf dem Markt durchsetzt.  38฀฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 WISSEN Literatur [1]฀Project฀Management฀Institute฀(Hrsg.): ฀A฀Guide฀to฀the฀Project฀Management฀ Body฀of฀Knowledge.฀PMBOK฀Guide฀2000฀Edition.฀Newton฀Square฀Pennsylvania฀ 2000,฀216฀S.฀,฀ISBN฀1-880410-23-0,฀Paperback Schlagwörter International฀Competence฀Baseline฀(ICB),฀International฀Project฀Management฀Association฀(IPMA),฀Project฀Management฀Body฀of฀Knowledge,฀Project฀ Management฀Institute฀of฀America,฀Projektmanagement-Kanon Autor Prof.฀Dr.฀Heinz฀Schelle,฀geb.฀1938,฀ist฀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 Universität฀der฀Bundeswehr฀München Fachbereich฀Informatik Werner-Heisenberg-Weg฀39 D-85577฀Neubiberg E-Mail: ฀h.schelle@gaponline.de 40฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Hamburger฀„ELAN“-Projekt: Mit฀Stakeholder-Management฀zum฀globalen฀Datennetz!  ฀ Seine Geschäftsbeziehungen hat der hanseatische Ölspezialist „Marquard & Bahls AG“ weltweit ausgedehnt. Jetzt zurrt Europas größter konzernunabhängiger Mineralölimporteur und Tanklagerhalter auch sein Datennetz rund um den Globus fester. Die Tochtergesellschaften in rund dreißig Ländern Europas, Asiens und Amerikas rücken datentechnisch näher an die IT-Struktur der Mutter in der traditionsreichen Hamburger Admiralitätsstraße. Mit dem rund neunmonatigen IT-Projekt „ELAN“ („Environment for Launching Applications & Networking“) spannt Marquard & Bahls sein Netz und entwickelt eine einheitliche Kommunikationsplattform. Spätestens im Frühjahr soll, so die Planung, die Plattform auf Basis von „Lotus Notes“ arbeiten. Ein Projekt, das den Arbeitsalltag der meisten der 1.400 Mitarbeiter berührt. Die neue Plattform erleichtert die tägliche Arbeit, beschleunigt die Kommunikation, schafft Transparenz. Rund um den Globus loggen sich die Spezialisten für Ölhandel und Öllagerung ins Firmennetz ein. Keine geringfügigen Tugenden auf dem umkämpften, sich ständig wandelnden Markt. Herausforderung für das Unternehmen: erstmals ein wirklich globales Projekt, das sich über alle Ländergrenzen und (vor allem) über alle Grenzen der eigenständigen Firmentöchter erstreckt. Für das im technischen Projektmanagement versierte Handelshaus eine neue Dimension, für die es international erfahrene, externe Projektbegleiter einschaltete. „Wir mussten die einzelnen Tochtergesellschaften und deren Mitarbeiter für unser Projekt gewinnen“, erklärt Projektleiter Christoph Lindke, der sein weltweit verteiltes Team von Hamburg aus koordiniert. Und: „Überzeugungsarbeit war neben der technischen Realisierung eine wichtige Projektanforderung.“ Eine IT-Lösung, weiß er, funktioniert nur so gut, wie die künftigen Nutzer sie auch akzeptieren. Wer hier ausschließlich die Technik im Auge hat, kann schnell mit seinem Vorhaben Schiffbruch erleiden. Projektmarketing, mehr als nur ein „Nice-to-have“. Die Stakeholder-Analyse beim Kickoff listete zehn verschiedene Gruppen auf - angefangen vom Vorstand über Senior-Manager, Abteilungsleiter und Bereichsleiter bis hin zu Sekretariat und Power-User. „Jede Gruppe hat andere Informationsbedürfnisse“, hat Christoph Lindke festgestellt. Die künftigen Nutzer, beispielsweise im Sekretariat, müssen mit dem System arbeiten lernen. Anders das Top-Management. Es benötigt zusätzlich strategisch wichtige Nachrichten aus dem Projekt. Noch anders die IT-Fachleute des Unternehmens, die technische Informationen brauchen. Um die Informationen aus dem Team in die Breite zu tragen, definierte das Projektteam so genannte „Key Contacts“, rund sechzig Abteilungsleiter und Niederlassungsleiter, die in ihrer Mannschaft die neue Kommunikationsplattform promoten. Sie sind die Multiplikatoren und „Sprachrohre“ des Teams. Hinzu kommen achtzig Power-User mit der Aufgabe, die Handhabung der neuen Kommunikationsplattform zu verbreiten. Dabei stellte das Team schnell fest, dass Projektmarketing ein aktiver Prozess ist, mehr ein „Verkaufen“ als nur Informationsangebot. „Wir฀mussten฀die฀einzelnen฀Tochtergesellschaften฀und฀deren฀Mitarbeiter฀ für฀unser฀Projekt฀gewinnen“,฀erklärt฀ Projektleiter฀Christoph฀Lindke฀(Marquard฀&฀Bahls),฀der฀sein฀weltweit฀ verteiltes฀Team฀von฀Hamburg฀aus฀ koordiniert. ELAN-Projektleiter฀Christoph฀Lindke: ฀ „Beim฀Projektmarketing฀reichte฀es฀ nicht฀aus,฀Informationen฀allein฀im฀ Intranet฀auf฀einer฀speziellen฀Projektwebseite฀bereitzustellen.“ Projektberater฀Michael฀Köhler฀ (Consensa,฀Hamburg)฀begleitete฀ das฀ELAN-Projekt: ฀„Projektleiter฀im฀ Tagesgeschäft฀haben฀nicht฀immer฀ Zeit฀und฀Distanz,฀ganzheitlich฀die฀verschiedenen฀Prozessebenen฀im฀Auge฀ zu฀halten.“ Foto: ฀privat Foto: ฀privat Foto: ฀privat 41฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 „Es reicht nicht aus, Informationen allein im Intranet auf einer speziellen Projektwebseite bereitzustellen“, warnt Christoph Lindke vor einer Falle im Projektmarketing. Hier suchen bereits Interessierte nach Antworten auf ihre Fragen, Mitarbeiter, die dem Projekt gegenüber ohnehin aufgeschlossen sind. Um Informationen gezielt zu „pushen“, braucht man mehr: zunächst eine sorgfältige Analyse der Stakeholder, dann mögliche Informationskanäle, die tatsächlich bis auf die Schreibtische der Adressaten reichen. „In einer Matrix haben wir den Stakeholdern die jeweiligen Informationsbedürfnisse mit entsprechenden Medien zugeordnet“, erläutert der Projektmanager. Wer bekommt den regelmäßigen E-Mail- Newsletter? Wer wird wie auf die Homepage des Projektteams aufmerksam gemacht? Wer wird über die Beiträge in der Firmenzeitschrift „Fleetpost“ erreicht? Wer benötigt technische Update-Informationen, wer strategische Informationen und Präsentationen, wer Schulungen? Mit diesem Plan in der Hand konnte das Team seine Aufgaben zuverlässig abarbeiten. Was für die Stakeholder außerhalb des Projekts gilt, gilt auch für den Informationsfluss in dem international zusammengesetzten, weltweit verteilten Projektteam. Hier richtete das Team unter anderem eine Datenbank für die Projektdiskussion ein, eine Art erweiterten Chat, in dem Nachrichten diskutiert und Dateien bereitgestellt werden. Vorteil dieser Datenbank: Rund um die Uhr können alle Mitglieder auf aktuelle und zurückliegende Beiträge zugreifen. „Das macht Sinn, wenn aufgrund der Zeitverschiebung nicht alle Mitarbeiter beispielsweise an einer Telefonkonferenz teilnehmen können“, hat Christoph Lindke festgestellt. Aktives Projektmarketing und zuverlässige Kommunikation kosten Zeit: eine Zusatzaufgabe für den ohnehin stark eingespannten Projektmanager. Christoph Lindke nahm Projektbegleiter an Bord, die den Prozess mit gestalteten und in den wichtigen Phasen das Projekt moderierten. „Das war“, meint Christoph Lindke, „eine wichtige Ergänzung zu unserer eigenen Methodik.“ Die Begleiter haben gewissermaßen den Prozess im Fluss gehalten, Hilfe zur Selbsthilfe, wie Christoph Lindke meint. Positiv überraschend für das Projektteam war der ungewöhnlich umfassende Ansatz der Projektbegleiter. Das Problem vieler technischer Projekte: Ihr Hauptaugenmerk gilt zumeist den rein technisch-fachlichen Lösungen und Projektzielen. „Neben diesem reinen Produktionsprozess eines Projekts sind aber weitere Prozessebenen für den Projekterfolg bedeutsam“, erläutert Michael Köhler, der gemeinsam mit Merle Runge für die Beratungsgesellschaft Consensa (Hamburg) das ELAN-Projekt unterstützte. So werde der Projektprozess aus vier verschiedenen „Prozessfäden“ gesponnen: dem Produktionspro- „Marquard฀&฀Bahls฀AG“฀gilt฀als฀Europas฀größter฀konzernunabhängiger฀Mineralölimporteur฀und฀Tanklagerhalter. „Marquard฀&฀Bahls฀AG“฀zurrt฀sein฀Datennetz฀rund฀um฀den฀Globus฀fester. Foto: ฀Marquard฀&฀Bahls฀AG Foto: ฀Marquard฀&฀Bahls฀AG 42฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 zess, dem Projektmanagementprozess, dem Teamprozess und dem Entscheidungsprozess. Diese vier Ebenen gelte es im Auge zu halten. Prozessbegleiter - so die Strategie - tragen moderierend und coachend Sorge, dass möglichst alle vier Ebenen im Projekt berücksichtigt und bearbeitet werden. Was im Vier-Ebenen-Modell noch theoretisch klingt, schlägt sich praxisnah auf das Projekt nieder. Beispiel Projektmanagementprozess: Hier klären Prozessbegleiter mit dem Team genau, welchen Input man für ein Projekt braucht, wo Grenzen und Restriktionen das Vorhaben einengen, welchen Nutzen das Projekt für Strategie und Mitarbeiter eines Unternehmens hat, welche Ergebnisse es haben soll und welche konkreten Aktivitäten sich daraus ergeben. Ähnliches gilt für die Ebene der Entscheidungsprozesse: Hier stehen Entscheidungsgremien, beispielsweise Steuerungsausschuss und Lenkungsausschuss, im Fokus. Welche Rückendeckung hat ein Projekt, was ist an Entscheidungen gefordert, wo zeichnen sich Konflikte ab? - „Projektleiter im Tagesgeschäft haben nicht immer Zeit und Distanz, ganzheitlich die verschiedenen Ebenen im Auge zu behalten“, weiß Prozessexperte Köhler. So moderieren die Projektbegleiter wesentliche Meetings und achten dabei auf gründliche Aussprache zu allen vier Ebenen. Sie helfen - ebenfalls die vier Ebenen im Blick - bei Konflikten, coachen Projektleiter und intervenieren bei plötzlich auftretenden Problemen. In einem umfangreichen Kickoff-Meeting schob Projektleiter Christoph Lindke gemeinsam mit den Consensa-Beratern und dem Projektsponsor Don Drescher (Director IT Development, M&B AG) den Prozess an. Zwei Tage nahm sich das Team Zeit, die Mitarbeiter aus Belgien, den USA und Indien wurden eingeflogen. Diskussionspunkte: Wo liegen die genauen Projektziele? Was bedeutet die angepeilte Lotus-Notes-Lösung für die Anwender? Welche Arbeitspakete ergeben sich daraus? Wie sind die Rollen im Team definiert, wie ist die Zusammenarbeit, die Kommunikation organisiert? „Alles, was die Projektmitarbeiter im Laufe des Prozesses erarbeiten, wird auf Pinnwänden festgehalten und dem Team als Fotoprotokoll übergeben“, erläutert Michael Köhler. So können die getroffenen Vereinbarungen für alle verbindlich umgesetzt werden. - In einem weiteren Review-Meeting machte das Team fünf Monate später Halbzeit. Was haben wir erreicht? Was ist gut gelaufen - was weniger gut? Wo müssen wir justieren, wo können wir etwas lernen? - Prozessbegleitung kann einem Projektleiter hier viel Arbeit ersparen, er kann sich auf seine Kernaufgaben konzentrieren. „Zudem wirkt sich externe Moderation positiv auf das Team aus“, nennt Christoph Lindke einen weiteren Vorteil der Begleitung. Derlei Prozessbegleitung eigne sich, so Michael Köhler, im Prinzip für jedes Vorhaben. Das Team erarbeite seine Vorgehensweise selbst, ihm werde kein fremdes Modell für Projektmanagement „übergestülpt“. Auch rechnet er mit einem hohen Lerneffekt. Dem Team werde nicht Arbeit abgenommen, sondern geholfen, sich selbst zu managen und an der Aufgabe zu wachsen. „Am Ende des Projekts kann man in einem abschließenden Workshop Erfahrungen sichern“, ergänzt er, „das Know-how fließt ins Unternehmen.“ O.฀Steeger Auch฀wenn฀das฀Öl฀im฀Lager฀„ruht“: ฀Schnelle฀Informationen฀sind฀im฀Ölgeschäft฀ erfolgsentscheidend. Das฀hanseatische฀Traditionsunternehmen฀Marquard฀&฀Bahls฀hat฀weltweit฀Geschäftskontakte฀geknüpft. Foto: ฀Marquard฀&฀Bahls฀AG Foto: ฀Marquard฀&฀Bahls฀AG 43฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3  Der Kunde gibt seinen Druck an das Team weiter. Keine Zeit verlieren, schon gar keine Zeit verschenken. Beispielsweise verschenken für den Projektstart. Binnen zehn Monaten soll die neue Softwarelösung in der Testphase sein. Den Wunsch des Projektleiters, in einer „stillen“ Woche den Projektstart vorzubereiten, schmettert der Auftraggeber ab: „Die Zeit, die Sie damit vergeuden, wird hinterher fehlen.“ Hinterher fehlt in der Tat Zeit. Zeit, die Fehler zu Beginn des Projekts zu korrigieren. Und was das für Fehler sind: Streit mit dem Kunden über Auftrag und Leistungsumfang, Kompetenzgerangel und Missstimmung im Team, Ärger mit beteiligten Abteilungen und politische Probleme im Management. Nicht alles, aber vieles wäre vermeidbar gewesen. Nach Expertenmeinung verschenken Deutschlands Projektmanager beim Projektbeginn nach wie vor viele Chancen und bringen sich unnötig in Gefahr. Sie definieren unzureichend Ziele, lassen den Auftrag im Unklaren, entwickeln keinen Teamgeist, machen sich zu wenig Gedanken über die Risiken ihres Vorhabens - all das, was in Projektmanagement-Seminaren betont wird, bleibt im Arbeitsalltag ungehört. Dies, scheint’s, wissen insgeheim auch die Projektmanager selbst. Symptomatisch: Als Beraterin Sabine Peipe vor GPM-Regionalgruppen das „Allerweltsthema“ Projektstart präsentierte, fand sie dicht besetzte Stuhlreihen in den Seminarräumen. „Das breite Echo auf mein Vortragsangebot hat mich überrascht“, meint sie, „Projektstart gehört doch zum kleinen Einmaleins des Projektmanagements.“ Methoden und Vorgehensweisen für den Aufbruch ins Projekt seien bekannt und in nahezu jedem Grundlagenwerk zum Projektmanagement zu finden. Indes, die Praxis lehrt anderes. Zwischen Sollen und Sein klafft ein Bruch. Der fachmännische Start geht im Alltag unter. Zu sehr müssen sich Projektleiter mit Inhalten ihres Vorhabens beschäftigen. Und zu häufig ordnen Kunden und Geschäftsleistung schnellstmöglichen Arbeitsbeginn an. „Da müssen Projektleiter um Zeit und Ressourcen kämpfen, um beispielsweise einen nötigen, eintägigen Kick-off durchzuführen“, klagt die schwäbische Expertin. Ein Ringen, das sich letztlich lohnt. Die Hoffnung, dass sich Startprobleme schon lösen, wenn das Projekt nur seine Betriebstemperatur erreicht hat und auf Touren gekommen ist - diese Hoffnung trügt. Von Phase zu Phase werden die Folgen des verschenkten Starts durch das Projekt gereicht. Auf unheimliche Weise wachsen sie, gewinnen an Kraft. Hand aufs Herz: Welches Problem im Projektmanagement hat sich schon durch Aussitzen gelöst? Typische Situation: Projektinitiatoren und Kunden zeichnen ein unpräzises Bild von den Erwartungen, die sie an das Projekt knüpfen. Stattdessen mahnen sie Tempo an. Projektstartphase, um Ziele und Aufträge zu klären? Kurz halten, kostet Zeit, vieles wird sich ergeben. In der Endphase rächt sich die verpasste Auftragsklärung, in der Ziele und auch Nicht-Ziele festgehalten werden. Dann moniert der Kunde, er habe sich die Ergebnisse anders vorgestellt. Oder er sattelt dem Team unerwartete Arbeitspakete auf, von denen nie die Rede gewesen ist. Gerade bei dieser Auftragsklärung knicken manche Projektleiter ein. „Sie wissen von ihrer Ausbildung her häufig, wie bedeutsam es ist, vor dem Arbeitsbeginn Informationen zu sammeln“, hat Sabine Peipe in ihrer fünfzehnjährigen Beratungstätigkeit festgestellt, „manchen fehlt aber das Selbstbewusstsein, hier auf einer Klärung zu bestehen.“ Oder ihnen fehlt Munition für die Diskussion mit ihren Auftraggebern. Der Hinweis auf die Bedeutung umsichtiger Vorbereitung wird gerne als netter Lehrbuch-Luxus abgetan. Ältere Projektleiter können sich hier auf ihre Erfahrungen berufen, um ihre Sicht vor Kunden, Geschäftsführung oder Lenkungsausschuss zu untermauern. Doch was können junge Projektleiter tun, die nach ihrer Ausbildung in ihr erstes oder zweites Projekt einsteigen? Sabine Peipes Tipp: Anhand von Erfahrungswerten vergangener Projekte nachweisen, wie entscheidend die ersten Schritte für den Erfolg oder Misserfolg des Projekts sind. Die Erfahrungsdatenbank des Unternehmens oder die Meinung anderer Projektleiter kann in der Diskussion helfen. Ähnliches gilt für die anderen Hausaufgaben des Projektstarts. Die Risikoanalyse beispielsweise, die Stakeholder-Analyse, die Kontextanalyse, in der der Zusammenhang des Projekts mit der Unternehmensstrategie ausgelotet wird. Sprichwort unter den Altvordern der Pro- Professioneller฀Projektstart฀-฀Kein฀netter฀„Lehrbuch-Luxus“ Projektmanagementberaterin฀Sabine฀ Peipe: ฀„Projektleiter฀müssen฀bei฀ihren฀ Auftraggebern฀um฀Zeit฀und฀Ressourcen฀kämpfen,฀um฀ihren฀Projektstart฀ fachgerecht฀beispielsweise฀mit฀einem฀ eintägigen฀Kick-off฀durchzuführen.“ Foto: ฀privat Aufbruch฀ins฀Projekt: ฀Ein฀gut฀geplanter฀Start฀ins฀ Ungewisse฀… Foto: ฀LEGO฀Serious฀Play 44฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 jektmanagementszene: „Sage mir, wie du ein Projekt beginnst, und ich sage dir, wie dein Projekt endet.“ Indes, die Experten wollen den Projektstart nicht allein auf sachliche Aspekte begrenzt sehen. Projektstartphasen, so betont Sabine Peipe, dienen mehr als nur der inhaltlichen Kursbestimmung. Sie beeinflussen auch das Projektklima. Zu Beginn des Projekts werden Weichen gestellt, die mit darüber entscheiden, wie das Team zusammenarbeitet und welches Standing der Projektleiter in seiner Mannschaft hat. Mit einem sorgfältigen Projektstart - Kick-off-Meeting inklusive - bestimmt der Projektleiter die soziale Großwetterlage und die Produktivität seiner Mannschaft. Er lebt vor, was er sich von seinem Team wünscht: sorgfältiges Planen, gewissenhafte Umsetzung, offene Kommunikation, Zielorientierung und effiziente Zusammenarbeit. Projektleiter fahren am besten, wenn sie sich zum Start nicht als energische Macher vorstellen. „Sie sind gut beraten, als Moderator zu agieren“, erklärt Sabine Peipe. Also das Team formen, immer wieder die Projektziele verdeutlichen, Kommunikation und Kontakt im Team fördern, gemeinsam mit dem Team eindeutig Verantwortlichkeiten, Rollen und Informationsstrukturen festlegen.“ Für ein gutes Mittel, mit dem Projekt auch die Teamprozesse in Gang zu setzen, hält Sabine Peipe den klassischen Kick-off-Workshop. Es lohne sich, gemeinsam mit dem Team über Zieldefinitionen nachzudenken, mögliche Interessengruppen und ihren Einfluss auf das Projekt zu studieren, Rollen und Regeln im Team festzuhalten, Kommunikationswege zusammen zu diskutieren, Verantwortlichkeiten abzustecken, den Umgang mit Konflikten zu erörtern und Reizthemen wie Pünktlichkeit, den gemeinsamen Umgang miteinander und Berichtspflichten zu bereden. „Das legt eine gute Basis“, weiß Sabine Peipe, „inhaltliche und soziale Fragen werden zugleich besprochen.“ Der Teamprozess komme noch vor dem eigentlichen Arbeitsbeginn in Gang. O.฀Steeger Projektstart-Best-Practice: ฀ Sich฀orientieren฀und฀Ziele฀lösen Projektstart: Die meisten Teams wollen die Ärmel aufkrempeln und sich ans Werk machen. Doch besonders zu Beginn ist Umsicht gefordert: Informationen sammeln, mit den Partnern klären und Entscheidungen dokumentieren - das sind die „stillen“ Startaufgaben. 1. Klären Sie den Auftrag mit Ihrem Projektgeber und Ihrem Team: Was sind die Ziele? Was sind „Nicht-Ziele“, also was soll das Projekt nicht erreichen? 2. Grenzen Sie Ihr Projekt ab: Was ist Anlass und Problem? Welcher Leistungsumfang ist nötig? Wie steht es um das Budget, um die Risiken, aber auch die Chancen? 3. Klären Sie die Rollen im Projekt: Welche Rolle haben beispielsweise Auftraggeber, Projektleiter, Team-Mitglieder und betroffene Fachabteilungen? Wo liegen die jeweiligen Kompetenzen? 4. Analysieren Sie den Kontext, in dem Ihr Projekt steht: Wo sind Zusammenhänge mit der Unternehmensstrategie, den Unternehmenszielen, mit anderen Projekten, mit wirtschaftlichen, technischen, gesetzlichen und politischen Einflussfaktoren? Welches Umfeld hat Ihr Projekt, wen beeinflusst es, wen beeinflussen Sie mit Ihrer Arbeit? Und: Was war vor dem Projekt - und was wird nach dem Projekt noch kommen? 5. Formulieren Sie Ihre Projektziele: Welche Leistungen müssen zu welchen Terminen mit welchem Budget erbracht werden? Achten Sie auf die SMART-Regel, Ziele sind spezifisch, messbar, aktiv beeinflussbar und anspruchsvoll, realistisch und terminiert. Und: Dokumentieren Sie die Termine. Ein฀umsichtig฀durchgeführter฀Projektstart฀hilft,฀die฀Projektfäden฀in฀der฀Hand฀zu฀halten. Foto: ฀Siemens Kommunikationsstrukturen฀im฀Projekt฀festlegen,฀eine฀bedeutsame฀Aufgabe฀in฀ der฀Startphase฀eines฀Projekts Foto: ฀Nokia 46฀฀ GPM฀INTERN P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Dr.฀Ulrich฀Wolff฀zum฀GPM-Ehrenmitglied฀ ernannt  Projektmanagement-Ausbilder scheinen derzeit auf einer Insel der Seligen zu leben: Den Weiterbildungsmarkt haben rauhes Klima und Eistreiben erfasst. Eitel Sonnenschein dagegen bei Kursen zu Projektmanagement-Qualifizierungen. Von Wachstum um die 20 % ist die Rede, eine florierende Marktnische, in der auch der Lehrgang „Projektmanagement-Fachmann“ der GPM wächst und gedeiht. „Rund 3.500 PM-Fachleute hat die GPM bislang qualifiziert“, berichtet GPM-Vorstand Dr. Ulrich Wolff nicht ohne Stolz, „Tendenz stark steigend.“ Die Erfolgsbilanz des Lehrgangs vermeldete Dr. Ulrich Wolff auf der jüngsten GPM-Mitgliederversammlung - allerdings zum letzten Mal. Nach zwölf Jahren gab er den Vorsitz ab. Er schied aus dem Vorstand aus, eine dritte Wiederwahl gestattet die Satzung des Fachverbands nicht. Es befriedigt ihn, seinem Nachfolger ein gutes Erbe zu hinterlassen. Die Chancen stehen gut, dass der Vorstand im nächsten Jahr seinen Mitgliedern ähnlich gute Zahlen kundtut. Und er weiß, dass der Vorstand den Lehrgang weiterhin pflegen wird, eine beruhigende Gewissheit. Immerhin hat Dr. Ulrich Wolff den Lehrgang als federführender Projektleiter konzipiert, immer wieder aktualisiert und als zuständiger Vorstand betreut. Der PMF, sein „Baby“? Eher: Eines seiner Babies. Sein Lieblings-Baby? Vielleicht. „Es ist befriedigend, etwas zu initiieren, sich gemeinsam mit Mitstreitern für etwas einzusetzen und dann zu sehen, wie die Sache fruchtet“, meint er sachlich. Doch seine Mimik verrät: Es freut ihn, dass der PMF gewissermaßen erwachsen geworden ist und auf eigenen Füßen steht. So berichtet Dr. Ulrich Wolff mit sympathischer Zurückhaltung auch über die anderen Erfolge seiner zwölfjährigen Vorstandstätigkeit. Da sind die ständig steigende Mitgliederzahl des Fachverbands, der Aufbau der Geschäftsstellen von GPM und PM-ZERT in Nürnberg und der Weltkongress in Berlin. Beachtliches, meint er, was sich in den zwölf Jahren ereignet hat, was er mit seinen Kollegen und vielen Helfern „gestemmt“ hat. Bei aller Selbstbescheidung stellt Dr. Wolff sein Licht nicht unter den GPM-Mitglieder: ฀ 2.927 Davon฀Firmenmitglieder: ฀ 177 Teilnehmer฀am฀Lehrgang฀„Projektmanagement-Fachmann“: ฀ 4.003 Durch฀PM-Zert฀vergebene฀Projektmanagement-Zertifikate฀insgesamt: ฀ 1.615 ฀+ +++ +++ +++ +++ +++ + ฀+ +++ +++ +++ +++ +++ + Dr.฀Ulrich฀Wolff: ฀Zwölf฀Jahre฀im฀ Vorstand฀der฀GPM,฀zuletzt฀als฀Vorsitzender Foto: ฀privat Scheffel. Er hat einen angenehmen Weg gefunden, Fakten sprechen zu lassen - und dann anderen zu überlassen, darüber zu befinden. Eben dies haben die GPM-Mitglieder auf der jüngsten Versammlung getan. Sie ernannten den Weimarer Projektmanagement-Experten mit langem Applaus zum Ehrenmitglied, eine Anerkennung für das Engagement und Verdienst des Projektmanagement-Spezialisten. Diese Verdienste, so wissen ältere GPM-Mitglieder, erstrecken sich längst nicht nur auf die Projektleiter-Qualifizierung. Dr. Ulrich Wolff gilt als Projektmanagement-Pionier in der ehemaligen DDR, dann als Vermittler zwischen Ost und West, schließlich als ein energischer „Vereiniger“ der beiden deutschen Projektmanagement-Verbände. So war an die Wiedervereinigung Deutschlands noch gar nicht zu denken, da hat er bereits mit gleich gesinnten Kollegen Kontakte und Fachaustausch zwischen Projektmanagern aus West und Ost organisiert. 1983 traf sich die Fachgruppe „Projektlenkung“ in Friedrichshütte mit Experten aus der West-GPM, darunter Klaus Pannenbäcker, Roland Gutsch und Prof. Sebastian Dworatschek. Der „westlastige“ Begriff Projektmanagement war im Osten Deutschlands mit eisernem Tabu belegt. Das hinderte die Experten nicht, bis spät in die Nacht eben doch zu diesem Thema zu diskutieren. Im Sommer 1990, kurz nach der Wende reiste er mit weiteren Fachkollegen nach Bremen, um westliches Projektmanagement-Knowhow aus erster Hand zu lernen. „Das war für uns eine wichtige Hilfeleistung der GPM“, meint er heute. 1990 gründete er mit Dr. Wolfgang Schallehn die GPM der DDR, sie wurde 1991 auf einer gemeinsamen Vorstandssitzung in Weimar mit der West-GPM zusammengeschlossen. Im gleichen Jahr rief er für die „Gesamt-GPM“ die Regionalgruppe Weimar/ Thüringen ins Leben und leitete sie bis 1996. In den Vorstand gewählt machte er die Ausbildung und Weiterbildung zu seiner Sache, ein Ressort, das sich mehrfach wandelte, aber immer in seiner Hand blieb. Weiterer Meilenstein: 1993 organisierte er als Projektleiter das Projektmanagement- Forum in Weimar, das erste GPM- 47฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 1 / 2 0 0 3 Forum auf dem Boden der Neuen Bundesländer. Rund 500 Teilnehmer reisten in die Kulturstadt. Zufrieden und erstaunt zugleich sah er seit 1993 auch das zarte Pflänzchen „Lehrgang Projektmanagementfachmann“ wachsen. 1996 gab er mit seinem Team dem Lehrgang ein neues Konzept. Sozialkompetenz floss vermehrt in die Lehrinhalte ein, Übungen sollten den Praxistransfer verbessern, ein neues Lizenzmodell für größere Verbreitung sorgen. 35 Trainer wurden 1998 speziell für den Lehrgang ausgebildet und lizenziert (heute: 65 Trainer). Dann, im Januar 2000, absolvierte der eintausendste Projektmanagement-Fachmann das Curriculum, sieben Jahre nach dem Start. Im Sommer 2001 die Nachricht aus der Geschäftsstelle: Der zweitausendste Fachmann steht vor dem Abschluss. „Sieben Jahre haben wir für das erste Tausend gebraucht“, wunderte sich Dr. Ulrich Wolff, „nicht einmal zwei Jahre für das zweite Tausend.“ Das Projekt nahm Fahrt auf, das „Baby“ lernte allein zu laufen. Genug Zeit für etwas Neues, ein neues Projekt, ein neues Produkt. „Dieses Neue war dann die Zertifizierung“, berichtet Dr. Ulrich Wolff. Gemeinsam mit Dr. Erhard Motzel, Prof. Sebastian Dworatschek und Klaus Pannenbäcker ließ er sich zum Quartett der „Ur-Assessoren“ ausbilden, zu Fachleuten, die selbst Assessoren für ihre Aufgaben vorbereiten dürfen. Damit stieß er ein zweites Angebot der GPM an. Heute haben bereits 1.000 Projektmanager das Zertifikat der unabhängigen, GPM-eigenen Zertifizierungsstelle „PM ZERT“ erhalten. „Auch hier zeichnet sich ein großer Erfolg ab“, meint Dr. Ulrich Wolff. Das alles hätte sich Dr. Ulrich Wolff vor 20 Jahren nicht träumen lassen, als er erstmals die Projektmanagement-Brücken von Weimar aus Richtung Westen schlug. Und erst recht nicht 1964, als er erstmals mit der Netzplantechnik in Berührung gekommen war. Er war Bauleiter und wissenschaftlicher Mitarbeiter an der damaligen „Hochschule für Architektur und Bauwesen“ in Weimar und promovierte 1968 zum Thema „Kostenoptimierung in der Netzplantechnik“. Ein für die Planwirtschaft sehr theoretisches Gebiet, wie er mit leiser Ironie berichtet. „Wir kannten ja nur Festpreise“, erzählt Dr. Ulrich Wolff, „ob Sie einen Kubikmeter in Jena oder Rostock kauften - er kostete überall gleich viel.“ Milde gesagt: Keine gute Grundlage für Kostenrechnung. Bauprojektleiter in der DDR - unter Umgehung westlicher Begrifflichkeiten „Auftragsleiter“ genannt - mussten ohnehin andere Qualitäten beweisen. Beispielsweise Organisationstalent und Phantasie, um die Mangelware Baustoffe aus allen Gegenden herbeizuschaffen. Notfalls auch selbst hinter dem LKW-Steuer. Auf฀der฀jüngsten฀Mitgliederversammlung฀wurde฀der฀scheidende฀GPM-Vorsitzende฀Dr.฀Ulrich฀Wolff฀zum฀Ehrenmitglied฀ernannt.฀Auf฀dem฀Foto฀überreicht฀ihm฀ Vorstandsmitglied฀Günter฀Rackelmann฀(links)฀die฀Ernennungsurkunde. Foto: ฀Oliver฀Steeger 1971 wurde Dr. Wolff in Weimar zum Hochschuldozenten berufen, er begründete erstmals das Lehrgebiet Projektmanagement in der DDR. Mit dem Begriff „Leitung und Organisation der Bauproduktion“ umging man sorgfältig den politisch missliebigen Begriff Management. „Faktisch habe ich mich wahrscheinlich als einer der Ersten in der DDR wissenschaftlich mit dem Thema Projektmanagement beschäftigt“, berichtet Dr. Ulrich Wolff. Und als er 1973 nochmals zum Bau zurückkehrte und an der Rekonstruktion der Berliner Charite mitwirkte - da waren die Parallelen zum (westlichen) Projektmanagement kaum noch zu übersehen. Ab 1975 baute er an der Bauhaus-Universität in Weimar die Betriebswirtschaftsinformatik und das Projektmanagement auf - eben das Forschungsfeld, das der 65-Jährige bis heute leitet und demnächst auch an einen Nachfolger übergibt. „Was das Projektmanagement betrifft, so haben unsere Studenten heute die Zeichen der Zeit erkannt“, meint Dr. Ulrich Wolff. Angehende Bauingenieure und Architekten besuchen Projektmanagement-Lehrveranstaltungen, häufig zusätzlich oder als Wahlvertiefungsfach. Für die berufliche Weiterbildung der Bau-Fachleute leitet Dr. Ullrich Wolff seit 1998 die „Bauhaus Weiterbildungsakademie Weimar e.V.“, ein anerkanntes, so genanntes „An-Institut“ der Bauhaus-Universität, das sich mit derzeit vier Studiengängen unter anderem zum Projektmanagement an berufstätige Ingenieure richtet. Neben Projektmanagement stehen Fabrikplanung, Baumanagement und Bauwerkserhaltung auf dem Lehrplan. „Diese Akademie werde ich weiterhin leiten“, plant Dr. Ulrich Wolff. Und die GPM? „Da gibt es genug Aufgaben“, meint er. Beispielsweise den PMF-Lehrgang weiterentwickeln und aktualisieren, auch die Assessorentätigkeit weiterführen. Aber auch privat ist er aktiv im „Taubacher Männerchor“, der über Weimar hinaus einen guten Ruf genießt. Der scheidende GPM-Vorsitzende interpretiert den „Ruhestand“ eigenwillig - als die „Ruhe, etwas Neues zu beginnen.“ O.฀Steeger