Agile Transformation – eine Begriffsneudefinition von Projekten?

Projekt-Kickoff, Entwicklung, fertig.

“Wir brauchen ein Projekt.” Einen Satz, den man im eigenen Unternehmen oft zu hören bekommt. Aber was ist eigentlich ein Projekt und welche Bedeutung nimmt dieses in einer agilen Organisation an?

Laute der Betriebsökonomie ist ein Projekt eine zeitlich befristete, relativ innovative und risikobehaftete Aufgabe von erheblicher Komplexität. Im Zusammenhang werden oft Projektorganisationen mit einem Projektmanagement über die Dauer des Projektes gegründet. (Vgl. DIN 69900 bzw. 69901)

Aus meiner Erfahrung heraus wird fast alles zu einem Projekt, was konzeptionell mehr als zwei DIN A4-Seiten füllt. Und Regulatorik? Naja, da ist sowieso alles in Stein gemeißelt und es gibt ein festes “due-date” – perfekt geeignet für ein Projekt.

Unter der Annahme, dass das Projekt erfolgreich – aus Sinne der Projektorganisation – beendet wird, erfolgt im Anschluss die Übergabe (Die Zweideutigkeit dieses Wortes lässt mich im Projektabschluss immer wieder schmunzeln). Die entstandenen Lösungen, Prozesse und Softwarekomponenten werden in die “Linie” übergeben, was meiner Erfahrung nach noch nie gut funktionierte. Halbfertige und teilweise fehlerhafte Software, fehlende Einarbeitung und etwas Dokumentation, die mal hier und mal dort im Projekt entstanden ist, könnten schon fast als “best-practice” bezeichnet werden.

Aber was hat das Ganze denn jetzt mit Agilität zu tun? Wir brauchen doch auch zukünftig Projekte, oder?

Die kurze Antwort vorweg: auch zukünftig wird es Projekte geben. Kritisieren möchte ich aber die Vorgehensweise, was alles zu einem Projekt gemacht wird, was kein Projekt ist.

Ich möchte gerne anhand eines Beispieles meine Kritik kenntlich machen:
Ein Versicherungsunternehmen “Insure” möchte paypal als neuen Zahlungsservice für Ihre Kunden anbieten. Dazu wird ein neues Projekt initiiert.
Da bei Insure gerade agile Methodiken angesagt sind, entscheidet sich das Unternehmen für ein agiles Scrum-Projektteam. Das Projektteam arbeitet wirklich nach Scrum und liefert nach einem Jahr Entwicklung ein solide Softwareintegration in die bestehende IT-Systemlandschaft. Insure hat aus vergangenen Projekten gelernt und kümmert sich in dem letzten Sprint des Projektes um die Übergabe in die Linie. Innerhalb der zwei Wochen muss aber die komplette Übergabe erfolgt sein, da das Projekt zeitnah beendet werden soll und auch das Budget knapp ist. Das Projektteam kümmert sich um die Übergabe an die Spezialisten, die aktuell auch andere Zahlungsservices von Insure betreuen. Teilweise müssen aber auch Teile an Spezialisten vom Web-Frontend von Insure übergeben werden. Nach dem letzten Sprint ist die Übergabe abgeschlossen.

Vier Wochen nach Einführung gibt es die ersten Probleme mit der Anbindung an paypal und Kunden beschweren sich bei Insure. Die Rückfragen gehen an die unterschiedlichen Spezialisten aus der Linie, die die Themen aus dem Projekt übernommen haben. Rückmeldungen und Fehlerbehebungen dauern lange, da die Spezialisten sich innerhalb der vier Wochen noch nicht in die Tiefe der Software einarbeiten konnten. Die Fehler, die auftauchen, sind grundlegende Probleme, die in den Tests vom Projektteam nicht aufgetreten sind. Die übergreifende Abstimmungen ist schwierig, da die Teams nicht mehr in einer Einheit zusammenarbeiten. Parallel findet aber auch noch Weiterentwicklung von neuen paypal-Themen statt, die in dem Projekt aufgrund der Scopereduzierung nicht mehr umgesetzt werden konnten. Die Probleme sammeln sich und nach einem Jahr in Produktion entscheidet man sich ein Folgeprojekt zu starten. Die Story wiederholt sich.

Was hätte man anders machen können?

Zuerst möchte ich prüfen, ob die Kriterien die zu einem Projekt geführt haben zugetroffen haben:

Komplexität
Die Anbindung eines neuen Zahlungssystem in eine bestehende IT-Systemlandschaft kann sich durchaus als erhebliche Komplexität herausstellen. Das Kriterium trifft also zu.

Innovativ
Es wurde ein neues Kundenerlebnis im Bezahlprozess für den Kunden der Insure geschaffen, in dem Projekt wurden neue Technologien eingesetzt. Die Aufgabe war innovativ, was auch für ein Projekt spricht.

Risikobehaftet
Ob es ein risikobehaftete Aufgaben war, kann man ohne weitere Informationen nicht konkret sagen. Wenn man sich jedoch vorstellt, dass eventuell im Zusammenhang ein anderes Zahlungssystem abgeschalten worden ist, könnte man auch vermuten, dass es eine risikobehaftete Umsetzung war.

Zeitlich befristet
“Na klar! Wir mussten das Projekt innerhalb eines Jahres abschließen!” Das Argument mag stimmen, aber ist diese Grenze nicht künstlich herbeigeführt? Das neue geschaffene “Produkt” wurde in die Linie übergeben, aber wie man sieht, ist es damit noch nicht vorbei. Es gibt Weiterentwicklung und Fehlerbehebungen die außerhalb des Projektes weitergeführt werden sollen. Wenn man ehrlich ist, kann man also nicht davon sprechen, dass es ein festes Ende gab.

Man muss sich bewusst werden, dass dieses neu geschaffene Produkt erst mit der Einführung richtig angefangen hat zu “leben”. In der Betriebsökonomie gibt es dafür das Modell des Produktlebenszyklus, was auch auf eine Softwarelösung angewendet werden kann. In der Literatur findet man dazu den Software-Lebenszyklus. Prinzipiell unterscheiden sich diese Theorien in Nuancen, die in diesem Zusammenhang auch nicht entscheiden sind.

Produkte statt Projekte?

Man sollte sich vor einem Projekt im Klaren darüber sein, ob man wirklich nur eine einmalige Softwareentwicklung durchführt, oder ob es im weiteren Sinne die Einführung eines neuen Produktes ist, auch wenn dieses “Produkt” nicht im Sinne der Organisation direkt vermarktet werden kann.
Die Einführung eines Projektes mit einem festen Scope ist an sich nicht das Problem, doch durch die Vorgabe, dass ein Projekt ein Ende hat, ist in der Praxis die logische Schlussfolgerung, dass nach einem Projekt etwas übergeben wird und meistens andere Menschen das Produkt weiterentwickeln müssen. Hierbei entsteht durch die Übergabe ein regelrechter Wissensverlust, der nicht vermieden werden kann. Eine Akzeptanz des Managements, das die Mitarbeiter, die eine Software übernehmen, mindestens 6 Monate benötigen, bis sie sich in eine Software eingearbeitet haben, ist meistens nicht vorhanden.

Das Team, welches das Produkt entwickelt hat, sollte auch nach dem Projektende weiter an diesem arbeiten. Das Team arbeitet nach einem Jahr bereits sehr gut zusammen und kennt die Software am besten. Das Product-Backlog des Projektes kann direkt bestehen bleiben und muss nicht in andere Teams übertragen werden.

Desweiteren entstehen diverse Effekte, wenn von Anfang an klar ist, dass das Team auch nach dem Ende des Projektes das Produkt verantwortet.

• Die Softwarequalität kann besser sein, da das Team genau weiß, dass am Ende die fehlende Qualität ihnen selbst die Arbeit erschwert.
• Das Team identifiziert sich mit dem neuen Produkt und ist sich somit der Verantwortung bewusst.
• Das Team weiß, dass die Dokumention ihnen zu Gute kommt.

Fazit

Projekte haben auch bei agilen Vorgehensweisen ihre Daseinsberechtigung. Allerdings ist es naiv zu glauben, dass sich mit dem Projektende Softwarewartung in Luft auflöst – auch nicht, wenn es keine Weiterentwicklung gibt. Des Weiteren sind Übergaben immer ein erheblicher Wissensverlust, der auch durch gute Planung nicht vermieden werden kann.

Manche mögen sich nun fragen, wie das bitte umgesetzt werden soll.

“Wir haben nicht so viele MitarbeiterInnen, dass wir nach jedem Projekt ein neues Team schaffen können.”

Das ist richtig und auch nicht die allgemeine Lösung.

Wie man diesen Herausforderungen jedoch Herr werden kann, folgt in meinem nächsten Beitrag.

Ich freue mich über Kommentare und Rückfragen.

Sie möchten zu diesem Thema mehr erfahren oder haben Rückfragen die sie nicht kommentieren möchten?
Dann kontaktieren sich mich – ich freue mich über Ihre Nachricht.