PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
31
2003
141
GPM Deutsche Gesellschaft für Projektmanagement e. V.Ex occidente lux?
31
2003
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 der Operations Research.
pm1410034
34 P R O J E K TMANA G E M E N T 1 / 2 0 0 3 WISSEN Exoccidentelux? KritischeBemerkungenzumPMBOKGuide2000Edition[1] HeinzSchelle NacheinerknappenDarstellungdesInhaltsundderSystematikdesPMBOKwerdendie wesentlichenVorzügeundMängelderPublikationherausgestellt.Kritisiertwerdenvor allemdieüberstrapazierteProzessorientierung,dasFehlenwichtigerThemen,dieweitgehendeVernachlässigungorganisationspsychologischerAspekteunddieBehandlungvonin derPraxiserfolglosenAnsätzendesOperationsResearch. 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. WasisteinProjektundwasverstehtmanunterProjektmanagement? 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überdenInhaltdesGuide,vorerst weitgehendohnekritischeKommentare 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: ProzessschemafürTeamentwicklung 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. ZusammenfassendeSchlussbewertung 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]ProjectManagementInstitute(Hrsg.): AGuidetotheProjectManagement BodyofKnowledge.PMBOKGuide2000Edition.NewtonSquarePennsylvania 2000,216S.,ISBN1-880410-23-0,Paperback Schlagwörter InternationalCompetenceBaseline(ICB),InternationalProjectManagementAssociation(IPMA),ProjectManagementBodyofKnowledge,Project ManagementInstituteofAmerica,Projektmanagement-Kanon Autor Prof.Dr.HeinzSchelle,geb.1938,istInhabereiner ProfessurfürBetriebswirtschaftslehremitbesonderer BerücksichtigungdesProjektmanagementsanderFakultätfürInformatikderUniversitätderBundeswehrMünchen.EristeinerderGründerderGPM,warvon1979bis 1998MitglieddesVorstandsundistheuteEhrenvorsitzenderderGesellschaftundMitglieddesKuratoriums. Anschrift UniversitätderBundeswehrMünchen FachbereichInformatik Werner-Heisenberg-Weg39 D-85577Neubiberg E-Mail: h.schelle@gaponline.de
