PHP Magazin | Klar, miteinander reden!

Das Wasserfalldenken ist in Unternehmen allgegenwärtig. Gestützt durch diese Erfahrung werden Teams nur aus einer Disziplin, nicht über Disziplin- und Abteilungsgrenzen hinweg besetzt. Damit einhergehend werden Projektziele nur selten interdisziplinär vereinbart.

 

Daher messen die beteiligten Unternehmensbereiche Projekterfolg unterschiedlich. Entsprechend werden Prioritäten im Projekt unterschiedlich gesetzt. Löst man diese Widersprüche nicht auf, wird man im Projektalltag stolpern.

Wie Interdisziplinarität dem Unternehmenserfolg dient

Cover-Foto | PHP Magazin 04.2013
PHP Magazin 04.2013

Projekte verlaufen schwierig, weil zum Projektstart elementare Fragen nicht gestellt werden. So ist in vielen Projekten weder klar, wer genau zum Projektteam gehört, noch ist klar, was im Projekt erreicht werden soll.

 

Wenn diese Fragen nicht geklärt sind, fallen alle Beteiligten unter Projektdruck in altbewährte Muster zurück. Diese Muster sind geprägt vom Wasserfall-Denken, Selbstverteidigung und Schuldvorwürfen gegenüber anderen Projektbeteiligten.

 

Um Projekte erfolgreich abzuschließen, ist es aber notwendig, dass alle Beteiligten an einem Strang ziehen. Wie kann man das erreichen?

Die große erste Unbekannte: das Projektteam

Eine sehr einfache Frage bringt viele Projektbeteiligte ins Schlingern: „Wer ist im Team?“ Diese Frage wird für Software-Projekte sehr unterschiedlich beantwortet. Fragt man das Management eines Unternehmens, werden diese häufig alle Beteiligten zum Team zählen, die an die Projektsteuerungsebene berichten. Fragt man „weiter unten“ an, werden vielleicht nur noch die Mitarbeiter und Mitarbeiterinnen aus der IT als Team-Mitglieder genannt. In vielen Fällen begreifen sich die Entwickler und Entwicklerinnen als das Projektteam. Alle andere Beteiligten liefern im Verständnis der Entwickler und Entwicklerinnen Vorarbeiten und Inhalte zu.

 

In der Praxis findet sich oft eine Gruppe, die sich für das Projekt zuständig fühlt. Diese definiert für sich selbst, das Projektteam zu sein. Diese Entscheidung kann jeder Mitarbeiter bzw. jede Mitarbeiterin für sich selbst treffen. In Extremfällen finden sich großen Unternehmen zu Projektmeetings Mitarbeiter bzw. Mitarbeiterinnen ein, bei denen Aufgabe und Rolle für alle anderen gänzlich unbekannt sind. Wenn eine solche Situation in einem klassisch-hierarchischen (großen) Unternehmen entsteht, in dem offenes Fragen unternehmenskulturell nicht verankert ist, nehmen Personen an bestimmten Arbeitstreffen da, von denen die anderen nicht sicher wissen, wie überhaupt der betreffende Name lautet. Die Projektmethode SWBLM („So wie beim letzten Mal“) zeigt sich über diese Art der Teamdefinition in Reinkultur [1].

 

Aber auch in kleineren Unternehmen und Projekten kann SWBLM zu Problemen führen. In diesen Fällen ist klar, wer zum Projekt gehört. Häufig ist aber weder nachvollziehbar und noch transparent, wer welche Rolle im Projektteam einnehmen soll.

 

Ein Projektteam ist eine Gruppe von Menschen, die ein gemeinsames Ziel verfolgt und dabei mit bestimmten Regeln und Ritualen vorgeht.

 

Es macht einen Unterschied, ob eine Mitarbeiter bzw. eine Mitarbeiterin etwas zuliefert oder ob eben jener Mitarbeiter bzw. jene Mitarbeiterin eine Team-Teilaufgabe im Projektteam erfüllt. Wenn jemand Zulieferungen zu erbringen hat, sind Qualität und Zeitpunkt der Übergabe zu klären. Die Prozessschritte bis dahin sind für das Projektteam nicht wichtig. Ist aber der Mitarbeiter bzw. die Mitarbeiterin in die Projektarbeit integriert, sind die Prozessschritte mit den anderen Aufgaben des Teams zusammen zu koordinieren und zu erstellen.

Tipp #1: Das Entwicklungsteam zum Projektteam erweitern

Wenn Eure Projektarbeit dadurch bestimmt ist, dass das Entwicklungsteam als das Projektteam verstanden wird, wird es Zeit für eine interdisziplinäre Vergrößerung. Damit diese gelingt, sollte sich das jeweilige Team Zug um Zug neue Team-Mitglieder anderer Disziplinen aufnehmen. Hierfür wird vom Team ermittelt, wer am Projekt mit welcher Rollen und welchen Aufgaben beteiligt ist. Mögliche Rollen sind

  • Zulieferer (Strategie, Konzept, Design, User Experience)

  • Integration (Infrastruktur, Betrieb, Schnittstellen)

  • Management (Qualitätssicherung)

Das Team entscheidet, welche Rolle und Aufgabe jeweils am Einfachsten in die direkte Teamarbeit zu integrieren ist. Wenn diese Integration dieser Person erfolgreich verlaufen ist, erweitert sich das Team wieder.

Eine schrittweise Erweiterung erleichtert das Etablieren und Ausprägen von Team-Regeln. Die spontane Erweiterung um viele Personen wird die notwendigen Team-Prozesse erschweren.

Aber selbst wenn die Beteiligten (und deren Rollen) feststehen, bleibt häufig eine weitere, elementare Fragenunbeantwortet: „Was wollen wir erreichen?“ - auf diese Frage folgt„Woran messen wir unseren Projekterfolg?“


Obwohl es unglaublich klingt, in vielen Projekten haben sich die Projektbeteiligten nicht auf ein interdisziplinäres Ziel für das Projekt geeinigt. Und so kann es sein, dass das Entwicklungsteam einen technischen Relaunch eines Systems mit wenigen Feature-Erweiterungen anstrebt, während gleichzeitig die Marketingabteilung durch einen Relaunch eine neue Markenpositionierung erreichen möchte. Ist dies der Fall, wird voraussichtlich eine der Parteien beim Projektende enttäuscht sein.

Die zweite große Unbekannte: das Projektziel

Ein gutes Projektziel ist eindeutig formuliert und wird von allen Projektbeteiligten getragen und angestrebt. Um festzustellen, ob Projektziele gut formuliert sind, ist nachzuprüfen, ob sie SMARTEN Kriterien folgen:

 

Zielsetzung

Bedeutung für das Projektziel

S

Spezifisch

Das Ziel ist präzise, eindeutig und für alle nachvollziehbar formuliert.

M

Messbar

Das Projektziel wird mit messbaren Kriterien unterlegt. Es werden Kriterien gewählt, die objektiv ermittelbar sind.

A

Annehmbar

Das Ziel ist so formuliert, dass das Projektteam die Aufgabe annehmen kann und möchte.

R

Realistisch

Das definierte Ziel ist für die Beteiligten erreichbar. Auch wenn durch das Projekt Neuland betreten wird, erscheint das Ziels machbar.

T

Terminiert

Die Fertigstellung des Projekts ist mit einem genauen Datum versehen.

 Aber Klarheit in der Zielsetzung alleine genügt nicht. Wenn das Ziel nur aus einer Disziplin heraus formuliert ist, kann eine Überprüfung der Zielerreichung und die Ableitung der notwendigen Projektmaßnahmen nicht erfolgen.

Ein gemeinsames Ziel erarbeiten

 In vielen Projekten ist eine Frontenbildung um Ziele anzutreffen. Die Disziplinen formulieren jeweils für sich Ziele. Es gibt keine gemeinsame Sicht. Als Beispiel sei der Relaunch eines Webshops mit den Zielen einiger Disziplinen benannt:

  • Das Marketing möchten ein maximales Online-Markenerlebnis erreichen und als „Best in Place“ wahrgenommen werden.

  • Der Vertrieb möchte einen Webshop ausliefern, welches zukünftig eine deutlich höhere Konversionsrate aufweist.

  • Das Entwicklungsteams formuliert das Ziel: Das bestehende System wird technisch neu aufgesetzt („state of the art“), einige Features werden hinzugefügt. Das System wird zu einem bestimmten Datum live gestellt.

Weitere Disziplinen werden für das Projekt andere Ziele formulieren. Werden nun die Anforderungen im Wasserfall-Modell aufgenommen und nach Passieren der Design-Abteilung an das Entwicklungsteam durchgereicht, ist der Konflikt vorprogrammiert. Beim Durchlaufen der einzelnen Stationen werden die Anforderungen jeweils durch die aktuelle Disziplin überprägt. Dieser Konflikt kann direkt ausgetragen werden. In vielen Fällen überformt die jeweilige Disziplin die jeweiligen Arbeitsergebnisse. Erst bei der internen Auslieferung wird den anderen Disziplinen bewusst, dass ihre Ziele nicht eingelöst werden. Der Vorwurf geht an dieser Stelle an die Technik, „die nicht liefert“.

Durch eine gemeinsame Definition der Ziele wird dieser Vorgang vermieden. Das Ziel ist so zu formulieren, dass es für alle Beteiligten verständlich ist.

Tipp

#2: Als gemeinsame Sprache die Betriebswirtschaft nutzen

Um das interdisziplinäre Projektziel zu formulieren, tragen alle Projektbeteiligten ihre Zielsetzungen zusammen. Diese werden gegenseitig erläutert und erklärt. Die Folgen werden dabei in der eigenen Disziplin formuliert – und in eine gemeinsame Sprache überführt. Alle Beteiligten übersetzen dabei immer ihre Punkte in fachliche, möglichst betriebswirtschaftliche Folgen.

Dabei geht es nicht um eine exakte Voraussage, sondern um eine ungefähre Abschätzung der Folgen.

  • Testabdeckung 90% => Lebensdauer des Systems ca. acht Jahre

  • Seitenaufbau innerhalb von 10ms => erhöhte Konversionsrate

  • Konsistente Markensprache => erhöhte Wiedererkennung (= erhöhte Kundenbindung)

Um ein einheitliches Ziel zu formulieren, müssen die Beteiligten das Umfeld verstehen. Dabei sind alle Disziplinen zu befragen:

  1. Fachlicher Kontext: In welchem Marktumfeld findet das System statt? Welchen Zweck erfüllt das System? Welche Lebensdauer hat das System voraussichtlich? Sind Änderungen (welcher Art, welchen Umfangs) während der Lebenszeit zu erwarten?

  2. Betriebswirtschaftlicher Kontext: Wie funktioniert das Geschäftsmodell? Gibt es besondere Funktionen des Systems, die starken Einfluss auf das Geschäftsmodell haben?

  3. Technischer Kontext: In welchem Umfeld ist das System positioniert? Welche Schnittstellen bestehen?

Ein technischer Relaunch ist in diesem Sinne kein Ziel, sondern eine Maßnahme, um darauf aufsetzende betriebswirtschaftliche Vorgänge zu ermöglichen. Unter Berücksichtigung des Umfelds formuliert das Team das Projektziel. Um diese wörtlich nicht aus dem Auge zu verlieren, empfehlen sich zwei Maßnahmen:

  1. Das Projektteam sitzt räumlich direkt beieinander. Um eine direkte, einfache Kommunikation zu ermöglichen, stehen weder Mauern, Stockwerke oder Gebäude zwischen den Team-Mitgliedern.

  2. Das Projektziel ist für alle Team-Mitglieder zu sehen. Die Ziele sind z.B. als Poster auf der Wand angepinnt – oder Teil der Wandzeitung, die den Projektverlauf beschreibt.

Tipp #3: Über Pessimierung zum interdisziplinären Projektziel finden

Manchmal fällt es den Projektbeteiligten schwer, Ziele für Projekte zu benennen. Die Gründe hierfür sind vielfältig. Ein möglicher Weg aus dieser Situation ist die Moderationsmethode des Pessimierens (diese macht darüber hinaus sehr viel Spaß).

In einem Meeting mit allen Beteiligten fragt der Moderator bzw. die Moderatorin: „Das System soll heute live gehen. Alle sind sich einig: es ist das schlimmste System, das es jemals gab.... Wie genau sieht dieses System aus?“

Die Teilnehmer und Teilnehmerinnen des Meetings tragen die Punkte zusammen. Meistens ist dieser Teil der Übung sehr witzig. Die Punkte werden anschließend inhaltlich (fachlich) zusammengefasst. Dadurch entsteht eine geordnete, pessimierte Sicht auf das Projekt.

Nun drehen die Beteiligten die Aussagen einfach um. Auf diese einfache und zwischenzeitig sehr amüsante Art lassen sich schnell Ziele für das Projekt ableiten.

Teil der Zieldefinition ist die spezifische Beschreibung der Aufgaben. Mehrere Aufgaben werden zu einem Projekt zusammengefasst. Die Projektgröße ist ein wesentlicher Erfolgsfaktor.

Kleine Projekte aufsetzen

Das Projekt als solches sollte immer möglichst klein ausfallenDas geht auf zwei Weisen:

  • „Weniger ist mehr“ - durch eine gezielte Reduktion der Aufgaben wird das Projekt überschaubar.

  • Ein großes Projekt wird in mehrere, voneinander unabhängige Teilprojekte unterteilt.

In den zwölf Prinzipien des agilen Manifests heißt es dazu: „Simplicity – the art of maximizing the amount of work not done – is essential.“ [2] Bei Relaunches ist immer zu fragen: benötigen wir wirklich noch alle Features, die im alten System enthalten sind? Bei der Erstellung eines neues Kerns ist immer zu fragen: „Was ist das kleinste Setup, mit dem das Projektteam live gehen kann?


Viele Projektteams verheben sich. Aus einer langen Regelbetriebsphase auf dem bestehenden System (d.h. einer langen Maintenance-Phase) kommend unterschätzen die Projektteams die Arbeit, die in einem großem Projekt liegt. Aufgrund der fehlenden Projektpraxis macht das Team beim Planen und in der Umsetzung viele Fehler. Mangelnde Projektroutine erschwert das Erreichen der gesetzten Ziele. Daher lohnt es sich, die angehenden Aufgaben in mehrere Teilprojekte zu schneiden, die nacheinander bearbeitet. Durch eine regelmäßige Kontrolle der Arbeit über Retrospektiven wird die Projektarbeit nach und nach verbessert. Durch den bewussten Abschluss von Teilprojekten durch Reviews können die nachfolgenden Teilprojekte weiter optimiert werden. Mehrere kleinere Projekte versprechen mehr Erfolg als das große, eine Projekt. Das jeweilige Ziel ist leichter einzulösen, weil die Aufgabe als solches überschaubarer ist.

Externe Projektziele durch das Team adaptieren

Bei einer externen Beauftragung ist darauf zu achten, dass der Auftraggeber bzw. die Auftraggeberin das Projektziel eindeutig im Lastenheft definiert haben. Derartig vorgegebene Zielesind häufig weder „messbar“ noch „realistisch“ im Sinne der SMART-Charakterisierung.

 

Gleichzeitig enthaltenFormulierungen dieserEbene, vorwiegend fachliche Ziele aufzuführen. Der Schwerpunkt liegt dann in Geschäfts- und Marketingzielen. Die Betrachtung aus technischer Sicht fehlthäufig. Diese Teilziele sind im Rahmen des Projektprozesses zu ergänzen.

 

Diese Ziele sind interdisziplinär zu ergänzen. Dabei orientieren sich die Projektbeteiligten an den durch den Auftraggeber bzw. die Auftraggeberin formulierten strategischen Aussagen und leiten eine Zielformulierung ab, die alle beteiligten Disziplinen reflektiert.

 

Ist das Ziel im Lastenheft nicht SMART für alle Disziplinen formuliert, ist für das Projektsetup der Aufwand einzuplanen, um die Zielsetzung genauer zu formulieren. In diesen Prozess sind sowohl die Auftraggeber und alle anderen Projektbeteiligten zu integrieren.

 

Legt nicht das Team das Ziel fest, sondern wird dieses durch den Auftraggeber bzw. die Auftraggeberin vorgegeben, sind die vorgegebenen Ziele im Sinne von SMART und durch Betrachtung des Umfelds zu überprüfen.

 

Werden alle wichtigen Fragen – aller Disziplinen – über die Zielsetzung beantwortet? Wenn nicht, gilt es nachzuarbeiten. Die Ergebnisse sind mit den Auftraggebern zusammen zu bearbeiten bzw. die Ergebnisse sind bei den Auftraggebern abzusichern.

 

Aus der Zielsetzung des Projekts leiten die Team-Mitglieder Maßnahmen und Aufgaben für das Projektteam ab.  

Die dritte Unbekannte: das Projektvorgehen

Über den Schnitt der Aufgaben hinaus ist durch das Team zu klären, wie im Projekt gearbeitet werden soll. Erst durch eine gemeinsame Arbeitsweise und ein gleiches Verständnis dieser entsteht ein Team im eigentlichen Sinne: eine Gruppe wird dann zum Team, wenn ein gemeinsames Ziel über eine definierte Kooperationsform angestrebt wird.

Um eine gemeinsame Arbeitsweise zu finden, hilft nur eines: Reden! In einem gemeinsamen Meeting legen die Team-Mitglieder grundsätzlich fest,

  1. wie die groben Projektschritte aussehen und

  2. welches Methodenbausteine für die Umsetzung gewählt werden.

Bei diesen Definitionen sollte das Team darauf achten, den groben Projektablauf mit allen Zulieferungen und Lieferterminen zu besprechen. Es empfiehlt sich auch, eine gemeinsame Risikoanalyse vorzunehmen. Wenn die Risiken durch das Projektteam interdisziplinär erfasst werden, steigt die Wahrscheinlichkeit, dass mögliche Risiken auch erkannt werden – schließlich halten dann alle gemeinsam Ausschau danach. Auch bei der Risikoanalyse empfiehlt es sich, neben der Benennung des Risikos aus der eigenen Sicht die Folgen in einer gemeinsamen Sprache zu formulieren. Übertragen alle Beteiligten ihre Themen in betriebswirtschaftliche Auswirkungen, fällt eine Priorisierung der Risiken leichter (da die Folgen in eine vergleichbare Metrik überführt wurden).

 

Setzt ein Projektteam in dieser Phase auf SWBLM, wird es voraussichtlich scheitern. Durch die interdisziplinäre Erweiterung des Teams sind neue Team-Mitglieder dabei, die nicht wissen, wie „es beim letzten Mal“ gelaufen ist. Daher sind alle Methodenbausteine gemeinsam zu besprechen.

 

Dabei genügt es nicht, einfach eine Methodik als Namen in den Raum zu stellen. Mit großer Wahrscheinlichkeit ist das Verständnis über die jeweilige Methodik mindestens in den beteiligten Disziplinen unterschiedlich.

Für alle gewählten Methodenbausteine ist zu erläutern, warum dieser Methodenbaustein gewählt wird:

  • Wer ist an dem Methodenbaustein beteiligt?

  • Was genau passiert dabei?

  • Welche Erwartungshaltungen gibt es and ie Beteiligten?

  • Welches Ergebnis wird durch den Methodenbaustein erzielt?

Diese Explizierung wird allen Beteiligten – wenn sie dies nicht geübt sind – schwerfallen. Das „Meta-Wissen“ über Projekt-Methodenbausteine ist häufig sehr gering. Vielleicht ist aber die bewusste Diskussion um das Projektvorgehen auch eine Chance, sich von alten Hüten zu trennen.

Während dieser Diskussion der Methodenbausteine ist darauf zu achten, dass alle Disziplinen einen Beitrag zur Diskussion leisten. Wenn mehrere Vorgehensmodelle zur Diskussion stehen, bietet sich eine für die Beurteilung eineadaptierte Form des ATAM-Vorgehens (Architecture Tradeoff Analysis Method, [3]) an.

Tipp #4: Mit „ATAM“ Vor- & Nachteile des Projektvorgehens benennen

Mit ATAM leitet das Projektteam aus technischen, betriebswirtschaftlichen und fachlichen Anforderungen mögliche Vorgehensmodelle ab. Diese Modelle werden eigenständig nebeneinander visualisiert. Die jeweilige Zielerfüllung wird in fachlicher und technischer Hinsicht bewertet.

Durch diese Darstellung werden Vor- und Nachteile des jeweiligen Vorgehens offengelegt. Nach Priorisierung der Anforderungen wird ein Vorgehensmodell ausgewählt. Die Ergebnisse können der ATAM-Beurteilung können interessante Impulse für die Risikoanalyse des Projekts liefern.

Bei der Definition der eigentlichen Projektarbeiten ist nochmals kritisch zu überprüfen, ob alle Personen, die initial und zukünftig mit der Anwendung arbeiten werden, bei der Formulierung des Projektziels gehört wurden. Je stärker die Beteiligung in dieser Projektphase ist, desto geringer ist die Gefahr, das während des Projektverlaufs komplett neue Anforderungen auftauchen.

Wenn das Projektteam in gemeinsamen Teamregeln ein Vorgehensmodell verankert hat, dass einen einfachen Umgang mit Anforderungsänderungen sicherstellt, werden kleinere und auch größere Anforderungsänderungen den Projektverlauf nicht gefährden. 

Mit Rückschlägen rechnen und damit umgehen

 Der interdisziplinäre Ansatz sorgt für realistische und befriedigende Arbeitsergebnisse. Gleichzeitig eröffnet sich ein neue Kommunikationsebene. Waren die jeweiligen Prozesspartner bisher in den einzelnen Projektphasen gekapselt, kapselte dies auch die Kommunikation. Der Ärger über unterlaufene Zielsetzungen und die Schludrigkeiten der anderen Disziplinen wurde meist nicht offen ausgetragen.

 

Arbeiten die Projektbeteiligten in einem Team (und möglichst an einem Ort) zusammen, werden Konflikte dieser Art offensichtlich. Diese sind nicht totzuschweigen. Sie sind auszutragen. In Wertschätzung und unter Anerkennung der gemeinsamen Ziele sind Vorgehen und Zwischenergebnisse zu prüfen und zu diskutieren. Am wichtigsten ist dabei die Wertschätzung der Arbeit der anderen Projektbeteiligten. Nur wenn wir diese wahren, fordern und fördern, wird eine wirkliche, interdisziplinär getragene Zusammenarbeit möglich sein.

Der Weg in die Interdisziplinarität: Schritt für Schritt

Ein Entwicklungsteam sollte Projekt für Projekt weitere Team-Mitglieder in die Projektarbeit integrieren. Die Zug-um-Zug erfolgende Erweiterung des Teams erleichtert das Etablieren neuer, gemeinsamer Team-Regeln. Mit jedem Team-Mitglied wird die Zielsetzung überprüft, ergänzt bzw. insgesamt angepasst. Gleichzeitig wird die teaminterne Risikoanalyse mit dem Wissen der neuen Disziplin ergänzt.

 

Um Fehleinschätzungen und das Unterlaufen von Erwartungshaltungen zu vermeiden, klärt das Projektteam genau das Projektvorgehen. Dabei werden die genutzten Methodenbausteine analysiert und von allen Team-Mitgliedern verabschiedet.


Dieser Artikel ist zuerst im PHP Magazin, Ausgabe 04/2013, Software & Support Verlag erschienen.


Kommentar schreiben

Kommentare: 0