Entwicklungsprojektmanagement | Brückenbau zwischen zwei Welten

Die täglichen Herausforderungen an einen Entwicklungsprojektleiter (EPL) sind vielfältig: Entwicklung der Release- und Terminplanung in enger Abstimmung mit dem Kunden, Dailies mit dem Entwicklerteam, regelmäßiges Reporting für das Steering Committee, technische Diskussionen mit dem Solution Architekt und natürlich die übergreifende Abstimmung mit dem Gesamtprojektleiter.

Heutzutage hat sich Scrum gut etabliert oder ist in agilen Teams und Arbeitsweisen organisiert. Nirgends trifft das mehr zu als in der Softwareentwicklung. Für junge Entwickler sind Begriffe wie „Terminplan“, „Deadline“ und „Wasserfallmethode“ selten positiv besetzt. Entwicklung ist eher im Ausnahmefall ein geradliniger Prozess, unerwartete Stolpersteine und ständiges Neuplanen sind an der Tagesordnung. In dieser Welt wurden agile Arbeitsformen entwickelt und dort werden sie heute auch überwiegend eingesetzt.

Spannend wird es, wenn die Welt des agilen Arbeitens mit den Anforderungen der etablierten Automotive OEMs zusammen kommt. Hier sind Tugenden wie Planbarkeit und Termintreue weiterhin sehr geschätzt. IT-Projektmanager der Automobilisten wissen genau, dass seitens des Managements ein akkurater Plan gefordert wird. Und da die wenigsten Entscheider auf Sicht fahren wollen, sollte dieser Plan den kompletten Zeitraum von der Aufnahme der Anforderungen bis zur Pro­duktionsbetreuung nach der Übergabe der Software abdecken. Wenig verwunderlich also, dass diese Anforderungen auch an das mit der Entwicklung beauftragte Unternehmen weitergegeben werden.

Agiles Arbeiten als auch das klassische Projektmanagement haben jeweils Ihre Daseinsberechtigung. Im Umfeld von langfristigen Softwareentwicklungsprojekten kann es das eine ohne das andere nicht geben. Umso wichtiger ist es daher, dass an den Schnittstellen Kollegen sitzen, die sich in beiden Welten auskennen und wohlfühlen. Und damit ist auch schon eine der Hauptanforderungen an einen EPL beschrieben. Ein EPL verbindet den Wunsch nach Struktur und Planbarkeit der Auftraggeber mit der Realität des Entwicklungsprozesses, der oftmals von Unwägbarkeiten geprägt ist.

In dem dieser CaseStudy zugrundeliegenden Projekt wurde unser Kunde beauftragt ein existierendes System zur Logistiksteuerung durch ein modernes System zu ersetzen. Aufgrund der Vielzahl von endkundenspezifischen Lösungen in der bestehenden Software konnte die Standardsoftware nur einen Teil der Anforderungen ohne Anpassungen erfüllen. Daraus ergab sich eine hohe Komplexität und ein hoher Aufwand für die Anpassung der bestehenden Software an die spezifischen Bedürfnisse des Endkunden. Eine weitere Herausforderung, war das Resultat aus Verzögerungen zum Projektbeginn sowie der Tatsache, dass einige Entwicklungsmitarbeiter parallel an verschiedenen Projekten arbeiteten. Da die bestehenden Kapazitäten bei unserem Auftraggeber zu diesem Zeitpunkt nicht ausreichten, um das „größte Entwicklungsprojekt in den letzten Jahren“ selbst zu managen, wurde die Dürr Consulting mit der Übernahme der Entwicklungsprojektleitung beauftragt.

• Wir sind Brückenbauer und fühlen uns sowohl im agilen Umfeld als auch dem klassischen Projektmanagement wohl
• Etablierte PMO Services – Wir halten Zeit, Qualität und Kosten stets im Blick
• Langjährige Projekterfahrung in der Automotive und der allgemeinen produzierenden Industrie

Die Rolle des EPL als Vermittler zwischen der agilen Welt und dem klassischen Projektmanagement wurde bereits genannt – aber was macht ein EPL konkret? Die wesentlichen Aufgaben sind bereits in der Überschrift dieses Abschnitts prägnant zusammengefasst. Denn auch wenn das Endprodukt funktionierende Software ist, ist der EPL im Allgemeinen nicht an der Softwareentwicklung im Sinne von Programmieren beteiligt. Vielmehr gilt es eine Vielzahl an Informationen zu sammeln, zu strukturieren, zielgruppengerecht aufzubereiten und mit dem jeweiligen Stakeholder zu teilen und zu diskutieren (siehe beispielhaft Abbildung 1). In einer „klassischen“ Woche in diesem Entwicklungsprojekt organisierte und führte der EPL folgende Termine mit den jeweiligen Stakeholdern:

Tägliches Meeting (Daily) mit den zentralen Mitarbeitern aus der Entwicklungsabteilung. Ziel des Dailies ist es, innerhalb von 15 Minuten die Fortschritte und Barrieren der einzelnen Beteiligten auszutauschen und Barrieren, die nicht innerhalb des Entwicklerteams gelöst werden können, aufzunehmen.

Wöchentliches internes Managementmeeting: Neben der Vorstellung des aktuellen Projektstatus aus Entwicklungssicht ist das Ziel des Meetings, unterstützende Maßnahmen zu definieren, um Barrieren zu überwinden, die nicht durch das Entwicklerteam selbst gelöst werden können.

Kunden Jour fixe: Eine regelmäßige Kommunikation mit dem Endkunden ist essenzielle Grundlage eines erfolgreichen Entwicklungsprojektes. Um diese zu gewährleisten, haben die Projektbeteiligten einen regelmäßigen Jour fixe vereinbart. An diesem Meeting nehmen neben dem EPL der Gesamtprojektleiter sowie der oder die Projektleiter des Endkunden teil. Inhaltlich ist in diesem Meeting alles relevant, was für die termingerechte Umsetzung des Projektes notwendig ist. Dazu gehören unter anderem die Besprechung von Release – und Terminplänen sowie aktuellen technischen Herausforderungen

Weiterhin findet alle zwei Wochen eine Project SteerCo Meeting statt. Daran nehmen sowohl die Projektleiter als auch Vertreter übergeordneter Managementebenen beider Unternehmen teil. Primär dient der Termin dem Bericht des aktuellen Projektstatus, darüber hinaus dient der Personenkreis als Eskalations- und Entscheidungsgremium.

Wenig formalisiert aber dennoch enorm wichtig ist eine enge Abstimmung und vertrauensvolle Zusammenarbeit zwischen dem EPL und dem Leiter des Entwicklungsteams. Dieser kennt seine Mannschaft am besten und kann notfalls auch kurzfristig die notwendigen Ressourcen bereitstellen.

Wie schon Cicero wusste: „Bevor Sie anfangen, planen Sie sorgfältig“. Dwight D. Eisenhower ergänzt: „Pläne sind nichts. Planung ist alles“. Nirgends wird der Gegensatz zwischen traditionellem Projektmanagement und agiler Arbeitsweise deutlicher als bei der zeitlichen Projektplanung. Ersteres fordert langfristige Zeitpläne mit Milestones während zweiteres eine Planung auf Basis der aktuell verfügbaren Daten und für einen kurzen Zeitraum bevorzugt. Auf die Frage, wie viel Aufwand die Fertigstellung eines Epics (eine größere Anforderungseinheit) benötigt, können die Schätzungen seitens der Softwareentwickler gerne um den Faktor 3 variieren. Da eine Entwicklungsaufgabe per Definition etwas Neues ist und man sich selten auf konkrete Erfahrungswerte verlassen kann, ist eine ex ante Bestimmung der Aufwände jeweils mit hohen Unsicherheiten verbunden. Unsicherheiten könnten neben technischen Risiken auch organisatorische Risiken wie beispielsweise die Abwesenheit wichtiger Personen beinhalten. Für Softwareentwicklung sehr typisch ist darüber hinaus das Risiko, dass der Softwareentwickler ein anderes Zielbild als der Auftraggeber hat. Jeder, der sich mit Softwareentwicklung beschäftigt, kennt wahrscheinlich die humoristische Darstellung einer Baumschaukel mit den verschiedenen Perspektiven: „Wie der Kunde es beschrieben hat“, „wie es der Projektleiter verstanden hat“, „wie es der Programmierer umgesetzt hat“ und letztlich, „was der Kunde wirklich gebraucht hätte“. Daraus resultiert nicht selten ein Softwareartefakt, in das viel Aufwand geflossen ist, welches jedoch für den Endkunden nicht den geforderten Mehrwert leisten kann. Eine etablierte Maßnahme, um mit allgemeinen Unsicherheiten umzugehen, ist es, präventive Zeitpuffer in die Planung aufzunehmen. Unerwartete Verschiebungen lassen sich so kompensieren. Im konkreten Fall war die Zeitschiene zu Beginn der Übernahme der EPL Rolle jedoch fix vorgegeben.

Risikopuffer in größerem Maße zu verwenden, war also keine Option. Als Konsequenz daraus verständigten sich der EPL und der Teamleiter des Softwareentwicklungsteams des Kunden auf einen dynamischen und datenbasierten Planungsansatz. Was heißt das konkret? Unser Kunde nutzt intern die Software „Jira“. Diese erlaubt das Schätzen der Entwicklungsaufwände auf Story und/oder Epic Ebene. Jede Story wiederum wurde anschließend einem geplanten Release zugewiesen. Zusätzlich wurde die Kapazität der Entwicklungsteams in Jira eingepflegt.

Auf dieser Basis erstellt Jira einen dynamischen Plan im Gantt-Chartformat. Dadurch wird jederzeit transparent, welche Entwicklungsfortschritte auf Basis der aktuellen Aufwandsschätzung bis zu welchem Release fertig werden. Der tatsächliche Aufwand wird automatisch über die geloggte Zeit der Entwickler pro Story erfasst. Benötigen einzelne Entwicklungsschritte mehr Zeit als geplant, passt sich der Terminplan automatisch an und der kritische Pfad wird neu bestimmt. Wird die Abweichung so groß, dass die kommunizierte Releaseplanung in Gefahr ist, wird dies frühzeitig ersichtlich. Dies verschafft dem EPL mehr Zeit, um auf die Abweichung zu reagieren.

Um die Konsistenz von Endkundenwunsch und realisierter Softwarefunktionalität sicherzustellen, ist ein systematisches Anforderungsmanagement notwendig. Ein umfassendes Lesson Learned zu Beginn der Beauftragung der Dürr Consulting mit allen Stakeholdern zeigte auf, dass die Product Owner (PO) historisch gewachsen viele Rollen übernommen haben. Um zum einen den POs mehr Kapazität für Ihre Kerntätigkeit zu gewähren, und zum anderen ein professionelles Anforderungsmanagement zu etablieren, hat man im Anschluss an die Lesson Learned die Rolle des Requirements Engineers geschaffen. Dieser entwickelte eine Methodik, um eine nahtlose Integration der Anforderungen in die Jira Entwicklungsumgebung sicherzustellen. Durch seine dezidierte Rolle als Requirements Engineer konnte der Kollege enger und intensiver mit den Projektleitern des Endkunden diskutieren. Entwicklungen am Kundenbedarf vorbei, waren infolgedessen stark rückläufig. Da weniger Bugfixing aufgrund von inkongruentem Verständnis des Zielbildes nötig war, verbesserte sich die Planungsgenauigkeit und die Geschwindigkeit des funktionalen Fortschritts.

Die Einführung einer neuen Rolle schafft Entlastung für die POs, gleichzeitig entstehen neue Schnittstellen. Jede zusätzliche Schnittstelle birgt Potenzial für Probleme bei der Informationsweitergabe sowie der Abgrenzung der Verantwortlichkeiten. Aus diesem Grund wurde gemeinsam mit dem Entwicklerteam ein Prozess definiert (siehe beispielhaft Abbildung 2). Diese beschreibt die Phasen des Softwareentwicklungsprozesses (Punkt 1), die jeweiligen Anforderungen (2), welche Rollen intern für die Zielerreichung der Anforderung verantwortlich sind (3), sowie an welcher Stelle eine Kundeninteraktion nötig ist, um das Phasenziel zu erreichen (4). Vervollständigt wird die Prozesssicht durch die Nennung und Flussrichtung der jeweils relevanten Dokumente (5) sowie eine Definition of Ready (DoR, 6).

Auf diese Weise haben wir eine höhere Transparenz geschaffen, Schnittstellenprobleme sind dadurch frühzeitiger erkennbar. Der EPL hatte in diesem Prozess die Rolle des Schnittstellenmanagers. Konkret ist er dafür zuständig sicherzustellen, dass die Bedarfe jeder Phase an die Vorarbeit aus der vorgelagerten Phase transparent und rechtzeitig kommuniziert werden. Nach Einführung des Prozesses wurden die Dailies anhand der Übersicht strukturiert und jeweils die Schnittstellen thematisiert.

Die Rahmenbedingungen für das Projekt waren sehr herausfordernd. Umfang, Komplexität und Zeitdruck waren im Vergleich zu anderen Projekten deutlich erhöht. Ausgehend von dieser Situation hat es die Organisation unseres Kunden geschafft, sich angesichts der neuen Herausforderungen weiterzuentwickeln. Ausgangspunkt der Entwicklung war die Lesson Learned zu Beginn der Beauftragung. Die Ergebnisse einer offenen Analyse der Schwachpunkte resultierten in der Einführung der neuen Rolle des Requirements Engineers, eines definierten Prozesses zur Softwareentwicklung mit klaren Schnittstellen sowie datenbasierter Planung unter Nutzung moderner Tools. Auch wenn es eine gewisse Zeit benötigt, einen neuen Prozess zu leben wurden schnell Verbesserungen sichtbar. Intern schafft die klare Rollenverteilung die Basis für eine effizientere Bearbeitung des Prozesses. Die höhere Geschwindigkeit und gleichzeitig bessere Qualität der Releases blieben auch dem Kunden nicht verborgen. Das Feedback: „Das letzte Release hat enorme funktionale Fortschritte gemacht“ sowie „wir sehen deutlich, dass das Entwicklerteam unsere Perspektive versteht“ sind für uns Beweis genug, dass sich unser Streben nach ständiger Verbesserung ausgezahlt hat.

Ein EPL ist für größere Entwicklungsprojekte unverzichtbar, gerade um die vielen internen und externen Schnittstellen im Blick zu halten. Er oder sie ist aber auch kein Heilsbringer. Eine intensive Kommunikation zwischen allen Beteiligten kann nicht garantieren, dass Software wie geplant released wird. Sie ist aber essenziell, um im Falle von Problemen und Abweichungen schnellstmöglich einen konstruktiven Weg zu finden, um mit der Abweichung umzugehen. Ob diese gelingt oder nicht, hängt letztlich auch immer davon ab, wie gut eine externe Projektleitung in die internen Prozesse des Kunden eingebunden ist. Im besten Fall ist die Tatsache, dass der Projektleiter nur temporär an Bord ist, im Projektalltag nicht zu spüren.