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.

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.

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.

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:

 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.

 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.

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.

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

Das Projekt als solches sollte immer möglichst klein ausfallen. Das 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.

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.  

Ü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.

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. 

 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.

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.

• Nächster Artikel: Ankündigung: DC13 | "Einfach so" mit Tests starten
• Vorheriger Artikel: Ja, schon. Aber erst, wenn..