Manche Software-Projekte scheitern. Das ist nicht weiter schwierig; meist reicht es vollkommen aus, den Dingen einfach ihren Lauf zu lassen.
Das Drama beginnt in der Regel mit dem ersten Akt – einem fulminanten Kick-Off-Meeting mit wortreichen Lippenbekenntnissen über die strategische Bedeutung des Projekts und der sich daraus ergebenden Forderung nach maximalem Engagement für die höchstmögliche Produktqualität. Wie immer soll es grandios werden – und innovativ natürlich. Aber es muss auch zügig vorangehen, denn das Budget ist selbstverständlich begrenzt. Alle sind zunächst hoch motiviert und legen sich mächtig ins Zeug, doch schon nach wenigen Wochen ist irgendwie die Luft raus, der Wurm drin, es läuft einfach nicht rund. Auch wie immer. Mit Ach und Krach und vielen Nachtschichten liefert das Team zur Deadline ein Produkt ab, das weder großartig noch wegweisend ist. Egal, Hauptsache Auftraggeber:in hat bezahlt, so schlimm kann es dann ja nicht gewesen sein. Und… ups, morgen ist ja schon das Kick-Off für das Anschlussprojekt, da haben wir jetzt leider keine Zeit mehr, Probleme zu reflektieren. Machen wir nächstes Mal, ganz bestimmt…
Woran scheitern Software-Projekte?
Aber halt, oben im ersten Satz ging es doch um das Scheitern? Wie kann ein Projekt gescheitert sein, obwohl ein Produkt geliefert und dieses auch abgenommen und bezahlt wurde? Ganz einfach: Weil es nicht mit Liebe zum Detail und maximaler Aufmerksamkeit durchgeführt wurde und die Entwickler:Innen nicht alles gegeben haben. Aus welchen Gründen auch immer (dazu gleich mehr), es reicht einfach nicht, ein Projekt „gerade so und irgendwie“ fertig zu bekommen. Das haben die Benutzer:innen nicht verdient, die oft jahrelang mit einer Software arbeiten müssen.
Es gibt viele Gründe, die angeblich einer erfolgreichen Projektbearbeitung im Wege stehen und immer wieder als Ausrede missbraucht werden. Hier kommt meine persönliche „Best-of“-Liste:
- Das Tagesgeschäft: „Als Entwickler:in muss ich schließlich auch Supportfälle bearbeiten, an Meetings teilnehmen, spontan beim Import irgendwelcher Fremddaten helfen, meine Kolleg:innen unterstützen, recherchieren und Verwaltungsarbeiten erledigen. Kannstenixmachen.“
- Unklare Anforderungen: „Was kann ich als Entwickler:in dafür, wenn mir nicht klar und deutlich gesagt wird, was ich wann und wie umsetzen soll? Nicht meine Schuld.“
- Warten auf andere: „Es dauert einfach zu lange, bis ich Antworten auf offene Fragen oder versprochenes Material erhalte. Die Ansprechpartner:innen aus der Fachabteilung sind nicht gut erreichbar, sind im Urlaub, fühlen sich nicht zuständig, haben mit ihrem eigenen Tagesgeschäft schon mehr als genug zu tun. Kein Wunder, dass es nicht rund läuft.“
Für sich betrachtet ist jede dieser Begründungen absolut stichhaltig und stört den erfolgreichen Verlauf eines Software-Projekts massiv. Trotzdem handelt es sich in allen drei Fällen um hausgemachtes Elend, denn stets lässt sich das Problem letztlich auf schlechte oder gar nicht erfolgte Kommunikation zurückführen. Und ist nicht gleichzeitig genau das einer der „Standardvorwürfe“, die man uns Softwareentwickler:innen immer wieder macht: Dass wir nicht in der Lage seien, vernünftig und ausreichend mit normalen Menschen zu sprechen?
Diese einfachen Maßnahmen machen Projekte erfolgreich
Dabei kann es so einfach sein: Wenn das Tagesgeschäft auszuufern droht, lasse ich nicht einfach meine Projekte ruhen, sondern bespreche das sofort mit meinen Auftraggeber:innen. Gemeinsam kann dann eine Entscheidung über die richtigen Prioritäten getroffen werden. Kannstewohlwasmachen. Wenn mir die Anforderungen nicht klar sind, frage ich aktiv nach und bitte um Erklärungen und Details. Selbstverständlich meine (Hol-)Schuld – Warten auf andere war gestern. Und wenn die Menschen nicht reagieren, auf deren Input oder Zulieferung von Teilergebnissen ich angewiesen bin, stecke ich nicht den Kopf in den Sand. Stattdessen spreche ich sie darauf an, wie wichtig ihr Beitrag für den Erfolg des Projektes ist, und frage nach, warum ich nichts höre. Kein Wunder, dass dann doch auf einmal alles rund läuft.
Agile Methoden wie z.B. Scrum können sehr viel dazu beitragen, gute Kommunikation im Projekt durch die vorgegebenen „Zeremonien“ zu fördern. Wenn ich auch nur einen einzigen (…den vierten…) Grundsatz des agilen Manifests („Business people and developers must work together daily throughout the project.“) wirklich ernst nehme, ist die größte Gefahr gebannt, nämlich dass man den Dingen einfach ihren Lauf lässt. Das darf nicht passieren und das muss es zum Glück auch nicht. Immer vorausgesetzt, die innere Einstellung stimmt: Es kann nur funktionieren, wenn ich stets wach, aktiv und immer auf der Suche nach Schwachstellen und Verbesserungsmöglichkeiten in der Zusammenarbeit bin.
Sie möchten mehr darüber wissen? Bitte sprechen Sie mich an, ich helfe gerne weiter.