Viele Unternehmen und Organisationen legen einen seltsamen Geiz an den Tag, wenn es um die Besetzung eines Projekt-Teams mit Projektleitern, Architekten oder Testern geht. Der Projektleiter zu teuer, die Architekten bauen doch eh nur Luftschlösser, testen kann doch auch der sowieso zu teure Projektleiter oder na gut, wir geben drei Projekten zusammen einen Tester, der aber nur ein kaltzustellender minderleistender Entwickler ohne „Bock“ auf die Aufgabe ist. Ach so – und die Software spezifizieren kann auch ein Fachbereichsmitarbeiter, der so etwas noch nie gemacht hat, ein Junior-Produktmanager, gar eine Sekretärin oder ein Praktikant, die lernen das dann per Trial & Error. Vielleicht. Hoffentlich. Ganz bestimmt. Im Traum.
Ich behaupte, gute Projektleiter/Scrum Master, Architekten, Tester und Spezifikateure kosten überhaupt kein Geld, im Gegenteil.
Nanu? Aber das Unternehmen zahlt ihnen doch jeden Monat Gehalt oder Honorar, im Fall von qualifizierten externen Mitarbeitern sogar stattliche Summen! Das ist doch Geld, oder nicht?
Klar, aber meine Aussage bezieht sich auf das Ergebnis des Projekts und die Gesamtkosten, nicht auf die Einzelvergütung. Ein Projekt ist ja viel mehr wert als sein Budget, sonst würde es sich nicht lohnen. Ein Projekt, für das nicht mindestens ein Effekt in Höhe von Budget plus Projektrisiko plus angestrebte Umsatzrendite erwartet wird, braucht man gar nicht erst zu starten. (Und ja, auch „strategische“ Projekte sollten sich mit einer monetär bezifferbaren Wirkungserwartung verknüpfen, Wirtschaftsunternehmen sind kein Ponyhof!)
Nun ist es so, dass Projekte, die mit unerfahrenen oder gar ungeeigneten Projektleitern oder Scrum Mastern, Spezifikateuren und Product Ownern, keinen oder nur Aushilfsarchitekten, keinen oder nur Aushilfstestern ausgestattet werden, ein fantastisch großes Risiko haben, die schillernde Statistik gescheiterter Entwicklungsanstrengungen zu bereichern.
Das Team wird nicht effizient wirksam, weil seine Mitglieder nicht an einem Strang ziehen. Es wird Ungeeignetes entwickelt oder die mangelhafte Benutzerfreundlichkeit macht das Produkt zur Totgeburt. Die fachlichen Klärungen sorgen für jede Menge Aktivität, aber lähmen den eigentlichen Fortschritt. Das Team häuft technische Schulden auf, die zukünftige Projekte zu erdrosseln drohen. Fehler werden spät gefunden und damit viel zu teuer beseitigt, oder sogar erst vom Kunden „entdeckt“, wenn das Produkt schon auf dem Markt ist.
Ergebnis: Budget mehrfach überzogen, riesige Opportunitätskosten angehäuft, Kunden und Mitarbeiter verloren, Projektziele nicht erreicht, Image beschädigt. Ein Desaster! Böses Team… oder?
Nach meiner Erfahrung kosten gescheiterte Projekte oft das Zwei- oder Dreifache des ursprünglichen Kostenansatzes, im Extremfall ein größeres Vielfaches – und damit manchmal das ganze Unternehmen.
Risiko? Da war doch was… Risikomanagement! Ich sehe es so, dass die Ausstattung von Projekten mit qualifiziertem Querschnitts-Personal eine Maßnahme des Risikomanagements ist. Man kann zwei bis fünfzig Entwickler zusammensetzen und hoffen, dass sie in endlicher Zeit das gewünschte Ergebnis produzieren werden. Das Risiko ist nur sehr, sehr groß, dass das nicht passiert und das Projekt entsprechend teuer wird – bei jeder ernstzunehmenden Projektgröße praktisch immer zu teuer.
Um das Risiko und damit die angenommenen Kosten zu senken, werden die Querschnittsfunktionen ins Projektteam aufgenommen.
Gute Projektleiter/Scrum Master sorgen für Disziplin und befördern Teambildung und Kommunikation, schaffen geeignete Rahmenbedingungen und beseitigen Hindernisse. Spezifikationsexperten und erfahrene Product Owner formulieren die Anforderungen an die zu entwickelnde Software so präzise, anschaulich und stabil, dass die Entwickler nur noch wenige Fragen dazu haben. Gute Architekten entwerfen eine Softwarestruktur und Strukturmuster, die dafür sorgen, dass das System redundanz- und fehlerarm, wartbar und leistungsfähig ist, und sie stellen sicher, dass das auch so umgesetzt wird. Tester finden Fehler so früh wie möglich, grenzen die Ursache ein und lassen beim Entwicklerteam nicht locker, bis das Problem beseitigt ist.
All diese Querschnittsaufgaben wirken im Idealfall stark multiplizierend. Ihr Nutzen vervielfacht sich über das ganze Team. Sonst würde man damit ja auch kaum die Kosten eines Projekts senken können, sondern bestenfalls die benötigte Zeit reduzieren!
Wird man sich dieses Zusammenhangs bewusst, wird klar, warum man hier nicht sinnlos sparen sollte: Jedes bisschen positiver Wirkung multipliziert sich positiv!
Es lohnt sich in jeder Hinsicht, Projekte richtig anzugehen, keine halsbrecherischen Abkürzungen zu nehmen und die ewigen Wahrheiten des Projektgeschäfts zu berücksichtigen. Dafür braucht man die richtigen Menschen in geeigneter Anzahl und man muss ihnen für ihre Arbeit Geld geben… das sich aus dem Risikobudget selbst finanziert: Risikosenkungsmaßnahmen, in diesem Fall die Arbeitsplätze und Gehälter oder Honorare der eingesetzten Personen, werden aus dem Wert des Risikos (finanzielle Auswirkung bei Eintritt mal Wahrscheinlichkeit) bezahlt.
Fiktives Beispiel: Angenommen, ohne den Top-Projektleiter besteht ein Risikowert von 250.000€. Den bisherigen Kandidaten durch einen über die Projektlaufzeit 50.000€ teureren zu ersetzen, senkt den Risikowert auf 100.000€. Die Maßnahme hat 100.000€ gespart, obwohl mehr Honorar bezahlt werden muss.
Natürlich gibt es auch hier eine Grenznutzenkurve: Zusätzliche Teammitglieder und zusätzliche Euro Vergütung (als ungefähres Maß für die Qualifikation eines Mitarbeiters) führen nicht unendlich zu linearen Verbesserungen beim Risiko. Der 2.000-Euro-pro-Tag-Berater halbiert nur selten das Projektrisiko gegenüber einem 1.000-Euro-pro-Tag-Berater. Zwanzig Tester finden in einem kleinen Projekt i.d.R. nicht doppelt so viele Fehler wie zehn. Mit hoher Wahrscheinlichkeit wird aber der positive Hebel zwischen einem 1.000-Euro-am-Tag-Berater und einem zu der jeweiligen Rolle verdonnerten Aufgabenneuling beträchtlich sein. Hier gilt es, das richtige Maß zu finden, das aber sehr oft weit unterschritten wird, in der Annahme, dass Querschnittsfunktionen in Projekten Geld kosten.
Meine Empfehlung: Bei PLs, POs, Scrum Mastern und Architekten, von denen es jeweils nur einen oder sehr wenige im Team geben kann, auf Qualifikation achten und dafür im Zweifel etwas tiefer in die Tasche greifen. Bei Testern auf ein ausgeprägtes Tester-Mindset achten und im Zweifel eher einen mehr ins Team stecken.
Warum wird das so oft falsch gemacht? Oft aus mangelndem Bewusstsein für den oben geschilderten Zusammenhang. Ebenso oft aber aus Gier. Aus Gier auf ein vermeintlich billig zu erzielendes Projektergebnis und/oder den damit verbundenen Ruhm werden wider jede Vernunft die Chancen hoch-, die Risiken heruntergespielt und die Kosten großzügig durch „Das wird schon irgendwie gehen“-Teams rechnerisch niedrig gehalten.
Gier vernebelt den Verstand.