Vom Projektportfolio zur Fähigkeitsarchitektur: Warum Ausstattung keine Transformation ist

Priorisierung & Macht

Lesezeit: 4 min


In vielen Organisationen herrscht Hochbetrieb bei der Einführung neuer Systeme, ohne dass die operative Leistungsfähigkeit spürbar steigt. Die meisten Unternehmen sind hochgradig beschäftigt: Sie führen Systeme ein, modernisieren Plattformen und verwalten umfangreiche Projektportfolios. Dennoch stagniert die operative Schlagkraft oft. Die Ursache liegt in der gewählten Steuerungseinheit: Organisationen denken Transformation in Projekten statt in Fähigkeiten.

Die Grammatik der Projektlogik

Projektlogik manifestiert sich in der Sprache. Geschäftsleitungen behandeln das CRM, das Kundenportal oder die Cloud-Migration wie physische Objekte, die man beschafft und installiert. Die Steuerung konzentriert sich auf klassische Liefermetriken:

  • Wann erfolgt der Abschluss?
  • Wer verantwortet Verzögerungen?
  • Wird das Budget eingehalten?

Transformation erscheint hier als zeitlich begrenzte Lieferleistung. Die tatsächliche operative Veränderung wird zur impliziten Nebenwirkung degradiert. Auch die Artefakte – Meilensteinpläne, Budgetkurven und Status-Ampeln – visualisieren Erfolg lediglich als punktuelles Ereignis, nicht als nachhaltigen organisationalen Zustand.

Die strukturelle Schwäche des Portfolios

Ein Projektportfolio ist als Steuerungsinstrument für Transformation ungeeignet. Projekte sind isolierte, endliche Einheiten. Transformation hingegen beschreibt einen qualitativen Reifeprozess. Während Projekte durch Start, Ende und Scope definiert sind, fehlt ihnen die Dimension der Beherrschung.

Ein Projekt stellt ein System bereit, garantiert aber nicht, dass die Organisation dadurch schneller, präziser oder anpassungsfähiger agiert. Die Projektlogik optimiert Fragmente, wo die Transformation eine grundlegende Veränderung der Wertschöpfungslogik verlangt.

Die alternative Einheit: Fähigkeit (Capability)

Die strategische Steuerung muss die Perspektive wechseln. Statt nach notwendigen Projekten zu fragen, muss die Geschäftsleitung definieren: Was muss die Organisation künftig besser können als heute?

Eine Fähigkeit (Capability) beschreibt die Kompetenz, unter realen Bedingungen wiederholbar ein spezifisches Geschäftsergebnis zu erzielen. Fähigkeiten benötigen Verben statt Nomen:

  • Schäden in weniger als zwei Stunden regulieren.
  • Netzlast in Echtzeit aussteuern.
  • Kundenbedürfnisse präzise antizipieren.
  • Risiken dynamisch bewerten.
Projekt-Logik Fähigkeits-Logik
Erfolg = Go-Live Erfolg = Beherrschung
Fokus auf Output (System) Fokus auf Wirkung (Ergebnis)
Zeitlich begrenzte Verantwortung Dauerhafte operative Verantwortung
Installation (Ausstattung) Veränderung der Wertschöpfung
Technischer Rollout Organisationaler Reifegrad

Die Übersetzungs-Falle

Ein kritischer Denkfehler unterläuft vielen Geschäftsleitungen bei der direkten Übersetzung strategischer Ziele in IT-Initiativen. Aus dem Ziel „mehr Kundenorientierung“ werden unmittelbar ein CRM-Projekt, ein Portal und eine Mobile App.

Die eigentliche Fähigkeit – Kundenbedürfnisse präzise zu verstehen und operative Entscheidungen darauf auszurichten – verschwindet hinter der Technik. Die Organisation lernt lediglich, das neue Werkzeug zu bedienen, ohne die Arbeitsweise substanziell zu verändern. Technologie fungiert hier als teurer Ersatz für organisationales Lernen.

Gegenüberstellung Projektwelt vs. Fähigkeitswelt
Abbildung 1: Systeme müssen Fähigkeiten dienen, nicht umgekehrt.

Die Folge: Hohle Modernisierung

Wer in Projekten statt in Fähigkeiten denkt, riskiert eine gefährliche Diskrepanz: Die technologische Komplexität steigt schneller als die operative Reife. Das Unternehmen betreibt moderne Plattformen nach Verhaltensmustern der „alten Welt“. Neue Systeme bilden lediglich bestehende Ineffizienzen digital ab.

Statt transformierter Leistungsfähigkeit entstehen:

  • Höhere Fixkosten und neue Abhängigkeiten.
  • Zusätzliche Governance-Ebenen.
  • Steigende Koordinationslast.

Die Organisation wird technologisch moderner, operativ jedoch nicht kompetenter.

Fazit

Transformation beginnt mit der Entscheidung, welche Fähigkeiten eine Organisation künftig beherrschen muss – nicht mit dem Aufsetzen von Projekten. Solange Unternehmen Transformation als Portfolio technischer Initiativen missverstehen, modernisieren sie lediglich ihr Inventar, aber nicht ihre Fähigkeit zur Wertschöpfung.


Zusammenhang verstehen Dieser Artikel markiert den Übergang von der reinen Beobachtung organisationaler Symptome hin zur Frage der strukturellen Steuerungslogik. Die bisherigen Beiträge haben gezeigt, wie Priorisierung, Delegation und additive Transformation operativ scheitern. Dieser Text verschiebt den Fokus auf die zugrunde liegende Einheit der Steuerung: Projekte organisieren Arbeit – Fähigkeiten organisieren Wertschöpfung.

Fokus: Priorisierung & Macht