Auf dieser Webseite verwenden wir Cookies und ähnliche Technologien („Cookies“). Um deren Verwendung zur Analyse der Webseitenutzung und zur Steigerung der Funktionalität zu erlauben, klicken Sie bitte auf „Akzeptieren“. Um auszuwählen welche Cookies wir im Einzelnen verwenden dürfen, um Ihre Einstellungen zu ändern oder um detaillierte Informationen zu erhalten, klicken Sie auf „Details“.

Details

Ablehnen

Akzeptieren

Nachfolgend können Sie einzelne Technologien, die auf dieser Webseite verwendet werden, aktivieren/deaktivieren.
Zu allen einwilligen
Erforderlich

Diese Cookies machen eine Webseite nutzbar, indem sie Grundfunktionen wie Seitennavigation, Spracheinstellungen und Zugang zu geschützten Bereichen der Webseite bereitstellen. Da die Webseite ohne sie nicht ordnungsgemäß funktionieren kann, können Sie sich nicht von dieser Art von Cookies abmelden.

Funktionalität

Diese Cookies helfen uns, die Funktionalität und Attraktivität unserer Webseites und damit Ihr Nutzungserlebnis zu verbessern, indem Ihre z.B. Einstellungen, Auswahl und Filterung gespeichert werden und Ihr Gerät bei einem späteren Besuch wiedererkannt wird.

Analyse

Diese Cookies erlauben uns und den Dienstanbietern (z.B. Google über den Dienst Google Analytics), Informationen und Statistiken über Ihre Interaktion mit unserer Webseite zu erhalten und auszuwerten, um mit den gewonnenen Erkenntnissen unsere Webseite zu optimieren.

Mehr Infos
(Datenschutzerklärung)

Einstellungen speichern

Management von Entwicklungsprojekten: Der Brückenschlag zwischen zwei Welten

Entwicklungsprojektmanager (DPMs) sehen sich täglich mit einer Vielzahl von Herausforderungen konfrontiert, von der Planung von Releases und Zeitplänen in enger Zusammenarbeit mit dem Kunden und der regelmäßigen Berichterstattung an den Lenkungsausschuss bis hin zu täglichen Gesprächen mit dem Entwicklungsteam und technischen Diskussionen mit dem Lösungsarchitekten - und nicht zu vergessen die umfassende Koordination mit dem allgemeinen Projektmanager

Agiles Arbeiten nach einem Zeitplan

Heutzutage hat sich Scrum gut etabliert, und die meisten Menschen sind zumindest mit agilen Teams und Arbeitsmethoden vertraut. Dies gilt insbesondere für die Softwareentwicklung. Junge Entwickler halten sich selten an Konzepte wie Zeitpläne, Fristen und Wasserfallmodelle. Die Entwicklung ist selten ein linearer Prozess: Unerwartete Stolpersteine und ständige Umplanungen sind an der Tagesordnung. In dieser Welt wurden die agilen Arbeitsmethoden geboren, und in diesem Bereich werden sie heute am häufigsten eingesetzt.

Richtig spannend wird es, wenn die Welt des agilen Arbeitens auf die Anforderungen etablierter Automobilhersteller trifft, die nach wie vor Wert auf Eigenschaften wie sorgfältige Planung und Termintreue legen. IT-Projektleiter, die für Automobilhersteller arbeiten, wissen, dass das Management einen gut durchdachten Zeitplan benötigt. Die meisten Entscheider lassen sich nicht gerne in die Karten schauen, deshalb muss dieser Zeitplan von der Aufnahme der Anforderungen über die Überwachung der Produktion bis zur Auslieferung der Software alles abdecken. Es ist daher nicht verwunderlich, dass die Hersteller von dem Unternehmen, das mit der Entwicklung ihrer Software beauftragt wird, ebenfalls diese Qualitäten erwarten.

Manager von Entwicklungsprojekten: Überwindung der Kluft

Sowohl agiles Arbeiten als auch traditionelles Projektmanagement haben ihre Stärken. Langfristige Softwareentwicklungsprojekte können ohne das eine oder das andere nicht funktionieren. Deshalb ist es wichtig, Kollegen zu haben, die in beiden Welten zu Hause sind und die Kluft zwischen den beiden Welten überbrücken. Dies ist eine der Schlüsselkompetenzen eines DPMs. Er schafft den Spagat zwischen dem Wunsch des Kunden nach Struktur und sorgfältiger Planung und den Realitäten des Entwicklungsprozesses und seiner oft unvorhersehbaren Natur.

Schauplatz: Projekt zur Entwicklung der Logistikkontrolle

In dieser Fallstudie geht es um ein Projekt, bei dem einer unserer Kunden beauftragt wurde, ein bestehendes Logistikleitsystem durch ein moderneres zu ersetzen. Da die vorhandene Software so viele verschiedene endkundenspezifische Lösungen enthielt, erfüllte die nicht angepasste Standardsoftware nur einen Teil der notwendigen Anforderungen. Die Anpassung der bestehenden Software an die spezifischen Bedürfnisse des Endkunden gestaltete sich sehr komplex und zeitaufwändig. Erschwerend kam hinzu, dass sich der Projektstart verzögerte und einige der Entwickler gleichzeitig an anderen Projekten arbeiteten. Da unser Kunde zu diesem Zeitpunkt nicht über genügend Kapazitäten verfügte, um sein größtes Entwicklungsprojekt seit mehreren Jahren selbst zu managen, beauftragte er Dürr Consulting mit der Übernahme des Entwicklungsprojektmanagements.

Vorteile für Sie

  • Wir schlagen die Brücke zwischen agilem Arbeiten und traditionellem Projektmanagement - und können in beiden Systemen gleich gut arbeiten
  • Bewährte Projektmanagement-Office-Leistungen: Wir haben Zeit, Qualität und Kosten immer im Blick
  • Langjährige Projekterfahrung im Automobilbau und in der allgemeinen Fertigung

Organisation und Kommunikation über die Programmierung

Wir haben bereits erforscht, wie ein DPM als Vermittler zwischen agilem und traditionellem Projektmanagement agieren muss. Schauen wir uns nun an, was ein DPM eigentlich tut. Seine Hauptaufgaben liegen in der Organisation und Kommunikation; obwohl das Ziel darin besteht, funktionierende Software als Endprodukt zu erstellen, ist der DPM im Allgemeinen nicht an der Programmierung beteiligt. Stattdessen konzentriert er sich darauf, viele Informationen zu sammeln und zu organisieren, sie auf die Zielgruppe zuzuschneiden und sie mit den entsprechenden Interessengruppen zu teilen und zu diskutieren. In einer typischen Woche würde der DPM in diesem Entwicklungsprojekt die folgenden Sitzungen mit den verschiedenen Beteiligten organisieren und leiten (wie in der Abbildung unten dargestellt):

ägliche Besprechungen (so genannte Dailies) mit den wichtigsten Mitarbeitern der Entwicklungsabteilung: Ziel der fünfzehnminütigen Dailys war es, die Fortschritte und Hindernisse aller Beteiligten zu besprechen und alle Hindernisse, die nicht innerhalb des Entwicklungsteams gelöst werden konnten, aufzugreifen.

Wöchentliche interne Management-Sitzungen: Ziel dieser Treffen war es, neben dem aktuellen Stand der Entwicklungsarbeiten auch Maßnahmen zur Überwindung von Hindernissen zu vereinbaren, die nicht innerhalb des Entwicklungsteams selbst gelöst werden konnten.

Jours fixes mit dem Kunden: Die regelmäßige Kommunikation mit dem Endkunden ist eine wesentliche Grundlage für jedes erfolgreiche Entwicklungsprojekt. Deshalb organisierten die Projektbeteiligten einen Jour fixe. An diesem Treffen nahmen der DPM, der Gesamtprojektleiter und der Projektleiter auf der Seite des Endkunden teil. Sie besprachen alles, was für die termingerechte Umsetzung des Projekts relevant war. Dazu gehörten Release- und Zeitpläne ebenso wie aktuelle technische Herausforderungen.

Außerdem fand alle zwei Wochen ein Projekt-SteerCo-Meeting statt, an dem die Projektleiter und Vertreter der höheren Führungsebene beider Unternehmen teilnahmen. Der Hauptzweck dieses Treffens bestand darin, über den aktuellen Projektstatus zu informieren, aber es diente auch als Eskalations- und Entscheidungsgremium.

Obwohl sie weniger strukturiert ist, ist die Beziehung zwischen dem DPM und dem Leiter des Entwicklungsteams ebenfalls von entscheidender Bedeutung: Sie müssen eng und offen zusammenarbeiten. Der Entwicklungsleiter kennt sein Team in- und auswendig und kann bei Bedarf kurzfristig die notwendigen Ressourcen bereitstellen.

Zeitpläne für komplexe Softwareprojekte

Wie Cicero einst sagte: "Bevor du anfängst, plane sorgfältig". Dwight D. Eisenhower war der gleichen Meinung: "Pläne sind wertlos, aber Planung ist alles." Nirgendwo ist der Gegensatz zwischen traditionellem Projektmanagement und agilem Arbeiten deutlicher als bei der Projektplanung. Ersteres setzt auf langfristige Zeitpläne mit klaren Etappen, letzteres bevorzugt eine kurzfristige Planung, die auf Daten in Echtzeit reagiert. Was den Zeitaufwand für die Fertigstellung eines Epos (der agile Begriff für eine größere Arbeitseinheit mit einem Ziel) angeht, so können die Schätzungen der Softwareentwickler um den Faktor drei variieren. Bei Entwicklungsaufgaben geht es definitionsgemäß darum, etwas Neues zu schaffen, und das bedeutet oft, dass man nicht auf frühere Erfahrungen zurückgreifen kann. Schätzungen über den Zeitplan sind daher immer nur Schätzungen. Dieses hohe Maß an Unsicherheit ist sowohl auf technische Risiken als auch auf organisatorische Risiken wie die Abwesenheit wichtiger Mitarbeiter zurückzuführen. Ein weiteres häufiges Risiko besteht darin, dass die Softwareentwickler oft ein anderes Verständnis vom Ziel haben als der Kunde. Jeder, der mit Softwareentwicklung zu tun hat, kennt wahrscheinlich den amüsanten Vergleich dieses Szenarios mit einer Schaukel, die sich zwischen gegensätzlichen Positionen hin- und herbewegt, von der Beschreibung des Kunden über das Verständnis des Projektleiters für seine Beschreibung bis hin zur Arbeit des Programmierers und schließlich zu dem, was der Kunde tatsächlich benötigt. Das Ergebnis ist oft ein Softwareprodukt, in dessen Erstellung viel Zeit und Energie geflossen ist, das aber nicht den Mehrwert bringt, den der Endkunde braucht. Eine bewährte Methode, mit diesen allgemeinen Unwägbarkeiten umzugehen, besteht darin, für unerwartete Verzögerungen im Zeitplan Rückstellungen zu bilden. In diesem speziellen Fall stand der Zeitplan jedoch bereits fest, bevor Dürr Consulting die Rolle des DPM übernommen hatte.

Dynamische, datengestützte Planung

Der DPM und der Leiter des Softwareentwicklungsteams des Kunden einigten sich auf einen dynamischen, datengestützten Planungsansatz. Wie sah das in der Realität aus? Unser Kunde nutzte die Software "Jira" für seine internen Abläufe. Damit kann man die Dauer der Entwicklungsarbeit auf Story- und/oder Epic-Ebene abschätzen und dann jede Story einem geplanten Release zuordnen. Außerdem können Sie damit die Kapazität des Entwicklungsteams aktualisieren.

Jira verwendet diese Informationen, um einen dynamischen Plan in einem Gantt-Diagramm zu erstellen, der einen klaren Überblick darüber gibt, welche Phasen bis zu welchem Release abgeschlossen sein werden, basierend auf der letzten Schätzung der Dauer. Die tatsächliche Dauer jeder Story wird auto- matisch anhand der protokollierten Zeit des Entwicklers erfasst. Benötigen einzelne Phasen mehr Zeit als ursprünglich geplant, passt sich der Zeitplan automatisch an und der kritische Pfad wird neu definiert. So lässt sich schon im Vorfeld erkennen, ob der dem Kunden kommunizierte Veröffentlichungstermin aufgrund einer besonders langen Verzögerung möglicherweise nicht eingehalten werden kann. So hat der DPM mehr Zeit, auf die Verzögerung zu reagieren.

dup.

Erfolgreiche Terminplanung beginnt mit dem Anforderungsingenieur

Systematisches Anforderungsmanagement ist der Schlüssel, um sicherzustellen, dass die erstellten Softwarefunktionalitäten mit den tatsächlichen Anforderungen des Endkunden übereinstimmen. Im Rahmen eines umfassenden Lessons-Learned-Meetings mit allen Beteiligten bei der Beauftragung von Dürr Consulting wurde deutlich, dass die Product Owner (POs) in der Vergangenheit viele Rollen übernommen hatten. Als Reaktion auf das Meeting wurde die neue Rolle des Requirements Engineers geschaffen, um die POs stärker für ihre Kernaufgaben zu entlasten und ein professionelles Anforderungsmanagement einzuführen. Der Requirements Engineer entwickelte daraufhin eine Methode, um die nahtlose Integration der Anforderungen in die Jira-Entwicklungsumgebung zu gewährleisten. Da seine Rolle speziell dem Anforderungsmanagement gewidmet war, konnte er enger und intensiver mit den Projektleitern des Endkunden zusammenarbeiten. Dies bedeutete, dass der größte Teil der Entwicklungsarbeit direkt auf die Bedürfnisse des Kunden zugeschnitten war. Da weniger Fehler behoben werden mussten, um Missverständnisse über das endgültige Ziel zu beseitigen, stiegen sowohl die Pünktlichkeit als auch die Produktivität.

Auch Softwareentwicklung braucht klare Strukturen

zu einer Überschneidung der Zuständigkeiten geführt. Überschneidungen führen oft zu Kommunikationsproblemen und Schwierigkeiten bei der Definition von Zuständigkeiten. Deshalb hat Dürr Consulting gemeinsam mit dem Entwicklungsteam einen speziellen Prozess entwickelt, der in Abbildung 2 dargestellt ist. Das Bild beschreibt die verschiedenen Stufen des Softwareentwicklungsprozesses (Zeile 1), die relevanten Anforderungen (2), wer intern für die Erreichung dieser Anforderungen verantwortlich ist (3) und welche Interaktion mit dem Kunden erforderlich ist, um das Stufenziel zu erreichen (4). Abgeschlossen wird die Prozessübersicht mit einem Flussdiagramm, in dem die relevanten Dokumente aufgelistet sind (5) und einer Definition of Ready (DoR, 6).

Auf diese Weise konnten wir für mehr Transparenz sorgen und Überschneidungsprobleme frühzeitig erkennen. In diesem Prozess war der DPM für das Crossover-Management verantwortlich. Das bedeutet, dass die Anforderungen an die in der vorgelagerten Stufe durchgeführten Vorarbeiten vor jeder nachfolgenden Stufe klar kommuniziert werden. Nach Einführung des Prozesses wurden die Tageszeitungen entsprechend der Übersicht strukturiert und auf ein bestimmtes Crossover-Thema ausgerichtet.

Ständige Verbesserung braucht Zeit, zahlt sich aber aus

Die Rahmenbedingungen für das Projekt waren sehr anspruchsvoll. Im Vergleich zu anderen Projekten waren der Umfang, die Komplexität und der Zeitdruck viel größer. Die Organisation unseres Kunden war in der Lage, sich angesichts dieser neuen Herausforderungen weiterzuentwickeln. Ausgangspunkt für die Entwicklung war das Lessons-Learned-Meeting bei der Erstbeauftragung von Dürr Consulting. Die Ergebnisse einer offenen Schwachstellenanalyse führten zur Einführung der neuen Rolle des Requirements Engineers, eines klar definierten Softwareentwicklungsprozesses mit klaren Übergängen und eines datenbasierten Zeitplans, der moderne Werkzeuge nutzt. Die Einführung eines neuen Prozesses brauchte zwar Zeit, führte aber schnell zu sichtbaren Verbesserungen. Die klare Verteilung der internen Rollen ermöglichte es dem Team, den Prozess effizient zu durchlaufen. Die Vorteile der erhöhten Geschwindigkeit und der höheren (statt beeinträchtigten) Qualität waren auch dem Kunden klar, der in seinem Feedback sagte, dass "die letzte Version enorme Fortschritte in Bezug auf die Funktionalität gemacht hat" und "es offensichtlich ist, dass das Entwicklungsteam versteht, was wir erreichen wollen." Für uns war dies der Beweis, dass sich unsere Bemühungen um ständige Verbesserungen ausgezahlt haben.

Zusammenfassung

DPMs sind für große Entwicklungsprojekte von entscheidender Bedeutung, da sie die vielen internen und externen Überschneidungen überwachen, aber sie können nicht jedes Problem lösen. Intensive Diskussionen zwischen allen Beteiligten sind keine Garantie dafür, dass die Software wie geplant freigegeben wird, aber sie sind wichtig, um bei Problemen und Verzögerungen möglichst schnell einen konstruktiven Weg zu finden. Ob dies gelingt, hängt letztlich davon ab, wie gut das externe Projektmanagement in die internen Prozesse des Kunden integriert ist. Im Idealfall sollte die Tatsache, dass der Projektleiter nur für eine begrenzte Zeit beteiligt ist, im Projektalltag nicht auffallen.