Requirements-Engineering und -Management

Auf die Plätze, fertig, los – Bereit für Pilotprojekte?

Requirements-Engineering und -Management beschäftigt sich auch mit der Kunst gute Anforderungen zu ermitteln und diese nachvollziehbar zu verwalten. Das Problem dabei ist, dass keine allgemeingültigen Methoden existieren. Pilotprojekte bieten eine ideale Chance neue Ansätze beim RE/M auszuprobieren.

 

n diesem Artikel stellen wir Ihnen vor, welche Erfahrungen wir bei der Einführung neuer Requirements-Engineering und –Management (RE/M)-Ansätze mittels eines Pilotprojekts gemacht haben. Im Rahmen eines Pilotprojekts haben wir Veränderungen auf Prozess-, Methoden- und Toolebene zunächst bei einer geringen Anzahl von Pilotanwendern eingeführt. Das Ziel dabei war, in einem Nachfolgeprojekt diese Veränderungen im Laufe der nächsten fünf Jahre auf ca. 2.000 Anwender innerhalb eines großen Konzerns auszurollen.

Zunächst jedoch ein paar Worte zu den angesprochenen RE/M-Ansätzen. Requirements-Engineering und -Management beschäftigt sich u. a. mit der Kunst gute Anforderungen zu ermitteln und diese nachvollziehbar zu verwalten. Das Problem dabei ist, dass, wie in anderen System- und Software-Disziplinen auch, keine allgemeingültigen Methoden existieren. Vielmehr müssen die aus der Literatur bekannten RE/M-Ansätze auf die speziellen Gegebenheiten adaptiert werden.

Um diese Adaptionen zielgerichtet durchführen zu können, bieten Pilotprojekte eine hervorragende Basis. Durch sie haben Sie als Verantwortlicher die seltene Gelegenheit, Ihre Ideen zur Verbesserung der Prozesse direkt auf operativer Ebene mit den späteren Anwendern auszuprobieren. Daneben bieten Pilotprojekte aber noch einen weiteren, nicht zu unterschätzenden Vorteil. Vielleicht haben Sie schon die Erfahrung gemacht, dass Neuerungen in den Entwicklungsabläufen, die »von oben« diktiert wurden, sehr selten in einer wünschenswerten Art und Weise von den Anwendern dieser Prozesse akzeptiert wurden. Die Lösung des Problems liegt darin, dass Sie die Anwender (bzw. eine Vertreterschaft) direkt in die Entwicklung der neuen Methoden einbeziehen. Haben Sie diese Pilotanwender von den Verbesserungen überzeugt, so werden die neuen Veränderungen auch viel schneller von deren Kollegen, der breiten Anwenderschaft, akzeptiert und genutzt. Der »Faktor Mensch« spielt hier eine nicht zu unterschätzende Rolle. Weiterhin kommt der Zeit- und Kostenaspekt, weshalb in vielen Organisationen an Verbesserungen im RE/M-Bereich gearbeitet wird, hinzu. Beispielsweise soll auf der Auftraggeberseite durch eine Reduktion von Änderungen oder Absprachen mit dem Auftragnehmer Zeit und Kosten reduziert werden. Mit Hilfe eines Pilotprojekts sind Sie in der Lage, die Neuerungen zunächst »im Kleinen« herzuleiten und zu testen, um so Zeit- und Kosteneinsparpotenziale zu identifizieren beziehungsweise zu bestätigen. Sie gehen somit dem Problem aus dem Weg, eine im Elfenbeinturm entstandene Lösung direkt in die breite Anwenderschaft auszurollen, um anschließend feststellen zu müssen, dass es an vielen Stellen Ihrer Lösung noch Schwierigkeiten gibt und Sie sich so den Missmut der Anwender zu ziehen. Im Rahmen eines Pilotprojekts können die Methoden dokumentiert werden, die sich als geeignet erwiesen haben. Somit steht Ihnen dann für eine Einführung im größeren Rahmen schon ein Leitfaden zur Verfügung, der als Basis für das Ausbildungsprogramm für die weiteren Anwender herangezogen werden kann.

Noch eine Bemerkung zum Abschluss dieses Kapitels: Wir werden im Rahmen dieses Artikels den Begriff der Methodik als Betrachtungsgegenstand eines Pilotprojekts verwenden. Er soll stellvertretend für all die Bereiche stehen, in denen Veränderungen stattfinden. Im Bereich RE/M können das Prozesse, Methoden und Tools sein, die angepasst und verbessert werden müssen.

Im Folgenden stellen wir Ihnen nun den Ablauf eines Pilotprojekts anhand der drei Phasen Vorbereitung, Durchführung und Nachbereitung vor.

Nutzen & Risiken analysieren

Projekt vorbereiten -> Projekt durchführen -> Projekt nachbereiten

 

Dabei werden wir Ihnen aufzeigen, was Sie in jeder Phase beachten müssen und welche Fallstricke im Allgemeinen existieren. Wir beziehen diese Kapitel auf das angesprochene RE/M Pilotprojekt, viele der Aussagen treffen jedoch auf alle Pilotprojekte, unabhängig von ihrem Inhalt, zu. Dabei haben wir den Fokus auf die Vorbereitungsphase gelegt, weil hier die Weichen für den Projekterfolg gestellt werden.

Pilotprojekt vorbereiten

Nachdem Sie einen offiziellen Projektauftrag für die Durchführung eines Pilotprojekts zur Einführung von RE/M erhalten haben, bereiten Sie Ihr Pilotprojekt in einem kleinen Rahmen vor. Wählen Sie einen Projektleiter der, mit Unterstützung eines Assistenten, das Pilotprojekt vorbereitet. Falls Sie wenig Erfahrung in der Durchführung von Pilotprojekten bzw. mit dem Fachgebiet RE/M haben, ist es bereits zu Beginn der Vorbereitungsphase wichtig, externes Know-how einzubeziehen, damit zum Einen Ihr Pilotprojekt auf einem stabilen und durchdachten Fundament steht, zum Anderen Sie nicht zusätzliche Aufwände zur Einarbeitung in die RE/M-Thematik einplanen müssen.

Auch wenn Pilotprojekte in der Regel nur ca. drei bis sechs Monate laufen, planen Sie mit einer Vorlaufzeit von ca. ein bis zwei Monaten, da die Durchführung der Pilotprojekte und vor allem deren Vorbereitung häufig neben dem alltäglichen Geschäft abgewickelt werden. Je besser Sie Ihr Pilotprojekt vorbereiten, desto mehr Zeit haben Sie während der Durchführung des Pilotprojekts sich auf die Aufnahme der vorhandenen, individuellen Gegebenheiten der operativen Ebene zu konzentrieren.

Zur Vorbereitung Ihres Pilotprojekts sollten Sie sich einige der bekannten »W-Fragen« stellen und versuchen deren Antworten z. B. auf einer »Powerpoint-Folie« zu dokumentieren. Das klingt vielleicht ein wenig einfach, aber so müssen Sie sich »zwingen«, sich gezielt auf die wesentlichen Faktoren, die Ihr Pilotprojekt definieren, zu konzentrieren.

Kernfragen für die Vorbereitung

• Kernfragen für die Vorbereitung

• Was sollte mit dem Pilotprojekt erreicht werden?

• Wer sollte von dem Pilotprojekt profitieren?

• Mit wem sollte das Pilotprojekt durchgeführt werden?

 

Warum sollte ein Pilotprojekt durchgeführt werden?

Was ist der Auslöser, der zur Einführung von RE/M in meinem Geschäftsbereich, meiner Abteilung führen soll? Wie ist meine IST-Situation im Hinblick auf RE/M zu beschreiben? Wo sehe ich Verbesserungspotenziale, die ich mit Hilfe von RE/M erreichen kann? Von welcher Geschäftsebene und aus welchen Gründen wurde die Einführung von RE/M befürwortet?

Binden Sie zur Beantwortung dieser Fragen bereits ausgewählte Anwender ein. Diese haben im Regelfall das Wissen, an welchen Stellen ihrer täglichen Arbeit Verbesserungspotenziale existieren. Für ein RE/M-Pilotprojekt lassen sich beispielhaft einige Auslöser nennen, die zu einem Umdenken geführt und die Einführung von RE/M im Rahmen eines Pilotprojekts gefordert haben:

Gründe für das Pilotprojekt

• Hohe Kosten bei Änderungen und Nachforderungen für bereits vergebene Anforderungsspezifikationen auf Grund nicht ausreichender Qualität und Durchgängigkeit der Spezifikationen.

• Schwieriger und nicht transparenter Zugriff aller Beteiligten auf vorhandene Anforderungen und Anforderungsspezifikationen.

• Fehlendes anforderungsbasierendes Variantenmanagement ihrer Produkte.

• Nicht darstellbares und durchgängiges Anforderungs- und Abnahmemanagement.

• Zu hoher Aufwand für die Bedienung von Tools im RE/M-Bereich.

• Fehlende Wiederverwendungskonzepte und dadurch verursachter Aufwand für immer wieder ähnliche Tätigkeiten.

Was sollte mit dem Pilotprojekt erreichen werden?

Welche Vorteile für welche Bereiche verspreche ich mir von der Einführung von RE/M? In welche Richtung soll sich meine IST-Situation verändern? Wie stelle ich mir meine verbesserte SOLL-Situation vor? Was sind meine Ziele (Grob- und Feinziele), die ich mit der Einführung von RE/M und meinem Pilotprojekt verfolge?

Einige der Ziele lassen sich natürlich sofort aus der ermittelten IST-Situation ableiten. Interessanter sind jedoch die allgemeineren Ziele, die für ein Pilotprojekt gelten sollten. Einige mögliche Kandidaten sind:

 Ziele des Pilotprojekts

•   Entwicklung von breit ausrollbaren, anwendbaren und gut angepassten Methoden

•   Abschätzungen für Kosten/Nutzen-Rechnungen

•   Erhöhung der Akzeptanz bei den späteren Anwendern

 Versuchen Sie, die Ziele messbar zu formulieren, so dass Sie deren Erreichung am Ende des Pilotprojekts überprüfen können.

Lassen Sie sich während der Durchführung Ihres Pilotprojekts nicht von diesen Zielen abbringen und achten Sie darauf, diese möglichst gut zu erfüllen. Das wird nicht immer einfach sein, da einige der Ziele in Konkurrenz zueinander stehen. Zum Beispiel sollten Sie auf die Pilotanwender und deren Wünsche eingehen, um die Akzeptanz bei den Anwendern zu erhöhen. Falls Sie dadurch sehr spezielle Lösungen entwickeln, so kann es passieren, dass diese sehr speziellen Lösungen eventuell nicht für die breite Anwenderschaft akzeptabel sind.

 Wer sollte von dem Pilotprojekt profitieren?

Welche Abteilungen betreiben schon RE/M und sollen ihre Methoden verbessern? Existieren weitere Abteilungen, bei denen RE/M neu eingeführt werden soll?

Diese und ähnliche Fragen gilt es sehr überlegt zu beantworten. Je breiter Sie die spätere Anwenderschaft auslegen, desto höher wird der Abstimmungsaufwand in Ihrem Pilotprojekt werden. Andererseits werden Sie Ihr Projekt vielleicht im Zuge einer breiter angelegten Vereinheitlichung durchführen, die auch andere Bereiche betreffen soll. Dann ist es natürlich sinnvoll, viele Abteilungen zu betrachten. In dem hier betrachteten Pilotprojekt sollten Methoden für sieben Entwicklungsabteilungen entwickelt und getestet werden.

Von der Beantwortung dieser Fragen hängen auch die Antworten auf die nächsten Fragen ab, mit denen die Mitarbeiter des Pilotprojekts gefunden werden.

Mit wem sollte das Pilotprojekt durchgeführt werden?

Mit wem muss ich während der Durchführung meines Pilotprojekts zusammenarbeiten? Welche internen Geschäftsbereiche bzw. Abteilungen auf der strategischen Ebene werden von der Einführung von RE/M tangiert, können mich unterstützen oder müssen Entscheidungen mit abstimmen? Brauche ich unter Umständen externe Unterstützung, um den Bedarf an neuem Know-how kurzfristig abdecken zu können und das laufende Geschäft nicht zu stören?

Unser Pilotprojekt dient ja u.A. dazu, eine breite Basis von Methoden zu schaffen, die dann später in der Breite, d.h. über viele Abteilungen hinweg, ausgerollt und genutzt werden sollen. Gerade wenn wir uns in einem großen Konzern bewegen, deren Abteilungen eventuell unterschiedliche Methoden und Lösungen für ähnliche Probleme einsetzen, sollten Sie möglichst viele betroffene Abteilungen in das Pilotprojekt integrieren. Diese dienen dann als Multiplikator in ihre jeweiligen Abteilungen hinein bzw. in umgekehrter Richtung als Sprachrohr für die besonderen Bedürfnisse.

Versuchen Sie zusätzlich sehr erfahrene externe Experten zu integrieren um auf fundiertes Methoden-Know-how und Erfahrungen zurückzugreifen. Weiterhin existieren vielleicht Mitarbeiter, die sich schon vorher in dem betrachteten RE/M-Bereich über Maßen engagiert haben. Nehmen Sie diese als »interne« Berater mit hinzu, um so auf das intern vorhandene Know-how aufsetzen zu können, auch wenn Sie sich hier einiges an Konflikten und Diskussionen auf sich zukommen sehen. Ein Pilotprojekt ist die beste Gelegenheit alle erdenklichen Methodenstreits auszuräumen und zu einer abgestimmten Lösung zu gelangen.

In unserem Pilotprojekt ergab sich die folgende Besetzung:

Projektstruktur

• Zwei Personen für Projektleitung und deren Unterstützung inklusive Projektmarketing

• Drei Personen für die Ausarbeitung individueller RE/M-Methoden

• Zwei Personen für die Tooladministration und -Weiterentwicklung

• Zwei Personen für den Support von sieben Pilotanwendern

• Ca. fünf Personen (mit jeweils ca. 20% Aufwand) aus anderen Bereichen (z.B. aus dem Einkauf und anderen Center) als „interne Berater“

 

Aus diesem Personenkreis haben wir das sogenannte Kernteam gebildet, in dem aus jeder der genannten Gruppen mindestens eine Person teilnahm.

Bei der Definition des Zeitplans sollten Sie darauf achten, genügend Puffer für unerwartet eintretende Tätigkeiten mit einzuplanen. Dies sollte zwar bei jedem Projekt gegeben sein, in einem Pilotprojekt hat dieser Puffer jedoch eine höhere Priorität. Die Gründe hierfür haben wir Ihnen in dem nächsten Kapitel genannt. Auch die Auswahl der Pilotanwender spielt eine große Rolle für den erfolgreichen Abschluss des Pilotprojekts. Sie werden in hohem Maße auf den Input und das Feedback dieser Anwender angewiesen sein. Versuchen Sie deshalb, möglichst offene, interessierte und wohlgesinnte Anwender zu rekrutieren. Dies ist natürlich nicht immer möglich, jedoch werden Sie feststellen, dass sich eine Gruppendynamik in der Pilotanwendergruppe einstellt, die auch nicht so positiv gestimmte Pilotanwender eines Besseren überzeugt.

Pilotprojekt durchführen

Nachdem Sie in der Vorbereitungsphase Ziele, notwendige Ressourcen und die Projektstruktur definiert haben, geht es nun darum, Ihr Pilotprojekt durchzuführen. Diese Durchführung haben wir in diesem Artikel in drei Kernaufgaben unterteilt, die weiteren Aufgaben des Projektmanagements werden hier nicht detaillierter betrachtet.

Kernaufgaben der Pilotdurchführung

• Kommunikation ist das A und O

• Entwicklung und Adaption der Methoden

• Support der Pilotanwender

 

 Kommunikation – das A und O

Der Start eines Pilotprojekts sollte, wie in der Regel bei jedem Projekt, mit einem offiziellen Kick-Off-Termin eingeleitet werden. Laden Sie dazu nicht nur das Kernteam Ihres Pilotprojekts ein, sondern auch Ihre Pilotanwender aus den betroffenen Abteilungen. Denn diese entscheiden letztendlich, ob Ihr Pilotprojekt ein Erfolg und ein evtl. folgender Rollout auf operativer Ebene akzeptiert wird oder nicht. Gerade bei Pilotprojekten ist so eine offene Herangehensweise unabdingbar. Fördern Sie daher schon von Beginn an einen intensiven und offenen Kommunikationsaustausch zwischen allen Beteiligten. Stellen Sie zudem während des Kick-Off-Termins Ziele, Zeitplan und Arbeitspakete vor und koordinieren Sie eine sinnvolle Zuteilung der Supporter zu den Pilotanwendern.

Unsere Erfahrung nach ist es hilfreich, während des Projekts für das Kernteam einen wöchentlichen Termin von ca. eineinhalb bis drei Stunden anzusetzen, um zu gewährleisen, dass die durch die Supporter bei den Pilotanwendern ermittelten Erkenntnisse auf direktem Weg und regelmäßig zum Methodenteam getragen werden können und das Methodenteam den Input sofort in die Ausarbeitung von geschäftsbereich-bezogener RE-Methoden mit einfließen lassen kann. Da gerade die internen Mitarbeiter nicht alle Vollzeit in dem Projekt mitarbeiten, dient dieser regelmäßige Termin zur Abstimmung untereinander und, zum Teil wenigstens, zur Diskussion fachlicher Themen.

Aber auch für die Pilotanwender bietet sich eine solche regelmäßige Sitzung an. Alle zwei bis vier Wochen sollten Sie den Pilotanwendern die Möglichkeit geben, sich gegenseitig zu informieren und abzustimmen. Diese Meetings können Sie auch dazu nutzen, neue Methoden etc. gesammelt vorzustellen und Feedback einzuholen.

In der Kommunikation aus dem Projekt nach außen sollten Sie zwei Dinge beachten: Seien Sie zu Ihren Vorgesetzten sehr offen, was den aktuellen Stand Ihres Projekts betrifft. In einem zeitlich so begrenzten Projekt werden Sie kaum Gelegenheit haben, Ressourcen und Zeitpläne zu verschieben. Zum Zweiten haben wir angestrebt, bei der Kommunikation auch die Pilotanwender mit einzubeziehen. Diese sollten in ihren Abteilungen von dem Projekt berichten und die dort getroffenen Entscheidungen mit ihren Kollegen abstimmen. 

Entwicklung und Adaption der Methoden

Mit diesem Aufgabenpaket wird Ihr Pilotprojekt stehen oder fallen. Hier werden Sie die Weichen für eine effiziente und von den Anwendern akzeptierte Lösung stellen.

Ohne auf die Besonderheiten bei unserem RE/M-Pilotprojekt einzugehen, gibt es doch einige Erfahrungen zu berichten, die allgemein für viele Pilotprojekte gelten sollten.

Wir haben immer wieder festgestellt, dass die Pilotanwender nach Lösungen für genau ihre speziellen Problemstellungen suchen. Hier ist es die Kunst, den goldenen Mittelweg zwischen zwei Extremen zu finden. Entwickeln Sie eine allgemeine Lösung, die in der Breite ausrollbar ist und versuchen Sie gleichzeitig die gefundene Lösung auf die speziellen Bedürfnisse anzupassen. Achten Sie aber darauf, dass Sie nicht unendlich viel Zeit in diese Adaptierung investieren. Die Pilotanwender werden auch zufrieden sein, wenn sie einen Weg aufgezeigt bekommen, der erst später realisiert wird. An dieser Stelle ist die Perspektive und das Gefühl, dass ihre Probleme gelöst werden können, für die Pilotanwender ausschlaggebend.

Scheuen Sie sich nicht an Stellen, an denen Sie zur Zeit keine optimale Lösung produzieren können, auch mit Interimslösungen zu agieren. Wichtig dabei ist jedoch, dass Sie diese auch als solche kommunizieren und nicht den Eindruck erwecken, dass die suboptimale Lösung das Non-Plus-Ultra für alle Anwender sei.

Vielleicht werden Sie auch feststellen, dass andere Abteilungen, die noch nicht in Ihr Pilotprojekt involviert sind, versuchen werden, auf den Zug aufzuspringen, um mitbestimmend für die gewählten Lösungen zu sein. Gerade wenn Ihr Projekt richtig Fahrt aufgenommen hat und von außen wahrgenommen wird, wird die Angst größer, von dem Neuen überrollt zu werden. Auch hier gilt es, alle Interessen mit Feingefühl zu beachten, aber andererseits auch seine selbst gesteckten Ziele nicht aus den Augen zu verlieren.

Support der Pilotanwender

Den Supportern wird in Ihrem Pilotprojekt eine besondere Rolle zukommen, denn sie bilden die Schnittstelle zu den Pilotanwendern. Sie haben die Aufgabe, die Pilotanwendern bei der Anwendung der entwickelten Lösungen zu unterstützen. Dies kann, je nach Fähigkeit der Anwender, von der Erklärung des RM-Tools bis hin zu einer sehr speziellen Adaption der entwickelten Lösungen reichen. Daher sollten die Supporter auf der einen Seite die »Sprache« der Anwender sprechen und auf der anderen Seite genügend RE/M-Know-how besitzen.

Bei dem Support sollten Ihre Supporter eine einfache Maßnahme anwenden: Sie sollten möglichst viel Arbeit von den Anwendern fernhalten, damit die Anwender ein positives Bild von den neuen Methoden entwickeln. Schließlich wollen Sie am Ende des Pilotprojekts ein positives Votum erhalten. Auf der anderen Seite darf der Eindruck der neuen Methoden durch diese Maßnahme nicht verfälscht werden. Transparenz ist auch hier wieder das Stichwort.

Um den Pilotanwendern eine selbstständige Meinungsbildung zu ermöglichen, bietet es sich an, das Projekt für die Anwender mit einer Schulung zu starten. Optimal wäre es, wenn sich diese Schulung nach den später beim Rollout geplanten Schulungen richtet. Damit hätten Sie an dieser Stelle zusätzlich eine Feedbackmöglichkeit von Seiten der Anwender.

 

Pilotprojekt nachbereiten

Für die Nachbereitung eines Pilotprojekts gibt es drei wichtige Aufgaben zu erledigen, denen eine besondere Bedeutung bei einem Pilotprojekt zukommen:

Kernaufgaben der Pilotnachbereitung 

• Großes Abschlussmeeting mit den Verantwortlichen

• Konsolidierung der Dokumentationen

• Einholen eines abschließenden Feedbacks

 

 Einholen eines abschließenden Feedbacks

Am Ende des Projekts sollten Sie ein abschließendes Feedback von den Pilotanwendern einholen. Es sollte die gemachten Erfahrungen noch einmal zusammenfassen, Empfehlungen für die Zukunft und die noch offenen Themen beinhalten. Nach diesen Empfehlungen und den offenen Punkten wird sich die Entscheidung richten, ob später die Methoden ausgerollt werden oder nicht.

Um die Ergebnisse »management-tauglich« aufbereiten zu können, müssen Sie schon bei den Feedback-Fragen darauf achten, dass die Antworten in übersichtlicher Form aufbereitet und dargestellt werden können. Stellen Sie nicht zu viele offene Fragen und verwenden Sie ein durchgängiges Bewertungsschema.

Konsolidieren der Dokumentationen

Während des Projekts werden Sie aller Voraussicht nach die entwickelten Methoden nicht in der benötigten Tiefe beschrieben haben. Es hat sich gezeigt, dass ein gewisser Aufwand, die Dokumentation noch einmal kritisch zu überarbeiten, lohnenswert ist.

Gründe für die Konsolidierung der Dokumentation 

• Die Ergebnisse des Pilotprojekts werden Ausgangspunkt für weitere Arbeiten sein

• Ein Nachfolgeprojekt wird erst mit einer gewissen Verzögerung gestartet

• Die Mitarbeiter im Nachfolgeprojekt können neu sein

• Für ein Ausrollen der Methoden wird eine ausführlichere Dokumentation benötigt

Auch wir haben bei dem Nachfolgeprojekt an einigen Stellen bereut, dass die Dokumentation keinen hochwertigen Stand hatte und so die Einarbeitung neuer Mitarbeiter mehr Aufwand als geplant in Anspruch nahm. Eine Möglichkeit wäre an dieser Stelle, die Dokumentation direkt während des Pilotprojekts als eine Art Leitfaden aufzubauen und diesen direkt den Pilotanwendern zur Verfügung zu stellen. Dieser Mehraufwand während des Pilotprojekts wird sich spätestens dann rechnen, wenn Sie im Nachhinein diesen Leitfaden erstellen müssen. Mehr über solche Leitfäden finden Sie in [Rupp07].

Großes Abschlussmeeting mit den Verantwortlichen

Auch das Ende eines Pilotprojekts sollte mit einem Abschlussmeeting ein definiertes Ende finden. Laden Sie auf jeden Fall die Personen ein, die über ein eventuelles Nachfolgeprojekt entscheiden. Lassen Sie die Pilotanwender ihre Erfahrungen aus erster Hand noch einmal zusammenfassen, um auch hier wieder Transparenz, diesmal in Richtung Management, zu schaffen. Vielleicht haben die Pilotanwender auch schon mit ihren Kollegen diskutiert und können so ein breiteres Meinungsbild vertreten. Gleichzeitig können Sie hierbei auch versuchen, die Teilnehmer am Pilotprojekt für das Nachfolgeprojekt zu gewinnen, damit das erworbene Wissen der Beteiligten auch weiterhin gewinnbringend eingesetzt werden kann.

Zusammenfassung

In diesem Artikel haben wir Ihnen die drei Phasen eines Pilotprojekts vorgestellt. Wir sind auf die wichtigsten Aufgaben und Fallstricke eingegangen, die zum größten Teil typisch für ein Pilotprojekt sind.

Leider konnten wir nicht auf die Einzelheiten des Pilotprojekts und des daraus entstandenen Rollout-Projekts eingehen. Wenn Sie mehr Information dazu oder einen Zusammenfassung über Einführungsstrategien im Bereich RE/M haben möchten, können Sie uns gerne unter www.sophist.de kontaktieren.

Abschließend haben wir Ihnen den Nutzen und die Risiken eines Pilotprojekts noch einmal in der nachfolgenden Tabelle zusammengefasst.

Dr. Stefan Queins, Chris Rupp

 

Nutzen	Risiken
Mit Hilfe von Pilotprojekten kann ein praxisnahes und -erprobtes Basiskonzept erarbeitet werden.	Fehlende und laufende Dokumentation der Arbeitsstände und Arbeitsergebnisse während des Pilotprojekts erschweren die Wiederverwendung und Weiterverarbeitung der Ergebnisse des Pilotprojekts. Eventuell sind die ermittelten Lösungen auch zu anwenderspezifisch. Planen Sie einen gewissen Aufwand ein, um nach der Durchführung des Projekts die Dokumentationen zu überarbeiten und dabei zu verallgemeinern.
Das Kosten/Nutzen-Verhältnis der neuen Methoden kann mit Hilfe von Pilotprojekten in »kleinem« Rahmen getestet werden.	Steht nur ein knapp bemessener Zeitraum zur Durchführung von Pilotprojekten zur Verfügung, können bei einer intensiven Zusammenarbeit mit mehreren Pilotanwendern terminliche Verzögerungen eintreten, die durch weiteren Support bzw. einer eingeschränkten Umplanung abgefangen werden können.
Mit Hilfe von Pilotprojekten gewinnen Sie Multiplikatoren auf operativer Ebene.	Der Nutzen der eingeführten Methoden ist einem einzelnen Anwender nicht vermittelbar. Rekrutieren Sie offene und positiv eingestellte Anwender.
Mit Hilfe von Pilotprojekten kann die Einführung von neuen Methoden über die operative Ebene »Bottom-Up« unterstützt werden.	Es können Widerstände auf strategischer Ebene bzgl. der Investition für neue Methoden auftreten, die ein Nachfolgeprojekt gefährden. Erhöhen Sie hier von unten den Druck, indem die Pilotanwendern ihren Vorgesetzten von dem Verlauf des Projekts berichten.

 

 Literatur:

[Rupp07] Rupp, C., u.a.: Requirements Engineering und Management, Hanser, 2007.