Planview Blog

Ihr Weg zu geschäftlicher Agilität

Enterprise Agile Planning

Probleme im Zusammenhang mit dem Projektfinanzierungsmodell

Teil 1: Der Wechsel von Projekten zur Produktlieferung

Veröffentlicht Von Jon Terry

probleme-im-zusammenhang-mit-dem-projektfinanzierungsmodell-teil-1

Im heutigen Zeitalter der digitalen Disruption ist die Fähigkeit, schnell Werte zu liefern, für das Überleben eines Unternehmens entscheidend. Dieses Bedürfnis ist einer der Gründe für die wachsende Beliebtheit von Agile mit seiner Fähigkeit, schneller zu liefern und schnellere Feedback-Zyklen mit Kunden zu ermöglichen. Agilität hat einen langen Weg hinter sich und ist nicht mehr nur eine Ideologie für Außenseiter und Querdenker. Heutzutage setzen Spitzenunternehmen auf der ganzen Welt Agile in großem Umfang ein und wenden sich vom traditionellen Modell der Projektfinanzierung ab.

Es gibt einen Aspekt von Agile, über den heutzutage viel gesprochen wird, den aber nur relativ wenige wirklich verstehen -das Produktmodell. Dieser Ansatz dient dazu, die Entscheidungsfindung zu dezentralisieren und die Kapazitäten für digitale Ressourcen enger und konsequenter auf die Geschäftsbereiche auszurichten, über die das Unternehmen seinen Kunden einen Mehrwert bietet. Es ist eine Abkehr vom traditionellen Projektfinanzierungsmodell, bei dem die Entscheidungsfindung über einen langsamen und kostspieligen Prozess der Schätzung aller potenziellen Arbeiten und der vorübergehenden Zuteilung gemeinsamer Ressourcen für genehmigte Arbeiten zentralisiert wurde, hin zu einem mehr Lean Portfolio Management Stil der Planung, Finanzierung und Arbeitsausführung.

Bevor wir das Produktmodell und seine Vorteile richtig verstehen können, müssen wir uns zunächst das Modell der Projektfinanzierung ansehen, um zu verstehen, warum es entstanden ist und welche Herausforderungen es mit sich bringt.

Probleme im Zusammenhang mit dem Modell

Wenn Sie Menschen, die schon lange in der IT-Branche tätig sind, von Agile erzählen, hören Sie nicht selten: "Aber so haben wir doch früher gearbeitet!" Damit haben sie nicht Unrecht. Vor den 1990er Jahren waren die IT-Abteilungen viel kleiner als heute, weil die Datenverarbeitung auf Mainframes und andere große zentrale Geräte beschränkt war. In den 1990er Jahren kamen PC-basierte Client-Server-Systeme auf, insbesondere solche, die über einen Webbrowser bereitgestellt werden. Plötzlich konnte jede Abteilung eines Unternehmens mit relativ einfachen Tools Kundensoftware erstellen - und das taten sie auch. Sie sahen, wie überall Server aus dem Boden schossen - unter Schreibtischen und in Besenkammern. Es war aufregend, aber es hat auch einige Probleme verursacht.

Die CFOs bemerkten all diese Ausgaben und erkannten, wie ineffizient sie oft waren. Die Anschaffung eines eigenen leistungsstarken Servers für jede Abteilung, um ein einziges System zu betreiben, war nicht die beste Verwendung des Geldes. All diese im Büro verstreuten Computer waren ein Sicherheitsrisiko - viele sensible Daten, die gestohlen werden oder verloren gehen konnten, wenn eine Festplatte ausfiel. Außerdem wurde die Arbeit oft uneinheitlich erledigt, da jede Abteilung ihre eigenen Programmierer einstellte, was Support und Integration zu einem echten Problem machte. Also wurde die IT wieder zentralisiert. Mehr Unternehmen schufen zentrale IT-Abteilungen, die dem Chief Information Officer unterstellt sind und häufig an den CFO berichten.

Bei diesem Modell entscheidet die Finanzabteilung jedes Jahr, wie viel sie angesichts der finanziellen Situation des Unternehmens für Technologie ausgeben möchte und "besteuert" die Geschäftsbereiche mit einem Teil ihrer Einnahmen, um einen zentralen Pool zu schaffen. Das Führungsteam legt Strategien fest, die als Grundlage für Investitionsentscheidungen dienen sollen. Theoretisch werden die Projekte auf der Grundlage dieser Strategien ausgewählt, um die Ressourcen auf die höchsten Prioritäten für das Unternehmen als Ganzes zu konzentrieren. In der Praxis sind die lokalen Prioritäten in der Regel ausschlaggebend für den Prozess, wobei jedes Gebiet darauf hinarbeitet, 'sein' Geld zurückzubekommen.

Lean Portfolio Management for the Enterprise Whitepaper

Business Cases werden so bearbeitet, dass sie ein hübsches Bild ergeben, das von der Finanzabteilung abgenickt werden kann. Wenn die Arbeit erst einmal begonnen hat, verlagert sich fast alles darauf, die IT-Abteilung dafür verantwortlich zu machen, wie gut sie im Vergleich zu den Schätzungen abschneidet, die im Planungsprozess oft angepasst werden, um eine Genehmigung zu erhalten. Und der ursprünglich versprochene Geschäftswert wird nach dem Projekt nur selten bewertet. Der Erfolg wird im Allgemeinen anhand des eisernen Dreiecks des Projektmanagements gemessen: On Time, On Scope, On Budget. Es spielt keine Rolle, ob die geleistete Arbeit tatsächlich zu echten Ergebnissen für das Unternehmen geführt hat.

Das Projektmodell schuf eine Reihe von Problemen, die sich negativ auf die Art und Weise auswirkten, wie die Teams Innovationen planten und umsetzten.

Die Probleme mit dem Projektfinanzierungsmodell hören für Organisationen, in denen Mitarbeiter in funktionalen Silosarbeiten - was in IT-Organisationen häufig der Fall ist - nicht auf, und ein Teil ihrer Zeit wird vorübergehend verschiedenen Projektteams zugewiesen. Dies führt zu einer unangenehmen Situation, in der mehrere Projekte um dieselben Ressourcen konkurrieren, d.h. die Mitarbeiter werden mehr als einem Projekt zugewiesen. Und natürlich argumentiert in dieser Situation jeder Projektmanager sein Projekt sei das wichtigste für das Unternehmen.

Wie Sie sich vorstellen können, schafft dies ein schwieriges Arbeitsumfeld, das dem Unternehmen schadet. Das bedeutet, dass verschiedene Teams innerhalb desselben Unternehmens gegeneinander arbeiten, um ihre Projektziele zu erreichen, anstatt das Unternehmen voranzubringen. Darüber hinaus versetzt dieses Modell die Organisation in einen ständigen Zustand der Unsicherheit und Instabilität. Da die Ressourcen auf mehrere Projekte verteilt sind (und um sie konkurrieren), hat ein Rückschlag bei einer Initiative einen Dominoeffekt, der alle anderen Projekte beeinträchtigt.

Klingt kontraproduktiv, oder? Das ist es.

Dieses Modell der gemeinsamen Nutzung von Ressourcen ist nicht nur instabil und unvorhersehbar, sondern auch nicht geeignet für , um kontinuierliche Verbesserungen zu erzielen. Die Mitarbeiter werden ständig aus ihren Fachabteilungen abgezogen und verschiedenen Projektteams zugewiesen. Sobald sie ihre Aufgabe innerhalb eines Teams erfüllt haben, werden die Personen entfernt und einer neuen Gruppe zugewiesen, und der Zyklus geht weiter. Sie stecken in einem vorübergehenden Zustand fest und haben weder die Zeit noch den Anreiz, Energie in kontinuierliche Verbesserungen zu investieren. Angesichts der Anforderungen von "On Time, On Scope, On Budget" wird das Team geradezu ermutigt, sich auf nichts anderes als den Projekterfolg zu konzentrieren. Und oft gibt es eine Trennung zwischen den Personen, die Projekte umsetzen, und denjenigen, die sich um Betrieb und Wartung kümmern. So müssen sich die Projektteams nicht mit den Problemen befassen, die sie in der Folge verursachen. Anstatt Verbesserungen zu fördern, ist dies ein Rezept für schlechte Qualität und technische Schulden.

In , dem nächsten Teil dieser Serie, werden wir uns ansehen, wie diese Probleme im Rahmen des Produktmodells angegangen werden. In der Zwischenzeit erfahren Sie mehr darüber, wie Planview die Umstellung von Projekten auf Produkte unterstützt, indem Sie sich die Demo ansehen oder unser Whitepaper "Lean Portfolio Management for the Enterprise" herunterladen, um zu sehen, wie Unternehmen LPM nutzen, um die Umstellung auf ein produktorientiertes Modell zu vollziehen.

Ähnliche Beiträge

Geschrieben von Jon Terry Chef-Evangelist, Lean-Agile Strategie

Jon Terry ist Chief Evangelist, Lean-Agile Strategy bei Planview, einem marktführenden Anbieter von Software für Portfoliomanagement, agiles Management, Zusammenarbeit und Ideenfindung. Davor war Jon Co-CEO und Mitbegründer von LeanKit, einem Pionierunternehmen für die Anwendung von Kanban in der Wissensarbeit. Davor hatte Jon eine Reihe von leitenden IT-Positionen beim Krankenhausriesen HCA und dessen Logistik-Tochter HealthTrust Purchasing Group inne. Er war mitverantwortlich für die Einführung von Lean-Agile-Methoden bei HCA.