MVP ist nicht gleich MVP: Wenn Projekt-Kürzel zwischen Fachbereich und IT brechen

In vielen deutschen Unternehmen laufen IT-Projekte an einer unsichtbaren Schnittstelle auf: der Übergabe zwischen Fachabteilung und IT-Team. Dort werden Begriffe verwendet, die beide Seiten zu kennen glauben – und genau dort entstehen die Missverständnisse. Wer ein MVP als „fast fertiges Produkt" versteht, während das Entwicklungsteam damit eine bewusst abgespeckte Lernversion meint, wird mit dem Ergebnis kaum zufrieden sein.

Das MVP-Problem: Minimal heißt nicht beliebig

Das Kürzel MVP steht für „Minimum Viable Product" – also das kleinste funktionsfähige Produkt, mit dem eine Hypothese am Markt oder im Unternehmen geprüft werden kann. In der Praxis wird das oft umgedeutet: Die Fachabteilung erwartet ein einsatzfähiges System, die IT liefert eine Testversion mit bewusst reduziertem Funktionsumfang. Beide Seiten haben „MVP" verstanden, aber etwas völlig Verschiedenes darunter gemeint.

Teuer wird es, wenn die Erwartungshaltung nicht korrigiert wird. Der Geschäftsführer eines mittelständischen Produktionsbetriebs, der im Sprint-Review ein „fertiges" Tool erwartet, wird den Umfang als Rückschritt werten – obwohl das Team exakt nach agilem Lehrbuch gearbeitet hat. Der Unterschied lässt sich nicht durch Mehrarbeit ausgleichen, sondern nur durch klare Begrifflichkeit vor Projektbeginn.

PoC, Prototype, Pilot: Drei Dinge, die oft in einen Topf geworfen werden

Ähnlich verhält es sich beim Proof of Concept. Ein PoC beantwortet eine technische Frage: Lässt sich die Anbindung an das bestehende ERP-System realisieren? Skaliert die Schnittstelle bei 50.000 Datensätzen? Ein Prototyp hingegen zeigt, wie etwas benutzt werden könnte – er ist in der Regel weggeworfen. Ein Pilotbetrieb schließlich testet eine Lösung unter echten Bedingungen mit echten Nutzern.

Wer diese drei Begriffe synonym verwendet, riskiert, dass ein PoC als belastbare Entscheidungsvorlage verkauft wird. Das Ergebnis: Investitionsentscheidungen auf Basis eines Laborexperiments. Gerade im Compliance-Kontext – etwa bei der Dokumentation nach GoBD – kann das nachträglich problematisch werden.

Sprint und Rollout: Tempo-Vokabeln mit Falle

Auch agiles Vokabular wird häufig dekorativ übernommen. „Wir arbeiten in Sprints" bedeutet nicht automatisch, dass Ergebnisse alle zwei Wochen produktiv gehen. Ein Sprint ist eine Entwicklungsperiode, kein Liefertermin. Der Rollout schließlich – die Einführung im Produktivbetrieb – wird gern als einmaliger Termin gedacht. In der Praxis unterscheidet man aber Big Bang, gestaffelte Einführung und Pilotnutzer. Die Wahl des Verfahrens ist eine betriebswirtschaftliche Entscheidung, keine technische Fußnote.

Wie ein Mini-Glossar hilft

Die Lösung ist unspektakulär, aber wirksam: ein gemeinsames, kurzes Glossar, das beide Seiten vor Projektstart abzeichnen. Wichtig ist weniger die wissenschaftliche Präzision als die gegenseitige Verbindlichkeit. Ein praxistaugliches Format:

• MVP: Kleinste funktionsfähige Version zur Hypothesenprüfung – nicht produktionsreif, nicht vollständig.
• PoC: Technischer Machbarkeitsnachweis, wird nach der Prüfung in der Regel verworfen.
• Sprint: Feste Entwicklungsperiode mit definiertem Ziel – kein Lieferversprechen für Produktivbetrieb.
• Rollout: Schrittweise oder vollständige Einführung; Verfahren wird gesondert entschieden.
• Go-Live: Der Zeitpunkt, ab dem Nutzer produktiv arbeiten – abhängig von Schulung und Datenmigration.

Zusätzlich empfiehlt sich die Frage an beide Seiten: „Was erwarten Sie konkret am Ende dieser Phase zu sehen?" Wenn die Antworten auseinanderlaufen, ist das Glossar noch nicht fertig.

Fazit

IT-Projektchaos entsteht selten durch fehlende Technik, sondern durch ungesprochene Definitionen. Kürzel wie MVP, PoC und Rollout sind nützliche Abkürzungen – sofern sie im Projektteam dieselbe Bedeutung haben. Wer einmalig zwei Stunden in ein gemeinsames Glossar investiert, vermeidet im Schnitt mehrere Wochen Mehrarbeit und erheblichen Reibungsverlust zwischen Fachbereich und IT.