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\u00f6sser, 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 \u2013 und die Software spezifizieren kann auch ein Fachbereichsmitarbeiter, der so etwas noch nie gemacht hat, ein Junior-Produktmanager, gar eine Sekret\u00e4rin oder ein Praktikant, die lernen das dann per Trial & Error. Vielleicht. Hoffentlich. Ganz bestimmt. Im Traum.<\/p>\n
Ich behaupte, gute Projektleiter\/Scrum Master, Architekten, Tester und Spezifikateure kosten \u00fcberhaupt kein Geld, im Gegenteil.<\/strong><\/p>\n 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?<\/p>\n Klar, aber meine Aussage bezieht sich auf das Ergebnis des Projekts und die Gesamtkosten, nicht auf die Einzelverg\u00fctung. Ein Projekt ist ja viel mehr wert als sein Budget, sonst w\u00fcrde es sich nicht lohnen. Ein Projekt, f\u00fcr das nicht mindestens ein Effekt in H\u00f6he 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\u00e4r bezifferbaren Wirkungserwartung verkn\u00fcpfen, Wirtschaftsunternehmen sind kein Ponyhof!)<\/p>\n 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\u00dfes Risiko haben, die schillernde Statistik gescheiterter Entwicklungsanstrengungen zu bereichern.<\/p>\n 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\u00e4rungen sorgen f\u00fcr jede Menge Aktivit\u00e4t, aber l\u00e4hmen den eigentlichen Fortschritt. Das Team h\u00e4uft technische Schulden auf, die zuk\u00fcnftige Projekte zu erdrosseln drohen. Fehler werden sp\u00e4t gefunden und damit viel zu teuer beseitigt, oder sogar erst vom Kunden „entdeckt“, wenn das Produkt schon auf dem Markt ist.<\/p>\n Ergebnis: Budget mehrfach \u00fcberzogen, riesige Opportunit\u00e4tskosten angeh\u00e4uft, Kunden und Mitarbeiter verloren, Projektziele nicht erreicht, Image besch\u00e4digt. Ein Desaster! B\u00f6ses Team… oder?<\/p>\n Nach meiner Erfahrung kosten gescheiterte Projekte oft das Zwei- oder Dreifache des urspr\u00fcnglichen Kostenansatzes, im Extremfall ein gr\u00f6\u00dferes Vielfaches \u2013 und damit manchmal das ganze Unternehmen.<\/p>\n Risiko? Da war doch was… Risikomanagement! Ich sehe es so, dass die Ausstattung von Projekten mit qualifiziertem Querschnitts-Personal eine Ma\u00dfnahme des Risikomanagements ist. Man kann zwei bis f\u00fcnfzig Entwickler zusammensetzen und hoffen<\/em>, dass sie in endlicher Zeit das gew\u00fcnschte Ergebnis produzieren werden. Das Risiko ist nur sehr, sehr gro\u00df, dass das nicht passiert und das Projekt entsprechend teuer wird – bei jeder ernstzunehmenden Projektgr\u00f6\u00dfe praktisch immer zu<\/em> teuer.<\/p>\n Um das Risiko und damit die angenommenen Kosten zu senken, werden die Querschnittsfunktionen ins Projektteam aufgenommen.<\/p>\n Gute Projektleiter\/Scrum Master<\/em> sorgen f\u00fcr Disziplin und bef\u00f6rdern Teambildung und Kommunikation, schaffen geeignete Rahmenbedingungen und beseitigen Hindernisse. Spezifikationsexperten<\/em> und erfahrene Product Owner<\/em> formulieren die Anforderungen an die zu entwickelnde Software so pr\u00e4zise, anschaulich und stabil, dass die Entwickler nur noch wenige Fragen dazu haben. Gute Architekten<\/em> entwerfen eine Softwarestruktur und Strukturmuster<\/em>, die daf\u00fcr sorgen, dass das System redundanz- und fehlerarm, wartbar und leistungsf\u00e4hig ist, und sie stellen sicher, dass das auch so umgesetzt wird. Tester<\/em> finden Fehler so fr\u00fch wie m\u00f6glich, grenzen die Ursache ein und lassen beim Entwicklerteam nicht locker, bis das Problem beseitigt ist.<\/p>\n All diese Querschnittsaufgaben wirken im Idealfall stark multiplizierend<\/em>. Ihr Nutzen vervielfacht sich \u00fcber das ganze Team. Sonst w\u00fcrde man damit ja auch kaum die Kosten eines Projekts senken k\u00f6nnen, sondern bestenfalls die ben\u00f6tigte Zeit reduzieren!<\/p>\n Wird man sich dieses Zusammenhangs bewusst, wird klar, warum man hier nicht sinnlos sparen sollte: Jedes bisschen positiver Wirkung multipliziert<\/em> sich positiv!<\/em><\/p>\n Es lohnt sich in jeder Hinsicht, Projekte richtig<\/em> anzugehen, keine halsbrecherischen Abk\u00fcrzungen zu nehmen und die ewigen Wahrheiten des Projektgesch\u00e4fts zu ber\u00fccksichtigen. Daf\u00fcr braucht man die richtigen Menschen in geeigneter Anzahl und man muss ihnen f\u00fcr ihre Arbeit Geld geben… das sich aus dem Risikobudget selbst finanziert: Risikosenkungsma\u00dfnahmen, in diesem Fall die Arbeitspl\u00e4tze und Geh\u00e4lter oder Honorare der eingesetzten Personen, werden aus dem Wert des Risikos (finanzielle Auswirkung bei Eintritt mal Wahrscheinlichkeit) bezahlt.<\/p>\n Fiktives Beispiel: Angenommen, ohne den Top-Projektleiter besteht ein Risikowert von 250.000\u20ac. Den bisherigen Kandidaten durch einen \u00fcber die Projektlaufzeit 50.000\u20ac teureren zu ersetzen, senkt den Risikowert auf 100.000\u20ac. Die Ma\u00dfnahme hat 100.000\u20ac gespart<\/em>, obwohl mehr Honorar bezahlt werden muss.<\/p>\n Nat\u00fcrlich gibt es auch hier eine Grenznutzenkurve: Zus\u00e4tzliche Teammitglieder und zus\u00e4tzliche Euro Verg\u00fctung (als ungef\u00e4hres Ma\u00df f\u00fcr die Qualifikation eines Mitarbeiters) f\u00fchren nicht unendlich zu linearen Verbesserungen beim Risiko. Der 2.000-Euro-pro-Tag-Berater halbiert nur selten das Projektrisiko gegen\u00fcber einem 1.000-Euro-pro-Tag-Berater. Zwanzig Tester finden\u00a0in 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\u00e4chtlich sein. Hier gilt es, das richtige <\/em>Ma\u00df zu finden, das aber sehr oft weit unterschritten wird, in der Annahme, dass Querschnittsfunktionen in Projekten Geld kosten.<\/p>\n 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\u00fcr im Zweifel etwas tiefer in die Tasche greifen. Bei Testern auf ein ausgepr\u00e4gtes Tester-Mindset achten und im Zweifel eher einen mehr ins Team stecken.<\/p>\n Warum wird das so oft falsch gemacht? Oft aus mangelndem Bewusstsein f\u00fcr 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\u00dfz\u00fcgig durch „Das wird schon irgendwie gehen“-Teams rechnerisch niedrig gehalten.<\/p>\n Gier vernebelt den Verstand.<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u00f6sser, testen […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55],"tags":[58,10,56,15,60,59,14,57],"_links":{"self":[{"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/posts\/31"}],"collection":[{"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/projektklinik.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=31"}],"version-history":[{"count":16,"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions"}],"predecessor-version":[{"id":142,"href":"https:\/\/projektklinik.de\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions\/142"}],"wp:attachment":[{"href":"https:\/\/projektklinik.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/projektklinik.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/projektklinik.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}