Bleibt vom IT-Projekt ein besserer Dienst übrig?

Ein IT-Projekt kann sauber geplant, pünktlich berichtet und trotzdem am falschen Ziel vorbeilaufen. Für den Betrieb zählt am Ende nicht die Projektaktivität, sondern der bessere Dienst.

IT-Projekte starten oft mit einem überzeugenden Anlass: ein Tool wird alt, ein Fachbereich verlangt eine Funktion, ein Audit fordert Nachweise oder ein Vorstand erwartet Automatisierung. Diese Gründe können berechtigt sein. Sie reichen aber nicht aus, um Priorität dauerhaft zu rechtfertigen. Entscheidend ist die Frage, welcher konkrete IT-Dienst dadurch stabiler, schneller, sicherer oder für Nutzer verständlicher wird.

Projektfortschritt ist noch kein Servicenutzen

Ein Ampelbericht kann grün sein, obwohl der Nutzen im Betrieb unscharf bleibt. Meilensteine wurden erreicht, Workshops fanden statt, Anforderungen sind dokumentiert und das Budget läuft im Rahmen. Trotzdem kann offen bleiben, ob der Service Desk weniger Rückfragen bekommt, ob eine kritische Anwendung robuster wird oder ob ein Fachbereich tatsächlich schneller arbeiten kann.

Genau hier entsteht die typische Portfolio-Falle. Projekte werden nach Aufwand, Sichtbarkeit oder politischer Dringlichkeit gesteuert, während die Verbindung zum späteren Service schwach bleibt. Für ITSM-Generalisten ist diese Verbindung wichtig, weil sie die operative Wirklichkeit kennen. Ein Dienst ist nicht besser, weil ein Projekt abgeschlossen wurde. Er ist besser, wenn Nutzer weniger Reibung spüren, Störungen seltener eskalieren, Verantwortlichkeiten klarer werden oder Risiken kontrollierbarer sind.

Jedes Projekt braucht einen betroffenen Dienst

Eine einfache Portfolio-Frage hilft vor jeder Freigabe: Welcher Dienst verändert sich durch dieses Projekt sichtbar? Wenn die Antwort nur ein Systemname, ein internes Arbeitspaket oder eine allgemeine Modernisierung ist, fehlt der Bezug zum Service. Besser ist eine Formulierung wie: Der Onboarding-Dienst wird schneller, der Bestellprozess wird nachvollziehbarer, der Kundenservice bekommt verlässlichere Statusdaten oder der Wiederanlauf nach Ausfall wird messbarer.

Diese Sprache zwingt zur Konkretisierung. Sie zeigt auch, ob ein Projekt eigentlich nur technische Schuld reduziert, eine Compliance-Lücke schließt oder einen echten Nutzermehrwert liefert. Alle drei Gründe können richtig sein. Sie sollten aber nicht gleich aussehen. Ein Sicherheitsprojekt braucht andere Erfolgskriterien als eine Servicekatalog-Verbesserung, ein Automatisierungsprojekt andere Kriterien als eine Lizenzbereinigung.

Der Nutzen gehört in den laufenden Steuerkreis

Die Association for Project Management beschreibt Portfolio-Management als koordinierte Steuerung mehrerer Projekte und Programme, damit sie strategische Ziele unterstützen. Im ITSM-Alltag muss diese Ausrichtung in den Betrieb übersetzt werden. Das heißt: Nicht nur Projektkosten, Termine und Risiken gehören in die Steuerung, sondern auch der erwartete Effekt auf konkrete Dienste.

Atlassian beschreibt IT Service Management als Ansatz, der IT-Leistungen über ihren gesamten Lebenszyklus plant, liefert und unterstützt. Daraus folgt eine praktische Konsequenz für Portfolios: Ein Projekt sollte nicht nur ein Vorhaben sein, sondern eine geplante Veränderung an einem Service. Wer das ernst nimmt, fragt während der Umsetzung regelmäßig, ob die ursprüngliche Nutzenerwartung noch gilt.

Schwache Nutzenbilder werden früh sichtbar

Ein Projekt ohne klares Nutzenbild erkennt man an bestimmten Sätzen. Es soll die Plattform zukunftsfähig machen, Synergien heben, Transparenz schaffen oder Prozesse optimieren. Solche Formulierungen können einen wahren Kern haben, bleiben aber zu weich für Priorisierung. Sie sagen nicht, wer nachher weniger Aufwand hat, welches Risiko sinkt oder welche Entscheidung besser wird.

Besser ist ein kleiner Nutzennachweis in drei Teilen. Erstens: betroffener Dienst. Zweitens: konkrete Verbesserung. Drittens: messbarer oder beobachtbarer Effekt. Aus Wir modernisieren das Ticketsystem wird dann zum Beispiel: Der Service Desk findet Lösungswissen schneller, damit wiederkehrende Anfragen weniger Rückrufe erzeugen. Aus Wir bauen eine Integrationsplattform wird: Statusdaten aus Fachsystemen kommen verlässlicher in den Kundenservice, damit Rückfragen nicht zwischen Teams pendeln.

Stoppen kann professioneller sein als Weiterlaufen

Portfolioarbeit wird oft mit Startentscheidungen verbunden. Die wichtigere Disziplin ist manchmal die Unterbrechung. Wenn ein Projekt keinen klaren Dienst mehr verbessert, gehört es zurück in die Priorisierung. Vielleicht muss es gekürzt, neu geschnitten, mit einem anderen Vorhaben verbunden oder ganz gestoppt werden. Das ist kein Scheitern, sondern Schutz vor Beschäftigung ohne Wirkung.

COBIT betont, dass Governance und Management der Unternehmens-IT auf Wert, Risiko und Ressourcen ausgerichtet sein müssen. Für ein IT-Projekt heißt das: Wert ist nicht die Menge der gelieferten Arbeitspakete. Wert entsteht, wenn ein Dienst für Nutzer, Betrieb oder Entscheidungsträger besser funktioniert. Risiko entsteht, wenn Teams weiter investieren, obwohl dieser Zusammenhang nicht mehr belegbar ist.

Die Kontrollfrage für das nächste Portfolio-Meeting

Vor dem nächsten Portfolio-Meeting reicht eine harte, aber faire Frage: Welchen Dienst würden Nutzer, Service Desk oder Betrieb nach diesem Projekt konkret anders erleben? Wenn darauf keine einfache Antwort möglich ist, braucht das Projekt keine schönere Präsentation, sondern eine neue Nutzenklärung.

Gute IT-Strategie zeigt sich nicht daran, dass möglichst viele Projekte gleichzeitig laufen. Sie zeigt sich daran, dass Projekte sichtbare Verbesserungen an echten Diensten erzeugen. Der Unterschied liegt in der Disziplin, jedes Vorhaben an Service-Nutzen, Betriebswirkung und Entscheidungsqualität zurückzubinden.

Quellen und Einordnung Atlassian zu IT Service Management, AXELOS zu ITIL Service Management, ISACA COBIT, APM zu Portfolio Management. Stand der Quellenprüfung: 08.07.2026. Bildquelle: Pexels, Foto-ID 3184291.