Strategisches Projektmanagement || Projektmanagement in der Entwicklung von Werkzeugen für die modellbasierte Entwicklung mechatronischer Regelsysteme

11Projektmanagement in der Entwicklung vonWerkzeugen für die modellbasierte Entwicklungmechatronischer Regelsysteme

Hans-Joachim Rabe

Inhaltsverzeichnis

11.1 Das Unternehmen dSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22811.2 Entwicklungsprojekte bei dSPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22911.3 Die Organisation des Projektmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23011.4 Vorgehensweise bei der Einführung des Projektmanagements . . . . . . . . . . . . . . . . . 231

11.4.1 Die Zusammenstellung des Projektteams . . . . . . . . . . . . . . . . . . . . . . . . 23211.4.2 Die Prozessdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23311.4.3 Die Werkzeugauswahl und die Drehbuchmethode . . . . . . . . . . . . . . . . . . 23411.4.4 Pilotphase und Rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23711.4.5 Die Expertenrunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

11.5 Projektreviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23911.5.1 Projektreview mit Fragebögen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24011.5.2 Projektreviews als Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24111.5.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

11.6 Projektmanagement in Hardware- und Softwareentwicklung . . . . . . . . . . . . . . . . . 24311.6.1 Die Anwendbarkeit des Projektmanagementprozesses . . . . . . . . . . . . . . . 24311.6.2 Typischer Ablauf eines Softwareentwicklungsprojektes . . . . . . . . . . . . . . . 24411.6.3 Typischer Ablauf eines Hardwareentwicklungsprojektes . . . . . . . . . . . . . . 245

11.7 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24611.8 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Dr. H.-J. Rabe (B)dSPACE GmbH, Rathenaustraße 26, 33102 Paderborne-mail: [email protected]

227F. Ahlemann, C. Eckl (Hrsg.), Strategisches Projektmanagement,DOI 10.1007/978-3-642-34761-0_11, © Springer-Verlag Berlin Heidelberg 2013

mailto:[email protected]

228 H.-J. Rabe

11.1 Das Unternehmen dSPACE

dSPACE ist ein junges, rasch gewachsenes Unternehmen, das weltweit Werkzeuge für dieEntwicklung von Steuergeräten und mechatronischen Systemen entwickelt und vertreibt.Dieses Marktsegment hat dSPACE vor mehr als 20 Jahren mitbegründet und prägt es bisheute. Der Schwerpunkt der Anwendungen liegt im Bereich der Automobilindustrie.

Mit diesen Systemen ist es möglich, beim Entwurf von Steuergeräten und Reglern dieEntwicklungszeiten und -kosten drastisch zu reduzieren und damit deren Produktivitätsystematisch zu steigern. Die dafür grundlegende Technologie bildet die Echtzeitsimu-lation mechatronischer Systeme. Neue Regelfunktionen und Erweiterungen bestehenderSysteme können grafisch beschrieben und mit Hilfe automatischer Codegenerierung um-gehend in echtzeitfähige Simulationsprogramme übersetzt werden. Eine zeitraubendemanuelle Umsetzung der Funktionen in geeignete Rechnerprogramme entfällt vollstän-dig. Damit lassen sich auf sehr einfache und für den Regelungstechniker gewohnte WeiseRegelfunktionen beschreiben und an realen Geräten und Fahrzeugen verifizieren. Manspricht in diesem Falle vom sog. Rapid Control Prototyping (RCP). Die Verkürzung derZeiten zwischen der Veränderung der grafischen Beschreibung und der erneuten Über-prüfung am realen System stellen eine erhebliche Effizienzsteigerung für den Kundendar.

In späteren Phasen des Entwicklungsprozesses müssen die fertig implementierten Se-riensteuergeräte getestet werden. Die Echtzeitsimulation wird nun dazu verwendet, daskomplexe Verhalten des vom Steuergerät zu regelnden oder zu überwachenden Gerätes(z. B. das Verhalten eines Verbrennungs- oder Elektromotors, eines Getriebes oder die ge-samte Dynamik eines Gesamtfahrzeugs etc.) zu simulieren. Damit wird es möglich, dieSteuergeräte statt in aufwändigen Feld- und Flottentests bereits im Labor zu testen. Die-ser Fall wird Hardware-in-the-Loop-Simulation (HIL) genannt. Neben der Tatsache, dassdiese Vorgehensweise naturgemäß Zeit und Kosten spart, erhöht sie auch die Sicherheitund die Testtiefe etwa dadurch, dass im Labor in einem simulierten, also virtuellen GerätBetriebs- und Fahrzustände angefahren werden können, die mit realen Geräten z. B. ausSicherheitsgründen gar nicht erreichbar sind.

DasUnternehmen dSPACEbietet ein ausgewogenes Portfolio aus Standardlösungen fürdas Rapid Control Prototyping, die automatische Seriencode-Generierung und die Hard-ware-in-the-Loop-Simulation. Zudem bietet es Dienstleistungen an – von Schulungen vorOrt bis hin zu kundenspezifischemSystem-Engineering, z. B. in Formvon schlüsselfertigenHIL-Testsystemen.

Auch wenn ihr Einsatzschwerpunkt in der Automobilindustrie liegt, kommen die Pro-dukte ebenso in der Luft- und Raumfahrt, der Antriebstechnik, der Medizin oder der In-dustrieautomation zum Einsatz.

dSPACE agiert schon seit langer Zeit international mit Niederlassungen in den USA,Frankreich, Großbritannien, Japan sowie in China. Ergänzend betreuen zahlreiche Distri-butoren die Kunden vor Ort.

11 Projektmanagement in der Entwicklung von Werkzeugen 229

Diese Fallstudie stellt anhand einiger ausgewählterThemendie Erfahrungen dar, die dasUnternehmen dSPACE in den letzten Jahren mit der Einführung, der Werkzeugauswahlund der praktischen Umsetzung des Projektmanagements in der technischen Produkt-entwicklung gemacht hat. Dabei seien unter Einführung nicht nur die Werkzeugauswahl,sondern auch die Definition und die Einführung des Projektmanagementprozesses ver-standen. Es sei ebenso vorausgeschickt, dass sich die in diesem Artikel dargestellte Fallstu-die auf das Projektmanagement in der Produktentwicklung von Entwicklungswerkzeugenbezieht.

11.2 Entwicklungsprojekte bei dSPACE

In der Anfangsphase sind die neu entstehenden Produkte häufig noch überschaubar undmit ihnen die sie betreuenden Entwicklungsteams. In diesen Teams gibt es in der Regel ei-ne noch minimale Aufgabenteilung. Zahlreiche Ideen, die im Gespräch mit Kunden oderim Verlauf der Entwicklung entstehen, lassen sich in solchen Strukturen oft ad-hoc indie Produkte einbauen. Technische Auswirkungen und Risiken sind in kleinen Entwick-lungsteams dadurch, dass alle Experten an einem Tisch sitzen, relativ leicht einschätz-bar. Eine systematische Planung sowie präzise Ermittlung der Termin- und Kostenrahmenvor Projektbeginn werden in einem solchen Umfeld eher den Aktivitäten zur technischenWeiterentwicklung untergeordnet, zumal (abhängig vom Grad der Innovation) Termin-überschreitungen in einem gewissen Rahmen noch eher akzeptiert werden können als inspäteren Phasen eines Produktlebenszyklus. Auch die projektinterneKommunikation ist inden kleinen Teams erheblich leichter als in großen Projektteams. Änderungen an Schnitt-stellen oder an den Projektzielen kommunizieren sich in kleinen Teams fast von allein.Häufig sind in den frühen Phasen einer Innovation nicht nur die Produkte, sondern auchdie dadurch abgedeckten Use Cases weniger komplex. Daher können, je nach Struktur desProduktportfolios, Entwicklungsteams an verschiedenen Produkten relativ autark arbei-ten.

In folgenden Phasen des Produktlebenszyklus ergeben sich jedoch wesentliche Verän-derungen:

Steigende Produktgrößen und Produktkomplexität: Eine Vielzahl von Anforderungenmuss in engen Zeitfenstern umgesetzt werden. Das erfordert erheblich größere Pro-jektteams und damit einhergehend eine größere Parallelisierung und Spezialisierungder Aufgaben. Damit steigt der Koordinations- und Kommunikationsaufwand im Pro-jekt.

Breitere Kundenbasis: Die Produkte werden nach der Innovationsphase mehr und mehrzu Werkzeugen, auf die sich der Anwender in seinen Entwicklungsprozessen verlassenkönnen muss. Termin- und Kostenzusagen für die Bereitstellung neuer Features oderFehlerkorrekturen müssen präzise eingehalten werden. Dies verlangt sowohl eine gutePlanung als auch eine entsprechende Kontrolle und Verfolgung des Projektstatus.

230 H.-J. Rabe

Steigende Vernetzung der Produkte untereinander: Innovations- und Zeitdruck beimKunden führen nicht nur zu immer neuen Anforderungen an die Produkte, sondernauch dazu, dass auf Basis dieser Produkte immer komplexere Use Cases erschlossenwerden müssen. Dadurch entstehen nicht nur neue Anforderungen an die Produkteselbst, sondern auch an deren Zusammenwirken. Daraus wiederum ergibt sich, dassverschiedenste Produktweiterentwicklungen, die jeweils ihren eigenen Roadmaps fol-gen, nicht mehr unabhängig durchgeführt werden können, sondern sowohl terminlichals auch inhaltlich synchronisiert werden müssen.

Damit wird offensichtlich, dass für die Beherrschung der Termine und Kosten bei stei-gender Produktkomplexität ein leistungsfähiges Projektmanagement etabliert bzw. wei-terentwickelt werden muss. Diese Notwendigkeit ergibt sich aber nicht nur aus denProduktanforderungen, sondern auch aus den Erfordernissen des Qualitätsmanagements.Zunehmend erwarten die Kunden den Nachweis eines etablierten Qualitätsmanagement-systems vomHersteller, insbesondere auch von Herstellern von Entwicklungswerkzeugen.Alle Qualitätsmanagementsysteme setzen aber wiederum ein etabliertes Projektmanage-ment voraus.

Die Produktentwicklung bei dSPACE hat bereits seit vielen Jahren Projektplanungser-fahrung. Jedoch gab es unterschiedliche Vorgehensweisen, Terminologien undWerkzeugein den verschiedenen Entwicklungsgruppen. DieseWerkzeuge eigneten sich nicht oder nurbedingt für größere Entwicklungsgruppen. Insbesondere die seinerzeit erwartete steigendeVernetzung der Produkte untereinander konnte mit der existierendenWerkzeug- undMe-thodenwelt nur unzureichend abgebildet werden. dSPACE startete daher gegen Ende desJahres 2003 eine Initiative, die das Projektmanagement in der Produktentwicklung verein-heitlichen sollte. Ziel war es, einen einheitlichen Projektmanagementprozess einzuführen,die Terminologie zu harmonisieren und ein für größere Entwicklungsprojekte geeignetesWerkzeug einzuführen, das Multiprojektmanagement unterstützt.

11.3 Die Organisation des Projektmanagements

Das Projektmanagement ist als Teil der Produktentwicklung dieser auch organisatorischzugeordnet. Die wichtigsten Rollen und Gremien im Projektmanagement sind:

• Der Projektleiter und die ggf. benannten Teilprojektleiter (PL, TPL),• Die Steering Committees (SC),• Die Expertenrunden (ER),• Das Qualitätsmanagement (QM),• Das Project Office (PO).

Projektleiter undTeilprojektleiter sind die zentralen Rollen im Projektmanagement undbedürfen an dieser Stelle keiner weiteren Erläuterung. Bei dSPACE steuern sie, falls erfor-


derlich, Projekte über Abteilungsgrenzen hinweg. Die Projektleiter berichten in regelmä-ßigen Abständen den Steering Committees (SC), die i. d. R. aus Vertretern der Produktent-wicklung und des Produktmanagements, das für die inhaltliche Definition der Produkteverantwortlich ist, zusammengesetzt sind. In den SCs erfolgt zum einen eine zusätzlicheFortschrittskontrolle des Projektes, zum anderen stellt das SC eine (nicht die einzige) mög-liche Eskalationsinstanz für Probleme oder Fragestellungen dar, die außerhalb der Ent-scheidungskompetenz des Projektteams und des Projektleiters liegen.

Bei der Expertenrunden handelt es sich umein abteilungsübergreifend arbeitendesGre-mium, in dem sich „Delegierte“ aus den einzelnen Fachabteilungen, die sich speziell imThema Projektmanagement auskennen, regelmäßig treffen, um Best Practices, aber auchProbleme in den Prozessen und im Umgang mit den Werkzeugen zu identifizieren undnotwendige Veränderungen abzuleiten.

Das Qualitätsmanagement begleitet als separate Abteilung die Einführung und Durch-führung der Prozesse, stellt die entsprechende Werkzeugumgebung bereit, veröffentlichtfirmenintern die Regeln und überprüft sie durch interne Assessments.

Das Project Office unterstützt den Projektleiter bei der Projektanlage; es legt in allenrelevanten Software-Werkzeugen die notwendigen Datenstrukturen an, vergibt die eindeu-tigen Kennnummern für Projekte und überprüft, ob alle für die Anlage eines Projektesnotwendigen Informationen zusammengetragen worden sind.

11.4 Vorgehensweise bei der Einführung des Projektmanagements

Die Hauptziele bei der Einführung des Projektmanagements in der Produktentwicklungwaren:

• Vereinheitlichung des Projektmanagement-Vorgehens in den verschiedenen Fachabtei-lungen, einschließlich Einsatz eines Projektmanagement-Werkzeuges in allen Fachab-teilungen.

• Vereinheitlichung der Begrifflichkeit im Projektmanagement.• Zunehmende Etablierung von abteilungsübergreifend arbeitenden Teams.• Erreichung höherer Genauigkeit bei Terminvoraussagen bei gegebenen inhaltlichen

und Qualitätszielen.• Mehr Transparenz hinsichtlich der Auslastung von Teams und Abteilungen.• Etablierung von Multiprojektmanagement, um Abhängigkeiten komplexer Entwick-

lungsprojekte identifizieren, abbilden und überwachen zu können.• Auswahl und Beschaffung eines geeigneten Projektmanagement-Werkzeuges.

Beim Start des Einführungsprojektes konnten Erfahrungen aus einem vorangegangenenProjekt (Konfigurationsmanagement) genutzt werden, in dem es ebenfalls um die entwick-lungsweite Einführung eines gemeinsam genutzten Werkzeuges ging. Insbesondere dreiErkenntnisse waren wertvoll und wurden berücksichtigt:

232 H.-J. Rabe

1. Die Zusammensetzung des Projektteams für die Prozessdefinition und die Toolauswahlhatte sich bewährt. Das Verfahren wurde übernommen und ist im folgenden Abschnittdetaillierter ausgeführt.

2. Wesentliches Ziel des Vorgängerprojektes war vor allem die Ablösung eines vorhande-nen, aber mit mancherlei Unzulänglichkeiten behafteten Versionsmanagement-Werk-zeuges. Dies und die Tatsache, dass seinerzeit bei dSPACE noch nicht sehr viele Erfah-rungen mit Prozessdefinitionen vorhanden waren, führte dazu, dass der Fokus zu frühund zu stark auf die Werkzeugauswahl gelegt wurde und eine stabile Prozessdefiniti-on wie auch das Regelwerk für den Umgang mit dem Werkzeug zu spät angegangenworden waren. Zwar war ein Teil des Auswahlteams mit der Prozessdefinition befasst,aber die Präzision und praktische Handhabbarkeit der Festlegungen war noch nichtausreichend, wie sich beim Rollout herausstellen sollte. Es mussten seinerzeit einigeProzessfragen ad-hoc und sehr kurzfristig geklärt werden. Als Konsequenz aus diesenErfahrungen sollte in dem nachfolgenden Projekt mehr Gewicht auf die Prozessdefini-tion für das Projektmanagement vor der Toolauswahl gelegt werden.

3. Die so genannte „Drehbuchmethode“, die im Folgenden näher beschrieben wird, er-laubte eine recht effiziente, systematische und vergleichende Beurteilung neuer Werk-zeuge. Allerdings sollte zur Erarbeitung eines Drehbuches bereits eine hinreichend ge-naue Vorstellung vorliegen, nach welchen Prozessen vorgegangen werden soll.

11.4.1 Die Zusammenstellung des Projektteams

Für die Ausarbeitung eines einheitlichen Projektmanagement-Prozesses und die Werk-zeugauswahl wurde ein Projektteam zusammengestellt, für dessen Zusammensetzung diefolgenden Überlegungen ausschlaggebend waren:

• In den unterschiedlichen Fachabteilungen waren bereits Erfahrungen im Projektma-nagement auf verschiedenem Niveau vorhanden und diverse Vorgehensweisen hattensich etabliert. Diese Vorgehensweisen sollten analysiert und so vereinheitlicht werden,dass die neuen Prozesse und das zu beschaffendeWerkzeug die Anforderungen aus denFachabteilungen abdecken können.

• Alle Entwicklungsteams arbeiteten und arbeiten an sehr anspruchsvollen Produktenunter engen zeitlichen Randbedingungen. Entsprechend hoch sind die Erwartungender Projektleiter und Mitarbeiter an die von ihnen eingesetzten Werkzeuge und eben-so hoch sind die Akzeptanzschwellen für Prozesse und Werkzeuge. Um eine möglichstgroße Akzeptanz zu schaffen, ist daher eine frühzeitige Beteiligung der Fachabteilungenam Definitions- und Auswahlprozess wichtig.

• Das Vorhaben führte natürlich auch zu Änderungen an bestehenden Prozessdefinitio-nen in den Fachabteilungen und zum Aufbau von zusätzlichem Know-how. Sowohldieses Fachwissen als auch die mit der Einführung anstehenden Änderungen sollten


Abb. 11.1 Team-Rekrutierungund Kommunikation mit denFachabteilungen

ebenfalls frühzeitig und begleitend zum Einführungsprojekt in den Fachabteilungenmultipliziert werden.

Um diese Ziele zu erreichen, wurde das Projektteam mit jeweils einer im Projektma-nagement bzw. im Entwicklungsprozess erfahrenen Person aus den Fachabteilungen be-setzt, die auch das entsprechende Vertrauen der Mitarbeiter genoss (Abb. 11.1). Auf die-se Art und Weise konnten die Erfahrungen der Fachabteilungen im Projektteam berück-sichtigt und umgekehrt Entscheidungen des Projektteams den Fachabteilungen kommuni-ziert werden. Ebenso konnten Rückfragen dadurch schnell beantwortet werden. Dem Zielder Vereinheitlichung entsprechend, wurden sowohl die Software- als auch die Hardware-entwicklungsabteilungen wie auch die Abteilung Benutzerdokumentation einbezogen. DieGesamtkoordination und Projektleitung für das Einführungsprojekt oblag dem Qualitäts-management. Natürlich war es wichtig, für die beteiligten Personen die zeitlichen Freiräu-me zu schaffen, so dass eine kontinuierliche Arbeit amThema sichergestellt werden konnte.

11.4.2 Die Prozessdefinition

Das Projektteam definierte zunächst den Projektmanagementprozess mit insgesamt siebenElementen auf der obersten Ebene. Abbildung 11.2 zeigt das Ergebnis. Zu jedem dieserProzessschritte wurden die Begriffe definiert und in einem Glossar festgehalten, die Tätig-keiten sowie die ein- und ausgehenden Dokumente und Informationen festgelegt. Ebensomanifestierte das Team die beteiligten Rollen. Zum einen wurden bei der Rollendefini-tion bereits gelebte Rollen klarer fixiert, zum anderen Rollen neu geschaffen, so z. B. diedes Steering Committees. Die Mitglieder im Projektteam nahmen den jeweiligen Diskus-sionsstandmit in die Fachabteilungen und diskutierten ihn mit ihren Kollegen. In Summeführte dieses Vorgehen zu einer hohen Akzeptanz der Entscheidungen im Projektteam.Es sei an dieser Stelle schon vermerkt, dass das Projektteam nach der erfolgten Einfüh-rung des Projektmanagements nicht aufgelöst wurde, sondern als Expertenrunde bis heute

234 H.-J. Rabe

Abb. 11.2 Die siebenProzessschritte im Projekt-managementprozess

weiter arbeitet, um die Prozesse, Dokumente und Templates laufend verbessern und ggf.geänderten Rahmenbedingungen anpassen zu können (vgl. dazu Abschn. 11.4.4).

11.4.3 DieWerkzeugauswahl und die Drehbuchmethode

Nachdem eine tragfähige Basis und ein einheitliches Verständnis des einzuführenden Pro-jektmanagementprozesses hergestellt waren, konnte mit der Werkzeugauswahl begonnenwerden. Eine Inspektion der Anbieterlandschaft förderte nicht weniger als 28Werkzeugan-bieter zutage. Die Hauptschwierigkeit bestand nun darin herauszufinden, welches Werk-zeug unter den gegebenen Rahmenbedingungen optimal die definierten Prozesse unter-stützt. Bewertet man die Brauchbarkeit derWerkzeuge ad-hoc in Herstellerpräsentationenoder im Rahmen von Einführungsschulungen, so stechen natürlich immer die gerade inden Präsentationen besonders positiv herausgestellten oder intensiv diskutierten Themenhervor, was eine komplette, systematische und vergleichende Beurteilung mehrerer Werk-zeuge erschwert, wenn nicht unmöglich macht.

Ermutigt durch die Erfahrungen des vorausgegangenen Projektes wurde erneut die sogenannte „Drehbuchmethode“ angewendet. Der Grundgedanke der Drehbuchmethodebesteht darin, auf Basis des geplanten Vorgehens (d. h. der definierten Prozesse) Anforde-


Tab. 11.1 Auszug aus dem Drehbuch Workflow „Kalender einrichten“

Kalender einrichten +○− Pr BemerkungKAL1 globalen Kalender anlegen +

KAL2 regionale Kalender hinzufügen (unterschiedlicheFeiertage, unterschiedliche Arbeitszeiten)

+

KAL3 regionale Kalender an Ressourcen bin-den/zuweisen

+

KAL4 unterschiedliche Kalender in den Projekten be-rücksichtigen

+

rungen an dasWerkzeug zu erfassen und zwar in einer Form, die es erlaubt, die wichtigstenWorkflows inWorkshops zusammenmit dem Anbieter direkt amWerkzeug zu testen. DieAnleitung für diesen prozessorientierten Test ist das Drehbuch, von dem sich der internverwendete Name „Drehbuchmethode“ ableitet. Im Kern ist es eine Sammlung geeignetaufbereiteter, d. h. prüfbarer Anforderungen an das Werkzeug.

Die für das Projektmanagement-Werkzeug notierten Workflows im Drehbuch enthal-ten beispielsweise neben dem reinen Erstellen und Pflegen des Projektplans auch Work-flows im Bereich der Werkzeugadministration, des Ressourcenmanagements, der Kalen-derpflege, der Rechteverwaltung, der Berichtserstellung, der Sichtenbildung auf Projektefür verschiedene Rollen und vieles mehr. DesWeiteren sind den einzelnen AnforderungenPrioritäten zugeordnet, die die Wichtigkeit einer bestimmten Anforderung festlegen.

Tabelle 11.1 zeigt einen Auszug aus dem Drehbuch. In der Spalte 2 in der Tabellen-überschrift ist der Workflow oder die Funktion eingetragen, darunter befinden sich diezugehörigen Anforderungen. Die mit „+○−“ bezeichnete Spalte nimmt die Resultate derBewertung auf (s. u.), die mit „Pr“ bezeichnete Spalte die Prioritäten. Dabei bestehen dieInformation in der ersten Spalte nur aus eindeutigen Kürzeln, die die Identifikation dereinzelnen Anforderungen vereinfachen und helfen, Missverständnisse zu vermeiden.

Das Drehbuch für die Auswahl des Projektmanagement-Werkzeuges wurde vom Pro-jektteam erarbeitet und von den Fachabteilungen einem Review unterzogen. Wie bereitsausgeführt, orientierten sich die einzelnen imDrehbuch definiertenWorkflows an der Pro-zessdefinition. In Summewurden 50Workflowsmit durchschnittlich sechsAnforderungenerarbeitet. Die wichtigsten Workflows sind im Folgenden aufgelistet:

• Allgemeines:– Rollen und Sichten definieren,– Ressourcen anlegen.

• Projektmanagement:– Projekte bearbeiten,– Projekt definieren,– Projekt grob planen,– Projekt fein planen und steuern,

236 H.-J. Rabe

– Projekt-Controlling durchführen,– Projekt abschließen,– Projekt abbrechen,– Projekt-Templates anlegen.

• Multiprojektmanagement:– Gemeinsam genutzte Ressourcen,– Abhängigkeiten zwischen Projekten,– Informationsfluss/Abgleich zwischen Projekten.

• Projektteamsicht:– Allgemeine Anforderungen,– Zeiterfassung,– Auswertungen,– Mitarbeiter,– Online Informationen,– Berichte,– Vergleichsdaten aus mehreren Projekten,– Schnittstellen,– E-Mail-Anbindung,– Datenexport/-import abgleichen,– Infrastruktur.

Schließlich wurde den vorausgewählten Anbietern das Drehbuch zur Verfügung ge-stellt, so dass ihnen eine entsprechend profunde Vorbereitung möglich war. Vor jedemWorkshop wurde die SW vom Anbieter auf bereitgestellten Notebooks installiert. Für dieWorkshops selbstwurden alleAnbieter gebeten, sowohl einenVertriebsmitarbeiter als aucheinen technischen Berater zu entsenden, um den Testprozess optimal unterstützen zu kön-nen. Es ist unerlässlich, dieWorkshops in dieser Form zusammenmit demAnbieter durch-zuführen, da bei den eigenen Mitarbeitern noch keinerlei Know-how imUmgang mit demWerkzeug vorhanden ist und so Fragen unmittelbar geklärt werden können.

Das Projektteam hatte die Aufgabe, dieWorkflows des Drehbuches direkt amWerkzeugdurchzuspielen und zu bewerten (Evaluierung). DieWorkshops selbst waren auf zwei Tageausgelegt und wie folgt geplant:

• / Tag Präsentation des Tools und der Grundlagen durch den Anbieter, Vorstellungder vorbereiteten Lösungen des Anbieters,

• / Tag Evaluierung zumThema „Projektplanung“,• / Tag Evaluierung zumThema „Projektcontrolling“,• / Tag Evaluierung zumThema „Multiprojektmanagement“.

Um möglichst verlässliche Evaluierungsergebnisse und eine breite Beurteilbarkeit zu er-halten, wurde den Projektteammitgliedern noch jeweils ein erfahrenerMitarbeiter aus derentsprechenden Fachabteilung zur Seite gestellt, so dass die Evaluierung stets paarweise an


einem Rechner durchgeführt werden konnte. Auf diese Weise arbeiteten imWorkshop biszu vier Evaluierungsteams zu je zwei Personen. Jeweils am Abend gab in Abwesenheit desAnbieters jedes Evaluierungsteam noch eine qualitative Bewertung des bisher erarbeitetenGesamteindrucks ab. Diese Ergebnisse wurden ebenfalls gesammelt.

Jedes Evaluierungsteam bewertete unabhängig voneinander während des Workshops,wie gut das Werkzeug die jeweilige Anforderung erfüllen konnte. Dazu wurde eine drei-stufige Bewertungsskala vorgegeben, die zu jeder einzelnen Anforderung des Drehbuchesnotiert werden konnte (vgl. auch Tab. 11.1):

• + = Voll erfüllt, keine Einschränkungen,• ○ = Teilweise erfüllt, mit Workarounds oder Einschränkungen möglich,• − =Nicht erfüllt.

Mit diesem Vorgehen konnte sowohl ein Eindruck von der Bedienbarkeit des Werkzeu-ges gewonnen als auch beurteilt werden, ob und in welchem Umfang das Werkzeug inder Lage ist, die geplanten Prozesse zu unterstützen. Durch die Diskussion während desWorkshops entstand auch ein Eindruck von der Verlässlichkeit und Glaubwürdigkeit desAnbieters. Weiterhin bietet die Methode den Vorzug, dass aus Beurteilung und Prioritätein numerischer Wert gewonnen werden kann, der einen Vergleich zwischen verschiede-nenWerkzeugen erlaubt. Auch wenn die Entscheidung für oder gegen ein Werkzeug nichtnur von einem einzelnen Wert abhängig gemacht werden kann, hilft die numerische Be-wertung bei der Diskussion der Ergebnisse.

Natürlich ist es nichtmöglich, diesesVerfahrenmit 28Anbietern durchzuführen. Daherentschloss sich dSPACE, aus den vorbereiteten Drehbüchern die wesentlichsten Anforde-rungen zu identifizieren. Mit diesen Anforderungen konnte das Projektteam durch eigeneRecherchen wieMessebesuche, telefonische Anfragen und Internetrecherchen 20 Anbieterverwerfen. Mit den übrigen acht wurden drei- bis vierstündige Werkzeugpräsentationenüber das Internet vereinbart und die Anbieter wurden gebeten, einen Fragebogen, derebenfalls aus demDrehbuch abgeleitet war, zu beantworten. Nach Sichtung der Ergebnisseblieben drei Anbieter übrig, die zu den oben beschriebenen Workshops eingeladen wur-den.

Nach Abschluss der Workshops und aller qualitativen Bewertungen erhielt das Pro-jektteam und jede Fachabteilung die Möglichkeit, ein Ranking abzugeben, wie gut jedesWerkzeug die Workflows im Drehbuch aus ihrer Sicht abbildet. Daraus resultierte ein sehrknappes Rennen zwischen zwei Anbietern, von denen schließlich einer ausgewählt wurde.

11.4.4 Pilotphase und Rollout

Nach der erfolgreichen Vorauswahl des Werkzeuges begann das Projektteam mit der Vor-bereitung der Pilotphase, wobei die folgenden Ziele erreicht werden sollten:

238 H.-J. Rabe

1. Überprüfung der Prozessschritte und -definitionen auf Praxistauglichkeit:Die vorher erarbeiteten Prozessdefinitionen waren lediglich „am grünen Tisch“ ent-standen. Da die verschiedenen Fachabteilungen aufgrund unterschiedlicher Vor-gehensweisen auch diverse Projektmanagement-Mechanismen etabliert hatten, warsicherzustellen, dass die neuen Definitionen für alle Fachabteilungen anwendbar seinwürden.

2. Erarbeitung der Vorgehensdetails imWerkzeug:Im Vorgängerprojekt war dieser Punkt zu spät und nicht mit der gebotenen Präzisi-on angegangen worden. Daher wurde nun rechtzeitig vor der Einführung festgelegt,wie die Projekte zu hierarchisieren sind, wie die Rückmeldung vonstatten zu gehen hat,welche Projekttypen es geben soll, wie die Projekte untereinander in Beziehung gesetztwerden sollten u. v.m., so dass eine insgesamt schlüssige Arbeitsweise eingeführt wer-den konnte. Das Ziel der einheitlichen Vorgehensweise wäre sonst gefährdet gewesen.

3. Erarbeitung derWerkzeugkonfiguration:Als Konsequenz aus dem vorherigen Punkt war die Konfiguration desWerkzeuges fest-zulegen und einzustellen. Schließlich waren die Ressourcen in das Werkzeug zu über-tragen und Kalender zu erstellen. Insbesondere wurden Templates für die verschiede-nen Entwicklungsprojekttypen entwickelt und erste Berichte erstellt.

4. Ausarbeitung der Trainings für die Anwender:Bei den gemeinsam verwendeten Werkzeugen hat es sich als guter Standard entwickelt,dass der Zugang zumWerkzeug nur denen ermöglicht wird, die auch an einemTrainingin den Prozessen undderNutzung desWerkzeuges teilgenommenhaben.DiesesVorge-hen hilft zu vermeiden, dass ausmangelnder Sachkenntnis Fehler in der Toolbedienunggemacht werden oder abseits verabschiedeter Standards mit dem Tool gearbeitet wird.Dieselbe Praxis war auch für das Projektmanagement-Tool anzuwenden. Mithin warenverschiedene Trainingsmodule für Projektleiter, Projektmitarbeiter und externe Mitar-beiter zu erarbeiten.

5. Praxistauglichkeit desWerkzeuges selbst:Selbst die sorgfältigste Vorauswahl desWerkzeuges kann nicht sicherstellen, dass dieseskeine gravierenden Qualitätsmängel aufweist und in der Praxis keine Handhabungs-oder Performanceprobleme auftreten. Aufgrund der Erfahrungen aus dem Vorgän-gerprojekt planten wir eine ausreichend lange Pilotphase ein, u. a. um ggf. auftretendeQualitätsmängel in realen Betriebs- und Lastsituationen rechtzeitig erkennen und vomHersteller beseitigen lassen zu können. Darüber hinaus wurde später im Rollout mehrWert als vorher darauf gelegt, in kleinen Schritten auf das neueWerkzeug umzusteigen.

Mit konkreten, kleineren Pilotprojekten in unterschiedlichen Fachabteilungen sollten diePunkte 1 und 5 adressiert werden, die Punkte 2, 3 und 4 waren vom Projektteam unddem Qualitätsmanagement zu behandeln. Die Ergebnisse aus den Pilotprojekten flossenvia Projektteam und Qualitätsmanagement zurück und führten zu einer Verbesserung derProzessdefinitionen.


Für die Pilotprojektphase stand insgesamt ein Zeitraum von ca. sechs Monaten zur Ver-fügung. Die Pilotprojekte konnten allesamt erfolgreich abgeschlossen werden, so dass demRollout für die Produktentwicklung nichts mehr imWege stand. Der Rollout selbst wurdeschrittweise durchgeführt. Laufende Projekte wurden in der herkömmlichen Technik be-endet, neue Projekte nach dem geänderten Prozess und mit Hilfe des neuen Werkzeugesbegonnen. Anfang 2006 begann der sukzessive Umstieg, ein Jahr später war er vollständigabgeschlossen.

11.4.5 Die Expertenrunden

Es ist essentiell, dass mit dem Rollout die Arbeit an Prozessdefinitionen, Vorgehenswei-sen, Werkzeugkonfigurationen, Templates und Dokumenten nicht endet. Insbesondere inder Anfangsphase stellen sich bestimmte Festlegungen als nicht hinreichend präzise oderals nicht handhabbar heraus. Außerdem sind in späteren Jahren des Betriebs immer wie-der Anpassungen an neue Rahmenbedingungen erforderlich, so z. B. die Anpassung derProjektmanagement-Templates an einen neuen Entwicklungsprozess.

Um regelmäßig Betriebserfahrungen sammeln, zwischen den Fachabteilungen austau-schen und Prozessdefinitionen anpassen zu können, wurde das Projektteam nicht nachdem Rollout des Werkzeuges aufgelöst, sondern hat sich regelmäßig in Expertenrundenwieder getroffen. Diese haben folglich die gleiche Zusammensetzung wie das Projektteam.In den Expertenrunden werden regelmäßig Anfragen und Problememit dem Prozess oderdem Werkzeug aus den Fachabteilungen gesammelt und beurteilt. Entsprechend werdenEntscheidungen in die Fachabteilungen zurückkommuniziert oder es wird – falls erforder-lich – ein entsprechendes Veränderungsprojekt initiiert. Die Expertenrunden werden vomQualitätsmanagement, dem auch das interne Training der Mitarbeiter obliegt, moderiert.Dadurch ist sichergestellt, dass das Praxiswissen immer wieder in die Trainings einfließtund diese dadurch aktuell bleiben. Darüber hinaus helfen die Expertenrunden dabei, dieAkzeptanz der Vorgehensweisen zu wahren.

Die Erfahrungenmit den Expertenrunden sind durchaus positiv. Mit wachsender Grö-ße der Gesamtorganisation stellen wir jedoch fest, dass der Informationsrückfluss aus denExpertenrunden schwieriger wird und weniger zuverlässig ist als am Anfang. Außerdemzeigt sich, dass die Geschwindigkeit, mit der notwendige oder gewünschte Änderungen amProzess oder an denWerkzeugkonfigurationen umgesetzt werden, immer mehr abnimmt.Auch die eigentlichen Entscheidungsprozesse sind zu langsam geworden. dSPACEwill hierdurch die Einrichtung eines separaten Eskalationsweges und klarer Strukturen für Prozess-und Toolentscheidungen Abhilfe schaffen.

11.5 Projektreviews

Wie bereits dargestellt, ist es dSPACE ein besonderes Anliegen, die Betriebserfahrungenaus den Projekten in einer effizienten Weise zu sammeln und für die Weiterentwicklung

240 H.-J. Rabe

der Prozesslandschaft und der Werkzeuge nutzbar zu machen. Dabei ist es wichtig, nichtnur Erfahrungen im Hinblick auf Prozessverbesserungen zu sammeln, sondern auch ausanderen Bereichen eines laufenden oder abgeschlossenen Projektes, so z. B. aus dem Be-reich der Entwicklungsmethoden, der Werkzeuge oder aus dem Bereich Kommunikationund Zusammenarbeit im Projekt. dSPACE hat hierzu zwei unterschiedliche Verfahren er-probt, wie man die Erfahrungen, die in Projekten gesammelt werden, systematisch erfassenund auswerten kann. Diese werden im Folgenden vorgestellt.

11.5.1 Projektreviewmit Fragebögen

Der erste Ansatz basiert auf der Idee, die Projekt-Erfahrungen unter Verwendung einesFragebogens zu sammeln und zu analysieren. In Zusammenarbeit der projektleitendenFachabteilung mit dem Qualitätsmanagement wurden zwei unterschiedliche Fragebögen,die zum einen die fachliche Ebene, zum anderen die nicht-fachliche Ebene abdeckten, er-arbeitet. Der fachliche Fragebogen war gegliedert in die Abschnitte:

Projektergebnisse: Sind alle technischen Ziele erreicht worden?Offene Aufgaben: Sind alle Arbeitspakete abgeschlossen und dokumentiert?Technische Probleme und ihre Lösungen: Welche technischen Probleme gab es und wie

wurden sie gelöst? Was soll bei zukünftigen Projekten berücksichtigt werden?Projektplanung und Projektkontrolle: Wie gut waren die Projektplanung und die Pro-

jektkontrolle? Konnten sie effizient durchgeführt werden?

In Summe enthielt dieser Fragebogen 38 Einzelfragen. Darüber hinaus sollten jeweils dreiPunkte angegeben werden, mit denen positive Erfahrungen gemacht wurden und für dieVerbesserungspotenzial gesehen wurde.

Der nicht-fachliche Fragebogen umfasste 50 Einzelfragen undwar in die folgenden Ab-schnitte gliedert:

• Allgemeines:Wie war der Eindruck von der eigenen Rolle im Projekt und vom Projek-tumfeld?

• Zusammenarbeit im Projekt• Kommunikation im Projekt

Die Fragebögen wurden an die Projektteammitglieder mit einigen Erläuterungen ver-teilt, die einzelnen Fragen sollten mit einem knappen Freitext beantwortet werden. Übereinen Zeitraum von einem Monat wurden die Rückläufer gesammelt. Die Teilnahme warfreiwillig und anonym, weil die Mitarbeiter motiviert werden sollten, auch kritische Dingeoffen anzusprechen.

Nach Abschluss der Sammelphase wurden die Fragebögen vom Qualitätsmanagementausgewertet. In diesem Zusammenhang stellten sich allerdings einige unerwartete Proble-me heraus. Eine wesentliche Schwierigkeit bestand in der Vielzahl der Antworten, zumal


diese als Freitext gegeben wurden. Dies führte zu einer sehr langen Auswertungsphase, dadie Antworten alle einzeln gesichtet und interpretiert werden mussten. Wir stellten fest,dass die Tiefe der Antworten ebenso wie die Sichtweisen der einzelnen Mitarbeiter sehrheterogen waren. Daraus die Gemeinsamkeiten, aus denen klare Hinweise auf positive wieauf negative Erfahrungen hätten abgeleitet werden können, zu extrahieren, erwies sich alssehr mühsam und die einzelnen Antworten untereinander als schlecht vergleichbar. In ei-nigen Fällen hätte es eine Klärung durch Nachfrage geben müssen, was aber aufgrund derAnonymität der Erhebung nicht möglich war. Darüber hinaus war nicht feststellbar, wel-chen Stellenwert die Antworten für den Autor jeweils hatten: Waren bestimmte Punkte fürdie jeweilige Person Kleinigkeiten oder sehr wichtige Punkte? Die Antworten werden zu-dem immer aus der Perspektive eines Mitarbeiters gegeben: Dinge, die ihn persönlich inbesonderem Maße betroffen haben oder Ereignisse, die zeitnah zum Review stattgefun-den haben, rücken oft automatisch stärker ins Bewusstsein, während Vorkommnisse, dieaus gesamtheitlicher Betrachtung des Projektesmöglicherweise erheblich wichtiger sind, inden Hintergrund geraten und Gefahr laufen, vergessen zu werden. Da in einem anonymenVerfahren der Austauschmit anderen Projektmitgliedern unterbleibt, fehlt der Impuls, dievon anderen Kollegen genannten Punkte für sein eigenes Feedback zu bewerten. Damitkann kein Konsens bezüglich der Bewertung des Projektes und seiner Konsequenzen her-gestellt werden.

Diese Probleme führten insgesamt dazu, dass die Auswertung sehr viel mehr Zeit undAufwand benötigte als vorgesehen und die Ergebnisse nicht in hinreichendemMaße inter-pretiert und genutztwerden konnten.Hinzu kam, dass dieResultate nicht zeitnah demPro-jektteam dargestellt wurden, was berechtigterweise zu Kritik seitens der Projektmitarbeiterführte. dSPACE erschien das Verhältnis vonAufwand zuNutzen bei dieser Fragebogenme-thode unangemessen hoch und eine adäquate Reaktionsfähigkeit war nicht gegeben. DasTeam suchte daher nach einem schnelleren und effizienteren Verfahren für Projektreviews.

11.5.2 Projektreviews als Workshop

Der Grundgedanke für ein alternatives Verfahren ist, das Review zeitlich sehr konzentriertdurchzuführen und das Projektteam in einem gemeinsamenWorkshop zusammenzubrin-gen. Dadurch können die wesentlichen Nachteile der anonymen Fragebogenmethode ver-mieden werden: Zum einen sind die Ergebnisse in viel kürzerer Zeit verfügbar, zum ande-ren sind durch dieArbeit imTeamRückfragen und kurzeDiskussionenmöglich, die helfen,die Relevanz bestimmter Arbeitsergebnisse einzuschätzen, Missverständnisse zu reduzie-ren und gegenseitig den Betrachtungshorizont zu erweitern. Bei der Durchführung desWorkshops war es stets wichtig, dass nicht nur das Verbesserungspotenzial benannt wird,sondern dass auch explizit positive Erfahrungen festgehaltenwerden.Dies stärkt zumeinendie Motivation des Teams, zum anderen vermeidet man dadurch, dass bei der Definitionvon Maßnahmen an falscher Stelle Prioritäten gesetzt werden.

242 H.-J. Rabe

11.5.2.1 Vorbereitung des Review-WorkshopsDie Teamgröße im Review sollte etwa acht bis zwölf Personen betragen. Sind die Projekteselbst viel größer, empfiehlt es sich, Personen in das Reviewteam zu nehmen, die das Ver-trauen der übrigen Projektteammitglieder genießen und für einen bestimmten Bereich, seies einen fachlichen Bereich oder für bestimmte Rollen, im Projekt sprechen können. Da-durch lässt sich ein Gesamtbild vomProjekt erzeugen, ohne dass das Review-Team zu großwird. Mitunter kann es bei Reviews großer Projekte allerdings erforderlich werden, mehre-re Review-Workshops anzusetzen. Entscheidend ist dabei, dass alle Rollen aus dem Projektvertreten sind, also z. B. Auftraggeber, die Entwicklung oder die Produktion. Das fördertden Zusammenhalt der Mitarbeiter. Veranstaltet man mehrere Workshops, kann es sinn-voll sein, operative Mitarbeiter und Manager getrennt auf zwei Termine zu verteilen undanschließend die Ergebnisse zu vergleichen.

Ein Termin sollte etwa auf drei bis fünf Stunden angesetzt werden, kann aber je nachProjektgröße auch länger oder kürzer sein. Die Erfahrung zeigt, dass bei effizienter Mode-ration dieser Zeitraum auch für große Projekte ausreicht. Um einen reibungslosen Ablaufzu gewährleisten, ist vorab einModerator für denWorkshop zu bestimmen, idealerweise istdies eine Person, die die Projektinhalte versteht, das Unternehmen kennt und das Vertrau-en der Projektteammitglieder genießt. Allerdings sollte er nicht selbst Projektteammitgliedgewesen sein, damit keine Voreingenommenheit besteht und er als Moderator akzeptiertwird. So kannman z. B. den Leiter einer fachfremdenAbteilung aus demUnternehmen umUnterstützung bitten.

Ziel des Workshops ist es, die Probleme und positiven Erfahrungen im Projekt zu be-nennen und zu bewerten. Führt man dies völlig frei durch, so besteht die Gefahr, dass sichdie Ergebnisse um die noch am besten erinnerten Ereignisse im Projekt häufen und schonlänger zurückliegendeThemen unterrepräsentiert werden. Daher werden bereits einige Ta-ge vor dem Workshop Kategorien vorgegeben, zu denen im Workshop die Erfahrungennotiert werden sollen. Derartige Kategorien können z. B. die Projektphasen sein oder Ein-teilungen wie „Kommunikation“, „Projektcontrolling“, „Wissensstand“ oder „Trainings“.Allerdings sind die vorgegebenen Kategorien kein starres Korsett, sondern nur ein Hilfs-mittel, um möglichst breit über das Projekt nachzudenken.

11.5.2.2 Durchführung des Review-WorkshopsDer Workshop selbst wird mit Hilfe der Metaplantechnik durchgeführt. Die Themen wer-den auf Karten notiert und diese den vorbereiteten Kategorien zugeordnet. Sind Themennicht zuzuordnen, werden sie gesammelt und später geordnet. Handelt es sich um unkla-re Themen, können diese kurz diskutiert oder geklärt werden, da alle Projektvertreter amTisch sitzen. Hier ist das Fingerspitzengefühl des Moderators gefragt, der Diskussionenzur Klärung in angemessenem Umfang zulassen sollte, aber natürlich auch im Auge be-halten muss, dass die Gesamtzeit für das Review nicht überschritten wird. Am Ende desWorkshops erhält jeder Teilnehmer drei Punkte, mit denen er die Themen, die ihm amwichtigsten erscheinen, in abnehmender Reihenfolge wertet. Damit lässt sich im Gegen-


satz zum anonymen Verfahren die Relevanz der Themen für das gesamte Projektteam gutund zügig bestimmen.

11.5.2.3 Auswertung des Review-WorkshopsDie Auswertung übernimmt der Moderator, wobei die ausgewerteten Ergebnisse zeitnahdem Projektteam vorgestellt werden sollten. Je nach Organisation können vom Projekt-team selbst oder der zuständigen Linienfunktion gemeinsammit dem Projektteam Schlüs-se aus den Ergebnissen gezogen und Verbesserungsmaßnahmen erarbeitet werden, dieebenfalls umfassend kommuniziert werden. Bei der Erarbeitung von Verbesserungsmaß-nahmen ist jedoch der Eindruck zu vermeiden, dass alles unmittelbar umgesetzt werdenkann. Stattdessen konzentriert sich dSPACE auf einige wenige, aber besonders wirksameMaßnahmen. Wie im vorigen Abschnitt dargestellt, ist bei großen Projekten im Review-Workshopnur ein Teil des Projektteams vertreten. Die Ergebnisse sollten nachMöglichkeitallen Projektteammitgliedern in einer Präsentation vorgestellt, in jedem Fall aber zugäng-lich gemacht werden. Das fördert das gegenseitige Vertrauen und steigert die Identifikationmit dem Projekt.

11.5.3 Fazit

Die zuletzt beschriebene Workshop-Methode hat sich als gut geeignet erwiesen, in einerkompakten und effizienten Art undWeise Erfahrungen aus Projekten zu sammeln und zubewerten. Es kann ein schlüssiges Gesamtbild des Projektverlaufs gewonnen werden.

dSPACE führt Projekt-Reviews nicht obligatorisch für jedes Projekt durch, sondern ent-scheidet fallweise über die Durchführung. Sie kommen in der Regel dann zur Anwendung,wenn besondere Probleme bezüglich der Termine, der Kosten oder der Projektinhalte auf-traten oder etwa Kommunikationsprobleme offensichtlich wurden. Sinnvoll können solcheReviews aber auch dann sein, wenn neue Technologien eingesetzt wurden oder besondereRisiken vorlagen und gemeistert wurden. Meist erfolgen die Reviews nach oder gemein-sam mit dem Projektabschluss. Aufgrund der Einfachheit des Verfahrens lassen sich Re-views auch während eines laufenden Projektes durchführen, z. B. wenn festgestellt wird,dass erheblichemethodische Schwierigkeiten auftreten. Allerdings ist zu beachten, dass dieReviews vor allem dem Erfahrungsaufbau und der Identifikation verbesserter Vorgehens-weisen für folgende Projekte dienen und nicht der unmittelbaren Lösung von Problemenund Konflikten in einem laufenden Projekt.

11.6 Projektmanagement in Hardware- und Softwareentwicklung

11.6.1 Die Anwendbarkeit des Projektmanagementprozesses

Der in Kap. 4 skizzierte Projektmanagementprozess ist sehr allgemein gehalten, da er beidSPACE für eine Vielzahl von Projektklassen anwendbar sein soll. So war es auch ein Ziel,

244 H.-J. Rabe

Hardware- und Softwareprojekte mit demselben Verfahren und denselben Werkzeugendurchführen zu können. Dieses Ziel ergibt sich aus den folgenden Überlegungen:

• Insbesondere Hardware und Betriebssystemsoftware müssen mit Blick sowohl auf dieProduktanforderungen als auch auf die zu entwerfenden Architekturen eng verzahntentwickelt werden. Die Projekt- oder Teilprojektteams, die auf diesem Gebiet ohnehininhaltlich eng zusammenarbeiten, arbeiten leichter und damit auch effizienter, wenndieselbe Prozess- und Toollandschaft verwendet wird und zudem eine gemeinsame Be-grifflichkeit definiert ist.

• (Teil-)Projektleiter können, je nach Projektschwerpunkt, ohne größere Probleme ent-weder aus der Hardware- oder der Softwareentwicklung benannt werden, was die Fle-xibilität beim Aufbau der Projektteams erhöht.

• Die Anschaffung, die Administration und der Betrieb eines Werkzeuges sind kosten-günstiger, ebenso die Ausbildung der Mitarbeiter im Projektmanagement.

• Die Planung und die Steuerung der Projekte sind, gestützt durch das Projektmana-gementtool, für alle Projektklassen und damit insbesondere auch für Hardware undSoftware einheitlich möglich.

Um diesen Zielen und Überlegungen Rechnung zu tragen, wurde der Prozess für das Pro-jektmanagement sehr allgemein gehalten und beschrieben. So hat dSPACE festgestellt, dasses auf einer abstrakten Ebene kaum Unterschiede im Management von Hardware- undSoftwareentwicklungsprojekten gibt. Die Unterschiede ergeben sich dagegen im eigentli-chen Entwicklungsvorgehen, d. h. wenn man die typischen Aktivitäten und Meilensteinevergleicht, die es jeweils in der Hard- und Softwareentwicklung gibt. Auf der Seite desProjektmanagements wurde diesen Unterschieden dadurch Rechnung getragen, dass imProjektmanagementwerkzeug geeignete Projekttemplates angelegt wurden, die von denProjektleitern eingesetzt werden können. Eine grobe Skizze der wesentlichen Unterschiedeist in den nächsten beiden Abschnitten dargestellt.

11.6.2 Typischer Ablauf eines Softwareentwicklungsprojektes

In der Abb. 11.3 ist stark schematisiert der Ablauf der Realisierungsphase eines Software-entwicklungsprojektes dargestellt. Dabei wird vorausgesetzt, dass die Anforderungen imWesentlichen definiert sind und der Entwurf der Software ebenfalls so weit abgeschlossenist, dass die Realisierung sinnvoll beginnen kann.

Typischerweise wird das Projekt in eine Anzahl inhaltlich und zeitlich sinnvoll definier-ter Abschnitte zerlegt. Laufende projektbegleitende Integrationen und Inbetriebnahmenstellen sicher, dass die zu entwickelnde Software lauffähig bleibt. Der Erfüllungsgrad derAnforderungen durch die jeweils in Betrieb genommenen Funktionen erhöht sich in derRegel kontinuierlich über den Verlauf der Realisierungsphase. Für den Fall des Einsatzesvon agilenMethoden entsprechen die blockweise umgesetztenAnforderungen den Sprints.


Abb. 11.3 Typische Rea-lisierungsphase einesSoftwareprojektes (schema-tisch)

Start Zwischenziel Zwischenziel Release

Laufende Inbetriebnahmen und Integra�onen

Inbe

trie

bnah

me

in %

de

r Anf

orde

rung

en

100%

Während der gesamten Projektphase bleibt die Intensität der Ressourcennutzung in derRegel konstant hoch, um die einzelnen Zwischenziele möglichst zügig erreichen zu kön-nen. Die zeitliche Lage der Meilensteine für die Zwischenziele ist vor allem durch die Zeit-und Aufwandsplanung bestimmt. Termine ergeben sich hauptsächlich aus der Leistungs-fähigkeit des Projektteams.

11.6.3 Typischer Ablauf eines Hardwareentwicklungsprojektes

Betrachtet man vergleichend die Hardwareentwicklung, so stellt man fest, dass die Reali-sierung eines serienreifen Produktes (Hardware-Board) meist mehrerer Boardrevisionenbedarf, um mögliche Fehler ausmerzen und die Schaltungen optimieren zu können(Abb. 11.4). So wird Schritt für Schritt der Reifegrad des Boards erhöht. Um nicht un-nötig viele frühe Prototypen mit noch nicht hinreichendem Reifegrad zu fertigen, werdendie Stückzahlen so gering wie möglich angesetzt. Jede Prototypenfertigung nimmt stetseinige Zeit in Anspruch. Während dieser Phasen entstehen Wartezeiten, die vom Ent-wicklungsprojektteam nicht beeinflusst werden und im Bereich mehrerer Monate liegenkönnen. Damit ist die Planung der Meilensteine im Wesentlichen von außen bestimmt.Im Gegensatz zu Softwareentwicklungsprojekten kann sich die Intensität der Ressourcen-nutzung während der Wartezeiten erheblich ändern. So werden in dieser Zeit Mitarbeiterfrei für andere Projekte. Laufen in einem Entwicklungsteam mehrere Projekte parallel, soist eine gute Auslastungsplanung für den effizienten und flüssigen Ablauf aller Projekteessentiell.

Wichtig ist, dass nach Vorliegen der ersten Boardrevision die geforderten Funktionenschnell vollständig in Betrieb genommen und getestet werden, damit Änderungen nachMöglichkeit komplett in die nächste Boardrevision aufgenommen werden können und dieAnzahl der Iterationen minimal bleibt. Das ist in Abb. 11.4 an der mit B bezeichneten Linieskizziert. Die Vorgehensweise bei der Planung der einzelnen Inbetriebnahmeaktivitätenähnelt eher demSchema der Softwareentwicklung als der Planung des gesamtenHardware-Entwicklungsprojektes (Linie A).

246 H.-J. Rabe

Abb. 11.4 Typische Rea-lisierungsphase einesHardwareentwicklungspro-jektes (schematisch)

.veR draoB0 .veR draoB 1 Release

Inbe

trie

bnah

me

in %

de

r Anf

orde

rung

en

100%Laufende Inbetriebnahmen

A

B

Es darf nicht vergessen werden, dass die Hardwareentwicklung komplexer Syste-me praktisch nie ohne eine korrespondierende Softwareentwicklung stattfindet. Eineenge planerische und kommunikative Vernetzung ist zwischen Hardware- und Softwa-re-Entwicklungsprojekten daher unerlässlich und folglich auch in der Werkzeug- undProzesslandschaft abzubilden und zu unterstützen. Insbesondere hierfür ist ein Multipro-jektmanagement erforderlich.

11.7 Fazit und Ausblick

Seit der Einführung eines vereinheitlichten Projektmanagements im Unternehmen konn-ten wir eine Vielzahl von Erfahrungen sammeln, von denen einige hier dargestellt wur-den. Gutes und konsequentes Projektmanagement ist eine wichtige Voraussetzung, um beizunehmendem Wettbewerbs- und Kostendruck gute Produkte rechtzeitig auf den Marktbringen zu können. Die gesammelten Erfahrungen geben uns die Bestätigung, den einge-schlagenenWeg weiter zu verfolgen.

In diesem Zusammenhang hat sich die Drehbuchmethode erneut als leistungsfähigesund effizientes Hilfsmittel bei der Werkzeugauswahl bewährt und wird sicher auch bei zu-künftigen Projekten eingesetzt werden. Dies setzt voraus, dass bereits einige grundlegendeVorgehensweisen erarbeitet wurden. Von einer zu späten oder fehlenden Definition vonProzessen, Konfigurationen, Templates, Trainings, Ablagestrukturen etc. ist abzuraten.

Es empfiehlt sich, die Erfahrungen mit Tools und Prozessen über Abteilungsgrenzenhinweg regelmäßig auszutauschen und die gewonnenen Erkenntnisse zur Optimierungder Verfahrensweisen zu nutzen. Auf die Handlungs- und Entscheidungsfähigkeit dieserTeams ist zu achten.

Projektreviews stellen ein wichtiges Hilfsmittel zum Erkenntnisgewinn aus beendetenProjekten dar. Dieser Erkenntnisgewinn ist dabei keineswegs auf das reine Projektmanage-ment beschränkt. Projektreviews sollten nicht anonym und per Fragebogen durchgeführtwerden, sondern in einem gemeinsamen, moderierten Workshop.


Das Projektmanagement ist ein eigenständiger Prozess, der so formuliert werden kann,dass er für eine Vielzahl von Projektklassen tragfähig ist. Insbesondere die unterschied-lichen Entwicklungsprozesse in Hardware- und Softwareprojekten lassen sich in einemeinheitlichen Projektmanagementprozess abbilden.

In weiteren Schritten wird dSPACE das Projektmanagement weiterentwickeln. Dazuzählt zum einen die Vereinfachung von Prozessen wo es möglich ist, z. B. durch die gezielteVereinfachung der Vorgehensweisen für kleinere Projekte. Zum anderen wird angestrebt,das Risikomanagement in Projekten weiterzuentwickeln.

11.8 Danksagung

Zum Schluss möchte ich nicht vergessen zu erwähnen, dass die Weiterentwicklung unse-res Projektmanagements auf das heute erreichte Niveau ohne die kritische und mitunterkontroverse, aber immer zielführende Diskussion und engagierte Mitarbeit der Entwicklerund Führungskräfte, insbesondere im Bereich des Qualitätsmanagements, nicht möglichgewesen wäre.

Documents

Strategisches Projektmanagement || Projektmanagement in der Entwicklung von Werkzeugen für die modellbasierte Entwicklung mechatronischer Regelsysteme