Produktorientierung vs. Projektorientierung

Ein Projekt beginnt mit einer Idee, und wenn die Idee vielversprechend klingt, kann sie initiiert werden, um sie in die Realität umzusetzen. So faszinierend es auch klingen mag, das Wort „Projekt“ bedeutete früher vor (pro-) dem Handeln (-ject). In den 50er Jahren wurde Projektmanagement mit der Einführung verschiedener Techniken in der Fertigungs- und Verteidigungsindustrie immer akzeptabler. Dies erweiterte die Definition von „Projekt“ um Planung und Ausführung und hat seitdem Hunderte von Techniken in vielen anderen Branchen verändert.

Keine Sorge, dies ist keine Vorlesung über Projektmanagement. Ein Verständnis des aktuellen Stands des Projektmanagements sollte jedoch einen Kontext dafür liefern, warum ich es geschrieben habe.

Ergebnisse werden immer anhand akzeptierter Kriterien gemessen. Erfolg wird letztendlich so wahrgenommen, wie genau der Projektmanager den ursprünglichen Plan einhält – Umfang, Zeit und Budget.

Das scheint auf den ersten Blick vollkommen vernünftig.

Aber was ist mit den Projekten, die in Bezug auf Zeitplan und Budget gleichauf liegen und innerhalb des Umfangs liegen, aber dennoch nicht erfolgreich sind?

Ziel ist es nicht, Projekte zu liefern, sondern durch die Produkte einen Mehrwert zu schaffen

Kürzlich wurde ich damit beauftragt, ein Learning Management System zu verwalten, dessen Entwicklung von unserer Agentur in Auftrag gegeben wurde, während ich parallel dazu die geschäftlichen Bedürfnisse des Kunden unterstützte. Das Projekt wurde definiert, budgetiert und ein enger Zeitplan für die phasenweise Bereitstellung vorgeschlagen. Die Anwendung sollte Dutzende von Schulen bedienen, direkt nachdem das Berichtssystem fertiggestellt war, während die Quizplattform parallel entwickelt werden sollte. Unnötig zu erwähnen, dass unsere Begeisterung für LMS mit Elan begann. Die sich entwickelnden Anforderungen der Stakeholder, das System zu verbessern und gleichzeitig den Veröffentlichungstermin nicht zu beeinträchtigen, wurden jedoch zu einer Herausforderung. Das Team hatte Schwierigkeiten, fundierte und produktorientierte Entscheidungen zu treffen. Schließlich verschlechterte sich die Kundenzufriedenheit und beeinträchtigte die Produkt- und Geschäftsziele negativ, was das gesamte Projekt zum Stillstand brachte. Bei der Rückschau mit dem Team wurde mir klar, dass sich die meisten Teammitglieder mehr darauf konzentrierten, Tickets in den Status „Erledigt“ zu verschieben, als qualitativ über eine Funktion für Fehler- und/oder Edge-Case-Szenarien nachzudenken. Es hätte fruchtbarer sein können, wenn wir über die Funktion nachgedacht hätten und welchen Unterschied sie für den Endbenutzer machen würde. Wir haben kläglich versagt!

Projektorientiertes Denken ist weit verbreitet. Insbesondere in der Informationstechnologie haben die Menschen einen großen Teil ihrer Karriere auf Projekte und Projektmanagement konzentriert. Große Organisationen haben oft PMO-Abteilungen, die sich ausschließlich mit Projektmanagement befassen. Es ist nicht unbegreiflich, denn Projektmanagement gibt es schon sehr lange. Und es ist eine natürliche menschliche Tendenz, Projekt als das zu betrachten, was wir erledigen müssen.

Dienstleistungsagenturen tun sich oft schwer, das produktbasierte Denken in Teams einzuführen.

Die Projekt-Denkweise definiert den Erfolg von innen heraus, indem interne Messungen verwendet werden, die sich eher auf das Aufgabenmanagement und die Genauigkeit beziehen, mit der der ursprüngliche Plan befolgt wurde. Der Fokus des Projekt-Denkens liegt auf der „Lieferung“. Dies könnte die Lieferung von wirklich allem sein, einer bestimmten Funktion oder Software als Ganzes oder von Raketen bis zu Lebensmitteln. Und da das einzige Ziel die Lieferung ist, sind die wichtigsten Parameter zur Beurteilung hier der Zeitplan und der Zeitrahmen. Das Projektmanagement wird speziell auf den Output ausgerichtet und danach bewertet, wie genau wir den Zeitplan vorhersagen und dann den spezifizierten Output im vereinbarten Zeitrahmen liefern konnten. Erfolg wird weitgehend dadurch definiert, dass man die Spezifikationen von etwas im Voraus nimmt, einen Zeitplan mit Meilensteinen auf dem Weg dorthin aufstellt und diese Meilensteine dann erreicht.

Was schätzen Ihre Kunden? Projekte oder Produkte? Ziel ist es nicht, Projekte zu liefern, sondern durch die Produkte einen Mehrwert zu schaffen – Produkte, die letztendlich zu höheren Einnahmen und niedrigeren Kosten für das Unternehmen führen. Produkte, die so großartig sind, dass Ihr Kundenstamm wächst und bestehende Kunden gehalten werden.

Der Übergang von einer Projekt- zu einer Produkt-Denkweise erfordert eine Verlagerung des Denkens auf langfristige Ziele anstelle von kurzfristigen. Anstatt sich auf Zeitpläne und Termine zu konzentrieren, konzentrieren sich Teams mit einer Produkt-Denkweise auf Ergebnisse anstelle von Output und erstellen eine strategische Vision und Roadmap, die den ROI maximiert.

Wir halten uns an das Ziel, das wir erreichen wollen, oder an die Aufgabe, die erledigt werden muss. Da wir uns auf die Ergebnisse und nicht auf den Output konzentrieren, wird es schwieriger, Zeitbeschränkungen für die Liefergegenstände festzulegen, zumindest im Voraus. Vor allem, weil wir nicht unbedingt wissen, wie wir das Ziel überhaupt erreichen werden.

Dienstleistungsagenturen tun sich oft schwer, das produktbasierte Denken in Teams einzuführen. Die Leute glauben, dass sie an kurzlebigen Softwareanwendungen arbeiten, die einige Monate bis zu einem Jahr dauern können, und wenn sie fertig sind, können sie zu einem anderen Projekt übergehen. Die Anwendung wird kaum als „Produkt“ verwaltet, das nach Abschluss des Projekts mehrere Monate lang in der Produktion laufen muss.

Diese Art des Denkens kann eine ziemliche Umstellung sein, insbesondere für diejenigen, die viel Zeit mit Projekten und Projektmanagement verbracht haben. Im Allgemeinen fühlen sich die Leute nicht wohl mit der Ungewissheit, keine strukturierten Zeitpläne zu haben, die täglich überwacht werden können.

Der Daseinszweck der Produktentwicklung ist es, den Nutzern und Kunden einen Mehrwert zu bieten.

Wie machen wir das? Wie vermitteln Sie einen produktorientierten Ansatz?

Fast jedes Produkt beinhaltet ein gewisses Maß an Projektmanagementprozess. Wir müssen die Dinge in Bewegung halten, und es ist (leider) unrealistisch anzunehmen, dass wir in einer Umgebung arbeiten können, in der unsere Stakeholder und Partner keine Termine oder Zusagen erwarten.

Der Schlüssel hier ist, Projektpläne und Zusagen nur dann zu machen, wenn wir dies mit einem hohen Maß an Sicherheit tun können. Anstatt also im Voraus einen einzigen Weg einzuhalten, verpflichten wir uns erst, wenn wir validiert haben, was wir wirklich tun, und die Möglichkeit haben, einigermaßen zu verstehen, wie es sich auf die Endbenutzer auswirken wird. Normalerweise sind Sie bereits ein oder zwei Sprints in die Arbeit involviert, wenn Sie das Gesamtbild erkennen. Dies mag sich im Prozess überraschend spät anfühlen, aber an diesem Punkt können Schätzungen, Pläne und Zusagen tatsächlich etwas bedeuten.

Aus den bisherigen Erfahrungen lernend, erkannte das Team nun, dass das, was das Projekt antreibt, das Produkt ist und nicht umgekehrt. Glücklicherweise erhielten wir eine weitere Gelegenheit, ein LMS für einen in den USA ansässigen Pädagogen zu entwickeln. Das Team richtete sich auf den produktorientierten Ansatz aus und untersuchte jede Aufgabe kritisch, bevor es die Schätzungen abgab. Eine proaktive Beratung rund um das geplante Produkt ermöglichte es den Stakeholdern und Scrum Mastern, die meisten Probleme vorherzusehen, sodass sie rechtzeitig Geschäftsentscheidungen treffen konnten. Dies trug dazu bei, schwerwiegende Auswirkungen auf die Geschäftsabläufe zu vermeiden.

Kurz gesagt: Lassen Sie das Team eine ordnungsgemäße Erkundung und Recherche durchführen, bevor Sie nach Zusagen fragen.

Es ist ebenso wichtig, anderen zu helfen, die Vorteile des produktbasierten Denkens zu verstehen. Es gibt einen Grund, warum viele Leute nach Terminen und Zeitplänen fragen – ein Teil davon ist auf alte Gewohnheiten zurückzuführen, aber es gibt Zeiten, in denen es für das Geschäft und die Zuweisungen von größter Bedeutung ist. Daher müssen wir die Idee von Zeitplänen in diesen Fällen verstehen. Wenn es darum geht, den Verkauf eines Produkts zu fördern, sollte der Fokus eher auf der übergeordneten Geschichte als auf bestimmten Funktionen liegen. Wenn es darum geht, Risiken zu mindern, müssen wir den Leuten vielleicht helfen zu verstehen, dass das eigentliche Risiko nicht darin besteht, einen Termin zu verpassen, sondern das Ziel dessen, was wir an Werten liefern wollen, vollständig zu verfehlen.

Wenn alles gesagt und getan ist, ist der Daseinszweck der Produktentwicklung, den Nutzern und Kunden einen Mehrwert zu bieten. Oft wissen wir jedoch nicht, was genau diesen Wert liefern wird. Zu glauben, dass wir die richtigen Lösungen im Voraus, manchmal ein Jahr im Voraus, finden können, ist ziemlich unrealistisch.

Schreiben Sie uns an [email protected], um zu erfahren, wie wir mit Drupal 8 und unseren effizienten Projektmanagementtechniken eine innovative Web-Property erstellen können.