Alte Vorgehensweisen & warum diese Methodiken scheitern (müssen)

Agiles Controlling & Contracting | Teil 1

Im Zuge der Globalisierung müssen moderne Unternehmensauftritte nicht nur mehrsprachig sein. Oft kommt hier noch der Wunsch hinzu, Märkte spezifisch zu bedienen. Um Inhalte nicht mehrmals pflegen zu müssen und möglichst alle Inhalte zentral pflegen und ausspielen zu können, wird der Anspruch an das CMS auch hinsichtlich Bedienbarkeit immer größer.

Webanwendungen werden immer komplexer

Weiterhin versuchen Unternehmen aus dem Bereich Business-Logiken verstärkt im Web abzubilden. Der digitale Wandel tut sein übriges. Bestehende analoge Geschäftsprozesse werden digital. Dabei besteht bei Kunden oft das Bedürfnis, bestehende Software und Infrastruktur zu nutzen, was auf den ersten Blick sehr sinnvoll erscheint. Diese müssen dann natürlich noch an diverse Drittsysteme angebunden werden. Im Besten Fall geschieht das über eine API. Oftmals kommen aber auch aufgrund Fehlens ebenselbiger nur Austauschformate wie XML, JSON oder im schlimmsten Fall CSV zum Einsatz. Hinzu kommt die hohe Diversifikation der Ausgabemedien, die von Jahr zu Jahr steigt. Als Krönung des Ganzen werden die Innovationszyklen im Web auch immer kürzer.

Was ich hier beschrieben habe, ist keine Ausnahme sondern die Regel.

Viele Gespräche mit Kollegen aus anderen Agenturen bestätigen mir dies. Unsere Erfahrung zeigt, dass die Projektvoraussetzungen zu Beginn (konkrete Anfrage) eines Projektes immer weniger mit dem Ergebnis am Ende eines Projektes zu tun hat. Vielleicht sollten sowohl die Kunden als auch die Agenturen weniger vom Projekt Webseite reden, sondern mehr vom Produkt. Der Begriff Projekt impliziert einen festgelegten Start und einen definierten Abschluss, was ja immer weniger der Realität entspricht. Ein Produkt ist jedoch selten abgeschlossen, sondern marktreif. Jedem Hersteller ist klar, dass Produkte ständig verbessert werden müssen. So sollte bei einer Webapplikation meines Erachtens ebenfalls vorgegangen werden, im besten Fall in Verbindung mit Lean-Prinzipien.

Die Verträge stehen dem häufig konträr entgegen

Natürlich kann ich es nachvollziehen, dass Einkäufer gerne Sicherheit hätten. Sicherheit über die Kosten, die Laufzeit. Selbstverständlich muss auch geregelt sein, wer verantwortlich ist, wenn etwas schief läuft. Deshalb hören wir von unseren Kunden ja immer wieder: "Unser Einkauf braucht das". Somit werden Wochen und Monate in Vertragsverhandlungen investiert, obwohl die Anforderungen zu diesem Zeitpunkt kaum ausreichend spezifiziert und daraus resultierend noch weniger belastbar geschätzt werden können.

Dies hat sich sogar auf Kundenseite schon herumgesprochen. So ändern sich schon während der Vertragsabstimmung wichtige Parameter. Es werden weitere oder ergänzende Anforderungen formuliert oder Innovationen haben Einzug gehalten.

Deswegen sind die Verträge häufig die Tinte nicht wert, mit der sie unterschrieben werden. Den unmittelbaren Projektbeteiligten ist das durchaus bewusst. Den Vertrag jedesmal anzupassen und abzustimmen würde einen Stop der Entwicklung bedeuten, was auf Agenturseite immer gleichbedeutend damit ist, dass die Entwickler kurzfristig andere Aufgaben übernehmen müssten. Da das aber häufig gar nicht möglich ist, ließen und lassen sich Agenturen ja regelmäßig auf dieses Vabanque-Spiel ein.

Wie sagte es Sven Ditz von sitegeist mir gegenüber einmal so treffend: "Unsere Projekte werden immer komplexer, aber wir gestalten immer noch Verträge wie vor 20 Jahren."
Da muss ich ihm leider Recht geben. Meine persönliche Erfahrung zeigt mir, dass es eher Zufall ist, wenn dieses Vorgehen klappt. Vielleicht teilen sie ja meine Meinung. Zu einem Austausch bin ich gerne bereit.

Warum dieses Konstrukt scheitern muss

Bei den Kunden aber auch innerhalb der Agenturen herrscht leider noch häufig ein 100%-Denken. Das ist ja auch nicht verwunderlich, da die deutsche Wirtschaft gerade aufgrund ihrer Ingenieurskunst und ihrer kaum bis nicht vorhandenen Fehlertoleranz so erfolgreich war. Leider wird hierbei vergessen, dass diese Produkte bei ihrer Markteinführung eher einfach waren. Die Komplexität kam erst im Zuge der Weiterentwicklung hinzu.

Mein erster Golf hatte noch keine Tonne Leergewicht, 4 Gänge, Fenster kurbelte man mit der Hand hoch und runter und ABS war auch nicht eingebaut. Dafür war er aber auch erheblich günstiger als heutzutage.

Die Anforderungen an eine Webseite sind leider eher damit vergleichbar, als ob der Kunde einen vollausgestattenen 5er BMW kaufen möchte, bei dem man auch noch jederzeit die Außenfarbe oder gar die Antriebsart (Benzin, Diesel oder Elektro) je nach Bedarf wechseln kann. Bedauerlicherweise gibt es genug Agenturen (wie wir früher auch), die behaupteten, das auch noch innerhalb eines festen Budgets und Zeitplänen umsetzen zu können.

Aber seien Sie doch mal ehrlich. Welches dieser Projekte hat jemals innerhalb Time and Budget funktioniert? Wenn die Verzögerung nur 2 - 3 Monate beträgt, gilt das IT-Projekt als erfolgreich. Ehrlich?! Ist das wirklich unser Anspruch?!

Wir lügen uns am Beginn jedes Projektes schamlos an und sind auch noch überzeugt, dass diese Vorgehensweisen so sein müssen. Dann kommt so ein Vertrag zustande, von dem jeder weiß, dass er nicht funktionieren wird. Beide Seiten gehen hochmotiviert ins Projekt und alles klappt ja auch, da die Entscheidung zu strittigen oder unklaren Themen regelmäßig nach hinten verschoben werden. Das Resultat ist dann, dass gegen Ende des Projektes zur normalen Nervosität noch die Diskussion um diese Themen anstehen. In diesen Diskussionen wird dann regelmäßig auf den Vertrag - der ja gar nicht praktikabel war - verwiesen, da nur so die Diskussionen beendet werden können. Verstärkend kommt hier hinzu, dass sowohl beim Kunden als auch in der Agentur der Point-of-no-Return längstens überschritten ist. Somit bleiben bei diesen Methodiken nur noch Verlierer. Der einzige potentielle Gewinner bleibt vielleicht der Einkauf.

Fazit

Wir sollten aufhören uns gegenseitig anzulügen. Ja, es gibt Missverständnisse zwischen Kunde und Agentur. Nein, wir können in der Entwicklung nicht zaubern. Code schreibt sich nicht von selbst und wir laufen in unseren Überlegungen auch mal in die falsche Richtung. Nein lieber Kunde, Ihr wisst in der Regel nicht genau, was Ihr wollt und was Eure Kunden benötigen. Geschweige denn, dass der Projektverantwortliche wirklich eigenständig entscheiden kann und sich Vollzeit um das Projekt kümmern kann. Nein, die Schnittstellen sind nicht definiert. Nein, das bestehende Projekt ist auch nicht bis ins Detail dokumentiert. Auch wir tun das nicht, denn kaum ein Kunde ist wirklich bereit, dass zu bezahlen. Aber was ist denn die Lösung für mehr Ehrlichkeit? Das weiß ich nicht.

Aber einen Ansatz dazu verrate ich Ihnen in meinem nächsten Beitrag zu diesem Thema!

Zur Übersicht