Interview: Projektmanagement im Spannungsfeld von Kundenanforderungen und Code-Qualität

Hallo! Ja, da kommt im Laufe der Jahre einiges an Erfahrung zusammen. Schießen wir los!

Wenn ich ganz ehrlich bin: Die Projekte, an denen ich bisher beteiligt war, fielen hauptsächlich in den Bereich des Continuous Development. Es gab natürlich Meilensteine, bei denen es hier und da zu Verzögerungen, Verschiebungen oder Scope-Anpassungen kam. Aber ein Projekt mit einem klassischen, strikten Abschluss hatte ich bis dato eigentlich gar nicht.

Absolut. Ich habe mich in meinen Bachelor- und Masterarbeiten intensiv mit der Analyse befasst, warum IT-Projekte so oft scheitern – sei es durch einen kompletten Abbruch oder durch verspätete Lieferungen.

Die Statistik ist da recht ernüchternd: Nur gut ein Drittel aller Projekte wird zeitgerecht beendet. Etwa 18 Prozent werden komplett vorzeitig gestoppt und rund 46 Prozent übersteigen das Budget oder können den Go-Live-Termin nicht halten. Man kann also sagen, dass fast 75 Prozent der Projekte nicht wie geplant geliefert werden.

Meiner Erfahrung nach liegt es vor allem in IT-Projekten am Anforderungsmanagement. Oft weiß der Kunde selbst nicht genau, was er eigentlich möchte. Die Anforderungen sind unklar, oder sie werden – falls sie anfangs klar waren – zu einem späteren Zeitpunkt wieder geändert.

Genau. Das Anforderungsmanagement ist dadurch extrem beweglich. Die Folge: Projekte werden oft nur teilweise geliefert oder es kommt wegen neuer Anforderungen zu Kostenüberschüssen. Am Ende werden Meilensteine verschoben, Funktionalitäten gekürzt oder es ist schlicht kein Geld mehr übrig. Es liegt also nicht allein an der Planung. Der Kunde trägt hier eine riesige Mitverantwortung.

Natürlich, ich hatte auch schon Planungen, die nicht ganz korrekt waren. Während einer Business Analyse habe ich beispielsweise nachgerechnet und gesehen, dass wir länger als geplant für den Go-Live brauchen würden. Wir haben dann im Dev-Team die Ressourcen hochgeschraubt und die Teamzusammensetzung optimiert. Dadurch konnten wir das abfangen. Aktuell sieht es in meinem Projekt so aus, als ob wir voll in der Zeit liefern können.

Das ist viel Gefühlssache, die mit der Zeit kommt. Man muss den Entwicklern vertrauen, dass sie ihr Handwerk verstehen, und sich auf ihre Einschätzungen verlassen können. Sie müssen wissen, wie lange Aufgaben wie die API-Anbindung oder Datenbankanalysen dauern. Auf Basis dieser High-Level-Schätzungen mache ich dann meine Planung.

Die Leute, die ich bisher hatte oder selbst auswähle, sind mit ihrem Stack vertraut. Während meiner Zeit als BA im öffentlichen Sektor und im Steuerwesen waren die Leute oft noch auf Junior-Level. Das lag aber am fehlenden Fachwissen zum Thema Steuern, nicht am IT-Handwerk. Die Analysen konnten sie durchführen. Manche finden sich da einfach schneller in ein neues Thema ein, manche brauchen länger.

Bei den Entwicklern halte ich mich an den Lead Dev. Er schätzt das Team ein und bewertet, wie Junior jemand ist und wie lange er für die Arbeit braucht. In meiner Funktion kann ich die rein technische Tiefe nur schwer beurteilen.

Diese extreme Situation hatte ich an sich nicht. Ich habe mal in einem Team mit vielen Juniors gearbeitet, aber das war uns bewusst. Die Meilensteine wurden von vornherein so gewählt, dass es zum Setting gepasst hat.

Ja, in einem anderen Projekt hatten wir einen Junior, der leider nicht nur Junior war, sondern auch eine ziemliche Null-Bock-Einstellung hatte (Owezara, wie man in Österreich sagen würde). Das hat die anderen Juniors total runtergezogen. Da das ein externer Vendor war, haben wir das dort deponiert und die Person wurde ausgetauscht. Die neuen Kollegen kamen dann mit viel Motivation und Drive. Dieser Drive ist oft wichtiger als die reine Seniorität, weil er das ganze Team pusht.

Absolut. Wir haben uns die Velocity über die letzten Sprints angesehen und Prognosen erstellt. Man hat genau erkannt, dass wir seit dem Abgang des Kollegen performanter und zügiger unterwegs sind und unsere nächsten Meilensteine einhalten können.

Ich habe es eigentlich nie anders erlebt als durch aktives Ansprechen. Das wurde in meiner Praxis immer so gehandhabt, um die Projektqualität zu sichern. Es geht ja nicht nur darum, schneller zu liefern, sondern zu verhindern, dass negatives Verhalten auf andere überschwappt und das ganze Team demotiviert. Deswegen: Immer sofort das Gespräch suchen und eine Lösung finden, zum Beispiel durch einen Team- oder Positionswechsel. Das ist die Aufgabe des PMs, hier nachzujustieren.

Ja, ich habe schon hin und wieder mal in den Code reingeschaut und mitgelesen. Ich verstehe auch, was er macht. Aber ich kann beim besten Willen nicht beurteilen, ob man den Code besser, kürzer oder eleganter hätte schreiben können.

Genau, das sehe ich am Ende des Tages auch nicht als meine Aufgabe. Dafür habe ich ja die Lead Devs im Team.

Das ist unterschiedlich. Aktuell im Bankenwesen bin ich aus Dev-Sicht der Kunde, ich fordere also etwas an. Früher bei Accenture war ich der Dienstleister und habe für Kunden entwickelt. In meiner jetzigen Rolle als Kunde bekommen wir Profile und CVs, schauen uns die an und wählen aus. Oft gibt es Kundeninterviews. Aber ob jemand auf dem Projekt dann wirklich gute Arbeit leistet, sieht man halt erst, wenn es läuft.

Eben. Und ich glaube, dass Konsequenzen oft zu lange hinausgezögert werden. Nicht unbedingt unbemerkt, aber man hofft halt, dass sich das Blatt noch wendet. Das schadet dem Projekt letztendlich oft mehr, als es nützt. Ich glaube aber trotzdem nicht, dass das der ausschlaggebende Grund ist, warum Projekte scheitern. Ich habe es selten erlebt, dass es am Team oder der Qualität liegt – es liegt meistens am Kunden, weil er nicht weiß, was er will.

Wie gesagt, das ist eigentlich die Aufgabe des Leads. Wenn solche Beschwerden aufkommen, liegt es oft am strengen Zeitplan. Der Entwickler sagt dann: „Ich musste den Code da jetzt so durchgehen lassen, weil wir fertig werden mussten.“

Ja, aber ich habe auch schon mit Leads gearbeitet, die sich extrem für Code-Qualität eingesetzt haben. Wenn mir der Lead sagt: „Es wird vielleicht ein bisschen mehr Zeit dauern, aber die Qualität ist dafür besser“, dann entscheide ich mich als PM ganz bewusst dafür. Ich finde, dass uns Qualität letztendlich viel mehr bringt, als zu diesem Zeitpunkt eine kleine Spur schneller zu sein.

Weil die Anforderungen anfangs oft unklar sind, heißt es im Laufe des Projekts plötzlich: „Das muss jetzt auch noch schnell in den Release rein!“ Dadurch sinkt die Qualität im Code, es kommt zu mehr Bugs und man unterschätzt komplett, wie viel Aufwand das bedeutet. Statistisch gesehen gilt: Wenn ich den Bug sofort behebe, kostet es mich minimal Zeit und Geld. Je später ich ihn entdecke, desto teurer wird es am Ende des Tages.

Ja, für mich bleibt der Kunde das Hauptproblem. Es kann natürlich sein, dass der Lead Dev sagt: „Das bekommen wir schon irgendwie hin“, und dann insgeheim Abstriche bei der Code-Qualität macht. Aber das weiß ich dann als PM oft nicht, weil ich mich darauf verlasse, dass Qualität geliefert wird.

Nein, das habe ich noch nie gesagt. Ich will immer, dass die Qualität hoch bleibt. Ich finde, wenn Personen ihr Handwerk verstehen, sollte das ihr oberstes Ziel sein. Aber ich denke schon, dass es PMs gibt, die vielleicht nicht die richtige Ausbildung haben, sondern eher über Learning by Doing reingerutscht sind. Die arbeiten dann oberflächlicher, legen keinen Wert darauf oder wissen es einfach nicht besser. Die sehen nur: „Es ist rechtzeitig und im Budget geliefert worden, also passt es.“

Dass innerhalb des Projektteams aneinander vorbeigeredet wird, kommt definitiv vor. Ich habe das auch schon am Rande mitbekommen. So ein Problem sollte natürlich sofort aufgelöst werden, sobald man es merkt. Das über Monate hinweg zu verschleppen, ist ein riesiges Problem. Aber letztendlich ist das für mich auch wieder ein Stakeholder-Problem: Was wollen wir eigentlich genau haben?

Das kenne ich und habe es selbst schon erlebt. Wenn ein Entwickler ein <div> statt eines semantischen <button>-Elements nimmt, steht das für mich gar nicht zur Debatte – das ist einfach schlechtes Handwerk.

Explizit wird es für uns meistens bei Dingen wie barrierefreien PDFs. Wenn ich das testen und auditieren muss, ist das extra Zeit und extra Geld. Aber auf den reinen Code im Web bezogen, sollte Barrierefreiheit eigentlich kaum ein Problem sein. Kann ich das als PM beurteilen? Eher nicht, das muss der Lead Dev wissen und das muss im Ticket stehen, besonders wenn ein Audit ansteht. Aber Barrierefreiheit auf Code-Ebene sollte definitiv nicht als „Extra-Aufwand“ oder Kostenfresser gesehen werden.

Nein, das liegt einfach daran, dass man versucht, diverse Stakeholder kurzfristig zufrieden zu stellen. Der Stakeholder sieht: „Das Feature ist da, für mich passt es erst mal.“ Dass danach Bugs auftreten, ist ihm in dem Moment egal. Hauptsache, das Feature ist da. Nach mir die Sintflut.

Selten. Sie sehen das neue Feature und freuen sich.

Also zusammenfassend würd ich sagen: Das Anforderungsmanagement und die Stakeholder sind meiner Meinung nach das Hauptproblem. Das habe ich in meinen wissenschaftlichen Arbeiten herausgefunden und das erlebe ich tagtäglich in der Praxis. Das ist der Grund, warum IT-Projekte nicht rechtzeitig geliefert werden. Man macht eine High-Level-Schätzung, merkt dann, dass es viel komplexer ist und die Analyse länger dauert – und schon verschiebt sich der Einsatz um ein paar Wochen.