Häufige Fragen

Es gibt selten einen einzelnen Moment, in dem ein Projekt kippt. In der Regel zeigen sich mehrere Warnsignale gleichzeitig: Der Zeitplan wird wiederholt angepasst, ohne dass die Ursachen adressiert werden. Entscheidungen werden aufgeschoben oder in immer größere Gremien verlagert. Die Zahl der offenen Change Requests wächst schneller als die Abarbeitungsrate. Zwischen Fachabteilung und Dienstleister entsteht ein Klima des gegenseitigen Misstrauens. Und Meetings finden zwar regelmäßig statt, enden aber ohne konkrete Ergebnisse oder Entscheidungen.

Die direkten Kosten sind schnell berechnet: Personalkosten des Projektteams, laufende Lizenz- und Infrastrukturgebühren, gebundene Beraterverträge. Dazu kommen die indirekten Kosten: verzögerte Markteintritte, entgangene Effizienzgewinne, Opportunitätskosten durch blockierte Ressourcen. In der Praxis übersteigen die Kosten eines einzigen Monats Stillstand die Kosten einer externen Stabilisierung bei weitem.

Ein Projekt zu stoppen ist keine Niederlage, sondern eine wirtschaftliche Entscheidung. Die Frage lautet nicht „Wie viel haben wir schon investiert?“, sondern „Ist das Projektziel mit vertretbarem Aufwand noch erreichbar?“. Ein Stopp ist dann richtig, wenn sich die Geschäftsanforderungen grundlegend verändert haben, die Technologie nicht passt, oder die organisatorischen Voraussetzungen fehlen.

Der häufigste Fehler ist, mit der Tool-Auswahl zu beginnen. Vor jeder Produktentscheidung braucht es Klarheit über drei Dinge: Was ist das Geschäftsziel, das die IT-Veränderung antreibt? Wie sieht die aktuelle IT-Landschaft aus, und welche Abhängigkeiten bestehen? Und wie hoch ist die Veränderungsfähigkeit der Organisation — nicht technisch, sondern kulturell und organisatorisch? Erst wenn diese Fragen beantwortet sind, lassen sich sinnvolle Anforderungen formulieren, Anbieter bewerten und eine realistische Zeitplanung aufstellen.

Eine ERP-Ausschreibung ist keine Feature-Liste. Die häufigsten Probleme entstehen nicht durch die falschen Funktionen, sondern durch unklare Abnahmekriterien, fehlende Change-Request-Verfahren und Verträge, die keinen realistischen Umgang mit Scope-Änderungen vorsehen. Entscheidend ist, dass die Ausschreibung Ihre tatsächlichen Geschäftsprozesse abbildet, nicht eine idealisierte Version davon.

Die Produktdemo ist der am wenigsten aussagekräftige Teil einer Anbieterbewertung. Relevanter sind: Referenzprojekte in Ihrer Branche und Unternehmensgröße. Die tatsächliche Implementierungsmethodik, nicht die aus dem Vertriebsdeck. Die Teamzusammensetzung, die für Ihr Projekt vorgesehen ist. Das Lizenz- und Kostenmodell über den gesamten Lebenszyklus. Und die vertragliche Flexibilität bei Scope-Änderungen.

Agilität ist kein Prozess, den man ausrollt. Sie ist eine Arbeitsweise, die zur Organisation passen muss. Der häufigste Fehler ist, ein Framework einzuführen, ohne die Voraussetzungen zu schaffen: Entscheidungsbefugnisse in den Teams, kurze Feedbackzyklen zum Kunden, und eine Führungskultur, die Selbstorganisation tatsächlich zulässt. Deshalb empfehlen wir, mit einem überschaubaren Pilotprojekt zu starten.

Das hängt von der Organisationsgröße, der Art der Arbeit und dem Reifegrad ab. Scrum eignet sich für Teams, die in festen Zyklen an einem Produkt arbeiten. Kanban ist die bessere Wahl bei weniger planbarer Arbeit. SAFe kommt ins Spiel, wenn mehrere Teams an einem gemeinsamen Programm arbeiten. In der Praxis ist es oft eine Kombination.

Ein agiler Festpreis kombiniert die Planungssicherheit eines Festpreisvertrags mit der Flexibilität agiler Entwicklung. Der Gesamtrahmen — Budget, Zeitraum, Teamgröße — steht fest. Innerhalb dieses Rahmens kann der Scope priorisiert und angepasst werden. Der agile Festpreis ist besonders sinnvoll bei Projekten mit klarem Ziel, aber noch nicht vollständig definiertem Lösungsweg.

Pragmatisch und in kleinen Schritten. Der häufigste Fehler bei OKR-Einführungen ist, sofort die gesamte Organisation einzubeziehen. Besser: Mit einem einzelnen Team starten, einen ersten Zyklus von drei Monaten durchlaufen und aus den Erfahrungen lernen. Die ersten OKRs werden nicht perfekt sein — und das ist in Ordnung.

Zu viele Objectives gleichzeitig — wenn alles Priorität hat, hat nichts Priorität. Key Results, die Aktivitäten beschreiben statt messbare Ergebnisse. Fehlende regelmäßige Check-ins. Und der Versuch, OKRs mit bestehenden Zielvereinbarungen oder Bonus-Systemen zu verknüpfen — das erzeugt den falschen Anreiz.

Nicht zwingend. Für den Einstieg reicht eine einfache Tabelle oder ein Confluence-Board. Wichtiger als das Tool ist der Prozess. Wenn die Organisation wächst oder mehrere Teams mit OKRs arbeiten, stößt Excel allerdings an Grenzen. Für diesen Punkt haben wir das OCENOX OKR Tool entwickelt — kostenlos, webbasiert, gehostet in der EU.