Softwareprojekte müssen wirtschaftlich sein. Dies steht ausser Frage. Daher liegt es nahe, das unternehmerische Handeln in Softwareprojekten anhand des ökonomischen Prinzips zu gestallten. Das ökonomische Prinzip liegt in verschiedenen Ausprägungen vor. Eine abgeschlossene wirtschaftliche Handlung, also auch ein Projekt, sollte sich dabei klar an einer dieser Ausprägungen orientieren. Welches ökonomische Prinzip verfolgt wird, muss vor Projektstart festgelegt werden.
Bei vielen Projekten fällt es mir aber immer wieder schwer zu erkennen, welche Ausprägung des ökonomischen Prinzips verfolgt wird. Dabei spreche ich nicht nur von Softwareprojekten. Bei einem Blick in die tägliche Presse werden einem genügend – meist gescheiterte – Projekte vorgestellt. Versuchen Sie selbst einmal ob Sie bei diesen Projekten klar erkennen können welche Ausprägung des ökonomischen Prinzips als Grundlage des wirtschaftlichen Handelns gewählt wurde.
In diesem Artikel möchte ich Ihnen daher das ökonomische Prinzip vorstellen beziehungsweise in Erinnerung rufen. Ich möchte Ihnen zeigen wie dieses in Softwareprojekten Anwendung finden könnte und warum es so schwer ist sich klar für eine der Ausprägungen zu entscheiden.
Ausprägungen des ökonomischen Prinzips
Die folgenden drei Ausprägungen werden unterschieden:
- Minimalprinzip: Ein festes Ziel soll mit geringstmöglichen Mitteln erreicht werden. (Kosten minimieren)
- Maximalprinzip: Mit gegebenen Mitteln soll ein grösstmöglicher Nutzen erzielt werden. (Nutzen maximieren)
- Optimumprinzip: Die eingesetzten Mittel und der erreichte Nutzen sollen in einem optimalen Verhältnis stehen. (Kosten/Nutzen Verhältnis optimieren)
Beispiel aus dem täglichen Leben
So viel zur grauen Theorie. Betrachten wir zur besseren Veranschaulichung ein Beispiel. Dazu möchte ich gern etwas in der Zeit zurückgehen. Mein Grossvater war ein begeisterter Pilzsammler. (Die jüngere Generation mag es kaum glauben aber das Pilzsammler Minispiel in Facebook beruht tatsächlich auf wahren Begebenheiten.) Mich hat das Pilzsuchen zwar nie besonders fasziniert, aber als ich klein war habe ich meinen Grossvater bei seinen sonntäglichen Touren trotzdem gern begleitet. Unser „Auftraggeber“ war dabei meist meine Grossmutter. Sie hat das Projektziel vorgegeben.
Folgende Aufträge hat sie uns im Laufe der Zeit erteilt:
Projektauftrag 1: Um 12:30 müsst ihr bitte wieder zurück sein. Dann steht das Mittagessen auf dem Tisch.
Hier konnten wir ganz klar das Maximalprinzip anwenden. Wir haben versucht in der vorgegebenen Zeit so viele Pilze wie möglich zu finden.
Projektauftrag 2: Ich möchte zum Pilzessen noch ein paar Leute einladen. Bringt mir daher diesmal bitte mindestens 3 Kilo Pilze mit.
Diesmal wurde unser Quantitätsziel fest definiert. Wir konnten daher nach dem Minimalprinzip vorgehen und versuchen die Zeit für das Sammeln der bestellten Menge zu minimieren.
Projektauftrag 3: Viel Spass beim Pilze sammeln.
Diesmal wurde uns kein Projektrahmen vorgegeben. Wir haben daher nach dem Optimumprinzip gehandelt. Hatten wir genug Pilze gefunden dann sind wir wieder nach Hause gefahren. War die Suche nicht so erfolgreich, da der Wald eventuell schon am Vortag von einem anderen Sammler abgegrast wurde, dann haben wir unsere Suche früher abgebrochen.
Projektauftrag 4: Ihr müsst bitte bis 12:00 Uhr wieder zurück sein und 3 Kilo Pilze mitbringen.
Solch einen Projektauftrag haben wir zum Glück nie bekommen. Ich habe eben eine liebe Grossmutter die uns niemals solch ein fast unmöglich zu erreichendes Projektziel gegeben hätte.
Beispiel eines Softwareprojektes
Da wir bei der täglichen Arbeit aber keine Pilze sammeln sondern Software entwickeln, möchte ich versuchen, dieses Beispiel auf ein Softwareprojekt zu adaptieren. Nachfolgend möchte ich Ihnen die alternativen Vorgehensweisen bei Anwendung der unterschiedlichen Ausprägungen des ökonomischen Prinzips in einem Softwareprojekt aufzeigen. Da wir aber nicht in einer idealisierten Welt leben, müssen wir immer damit rechnen dass die von uns priorisierte Vorgehensweise abgelehnt wird. Die Ablehnung kann vom Kunden kommen oder sich dadurch ergeben, dass die unternehmenseigene Geschäftsphilosophie das Vorgehen unmöglich macht. Daher habe ich die nachfolgende Tabelle um eine Akzeptanz Spalte erweitert.
| Ausprägung des ökonomischen Prinzips | Anwendung im Softwareprojekt | Akzeptanz |
| Minimalprinzip | Der Kunde gibt die Features vor und es wird versucht diese so schnell wie möglich zu implementieren. | Meist wollen Kunden einen festen Termin vereinbaren. Das Motto „It’s done, when it’s done“ stösst allgemein auf wenig Akzeptanz. |
| Maximalprinzip | Der Kunde gibt einen festen Termin vor und priorisiert die umzusetzenden Features. Bis zu diesem Termin wird nun versucht so viele Features wie möglich umzusetzen. | Ein fester Termin gibt Planungssicherheit und ist meist unerlässlich. Aber die Unsicherheit des Kunden, ob das finale Produkt all seine gewünschten Features enthält, führt meist zu einer Ablehnung dieser Vorgehensweise. |
| Optimumprinzip | Man setzt die Features in (kleinen) Iterationsschritten um. Der Kunde gibt dabei die Features der nächsten Iteration oder den Zeitrahmen vor und entscheidet nach jeder Iteration über die Weiterführung des Projektes. | Dieses Vorgehen resultiert in einer sehr geringen Planungssicherheit sowohl beim Kunden als auch bei der Entwicklerfirma. Daher wird dieses Vorgehen selten zum Einsatz kommen. |
Alle drei Varianten sehen in der Theorie gut aus. In der Praxis stellen sie aber die Minderheit dar. Meist wegen der angesprochenen Akzeptanz Hindernisse. Dabei spreche ich nicht nur aus eigener Erfahrung sondern möchte auch hier erneut auf die in der täglichen Presse aufgeführten Projekte verweisen. Eine klare Zuordnung der Projekte zu einem der drei Prinzipien ist meist nicht möglich.
Wie sieht nun also die Realität in Softwareprojekten aus? Ich denke viele Softwareprojekte lassen sich anhand des nachfolgenden Musters beschreiben.
Bei einem typischen Softwareprojekt muss eine Reihe von Features implementiert werden. Diese definiert der Kunde zumeist im Vorfeld des Projektes, in einem mehr oder weniger hohen Detailierungsgrad. Die Details werden teilweise auch erst im Projektverlauf herausgearbeitet. Auf Grundlage der definierten Features wird nun meist der arme Softwareentwickler genötigt eine Aufwands- und Zeitabschätzung aufzustellen. Anhand dieser definitionsgemäss sehr ungenauen Abschätzung wird dem Kunden ein fixer Liefertermin versprochen.
Diese Vorgehensweise macht ein wirtschaftliches Handeln nach einem der ökonomischen Prinzipien aber schwierig. Erinnern wir uns dazu an das Beispiel der Pilzsuche zurück. Ein Softwareprojekt bei dem sowohl die Zeit als auch die Features vorgegeben sind entspricht dem Projektauftrag 4 aus dem Praxisbeispiel: „Ihr müsst bitte bis 12:00 Uhr wieder zurück sein und 3 Kilo Pilze mitbringen.“ Wie gesagt haben mein Grossvater und ich nie solch einen Auftrag bekommen. Ich möchte aber theoretisch überlegen was für Fälle in dieser Situation möglich gewesen.
| Fall | Wirkung |
| Es ist 11:30. Wir müssen daher das Sammeln einstellen damit wir um 12:00 Uhr zu Hause sind. Leider haben wir nur 2 Kilo Pilze gefunden. | Die Grossmutter, also unser Auftraggeber und Kunde, wird unzufrieden sein, da sie mit 3 Kilo Pilzen gerechnet hat. |
| Wir haben 3 Kilo Pilze gefunden. Es ist aber mittlerweile 13:30 Uhr. | Das quantitative Ergebnis liefern wir, aber das Mittagessen ist mittlerweile kalt geworden und die Grossmutter ist sauer auf uns. |
| Es ist 11:30 und wir haben genau 3 Kilo gefunden. | Super! Das Projektziel wurde exakt erreicht. Seien wir aber ehrlich. Wie hoch schätzen sie die Wahrscheinlichkeit für das gleichzeitige Eintreffen beider Ereignisse (11:30 und 3 Kilo) ein. Ja, diese geht leider gegen null! |
| Wir haben 3 Kilo gefunden und es ist erst 10:30 | Der Grossvater wird sicher auf dem Heimweg noch an seiner Stammkneipe anhalten sich ein Bier gönnen und mir eine Limonade spendieren. Eigentlich hätten wir aus Sicht des Auftraggebers das quantitative Ergebnis unter Einsatz von geringerem Aufwand erreichen können. Wir dehnen die Zeit aber künstlich bis 12:00 Uhr aus und brauchen den gesparten Mitteleinsatz wieder auf. |
Was geschieht in Softwareprojekten bei denen Zeit und Features vorgegeben sind? Genau das Gleiche! Die meisten Projekte enden damit, dass der Zeitrahmen gesprengt wird oder dass die Software in einem unfertigen Zustand ausgeliefert wird. Und selbst wenn der seltene Fall eintritt das ein Projektteam gut vorankommt, wird das Projekt sicher nicht früher als geplant abgeschlossen werden. Wenn es gut läuft setzt nämlich meist der Stammkneipen Fall ein und es wird entweder gegen Projektende immer langsamer voran gehen oder es werden zusätzliche Dinge implementiert die eventuell gar nicht nötig gewesen wären.
Fazit
Die typischen Softwareprojekte zeichnen sich dadurch aus das die gewünschten Features und der exakte Terminplan von Beginn an definiert werden. Durch die strikte Vorgabe von Kosten und Nutzen ist es aber nicht möglich die Projekte einer Ausprägung des ökonomischen Prinzips zuzuordnen. Dies erschwert das wirtschaftliche Handeln ungemein. Sowohl Zeitplan als auch Features exakt zu definieren resultiert darin, dass das Projekt von Beginn an zum Scheitern verurteilt ist.
Eine mögliche Lösung besteht darin, sich von diesem ausgetretenen Pfad zu entfernen. Es wird dabei aber sicherlich nicht möglich sein die festgelegten Geschäftsprozesse eines Unternehmens grundlegend zu ändern. Daher ist man auf Änderungen im kleinen Rahmen angewiesen. Im nächsten Artikel dieser Serie möchte ich Ihnen eine Möglichkeit vorstellen wie man mit geringfügigen Anpassungen im Softwareentwicklungsprozess zurück auf den rechten Pfad kommt und sein Projekt an einer Variante des ökonomischen Prinzips ausrichten kann.
coders corner 