DER WEG IST DAS ZIEL

schwerpunkt
mehr zum thema:
www.oose.de
www.oose.de/oep
der autor
DER WEG IST DAS ZIEL
In den letzten zehn Jahren habe ich dutzende Unternehmen oder Unternehmenseinheiten bei der Einführung verschiedener Vorgehensmodelle begleitet bzw. dabei
beobachtet sowie mehrere Vorgehensmodelle und Methoden entwickelt oder mitentwickelt. Wenn ich das Fazit daraus in Bezug auf Nutzen und Kosten von Vorgehensmodellen auf einen polarisierenden Satz reduzieren sollte, würde ich relativ
ernüchternd sagen: Die Einführung von Vorgehensmodellen führt zu hohen Kosten
und geringem Nutzen. Aber die Welt ist nicht schwarzweiß, es gibt viele
Abstufungen und Farben dazwischen und so muss man auch die Einführung und
Nutzung von Vorgehensmodellen differenzierter betrachten. Welche Ziele und
Erwartungen werden typischerweise mit Vorgehensmodellen verbunden und welche tatsächlichen Wirkungen und Resultate konnten die anwendenden Unternehmen erzielen? Welche Rahmenbedingungen, Erfolgsfaktoren und Risiken sind
typisch und welche Ziele wirklich realistisch? Darauf gibt dieser Beitrag Antworten.
Seit Anbeginn der Informatik existieren
Bestrebungen, die Softwareentwicklung
erfolgreicher zu machen. Neben immer
neuen und besseren Methoden ist ein
Mittel hierfür die Standardisierung von
Prozessen, z. B. mithilfe von Vorgehensmodellen. Die Grundidee dabei ist,
bewährte Techniken und Vorgehensweisen
als Mindeststandards konkret festzuschreiben. Bekannte Fehler und Problemsituationen sollen damit vermieden werden, was
vor allem für Unerfahrene nützlich ist.
Standardisierung
auf Mittelmaß?
Grundsätzlich funktioniert dieser Verbesserungsansatz, aber er hat auch Schattenseiten:
■ Sehr erfahrene und erfolgreiche Projektmanager werden gelegentlich behindert. Im Zweifelsfall erfolgt eine
Standardisierung auf Mittelmaß.
■ Projekte mit üblichen, durchschnittlichen und von den Vorgehensmodellen
vorgesehenen Problemsituationen erhalten eine gute Unterstützung. Für alle
anderen Projekte kann der Standard
unpassend und möglicherweise sogar
kontraproduktiv sein.
■ Vorgehensstandards können zum bürokratischen Selbstzweck verkommen,
wenn die dafür Verantwortlichen den
Praxisbezug verloren haben.
■ Standards werden oftmals zu langsam
weiterentwickelt und zielen somit auf
Problemsituationen, die in der Vergangenheit eine Relevanz hatten, unterstützen aber aktuelle Fragestellungen
nur unzureichend.
14
15
■ Die beteiligten Personen übernehmen
weniger eigene Verantwortung für ihre
Entscheidungen und ihr Handeln, da sie
schließlich nur Vorschriften befolgen.
Es gibt Vorgehensmodelle, die individuell
in einzelnen Projekten eingesetzt werden,
oft bewusst ausgewählt, manchmal aber
auch unbewusst. Es gibt Vorgehensmodelle, die werden als konzern-, unternehmens- oder abteilungsweiter Standard
eingeführt, manchmal von den Beteiligten,
häufig von Zentralabteilungen oder Elfenbeinturm-Bewohnern. Und es gibt Vorgehensmodelle, die aufgrund gesetzlicher
Vorgaben verwendet werden müssen.
Verwechslung von Methodik
und Vorgehensmodell
Die mit der Einführung von Vorgehensmodellen verbundenen Ziele variieren
ebenso. Hier ein paar Praxisbeispiele:
■ Einführung bestimmter Standards, z. B.
die Modellierung mit der UML, oder
ein gezieltes Ausmerzen bzw. Kompensieren der Defizite bestehender
Standards oder Werkzeuge, z. B. durch
die Definition eigener Anforderungsoder Anwendungsfalltypen.
■ Standardisierung und Vergleichbarkeit
verschiedener Projekte in einem Unternehmen, um einheitliche Beziehungen
der Projekte zu ihrer Umgebung zu
schaffen, die Austauschbarkeit von
Menschen und Ressourcen zu verbessern, die Transparenz zu erhöhen und
Ähnliches.
■ Erfüllung einer Rahmenbedingung,
z. B. wenn der Auftraggeber oder Ge-
Bernd Oestereich
(E-Mail: [email protected])
ist Geschäftsführer der oose Innovative
Informatik GmbH, Autor des Buches „APM –
Agiles Projektmanagement” und Coach für
Projektmanagement und Vorgehensmodelle.
setzgeber die Anwendung eines bestimmten Vorgehensmodells fordert. In
diesem Fall könnte die Anwendung des
Vorgehensmodells soweit reduziert
werden, wie es zur Erfüllung dieser
Rahmenbedingungen gerade notwendig oder opportun ist.
■ Etablierung einer lernenden Organisation, d. h. systematische Wiederverwendung von Best Practices und
Lernen aus Fehlern durch ein partizipativ und kontinuierlich (weiter-)entwickeltes Vorgehensmodell.
■ Einführung einer modernen Softwareentwicklungsmethodik: Dabei werden
Methodik und Vorgehensmodell verwechselt, d. h. eine Methodik wird
benötigt und ein Vorgehensmodell wird
als Lösung gesehen (siehe Kasten 1).
Sofern die Methodik im Vorgehensmodell enthalten ist, kann dies möglicherweise sogar ziel führend sein – in
jedem Fall ist es ineffizient und unnötig
aufwändig, da ein Vorgehensmodell
viele über die reine Methodik hinausgehende Bestandteile enthält. Noch
riskanter ist es, wenn gar nur einzelne
Konzepte von Interesse sind, z. B. nur
die Regelung der AuftragnehmerAuftraggeber-Beziehung oder nur das
iterative Vorgehen. Die übrigen
Elemente des Vorgehensmodells bewirken dann möglicherweise unnötige
Veränderungen.
■ Aufbau von Know-how im Unternehmen, d. h. das Vorgehensmodell soll die
Ausbildung der Mitarbeiter leisten,
ersetzen oder unterstützen. Selbstverständlich kann ein Vorgehensmodell
den Wissensaufbau unterstützen, len-
schwerpunkt
ken oder vereinfachen. Vorgehensmodelle sind aber abstrakte Beschreibungen und normalerweise nicht mit
dem Ziel der Mitarbeiterausbildung
entwickelt worden und daher hierzu
kaum geeignet. Dies kann besser über
didaktisch konzipierte Seminare,
Coachings und praktische Übungen
erreicht werden – gegebenenfalls begleitend zur Vorgehensmodelleinführung.
■ Vorgehensmodell als Existenzberechtigung für bestimmte Organisationseinheiten oder als eine Rückzugs- oder
Abschiebemöglichkeit für bestimmte
Personen, vor allem auch dann, wenn
ohnehin alle glauben, dass das Vorgehensmodell keine praktische Relevanz entfalten wird.
■ Vorgehensmodell als Instrument der
Machtausübung und Einflussnahme, d. h.
es geht den Initiatoren oder Unterstützern
weniger um die Inhalte als vielmehr
darum, über die mit dem Vorgehensmodell verbundenen Geschäftsordnungsregeln bestimmte Interessen
indirekt durchzusetzen oder abzuwehren.
Manchmal erfolgt das ganz subtil,
manchmal etwas plumper, aber häufig
dem Muster folgend: „Wenn ich schon
bestimmte Arbeits- und Organisationsstrukturen und -prozesse, also Machtverhältnisse, formal nicht zu meinen
Gunsten ändern kann, kann ich über
Formalien oder Details von Vorgehensmodellen Widersprüche schaffen oder
Projekte behindern, ohne direkt als
Saboteur aufzufallen”.
■ Kaschieren von Problemen: Viele, gerade größere oder lang existierende
Organisationen neigen zu einem defensiven, gar scheuen Umgang mit
Konflikten. In einem solchen Umfeld
können Vorgehensmodelle organisatorische oder soziale Probleme zeitweise
kaschieren. Ein Phänomen, das auch
beim Einsatz von Werkzeugen oder
Notationen in der Weise zu beobachten
ist, dass z. B. ein (berechtigter) direkter
Konflikt zwischen zwei Abteilungen
durch Zwischenschaltung eines Werkzeugs zu einem indirekten und somit
versteckteren Konflikt verwandelt wird.
Der eine oder andere der oben genannten
Punkte ist genau genommen natürlich kein
Ziel, sondern eher zynische und traurige
Realität.
1/2009
Eine Unterscheidung zwischen den Begriffen „Methode”, Methodik” und „Methodologie” ist im deutschsprachigen Wissenschaftsraum häufig anzutreffen. Viele
Fremdsprachen, auch die englische Sprache, erlauben diese Unterschiede jedoch nicht,
was zusammen mit einer unreflektierten Verwendung von Anglizismen zu Unschärfen
und Verwirrungen im Deutschen führt. Alleine schon deswegen ist eine kurze
Erläuterung der hier verwendeten Bedeutung sinnvoll.
■ Eine Methode ein einzelnes Verfahren und beschreibt eine Vorgehensweise für einen
bestimmten Anwendungsbereich. Beispielsweise kann die Beschreibung von
Anforderungen mit Hilfe von Anwendungsfällen als Methode bezeichnet werden.
Die Beschreibung von Anforderungen mit Hilfe von Testfällen wäre eine andere
Methode. Irrtümlicherweise werden Notationen manchmal auch als Methode
bezeichnet, z. B. die UML. Erst die Beschreibung, wie die UML anzuwenden ist,
wäre eine Methode.
■ Eine Methodik ist die Lehre von der Anwendung einer Methode.
■ Eine Methodologie ist die theoretische Reflexion über Methoden eines Fachgebiets.
■ Ein Vorgehensmodell beschreibt die Abwicklung eines Entwicklungsvorhabens und
orientiert sich dabei zumeist am Lebenszyklus des Vorhabens bzw. des zu erstellenden Produkts. Vorgehensmodelle sind mehr oder weniger strukturierte
Beschreibungen und Sammlungen von Aktivitäten, Ergebnissen, Beteiligten,
Organisations-, Entscheidungs-, Berichts- und Verantwortungsstrukturen,
Werkzeugen/Hilfsmitteln, Good Practices, Richtlinien, Standards, Mustern (z. B.
Formulare) und Beispielen. Insofern können Vorgehensmodelle wiederum Methoden
beinhalten und stellen eine Methodik (unter Umständen auch mehrere) dar. Sie beinhalten aber üblicherweise mehr als nur eine Methodensammlung. Das V-Modell XT
beschreibt z. B. die vertragliche Zusammenarbeit und Abgrenzung der
Verantwortlichkeiten von Auftragnehmer und Auftraggeber entlang des
Lebenszyklus eines Projekts. Es enthält aber zusätzlich auch Beschreibungen, was ein
Anwendungsfall ist und wie das Konzept des Anwendungsfalles eingesetzt werden
kann oder soll.
■ Ein Reifegradmodell stellt Forderungen an ein Vorgehen(smodell), um die Qualität
des Prozesses zu bewerten. Es dient vorrangig der Bestimmung von Verbesserungsmaßnahmen.
Kasten 1: Begrifflichkeiten.
Auch die Art und Weise, wie Vorgehensmodelle in der Praxis inhaltlich ausgestaltet, festgelegt oder (weiter-)entwickelt werden, kann sehr unterschiedlich sein:
■ Vorgehensmodelle werden unverändert, unangepasst (und eventuell auch
unreflektiert) übernommen.
■ Standard-Vorgehensmodelle werden
unternehmensspezifisch angepasst und
sind dann einheitlich zu verwenden.
■ Standard-Vorgehensmodelle sind jeweils projektspezifisch anzupassen.
■ Oder beides: Erst erfolgt eine unternehmensspezifische und zusätzlich eine
projektspezifische Anpassung.
■ Das Vorgehensmodell bildet einen möglichen (projektspezifischen) Ausgangspunkt, von dem aus beliebige Anpassungen eigenverantwortlich stattfinden
sollen und erwünscht sind.
■ Das Vorgehensmodell wird nur als
Ideensammlung oder Baukasten gesehen, in dem man sich bedarfsweise
bedienen kann.
Die Anpassung von Vorgehensmodellen
betrifft gewöhnlich folgende Aspekte:
■ die äußere Form, d. h. Farben, Unternehmens-Image (Corporate Identity),
Logos und Namen,
schwerpunkt
schnell, wenn sich kein kurzfristiger Nutzen für die Beteiligten einstellt. Erfolgsfaktoren für ein Mindestmaß an
Akzeptanz sind beispielsweise:
Abb. 1: V-Modell XT.
■ die Integration spezieller Konzepte,
z. B. bestimmte zusätzlich Standardmeilensteine,
Qualitätsmeilensteine
(Quality-Gates), Rahmenrichtlinien
und Qualitätsstandards,
■ die Terminologie, d. h. die Umbenennung von Phasen, Meilensteinen,
Aktivitäten, Ergebnissen, Akteuren
usw.,
■ die implizit oder explizit enthaltene
Softwareentwicklungsmethodik, z. B.
bezüglich spezieller Architekturen,
Werkzeuge, Rahmenwerke und Entwicklungsumgebungen,
■ die
Projektmanagement-Methodik,
z. B. wegen auf mehrere Standorte verteilter Projekte und spezieller Zulieferbeziehungen,
■ Branchen- und Domänenspezifika, z. B.
spezielle Qualitäts- und Sicherheitsanforderungen, externe Zertifizierungen
und Dokumentationspflichten sowie
■ Organisationsspezifika, z. B. Berichts-,
Kontroll- und Entscheidungsstandards
und Verantwortlichkeiten, aber auch
die typische Projektgröße und -dauer.
Akzeptanz von
Vorgehensmodellen
Die Akzeptanz von Vorgehensmodellen bei
den Projektmitgliedern und anderen Nichtentscheidern ist – in Abhängigkeit von den
oben genannten tatsächlichen Zielen – in
der Regel gering. Bei reinen machtgetriebe-
16
17
nen Instrumentalisierungen kann es zu
offener Ablehnung und Boykott kommen,
aber auch bei Zielen, die das Werteverständnis der Projektmitglieder mehr
treffen (z. B. partizipative Modelle) fehlen
häufig die Motivation, das Verständnis
oder das Wissen bzw. die Information an
sich. Ziele, auch wenn sie von einer
Mehrheit getragen würden, müssen aktiv
vermittelt und verinnerlicht werden. Hier
hapert es häufig einfach daran, dass
Führungskräfte die Vermittlung von Zielen
auf kurze Mitteilungen beschränken und
nicht als Diskurs, also als ein wechselseitiges, erörterndes Hin und Her, betrachten.
Da Vorgehensmodelle von Menschen
praktiziert werden sollen, also von intelligenten, mitdenkenden, kreativen, kritischen und sozialen Wesen, ist es mit
Befehlen oder einfachen Mitteilungen nicht
getan. In stark hierarchisch geführten
Organisationen – einige Militärs praktizieren diese – werden Menschen hierzu aufwändig gedrillt, in partizipativen Organisationen ist ein Diskurs üblich. In jedem Fall
lässt sich die Vermittlung und Verinnerlichung eines Vorgehensmodells nur sehr
bedingt ab- oder verkürzen. Für Entscheidungsträger ist dies ärgerlich, weil es Zeit
und Geld kostet.
Aber auch bei weitgehender Akzeptanz
ist eine extrem selektive Anwendung bzw.
ein selektives Interesse am Vorgehensmodell üblich und die anfängliche wohlwollende Annäherung und Neugierde stirbt
■ Die Verständlichkeit hat Vorrang vor
formaler Korrektheit, die verwendete
Terminologie ist reibungsarm.
■ Die Anwender finden Anregungen und
Leitlinien zur Förderung der Kommunikation und empfängerorientiertem Arbeiten.
■ Es existieren konkrete und direkte
Vorschläge zu Standardsituationen,
z. B. eine Musteragenda für ein Anforderungsarbeitstreffen. Des Weiteren
gibt es Prüflisten, Leitfragen, Dokumentenvorlagen, Muster, Beispieldokumente und Ähnliches.
■ Die Rahmenbedingungen für das
Vorgehensmodell sind möglichst einfach. Das Vorgehensmodell konzentriert sich auf die Beschreibung elementarer Konzepte und Inhalte, d. h. es
wird durch systematisches Weglassen
von Inhalten vereinfacht. Je mehr Eventualitäten und Sonderfälle zu berücksichtigen sind, desto höher ist der
Aufwand und desto geringer die Bereitschaft, das Vorgehensmodell konkret
anzuwenden.
■ Das Vorgehensmodell appelliert und
motiviert explizit zu einer eigenverantwortlichen und kritischen Anwendung,
um ein blindgläubiges (oder gar blindwütiges) Anwenden zu vermeiden.
Agile Vorgehensmodelle berücksichtigen
diese Aspekte gewöhnlich besser und treffen dadurch oftmals auf eine höhere
Akzeptanz. Aber natürlich können sie auch
nutzlos praktiziert werden, wenn sie etwa
blindlings oder unqualifiziert angewendet
werden, nicht zu den Werten der beteiligten
Menschen passen oder diese mit ihren häufig höheren Anforderungen an die
Eigenverantwortung überfordern. Agilität,
also Beweglichkeit, erfordert auch, gegebenenfalls vermeintlich sichere und damit
komfortable Positionen zu verlassen, was
Unsicherheit oder Ängste auslösen kann.
Die Diskussion und der Diskurs über
Vorgehensmodelle – sei es allgemeiner Art
wie im Schwerpunktteil dieser Ausgabe von
OBJEKTspektrum oder auch innerhalb
eines Projekts für das dortige Vorgehensmodell – ist jedoch hilfreich und
wichtig, weil alle Beteiligten die Chance
haben, zu lernen, zu wachsen und sich auf
schwerpunkt
gemeinsame Ideen, Überzeugungen, Konzepte und Begriffe zu
einigen. Zumindest dann, wenn die Diskussion nicht ideologisch
geführt wird und eine echte Bereitschaft vorhanden ist, die eigenen Überzeugungen zu hinterfragen und fremde Meinungen verstehen zu wollen.
■
■
■
■
■
Was lief gut?
Was kann verbessert werden?
Was haben wir gelernt?
Was wollen wir ändern?
Wie hat uns das Vorgehensmodell bei unserer Arbeit geholfen?
Diskurs statt Anordnung
Je mehr also Vorgehensmodelle als laufender Diskussions- und
gemeinsamer Entwicklungsprozess an Stelle eines einmal erstellten und einzuführenden Ergebnisses betrachtet werden, um so
höher wird der Nutzen für die Organisation sein. Das gilt meines
Erachtens auch für zwangsweise vorgegebene Vorgehensmodelle,
wie z. B. das „V-Modell XT”. Es ist eine Sache, die damit verbundenen Mindeststandards umzusetzen und zu erfüllen, etwa
die Auftraggeber-Auftragnehmer-Schnittstelle. Eine andere ist es,
die vielen Möglichkeiten zur konkreten Ausgestaltung in diesem
Sinne gut zu nutzen.
Das heißt nicht, dass in einer Organisation permanent über
Vorgehensmodelle diskutiert werden soll. Überhaupt sind es
nicht die Vorgehensmodell-Arbeitskreise, die der Akzeptanz und
dem Nutzen wirklich auf die Sprünge helfen. Der gescheitere
Weg ist die Etablierung regelmäßiger Retrospektiven in den
Entwicklungsprozess, z. B. am Ende einer jeden Iteration, mit
denen das Entwicklungsteam bzw. die einzelnen Organisationseinheiten innerhalb des Gesamtprojektes ihre eigene Arbeit
reflektieren:
1/2009
Die Erkenntnisse und Ideen aus diesen Retrospektiven gilt es
bezüglich ihrer Relevanz für das Vorgehensmodell zu filtern, einzusammeln und nach Kosten-Nutzen-Aspekten zu priorisieren,
um damit das Vorgehensmodell sukzessive und projektengetrieben weiterzuentwickeln und aktuell zu halten. Wobei
„weiterentwickeln” dann auch heißen muss, Bestandteile wieder
herauszunehmen, das Modell immer wieder zu verschlanken,
wenn Elemente offenbar nicht genutzt werden oder keine
Akzeptanz finden, oder sich andere Maßnahmen zu überlegen,
mit denen die Praxisakzeptanz gefördert werden kann.
Der Ansatz der kontinuierlichen projektgetriebenen
Weiterentwicklung des Vorgehensmodells ermöglicht es unter
entsprechenden Rahmenbedingungen auch, klein anzufangen,
das Vorgehensmodell langsam aufzubauen und weiterzuentwickeln und birgt in vielen Fällen eine bessere Chance, einen ROI
(Return on Investment) herbeizuführen als eine plumpe Vonoben-nach-unten-Entscheidung zur Einführung eines Vorgehensmodells.
■

Download Report