Der Wunsch nach erhöhter Transparenz im Kontext von IT-Dienstleistungen in Deutschland nimmt zu, insbesondere in Zeiten wirtschaftlicher Rezession. Größere Transparenz in Projekten stellt eine Herausforderung als auch eine Chance dar. Wir stellen drei Ansätze vor, um die Transparenz zu fördern, die Kommunikation zu verbessern und die Beteiligung der Kunden an der Planung des Projekterfolgs zu erhöhen.
Der Wunsch nach mehr Transparenz.
Zu viele Softwareprojekte scheitern, sind zu teuer und werden zu spät geliefert. Das ist nicht neu, sondern seit Jahren bekannt.
In den letzten Monaten sehen wir jedoch eine neue Entwicklung auf dem deutschen Markt für IT-Dienstleistungen, und insbesondere die Softwareentwicklung: Projektbudgets werden kleiner, Tagessätze geringer und der Druck auf den Projekterfolg höher. Kurzum: Die Rezession ist nun auch dort angekommen, wo das Geld in den letzten Jahren eher locker saß und wo überzogene Deadlines und Budgets zwar nicht freudig begrüßt, jedoch akzeptiert wurden.
Der Wunsch nach größerer Transparenz hat sich breit gemacht. Transparenz über den Projektfortschritt, über Probleme und Risiken. Projektverantwortliche können es sich nicht mehr erlauben, ein Projektbudget um das Vielfache zu überziehen. Zuverlässigkeit ist gefragt.
Herausforderung oder Chance? Es kommt auf den Blickwinkel an.
Auch wenn das zunächst nach einer Herausforderung für IT-Dienstleister klingt, kann man dieser Entwicklung auch etwas Positives abgewinnen: Ein Kunde, der Transparenz möchte, ist in der Regel auch ernsthaft am Projekterfolg interessiert und bereit, daran aktiv mitzuwirken. Und das wiederum ist das Beste, was einem Dienstleister passieren kann.
Führt der Wunsch nach Transparenz allerdings irgendwann dazu, dass der Kunde an allen trivialen oder leicht reversiblen Entscheidungen beteiligt wird, kann ein Projekt nicht mehr effizient durchgeführt werden.
Wie also den Spagat schaffen zwischen dem nachvollziehbaren Wunsch nach Transparenz und einer produktiven, ergebnisorientierten Zusammenarbeit?
Agile Methoden, wie SCRUM, haben uns Reviews, priorisierte Backlogs, transparente Projektboards und weitere wichtige Werkzeuge näher gebracht, die in den meisten agilen Software-Projekten im Einsatz sind. Nichtsdestotrotz stellt sich die Frage, reichen diese Werkzeuge und passen diese Werkzeuge in jeder Situation?
Das Bedürfnis nach Transparenz variiert je nach Situation.
Wir haben unsere Projekte der letzten Monate Revue passieren lassen und festgestellt, dass sowohl die geplante Projektdauer als auch die unterschiedlichen Projektphasen Auswirkungen auf das Transparenzbedürfnis unser Kunden haben.
In großen Transformations- und Digitalisierungsinitiativen, die über Monate und Jahre laufen, sind 2- bis 4-wöchentliche Reviews in der Regel das Mittel der Wahl, um dem Kunden und weiteren Stakeholdern neue Features zu zeigen und sie über den Projektfortschritt auf dem Laufenden zu halten. Ein zweimonatiges Projekt aber erfordert andere Vorgehensweisen. Hier sind direkte, informelle Kommunikationswege gefragt. Eine Entscheidung wie “Sollen wir noch mehr Zeit in die Analyse stecken oder reichen uns die aktuellen Erkenntnisse für eine Entscheidung?” muss unverzüglich getroffen werden, um eine effiziente Budgetnutzung zu gewährleisten.
Ähnliches haben wir in den Startphasen unserer Projekte beobachtet: Auch hier ist ein enger Austausch und schnelle Entscheidungsfähigkeit essentiell. Schließlich möchte niemand für ein Team zahlen, das handlungsunfähig ist, weil es auf eine Entscheidung des Managements wartet.
Startphasen haben darüber hinaus in der Softwareentwicklung häufig die zusätzliche Herausforderung, dass erstmal viel “Groundwork” passieren muss: Softwarearchitektur definieren, Technologien auswählen, Infrastruktur und Prozesse aufsetzen. All das lässt sich schwer als Demo in einer Review zeigen. Es braucht einen engeren, intensiveren Austausch.
Transparenz kann durch unterschiedliche Ansätze erzeugt werden.
Um diesen Ansprüchen nach mehr Transparenz und engerem Austausch nachzukommen, haben wir verschiedene Ansätze eruiert, die sich nach folgendem Schema unterteilen lassen:
Weg 1: Asynchrone Kommunikation
Bsp.: Das Developer’s Diary oder (auf deutsch und leider ohne Alliteration) das Entwickler-Tagebuch
Wir nutzen das Developer’s Diary insbesondere in unseren kürzeren Projekten und häufig als eine Mischung aus Tagebuch und Decision Log. Dort wird am Ende des Arbeitstages kurz zusammengefasst, woran das Team gearbeitet hat und welche Entscheidungen warum getroffen wurden. Bei Bedarf können auch Themen adressiert werden, die das Team gerade blockieren, wie beispielsweise ausstehende Entscheidungen. Diese Informationen werden optimalerweise in einem Kommunikationskanal geteilt, der unkompliziertes Feedback ermöglicht, wie z.B. Slack oder MS Teams. Empfänger:innen können, neben dem Kunden selbst, interne Entwickler:innen sein, die langfristig das Projekt übernehmen sollen.
Ein Developer’s Diary - und asynchrone Kommunikation generell - ist insbesondere dann ein guter Weg zur Transparenzschaffung, wenn eine Terminfindung mit dem Kunden kompliziert oder der Empfängerkreis sehr groß ist.
Wichtig für den Erfolg dieser Maßnahme ist es, wie so häufig, klare Regeln der Zusammenarbeit zu definieren, z.B. in welchem Zeitraum Fragen im Entwicklertagebuch beantwortet werden.
Weg 2: Synchrone - passive - Kommunikation
Bsp. Teilnahme des Kunden im Daily
Das Daily ist laut Definition explizit für den Austausch zwischen den Entwickler:innen vorgesehen, selbst Scrum-Master und Product Owner nehmen bei strikter Auslegung ausschließlich in der Rolle des Entwicklers teil.
So strikt leben wir es tatsächlich nicht. Bei uns sind Team Coach und Product Owner feste Teilnehmer:innen des Termins und bringen relevante Informationen ein. Die Teilnahme eines Kunden, der nicht an der Umsetzung beteiligt ist (wie beispielsweise der Product Owner), ist bisher zwar eher die Ausnahme, aber als Mittel zur Transparenzschaffung natürlich denkbar.
Dazu sollten jedoch einige entscheidende Punkte mit dem Kunden geklärt werden: Das Daily ist ein kurzer Termin mit dem Zweck, einen Austausch zwischen den Entwickler:innen zu führen, um zielgerichtet als Team arbeiten zu können. Der Kunde ist daher ein Zuhörer im Daily und hat in der Regel keinen aktiven Part, stellt also z.B. keine Fragen an das Team. Der Kunde möchte lieber einen aktiven Part spielen? Dann eignen sich andere Mittel, wie z.B. das Alignment Meeting, besser.
Wir empfehlen zudem, eine Testphase mit dem Kunden zu vereinbaren, um diese Methode zu testen. Nach spätestens einer Woche sollte es ein beiderseitiges Feedback zu der Testphase geben: Hat die Teilnahme geholfen, um Transparenz für den Kunden zu erzeugen, oder haben z.B. technische Diskussionen eher zu Verwirrung geführt? Hat die Teilnahme des Kunden das Team abgelenkt oder konnte das Daily wie üblich durchgeführt werden? Je nach Ergebnis kann dann entschieden werden, ob die Teilnahme des Kunden weiterhin erfolgen soll.
Weg 3: Synchrone - aktive - Kommunikation
Bsp. Regelmäßiges Alignment Meeting zwischen Kunde und Team
Gerade bei hohem Zeitdruck, wie er in Anfangsphasen von Projekten oder in kurzen Projekten häufig zu beobachten ist, kommt das Thema Alignment zwischen Kunde und Team häufig zu kurz. Wir haben jedoch immer wieder festgestellt, dass sich der Zeiteinsatz für ein mindestens wöchentliches Meeting lohnt, um den richtigen Kurs zu halten.
Im Alignment Meeting konzentrieren wir uns daher immer wieder auf die folgenden wichtigen Fragen:
- Welches Ergebnis erwartet der Kunde vom Projekt?
- Sind wir auf dem richtigen Weg?
- Ist das, woran wir gerade arbeiten, wirklich das Wichtigste?
- Gibt es Hürden im Projekt, die der Kunde ausräumen muss?
Das Alignment Meeting ist (ähnlich wie die Sprint Review) darauf ausgelegt, schnell Feedback vom Kunden zu bekommen - allerdings ohne feste Sprint-Zyklen und bei Bedarf auch in kürzeren Abständen.
Transparenz vom ersten Tag an auf dem Radar haben.
Die drei beschriebenen Maßnahmen sind natürlich lediglich Beispiele dafür, wie in Projekten Transparenz für den Kunden erzeugt werden kann. Was wann und wie wirklich passt, ist je nach individueller Situation zu eruieren und mit dem Kunden zu definieren. Und genau dazu wollen wir hier den Impuls geben: Transparenz ist wichtig und schafft Vertrauen, daher empfehlen wir zu Beginn (und auch immer mal wieder im Laufe) eines Projektes mit dem Kunden über seine Transparenzbedürfnisse zu sprechen und einen guten Weg zu finden, diese zu bedienen.
Und auch wenn es eine Wiederholung ist: Ein Kunde, der Transparenz möchte, ist in der Regel auch ernsthaft am Projekterfolg interessiert und bereit, daran aktiv mitzuwirken. Machen wir was daraus!
Quellen:
https://dieprojektmanager.com/scheitern-von-it-projekten/
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf