34฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 35฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Mängel฀bisheriger฀Studien Befriedigende vergleichende Studien der am Markt verfügbaren Software sind, wie oben schon betont, höchst selten. Wer Rat sucht, wird auf viele Mängel stoßen. Einige dieser Mängel sollen einleitend kurz dargestellt werden, um die Studie von Ahlemann daran zu spiegeln:  Das Angebot ist sehr unübersichtlich, die Versionen folgen schnell aufeinander. Einmal angestellte Marktanalysen werden nicht aktualisiert und veralten deshalb rasch.  Eine einsichtige Kategorisierung der Software fehlt in der Regel. Aus dem Lebensweg eines Projekts bzw. eines Programms von der ersten Idee bis zum Abschluss und zur Entlastung des Projektbzw. des Programm-Managers wird für die Softwareunterstützung zumeist nur ein kleiner Ausschnitt (meist die detaillierte Planung und Kontrolle mit Netzplantechnik) gewählt.  Daraus resultiert, dass häufig nur Programmsysteme untersucht werden, deren Kern die Unterstützung der Netzplantechnik ist.  Umfangreiche Kriterienkataloge mit z. T. über 600 Einzelmerkmalen (Zahl der einplanbaren Vorgänge und Zahl der einem Vorgang zuordenbaren Einsatzmittelarten, um nur zwei Beispiele zu nennen) lassen den potentiellen Benutzer den „Wald vor lauter Bäumen“ nicht mehr sehen und erschweren ihm eher die Entscheidung für ein Programmsystem, als dass sie ihm helfen.  Eigenschaften, die für die Praxis zumeist völlig irrelevant sind (einem Vorgang können z. B. bis zu 100 Einsatzmittelarten zugeordnet werden, oder für jeden Vorgang kann ein anderer Kalender definiert werden), werden mangels Vertrautheit mit der Praxis hoch bewertet.  Dass es für die Software verschiedene Zielgruppen gibt, wird nicht berücksichtigt. Natürlich muss auch der Verfasser dieser Studie mit dem Problem der Aktualisierung fertig werden. Nach seiner Auskunft ist eine turnusmäßige Neuauflage des Marktvergleichs geplant. Die฀Vorzüge฀des฀Modells฀von฀Ahlemann Die weiter oben angeführten Kritikpunkte berücksichtigt Ahlemann in folgender Weise:  In Form des so genannten M-Modells wird eine alles in allem einsichtige Kategorisierung und eine Zielgruppenorientierung geboten.  Auf umfangreiche Kriterienkataloge wird verzichtet. Stattdessen wird klugerweise folgendermaßen vorgegangen: “In contrast to other project management market studies, we have concentrated on a mediumlevel comparison of the systems. For example, you will not find any information about the time-scale of Gantt charts in this study.” Die Begründung, der man nur zustimmen kann, lautet: “We believe that such information is of limited use for companies that are in a early phase of a software selection process.” Das Ziel der Studie lautet: “In this study, project management systems are compared by their functionality to support the overall life cycle of projects and their ability to provide all levels of management with the information relevant to manage not only one but dozens or hundred of projects.” (Die Hervorhebung durch Fettdruck erfolgte durch den Rezensenten). Da das M-Modell nach Ansicht des Berichterstatters richtungsweisend für weitere Arbeiten und von hohem Neuheitsgrad ist, soll es im Weiteren sehr detailliert behandelt werden. Für die Bewertung der einzelnen Prozess-Schritte des M-Modells, die unten dargestellt werden, werden folgende Klassifikationen vergeben: Kein * keine Funktionen: keine Software(SW)-Unterstützung in diesem Bereich, Benchmarking฀von฀PM-Software Vergleichende฀Analyse฀der฀Universität฀Osnabrück Heinz฀Schelle Die฀folgende฀kritische฀Darstellung฀basiert฀auf฀den฀nachstehend฀zitierten฀Studien.฀Nach฀ Meinung฀des฀Berichterstatters฀sind฀die฀Arbeiten฀von฀Ahlemann฀ein฀ganz฀erheblicher฀ Fortschritt฀in฀der฀bislang฀eher฀unzureichenden฀Behandlung฀des฀Themas฀„Software฀zur฀ Unterstützung฀des฀Projektmanagements”.฀Ahlemann,฀F.: ฀Comparative฀Market฀Analysis฀of฀ Project฀Management฀Systems.฀University฀of฀Osnabrück.฀Chair฀of฀Business฀Administration/ Organization฀and฀Information฀Systems.฀Herausgeber: ฀Prof.฀Dr.฀Hoppe,฀http: / / www.pmstudie.de฀(Die฀Studie฀wurde฀im฀Januar฀2003฀abgeschlossen.)฀Ergänzend฀wurde฀folgende฀ Publikation฀für฀die฀Besprechung฀hinzugezogen: ฀Ahlemann,฀F.: ฀Das฀M-Modell฀-฀Eine฀konzeptionelle฀Informationssystemarchitektur฀für฀die฀Planung,฀Kontrolle฀und฀Koordination฀von฀Projekten฀(Projekt-Controlling),฀Januar฀2003.฀Soweit฀Ahlemann฀hier฀deutsche฀Termini฀anbietet,฀ wurden฀sie฀für฀die฀Übersetzung฀der฀Begriffe฀der฀Hauptstudie฀verwendet. 36฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 37฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 * Basisfunktionen: begrenzte SW-Unterstützung in diesem Bereich, ** hohe Funktionalität: erhebliche Unterstützung in diesem Bereich, *** nahezu vollständige Funktionalität: vollständige oder fast vollständige Unterstützung. Projekt,฀Projektprogramm฀und฀Projektportfolio Weiter verwendet der Autor in einer durchgängigen Hierarchie die Begriffe „Projekt“, „Programm bzw. Projektprogramm“ und „Projektportfolio“. Projektprogramme sind eine Zusammenfassung von Projekten, die eine übergeordnete Organisationseinheit verantwortet. Projekte können dabei funktional (z. B. alle Vorhaben der EDV-Abteilung) oder nach der Zielsetzung (z. B. alle Projekte zur Entwicklung, Fertigung und Markteinführung einer neuen Generation von PKWs) zusammengefasst werden. Alle Programme einer Strategischen Geschäftseinheit bilden ein Projektportfolio, das die Strategie dieser SGE implementieren soll. Mit dieser Begriffsbildung unterscheidet sich Ahlemann von Lomnitz, der als wesentliches Merkmal eines Programms, das aus mehreren Projekten bzw. Teilprojekten besteht, genauso wie bei Projekten die zeitliche Begrenzung sieht. Wählt man als Beispiel für ein Programm die schon erwähnte Entwicklung, Fertigung und Einführung eines neuen PKW-Modells, so ist das Programm beendet, wenn das Modell vom Kunden erworben werden kann. Das Projektportfolio erneuert sich dagegen zumindest bei starker Projektorientierung einer Firma ständig durch Beenden bzw. Abbruch von Vorhaben und Aufnahme neuer Projekte. Zielgruppen฀von฀Projektmanagementsoftware: ฀Führungsebenen Der hierarchischen Orientierung folgend werden Projekt, Programm und Projektportfolio drei verschiedenen Führungsebenen zugeordnet. Das Projektportfolio wird der Strategischen Geschäftseinheit (Vorstands- oder Geschäftsführerebene) zugewiesen. Sie hat die Aufgabe, den Projektmix so zu gestalten, dass er mit der gewählten Strategie in Einklang steht (Strategisches Management). Aufgabe der mittleren Führungsebene ist die Planung und Kontrolle des Projektprogramms (Hauptabteilungen oder Abteilungen). Die Koordination solcher Programme wird durch Projekt- oder Programmbüros übernommen. Die Aufgabe auf der mittleren Führungsebene nennt Ahlemann Taktisches Management. Mit dem Operativen Management sind Projektmanager und Projektcontroller beauftragt. Phasen฀und฀Prozess-Schritte Im Lebenszyklus eines Projekts werden auf hoher Abstraktionsebene die Phasen „Initiierung“, „Vorbereitung“, „Durchführung“ und „Abschluss“ unterschieden. Im M-Modell werden diese Phasen in weitere Prozess-Schritte unterteilt. Da die Definitionen des Autors vom üblichen Sprachgebrauch zum Teil abweichen, werden sie, soweit notwendig, wörtlich zitiert.  Gewinnung von Projektideen  Ideenbewertung: Erstes Screening bzw. danach detaillierte Analyse z. B. nach einem vorliegenden Projektplanungsmodell mit technischer und wirtschaftlicher Bewertung einschließlich Risikobetrachtung sowie mit einem ersten groben Zeitplan  Portfolioplanung: Hier wird - so der Verfasser - auf der Ebene der Unternehmensführung „über die Umsetzung von Projekten (Programmen und Portfolios) zur Realisierung der strategischen Zielsetzung entschieden. Somit ist die Strategiefindung mit abschließender Strategiedefinition notwendige Voraussetzung für die Portfolioplanung.“  Programmplanung: Auch hier soll der Autor zitiert werden: „Sobald die Projektprogramme durch die SGE-Führung freigegeben sind, kann die Programmplanung einsetzen. Die Programmplanung verfeinert die in der Bewertungsphase angefertigten Beschreibungen der Projektprogramme und wandelt dabei insbesondere die Personal- und Sachmittelbedarfe in konkrete Ressourcenzuordnungen um. Sofern Programme noch nicht ��������� ��������������� ���������� ���������������������������������������������������� ������������������������������ ���������������������������� �������� �������� �������� �������� ������� �������� ���� ���������� ���� ���������� ��������� �������� ��������� ����������� ������� �������� ������� ����������� ������� �������� ������� ����������� ������� ����������� ������� ����������� ���������� �� �������� Das฀M-Modell 36฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 37฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 in Einzelprojekte überführt wurden, findet diese Überführung statt.“  Projektplanung: Hiermit ist die detaillierte Projektplanung gemeint, die schon seit den Anfängen des Projektmanagements durch entsprechende Software unterstützt wird.  Projektkontrolle  Programmkontrolle: „Die Daten aus der Projektkontrolle münden verdichtet und angereichert in der Programmkontrolle. Aufgabe der Programmkontrolle ist die Koordination der einzelnen Projekte sowie das standardisierte Reporting an die Führungsebene.“  Portfoliokontrolle: „Auf der höchsten Ebene werden auch die Daten der Programmkontrolle verdichtet und bilden die Datenbasis für die Portfoliokontrolle. Die Portfoliokontrolle führt den aktuellen Stand der Programme und Projekte und die aktuelle strategische Stoßrichtung der Unternehmung zusammen und bewirkt - falls erforderlich - eine Korrektur der strategischen Ausrichtung der Programme und Projekte.“  Programmabschluss: „Wird ein Programm als Ergebnis der Portfoliokontrolle abgebrochen oder erreicht es sein vorgesehenes Ende, so erfolgt der Programmabschluss.“  Projektabschluss: „Der Projektschluss umfasst die Sicherung der Projektergebnisse und die Erfolgsrechnung.“ Innerhalb der einzelnen Prozess-Schritte werden weitere Funktionen (functionality) unterschieden, die eine subjektive Gewichtung enthalten. Bei der verbalen Beschreibung wird jeweils gesagt, welche Ausprägung keinem, einem, zwei oder drei Sternen entspricht. Prozess-Schritte฀und฀Funktionen Gewinnung von Projektideen:  Kreativitätstechniken (10 %)  System zum Sammeln von Vorschlägen der Mitarbeiter (30 %) (Betriebliches Vorschlagswesen)  Klassifikation von Ideen und Projekten (60 %) Ideenbewertung:  Workflowsystem zur Unterstützung des Prozesses der Ideenbewertung durch mehrere Instanzen (10 %)  Schätzung der erforderlichen Ressourcen zur Realisierung (35 %) (Aufwandsschätzung)  Risikobeurteilung (20 %)  Kostenschätzung und Rentabilitätsanalyse (35 %) Portfolioplanung:  Bewertung des Beitrags eines einzelnen Projekts oder Programms zur Strategie der Organisation (33 %)  Unterstützung bei der Projektauswahl (33 %)  Messung der Zielerreichung (33 %) Programmplanung:  Projektvorlagen (15 %). Damit sind Standards wie z. B. ein Standard-PSP gemeint, den man aus einem Katalog auswählen kann. So kann z. B. erzwungen werden, dass Projekte nach einem einheitlichen Schema geplant und durchgeführt werden.  Zeitplanung (25 %)  Einsatzmittelplanung (25 %)  Management der Zulieferer und Unterauftragnehmer (10 %)  Budgetierung (25 %) Projektplanung:  Projektstrukturplanung (25 %)  Qualitätsplanung (15 %)  Terminplanung auf der Grundlage der Netzplantechnik (25 %)  Risikomanagement (15 %)  Kostenplanung (20 %) Projektkontrolle (im englischen Text: Project Controlling):  Issue Management, am ehesten wohl mit Änderungsmanagement bzw. Konfigurationsmanagement übersetzt (20 %). Darunter fällt aber auch das, was in der angelsächsischen Literatur Action Item Control genannt wird.  Qualitätskontrolle (quality controlling) (10 %)  Management der Reisekosten (10 %) und sonstiger Ausgaben, die von Projektmitarbeitern vorgenommen wurden  Stundenerfassung (30 %)  Projektbegleitende Kostenüberwachung (30 %) Programmkontrolle:  Projektstatusberichterstattung (30 %)  Budgetkontrolle (30 %)  Auditierung des Budgets (10 %). Der englische Ausdruck lautet Project Auditing. Der Autor versteht darunter im Gegensatz zur laufenden Kontrolle des Projektbudgets die detaillierte Überprüfung der Projektparameter Zeit, Kosten, Qualität etc. „in depth“ mit dem Ziel, Probleme zu identifizieren, die den Programmerfolg gefährden könnten.  Projektüberwachung (30 %). Im englischen Text findet sich derAusdruck „project monitoring“. Hier ist Funktionalität gemeint, die über das statische Berichtswesen weit hinausgeht. So ist es beispielsweise möglich, interaktiv und Ad-hoc-Auswertungen über Projekte anzufertigen. Portfoliokontrolle: Hier gibt es keine weitere Unterteilung. Nach Ahlemann gilt grundsätzlich die gleiche Funktionalität wie bei der Portfolioplanung. Programmabschluss:  Wissensmanagement (80 %)  Projektmetriken (20 %) Projektabschluss:  Testmanagement (30 %). Im englischen Text heißt es „Acceptance/ Testing Management“.  Bewertung des Projektpersonals (20 %)  Beendigung des Projekts (50 %). Der englische Ausdruck lautet „Project Closure“. Wie aus dem M-Modell zu ersehen, gibt es sozusagen phasenübergreifend noch folgende weitere Funktionsgruppen, die das Projektmanagement unterstützen. Auch sie werden in den Softwarevergleich einbezogen. Personalmanagement (Personal Information Management):  Auf den jeweiligen Benutzer zugeschnittene Startinformationen über das Projekt (40 %). Im deutschsprachigen Raum wird hier vielfach der Begriff „Projekt-Portal“ verwendet; er bezeichnet einen personalisierten Start-Bildschirm mit allen Informationen, die den individuellen Mitarbeiter betreffen.  Stakeholdermanagement (30 %). Im englischen Text lautet der Ausdruck „Contact management“. Nach 38฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 39฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Angaben des Verfassers soll mit dieser Funktion das Management der Stakeholder unterstützt werden.  Persönlicher Terminkalender (30 %) für das Selbstmanagement Unterstützung der Teamarbeit (Team Collaboration):  Dokumentenmanagement (50 %)  Automatisches Versenden von Mitteilungen, wenn z. B. ein Termin überschritten wurde (20 %)  Unterstützung von Besprechungen (10 %)  Unterstützung von Diskussionsrunden zu einem bestimmten Thema (5 %)  Unterstützung von Chatting (5 %)  Unterstützung von Abstimmungen und Befragungen (5 %)  Datenbanken (5 %). Ahlemann versteht darunter speziell „table-like structures with configurable columns and an infinite number of rows.“ Das ist eine Spezialfunktionalität einiger Anbieter, beliebige andere Daten zu den Projekten in strukturierter Form abzulegen. Administration/ Konfiguration:  Zugangskontrolle in Multi-User-Software (40 %)  Definition von Berichtsformaten (25 %)  Definition von Formularen (15 %)  Definition von „Views“ für Benutzergruppen (15 %)  Unterstützung von Umrechnung in verschiedene Währungen (5 %) Schnittstellen, um das Projektmanagementsystem in das Unternehmen zu integrieren:  Datenbankschnittstellen (30 %)  Schnittstellen zu MS-Project (25 %)  Datenexport/ -import (15 %)  Schnittstellen zu anderen Anwenderprogrammen (15 %). Gemeint sind „Programmierschnittstellen“, d. h. Schnittstellen, die es Programmierern erlauben, auf die PM-Software zuzugreifen, z. B. um sie mit SAP zu koppeln.  Integration von Systemen wie Outlook (10 %). Ahlemann spricht hier von Personal Information Managers (PIM).  Directory Services (5 %). Gemeint ist Software, die Informationen über alle Arten von Einsatzmitteln verwaltet. Weitere Eigenschaften (Miscellaneous):  Benutzerfreundlichkeit (20 %)  Online-Hilfe (15 %)  Sicherheit (20 %)  Suchfunktionen (15 %)  Möglichkeit des Durchspielens von verschiedenen Szenarien (10 %). Im Text heißt es: Baselining-/ Scenario Techniques. Die Funktion „Baselining“ bedeutet, dass es möglich ist, für spätere Analysen, z. B. für die Meilensteintrendanalyse, Basispläne zu definieren.  Unterstützung von mehreren Sprachen (10 %)  Unterstützung des Arbeitens in verschiedenen Zeitzonen (10 %). Gruppen฀von฀untersuchter฀Software฀(Cluster) Für den Vergleich der Systeme zur Unterstützung des Projektmanagements hat der Verfasser fünf Gruppen definiert, da er mit Recht betont, dass nur ein Vergleich innerhalb der Gruppen Sinn macht. Auch bei dieser Clusterbildung, die natürlich nicht ganz trennscharf sein kann, wurde Pionierarbeit geleistet. Hier die Unterscheidung:  Planungsorientierte Multi-Projektmanagementsysteme (PMS) mit ausgeprägten Funktionen für Termin- und Einsatzmittelplanung (Beispiele: ACOS Plus 1, Primavera P3e-Project Planner for the Enterprise).  Prozessorientierte Multi-Projektmanagementsysteme mit Konzentration auf Qualitäts- und Prozessmanagement. Das Ziel dieser PMS ist es, im Rahmen eines weitgehend standardisierten Projektmanagements das Qualitäsmanagement und den Workflow zu unterstützen (Beispiele: Project Insight, Alpha Project Line).  Ressourcenorientierte Multi-Projektmanagementsysteme mit dem Schwerpunkt auf der Einsatzmittelplanung und dem Ziel, einen Ressourcenpool zu verwalten, Einsatzmittel Projekten zuzuordnen und ihre Verwendung zu kontrollieren. (Beispiel: resSolution).  Umfassende Projektmanagementsysteme (bei Ahlemann: Enterprise Project Management Systems). Systeme dieser Art unterstützen das Projektmanagement über den ganzen Lebensweg eines Projekts oder Programms. Konsequenterweise gehört deshalb die Portfolioplanung im Sinne des Verfassers dazu (Beispiele: PPMS, Artemis Portfolio, Project and Resource Management Solution).  Plattformen zur Unterstützung der Zusammenarbeit im Projekt (Project Collaboration Platform). Systeme dieser Art leisten wenig Hilfe beim Multi- Projektmanagement, bieten aber eine webbasierte Plattform für die Zusammenarbeit von in der Regel dislozierten Projektteams. Nicht untersucht wird „spezifisch funktionale Software“ (Dworatschek). Dazu zählen z. B. Programme zur Kostenschätzung wie etwa PRICE H oder PRICE S oder Software zur Bewertung von Projektrisiken. Bewertungsalgorithmus Für die Bewertung innerhalb der oben definierten Gruppen wurde folgender Algorithmus entwickelt: N = N w spi sp pi i f p ⋅     + = ∑ 1 1 2 Dabei ist in der Terminologie der Arbeit N sp das Ergebnis der Bewertung des Prozess-Schrittes p und der Software s. Ein Prozess-Schritt ist z. B. die Ideenbewertung; f p ist die Anzahl der Funktionen für den Prozess- Schritt p; N spi ist das Bewertungsresultat für die Software s, den Prozess-Schritt p und die Funktion i (entspricht der Zahl der Sterne) und w pi ist das Gewicht der Funktion. Ahlemann erläutert den Algorithmus an folgendem Beispiel: Prozess-Schritt „Ideengewinnung“: Kreativitätstechniken (10 %): ** System zum Sammeln von Vorschlägen der Mitarbeiter (30 %) : * 38฀฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 WISSEN 39฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 4 / 2 0 0 3 Klassifikation von Ideen und Projekten (60 %): *** Aggregiertes Bewertungsergebnis: (2*)*0,1 + (1*)*0,3 + (3*)*0,6 = 2,3*. Der Prozess-Schritt erhält abgerundet 2 Sterne. Wichtig ist in diesem Zusammenhang, dass auf eine Gesamtaggregation der Bewertung zu einer Gesamtpunktzahl verzichtet wurde, da solche Gesamtpunktzahlen mit Recht für nicht wirklich aussagefähig erachtet werden. Bewertete฀Software Nach der beschriebenen Bewertungsprozedur werden nun, jeweils innerhalb der definierten Cluster, 28 Produkte bewertet. MS-Project ist nicht dabei. Nach fernmündlicher Auskunft des Verfassers ist Microsoft angeschrieben worden, hat sich dem Produktvergleich aber nicht gestellt. Das wohl am meisten verbreitete Produkt ist deshalb nur in der Rubrik „Additional Products“ ohne Bewertung zu finden. In dieser Auflistung sind 71 (! ) Programmsysteme aufgeführt. Es werden dort nur die Anbieter, die Anschrift, Telefon- und Faxnummer bzw. E-Mail und Webadresse genannt. Zusammenfassende฀Bewertung Die Arbeit von Ahlemann setzt auf einem von der Theorie weitgehend vernachlässigten Gebiet Maßstäbe. Zukünftige Produktvergleiche werden sich an dieser Studie, die zugleich zeigt, wie kompliziert die Produktlandschaft in den letzten Jahren geworden ist, messen lassen müssen. Das M-Modell, das neben einer Zielgruppenorientierung auch den gesamten Lebenszyklus eines Projekts von der ersten Idee bis zum Abschluss betrachtet, bietet einen überzeugenden Rahmen für die Analyse. Man muss dem Verfasser bei seiner Unterscheidung von Projekt, Projektprogramm und Projektportfolio nicht unbedingt folgen, sie ist aber mit seiner Einteilung in drei Schichten der Führung konsistent. Auch bei der Unterscheidung einiger Funktionen gibt es, wie nicht anders zu erwarten, gewisse Unschärfen. Schließlich sind Zweifel anzumelden, ob die Unterstützung durch Software wirklich überall auf dem Lebensweg eines Projekts Sinn macht. Diese Bedenken gelten vor allem für die frühen Phasen, in denen die Projektbewertung vorgenommen und die Projektauswahl getroffen wird. Die Auswahl von Projekten ist unlöslich mit Macht- und Prestigefragen verbunden. Dem Einsatz von Algorithmen, die den optimalen Projektmix bestimmen, sind deshalb nach Meinung des Rezensenten enge Grenzen gesetzt. Freilich darf man dem Autor nicht zum Vorwurf machen, dass er auch solche Funktionen betrachtet und bewertet. Schließlich werden sie ja von einigen Softwareherstellern angeboten. Wer die Produktstudie aus Osnabrück gelesen hat, hat auf dem Gebiet des Vergleichs von Projektmanagement-Software seine Unschuld verloren und wird den herkömmlichen Analysen, wie sie insbesondere in den verschiedenen Fachzeitschriften zu finden sind, höchst skeptisch gegenüberstehen. Und das ist gut so!  Benchmarking฀zum฀Projektmanagement฀in฀Russland  Wie steht es um das Projektmanagement der europäischen Nachbarländer? Seit einigen Jahren führt die PRO- JEKTMANAGEMENT GROUP der Wirtschaftsuniversität Wien gemeinsam mit der IPMA International Project Management Association internationale Benchmarking-Studien durch. Sie vergleicht die Kompetenz so genannter „Projektorientierter Gesellschaften“ (POS) (vgl. Projektmanagement aktuell 2/ 2002). Jetzt stellte die PROJEKT- MANAGEMENT GROUP Ergebnisse für die Region Moskau (Russland) vor. Die Ergebnisse: Starke Kompetenzen fanden die Fachleute beim Projektmanagement selbst und beim Programm- Management. Auch beim Projektmarketing schnitt das osteuropäische Land überdurchschnittlich ab. Weniger gut wurden die Bereiche Portfolio-Management und Projektorientierte Organisation beurteilt. „Dieses Assessment und Benchmarking hat nicht nur einen wissenschaftlichen Zweck“, bemerken die Autoren der Studie, „es trägt auch dazu bei, Projektmanagement in Russland zu fördern und zu vermarkten.“ So hatte sich auch der russische Projektmanagement-Verband SOVNET an dem Assessment beteiligt. Das Assessment wurde in zwei Stufen durchgeführt. Im ersten Schritt hatten Forscher von SOVNET sowie Moskauer Universitäten ein Benchmarking der PM Services in der Region Moskau vorgenommen. In einem zweiten Schritt erarbeiteten 25 Projektmanagement-Experten aus verschiedenen Branchen Konsensergebnisse zur Bewertung der PM Praxis. Dabei knüpften die Fachleute auch ein persönliches Kontaktnetz für den künftigen Erfahrungsaustausch. Weitere Informationen: Projektmanagement GROUP der Wirtschaftsuniversität Wien, Martina Huemann, E-Mail: martina.huemann@wu.wien.ac.at. Informationen zum Benchmarking-Projekt der Wirtschaftsuniversität Wien mit Download-Möglichkeit der Studien: http: / / www.wu-wien.ac.at/ pmg/ pos/ index.html. Schlagwörter Benchmarking,฀Projektmanagement,฀Software Autor Prof.฀Dr.฀Heinz฀Schelle,฀geb.฀1938,฀war฀Inhaber฀einer฀ Professur฀für฀Betriebswirtschaftslehre฀mit฀besonderer฀ Berücksichtigung฀des฀Projektmanagements฀an฀der฀Fakultät฀für฀Informatik฀der฀Universität฀der฀Bundeswehr฀München.฀Er฀ist฀einer฀der฀Gründer฀der฀GPM,฀war฀von฀1979฀bis฀ 1998฀Mitglied฀des฀Vorstands฀und฀ist฀heute฀Ehrenvorsitzender฀der฀Gesellschaft฀und฀Mitglied฀des฀Kuratoriums. Anschrift Münchner฀Straße฀1 D-82496฀Oberau E-Mail: ฀h.schelle@gaponline.de