Die fortschreitende Digitalisierung von Unternehmen erfordert kontinuierliche Weiterentwicklung durch Software Upgrades und die Einführung neuer Technologien, meist inkl. Customizing. Hierzu werden i.d.R. Implementierungspartner beauftragt, die den Prozess der Software Entwicklung bzw. Anpassung organisieren. Dies erfolgt heutzutage fast immer in agil. Bei der Zusammenarbeit zwischen Mittelstand und agilem Softwarepartner kommt es jedoch häufig zu Verzögerungen. Warum ist das so und wie lassen sich Probleme vermeiden? Wir haben unsere Erfahrungen aus der Projektleitung solcher Projekte in diesem Artikel für Sie zusammengefasst.

Beispielhaft durchdenken wir die einzelnen Phasen der Einführung einer neuer Software bei einem etablierten Industrieunternehmen, das auf die Unterstützung eines Implementierungspartners zurückgreift.

Vor Projektstart: Schulen Sie alle Beteiligten zur agilen Projektmethodik

Häufig setzen mittelständische Unternehmen die Wasserfall-Methode für ihre Projekte ein (Analyse > Konzept > Umsetzung > GoLive). Deshalb sind die Teams innerhalb des Unternehmens nicht oder nur unzureichend mit der agilen Projektmethodik des Implementierungspartners vertraut. Die Beteiligten auf Unternehmensseite wissen oft nicht, was ihre Rolle bzw. ihre konkreten Aufgaben im Projekt sind und können diese daher auch nicht erfüllen. Das Projektteam ist häufig mit der agilen Arbeitsweise überfordert.

Klingt einfach, wird aber oft vergessen: Deshalb müssen alle Projektmitarbeitenden vor Projektbeginn in den Grundlagen der agilen Projektmethodik geschult werden. Im Bestfall lehren die Schulungen direkt die agile Methode, auf die sich der externe Partner und die Projektleitung geeinigt haben. So hat das gesamte Projektteam ein einheitliches Verständnis der Rollen und Verantwortlichkeiten sowie ein Basiswissen über die Prozesse im agilen Projekt.

Discovery Phase: Dokumentieren Sie die Anforderungen klar

In der ersten Projektphase, der Discovery-Phase, muss sich der Implementierungspartner ein grundlegendes Verständnis der zu entwickelnden Prozesse aneignen. Als Kunde wiederum sollten Sie Zeit investieren, um die Software kennenzulernen, insbesondere die verfügbaren Standardprozesse und -funktionen. Vor allem im SaaS-Umfeld empfehlen wir, dem Anbieterstandard so nahe wie möglich zu folgen. Individuelle Anpassungen führen in der Regel zu signifikant erhöhten Aufwänden in der Umsetzung und gefährden gegebenenfalls die Release-Fähigkeit des Systems.

In je nach Projektgröße variierender Anzahl an Discovery Workshops werden die Anforderungen an die neue Software erarbeitet. Dokumentieren Sie die Anforderungen gemäß der agilen Projektmethode in Epics und User Stories. Epics sind umfangreiche Arbeitspakete, die in kleinere Aufgaben, die User Stories, unterteilt werden können. User Stories sind kurze Anforderungen, die aus der Perspektive eines Endbenutzers formuliert werden. Da die Projektmitglieder auf Unternehmensseite oftmals selbst Endnutzer der neuen Software sind (oder die Endnutzer gut kennen), ist es eine interne Aufgabe, die unterschiedlichen User Stories auszuarbeiten.

Im Projekt: Planen Sie ausreichend interne Kapazität ein

Nach der Discovery Phase sollte der Projektumfang definiert sein. Dies bildet die Grundlage für die Schätzung des Aufwands und die Erstellung eines Statement of Work (SOW), das als maßgebliches Vertragsdokument für die Implementierung dient. Hierfür sollten Sie ausreichend Zeit einplanen. Überprüfen Sie am Ende der Discovery-Phase den geplanten Umsetzungszeitraum und passen Sie gegebenenfalls Ihre ursprüngliche Schätzung an.

Challenge #1: Komplexe Themen wie zum Beispiel Stammdaten oder Schnittstellen sind oft zu anspruchsvoll, um sie innerhalb eines Sprint-Zyklus zu spezifizieren und umzusetzen. Sie laufen Gefahr, immer wieder verschoben zu werden.

Challenge #2: Wenn der Projektumfang nicht ausreichend definiert ist, werden vor allem kleinteilige Anforderungen umgesetzt, die nicht geplant waren, weil dies vermeintlich einfach ist. Darunter leidet die Qualität des Produkts.

Lösung #1: Das Projekt-Backlog muss regelmäßig mit den ursprünglichen Softwareanforderungen abgeglichen werden. Und über den kompletten Projektverlauf muss ein:e Projektleiter:in zum regelmäßigen Austausch für den Implementierungspartner zur Verfügung stehen. Diese interne Projektleitung muss sicherstellen, dass es um die wirklichen „big points“ bei der Softwareentwicklung geht und man sich nicht im Klein-Klein verliert und zwar methodisch und augenscheinlich Fortschritt erzielt, inhaltlich aber nicht wirklich vorankommt.

Lösung #2: Stellen Sie sicher, dass Schlüsselrollen im Projekt, wie z.B. Product Owner mit erfahrenden Personen besetzt sind und die Mitarbeitenden ausreichend Kapazität für das Projekt haben. Auch für die Durchführung von User-Tests am Ende des Projekts und der Dokumentation der Testergebnisse muss intern genügend Zeit eingeplant werden.

Sie möchten mehr erfahren?

Direkter Austausch

Buchen Sie sich ganz unkompliziert einen 30 Minuten-Termin.
Wir freuen uns darauf, Ihre Fragen im persönlichen Gespräch zu beantworten.

Jetzt Termin buchen

E-Mail schreiben

Zögern Sie nicht und kontaktieren Sie uns gerne jederzeit.
Wir sind offen für Ihre Fragen und Anregungen.

Jetzt Nachricht schreiben