Warum Manager Projektentwicklung gegenüber der agilen Produktentwicklung bevorzugen und warum sie dabei falsch liegen.
Es gibt viele Arten wie sich Unternehmen organisieren. So vielseitig wie die Geschäftsmodelle dieser Unternehmen sind, so unterschiedlich sind auch deren Aufbauorganisationen und Prozesse. Viele Unternehmen lassen sich in eine von zwei Kategorien einteilen:
- Unternehmen mit Projektentwicklung
- Unternehmen mit Produktentwicklung
Je größter ein Unternehmen ist, desto mehr tendiert es sich in verschiedene Abteilungen entlang von Funktionen (wie beispielsweise.: Design, Marketing, Operations, Development, …) zu organisieren. Dies führt zu einer Starrheit des Systems und kann existenzbedrohend werden, wenn Änderungen am Markt nicht schnell genug erkannt werden und das Unternehmen auf diese Änderungen nicht schnell genug reagiert. Deswegen versuchen viele Unternehmen sich wieder in Produktentwicklungsunternehmen zu transformieren. Diese Transformation scheitert jedoch oft.
Dieser Artikel geht auf Unterschiede zwischen Projektentwicklung und Produktentwicklung ein, betrachten Vor- und Nachteile der beiden Entwicklungsorganisationsformen und beleuchtet das Thema aus der Managementperspektive.
Unterschiede Projektentwicklung vs. Produktentwicklung[1]
Was ist das Delivery?
Bei der Projektentwicklung geht es um die Lieferung eines vorher definierten Umfangs am Ende des Projekts.
Die Produktentwicklung hingegen strebt nach kontinuierlicher Lieferung von nachweislichem Wert.
Wann wird der Wert geliefert?
In der Projektentwicklung wird der genaue Umfang des Projekts zu Beginn in einer Planungsphase geplant, geschätzt und vertraglich fixiert. Die Lieferung der Entwicklungsleistung wird erst am Ende des Projekts oder zu definierten Meilensteinen abgeschlossen.
Bei der modernen agilen Produktentwicklung wird der Wert für den User/Kunden kontinuierlich geliefert. Das Team setzt die Arbeit meist in Zyklen um und liefert mittels Continuouse Delivery regelmäßig und frühzeitig dem „Markt“ (also den Usern bzw. Kunden) neuen Mehrwert.
Wonach strebt das Team?
In der Projektentwicklung strebt das Team danach, den zuvor definierten Umfang des Projekts zu liefern. Es strebt somit nach der Optimierung der Arbeitsleistung im Bezug auf den Umfang des Projekts. Das Team möchte mit möglichst wenig Arbeitsaufwand den Umfang des Projekts erfüllen.
In der Produktentwicklung strebt das Team nach dem maximalen Mehrwert für die Kunden/User. Es geht explorativ vor und sucht nach dem besten Product-Market-Fit.
Was wird finanziert?
In der Projektentwicklung werden Vorleistungen nicht direkt finanziert. Leistungen wie Planung, Schätzungen, Technische Evaluierungen werden Vorab entweder durch andere Übereinkommen finanziert, oder müssen durch die Entwicklung querfinanziert werden. Das Hauptaugenmerkt der Finanzierung liegt auf der Umsetzung des vereinbarten Umfangs in der Entwicklungsphase – eine Scope-Basierte Finanzierung der Entwicklungsphase.
Bei der Produktentwicklung ist der Ausgang der Entwicklung offen. Das Team versucht Hypothesen zum Markt zu erstellen und diese durch Umsetzung von Prototypen zu bestätigen oder zu falsifizieren. Es sucht so lange nach möglichen Problemen des Markts und technischen Lösungen dieser Probleme bis es einen passenden Product-Market-Fit bzw. Feature-Market-Fit gefunden hat. Das Management finanziert also ein interdisziplinäres Team, welches in der Lage ist, diesen Fit zu finden und ein wirtschaftliches Geschäftsmodell darauf aufzubauen.
Welche Arbeiten werden finanziert?
In der Projektentwicklung werden nur die eigentlichen Entwicklungsarbeiten finanziert, nicht jedoch die Vorphasen bzw. die nachgelagerten Arbeiten die mit Betrieb und Support des Produkts/Werkes einhergehen.
In der Produktentwicklung werden alle Tätigkeiten des Interdisziplinären Teams finanziert, die den gesamten Produktlebenszyklus betreffen. Von der explorativen Entwicklung und Weiterentwicklung des Produkts, über den Betrieb des Produkts bis hin zum Support des Users.
Worauf liegt der Fokus aller Beteiligten?
In der Projektentwicklung achten alle Beteiligten primär auf den Output des Projekts, erst danach werden Faktoren wie Nutzen, Qualität, Wartbarkeit usw. betrachtet.
In der Produktentwicklung achtet das Team und alle beteiligten auf den Outcome. Es werden konkrete Ergebnisse erwartet die Faktoren wie Nutzen für die User, Etablierung am Markt, Qualität, Wartbarkeit und Betriebskosten mit einbeziehen.
Roadmap
Bei der Projektentwicklung wird eine Output-orientierte Roadmap zu Beginn des Projekts erstellt. Diese umfasst einen genau definierten Umfang was im Projekt zu erledigen ist, und klar messbare Faktoren, die ein erfolgreiches Projektende definieren.
In der Produktentwicklung wird die Outcome-orientierte Roadmap im Zuge der explorativen Umsetzung gemeinsam im interdisziplinären Team mit Product-Owner und Teammember definiert. Der Product-Owner und das Team erarbeiten gemeinsam ein Product-Backlog, was eine Verfeinerung der „Outcome-orientierten Product-Roadmap“ darstellt.
Team
Bei der Projektentwicklung besteht das Team hauptsächlich aus Mitarbeitern der Entwicklung. Das Team wird temporär geschaffen, um das Projekt und das Projektziel zu erreichen. Danach wird das Team aufgeteilt und neue Teams werden passend zu den neuen Projekten geformt. Da andere Phasen abseits der Entwicklung (wie beispielsweise der Betrieb des Produkts) außer Acht gelassen werden, ist das Team sehr homogen und nach innen gerichtet.
In der Produktentwicklung ist das anders. Das Team ist konstant und interdisziplinär. Es besteht lange Zeit – solange das Produkt am Markt ist besteht das Team welches si e um den Betrieb, die Weiterentwicklung und die Wartung des Produkts kümmert. Das Team ist konstant nach außen gerichtet und in Kontakt mit Usern und anderen Marktteilnehmern.
Dauer des Bestehens des Teams
In der Projektentwicklung besteht das Team, solange es das Projekt gibt. Ist das Projektziel erreicht wird das Team aufgeteilt und die einzelnen Teammitglieder kümmern sich um andere Projekte bzw. formen neue Teams. Die Teams sind somit eher kurzlebig. Es wird von den Mitarbeitern eine hohe Flexibilität verlangt. Da Projekte stark variieren bilden sich eher keine Spezialgebiete heraus und Domänenwissen kann nur selten wiederverwendet werden.
In der Produktentwicklung bestehen Teams sehr lange. Sie formen sich entlang des Value Streams eines Geschäftsmodells, das im Kern ein Produkt hat. Hier können die Mitarbeiter Spezialwissen und Domänenwissen aufbauen und innerhalb des Teams interdisziplinär an der gesamten Wertschöpfungskette arbeiten. Ein Wechseln in eine andere Produktentwicklung ist dafür mit hohen Einstiegskosten verbunden.
Phasen des Development-Cycles
In der Projektentwicklung werden viele Arbeiten außerhalb des eigentlichen Projektes gemacht. Es werden entweder vorarbeiten durch den Auftraggeber geleistet. Oder es werden vor dem Entwicklungsprojekt noch Vorprojekte gemacht. In der Projektentwicklung wird dann neben der Detailplanung nur die Umsetzung gemacht. Die Projektentwicklung fokussiert sich somit hauptsächlich auf die Build-Phase, weitere Phase wie Run, Measure, Learn sind nicht Teil der Projektentwicklung.
Die Produktentwicklung hat einen ganzheitlichen Blick auf die Umsetzung des Produkts und bildet alle Phasen von der Ideenfindung bis hin zum Betrieb und zur Weiterentwicklung des Produkts ab. Das beinhaltet somit die Phasen Ideate, Build, Run, Measure, Learn, Repeat.
Ziele
In der Projektentwicklung hat das Team das Ziel den versprochenen und spezifizierten Scope des Projekts innerhalb der geplanten Zeit zu erreichen. Das Team hinterfragt also die Spezifikation nicht und denkt nicht abseits des spezifizierten Umsetzungspfades über die Entwicklung nach. Es werden auch keine Extras bezüglich Sicherheit, Wartbarkeit etc. entwickelt, sondern davon ausgegangen, dass ein gewisser Industriestandard anzuwenden ist. Nicht mehr und auch nicht weniger.
In der Produktentwicklung ist das anders, hier versucht das Team gemeinsam ein Produkt zu kreieren, welches letzten Endes einen guten Product-Market-Fit erreicht. Das Team versucht also Hypothesen zum Markt aufzustellen und diese durch Exploratives vorgehen zu bestätigen oder zu entkräften, mit dem Ziel ein Produkt zu erschaffen auf dem ein tragfähiges Geschäftsmodell betrieben werden kann. Das Ziel ist es also möglichst schnell einen guten Product-Market-Fit zu erreichen auf dem ein Geschäftsmodell aufgebaut werden kann.
Organisation
Da in der Projektentwicklung viele Leistungen vor und nach dem eigentlichen Entwicklungsprojekt durchgeführt werden, werden in Projektorganisationen Abteilungen nach Funktionen gebildet. Abteilungen entstehen sich die sich nur um Design, Development, Operations, Testing oder Support kümmern. Es entstehen Silos, die ihre eigenen Subziele innerhalb der Organisation verfolgen. Zwischen den Abteilungen müssen klare Grenzen gezogen und Schnittstellen definiert werden. Dies geschieht einerseits, weil sich die Manager der einzelnen Departments absichern wollen und andererseits, weil sonst die Kommunikation und der Erfolg schlichtweg nicht möglich wäre. Das macht die gesamte Organisation jedoch starr und schwer anpassbar.
In Produktentwicklungsorganisationen ist das anders, hier entstehen zwar auch Silos, jedoch entstehen sie entlang von Geschäftsmodellen und Produkten entlang des Value-Streams. Eine Interdisziplinäre Zusammenarbeit innerhalb dieses Value-Streams ist somit gewährleistet.
Betrachtung der Unterschiede zwischen Projektentwicklung und Produktentwicklung
Es gibt also zahlreiche große Unterschiede zwischen Organisationen mit Projektentwicklung und Produktentwicklung. Oftmals Entstehen Unternehmen aus einer Produktentwicklung heraus, und wachsen bis sie eine Größe haben, die eine Reorganisation bedarf. Unternehmen tendierten dann sehr oft sich entlang der Value-Chain in einzelne funktionale Departments aufzuteilen. Das führt zu Silobildung, zur Bildung von Grenzen und Kommunikationsschnittstellen und zur Projektentwicklung.
Da eine Derartige Organisation bei jeder Schnittstelle Wissensverlust erleidet und die Mittleren Abteilungen wie beispielsweise die Entwicklung keinen direkten Bezug zum Markt hat besteht die Gefahr das das Unternehmen jeglichen Marktvorteil über die Zeit verliert und das Geschäftsmodell eines Tages nicht mehr funktioniert. In der Produktentwicklung ist dies nicht der Fall. Hier werden Inputs vom Markt ständig erhoben und auf allen Ebenen für das Team zugänglich gemacht.
Die Projekteentwicklung hat aber gegenüber der Produktentwicklung den Vorteil, dass die Abteilungen nach innen leichter zu organisieren sind. Manager können sich Spezialisieren und Risiken minimieren.
Projektentwicklung hat gegenüber Produktentwicklung also Vorteile, jedoch verliert die Wertschöpfung an sich den Fokus. Wer Wert generieren will sollte also Produktentwicklung betreiben und nicht Projektentwicklung. Unternehmen, die das erkannt haben, setzten daher auf eine Transformation zurück zur Produktentwicklung und zur ganzheitlichen Organisation. Ein mittel dies zu schaffen ist das OKR-Framework[2].
Warum bevorzugen Manager dann Projektmanagement?
Manager wollen auf einer Unternehmensebene ökonomische und rechtliche Risiken minimieren. Gleichzeitig wollen sie aber ihre persönlichen Risiken (angst um Kontrollverlust oder persönliche Konsequenzen), die mit der Ausübung des Projekts einhergehen, ebenfalls minimieren, ihren Möglichkeiten zur Einflussnahme auf das Projektgeschehen jedoch maximieren. Im Idealfall wollen sie das Ganze mit so geringem Zeitaufwand wie möglich machen.
Möchte ein Manager also aus seiner Position heraus mit einem Dienstleister ein Produkt entwickeln, so möchte er sich legal absichern und wissen, was er für sein Gelb bekommt. Ebenso verhält es sich, wenn der Manager mit seinen eigenen Mitarbeitern ein Projekt für ein anderes Unternehmen umsetzt. Auch hier möchte er sich zu Beginn des Projekts durch Verträge vor etwaigen Schadensansprüchen oder Reklamationen rechtlich schützen. Bei rein interner Umsetzung von Projekten verhält es sich ähnlich. Der Manager will sich gegenüber seinen Mitarbeitern absichern und genau definieren, wann was wie gemacht wird, um mit möglichst wenig Aufwand benötigte Ressourcen für diesen Scope zu berechnen und die erwarteten Ergebnisse auch von den eigenen Mitarbeitern verlangen zu können. Er möchte also quasi einen Vertrag mit seinen eignen Mitarbeitern, um sich abzusichern.
Es geht also um die Finanzierung von und die Investition in Ressourcen und die sich daraus ergebenden Ergebnisse und Risiken.
Die Nachteile dieser Betrachtungsweise
Was diese Betrachtungsweise jedoch weitgehend offen lässt ist der Wert, der aus dem Projekt resultiert und die Verifizierung und Sicherstellung dieses Wertes bzw. die Verringerung des Marktrisikos des resultierenden Erzeugnisses. Das Management vernachlässigt somit komplett den Markt.
Wie unterscheidet sich Projektentwicklung von Produktentwicklung im Bezug auf Ressourcenbindung und Freiheiten der Mitarbeiter?
Bei der Produktentwicklung wird im Gegensatz zur Projektentwicklung ein Team auf unbestimmte Zeit finanziert und gebunden. Das Team fokussiert sich außerdem auf die gesamte Wertschöpfungskette vom Markt bis zum Betrieb des Produkts und Support des Endkunden. Dazu muss das Team interdisziplinär aufgestellt sein und große Freiheiten genießen. Entscheidungen müssen autonom vom Team aufgrund von Experimenten und Lernerfahrungen getroffen werden können.
Dieser hohe Grad an Autonomie, das lange Committment von Ressourcen und der interdisziplinäre Charakter des Teams machen es für das Management sehr schwierig diese Entwicklungsart zu finanzieren und zu managen. Ein einzelner Manager oder ein Management-Team können nicht mehr steuernd eingreifen, sondern müssen dem Team vertrauen. Das macht es für viele Manager unmöglich eine moderne Produktentwicklung zu erlauben.
Darüber hinaus unterlaufen Unternehmen, die entlang von Funktionen (wie beispielsweise.: Design, Marketing, Operations, Development, …) aufgeteilt sind, also Funktionale Abteilungen haben, einen Transformationsprozess, wenn sie die ersten Produktentwicklungsteams erzeugen.
Es ist für diese Unternehmen außerdem viel schwieriger die benötigten Teammitglieder für das interdisziplinäre Team zusammenzustellen und die notwendige Finanzierung und das Committment vom Management zu bekommen.
Wie verändert sich das Management?
Für das Management bedeutete dies oft starke Veränderungen. Bisherige Managementtools und Managementmethoden funktionieren in der agilen Produktentwicklung nicht mehr. Das Management muss Verantwortung an die Mitarbeiter abgeben und Vertrauen in das Team haben. Gleichzeitig fallen herkömmliche Berechnungen für Aufwände und Investitionskosten weg und können nicht mehr verwendet werden. Das Aufgabenfeld des Managements verlagert sich von einer eher nach innen gerichteten Aufmerksamkeit auf die eigenen Mitarbeiter nach außen auf den Markt. Es muss nun weniger in die Ressourcenplanung eingegriffen werden aber dafür sichergestellt werden, dass die Produktentwicklung ein tragfähiges Geschäftsmodell entwickelt und betreibt. Das interdisziplinäre Team ist sehr heterogen, weshalb das Management ein viel breiteres Wissen benötigt, um auf die Bedürfnisse der Mitarbeiter eingehen zu können.
Fazit
Die Produktentwicklung hat gegenüber der Projektentwicklung den Vorteil das interdisziplinäre Teams entlang des Value-Streams arbeiten und nach Produkten mit dem Passenden Product-Market-Fit suchen. Es werden tragfähige Geschäftsmodelle entwickelt und betrieben. Das Management in dieser Organisationsform verlagert sich von einer eher nach innen gerichteten Aufgabe, bei der die Mitarbeiter organisiert und geführt werden müssen hin zu einer nach außen gerichteten Aufgabe bei der Sicher gestellt werden muss, dass das interdisziplinäre Produktentwicklungsteam effizient arbeitet und ein tragfähiges Geschäftsmodell entsteht welches mit der Unternehmensstrategie kompatibel ist. Das macht es den Managern sehr schwer, denn sie müssen neue Strategien und Methoden in sehr kurzer Zeit erlernen, Verantwortungen an das Team abgeben und mehr vertrauen in die eigenen Mitarbeiter haben.
Quellen:
[1] https://martinfowler.com/articles/products-over-projects.html
[2] OKR
DigitalisierungsCoach 
Kommentar verfassen