In der Geschichte von Moravio gab es Jahre, in denen Software Project Rescue Die Arbeit machte fast 50% unseres Umsatzes aus. Es gibt ein Sprichwort, dass ein schlechter Entwickler leicht Arbeit für fünf gute schaffen kann — und das gilt immer noch. Aber die Wurzel dieses Problems geht viel tiefer. Eine schlechte technologische Umsetzung ist nur ein Bruchteil der Gründe, warum so viele IT-Projekte scheitern.

Wir sind währenddessen auf viele Arten von Problemen gestoßen Wir helfen Kunden dabei, ihre IT-Projekte zu retten. Wenn Leute an Project Rescue denken, denken sie in der Regel an fehlerhafte Apps, amateurhafte Entwicklung oder einfach nur an einen insgesamt schlechten IT-Job. Aber wenn das das einzige Problem wäre, wäre es tatsächlich einfacher zu lösen.

Leider beginnen nach unserer langjährigen Erfahrung die wirklichen Probleme in der Regel lange bevor die Entwicklung überhaupt beginnt. Unserer Meinung nach ist das Hauptproblem die unzureichende Geschäftsvalidierung und die Tendenz, „All-In“ zu gehen, anstatt eine POC/MVP-Strategie zu verfolgen.

Budgetsensibler Kunde mit einer großartigen Idee

Ein typischer Kunde von Rescue ist ein kleines bis mittleres Unternehmen, oft ein Startup, dessen Geschäftstätigkeit ein IT-Projekt im Mittelpunkt steht. In der Regel privat finanziert, geht ihnen das Geld aus und sie kommen mit einem Projekt zu uns, das nicht funktioniert oder noch lange nicht abgeschlossen ist. Sie haben ihr veranschlagtes Budget durchgebrannt und haben wenig vorzuweisen.

Hätten sie mit einer Risikokapitalgesellschaft oder einem professionellen Investor zusammengearbeitet, wäre es vielleicht anders gelaufen. Anleger sind es gewohnt, Kapital zu verwalten, Budgets zu kontrollieren und Ideen vor der Skalierung zu validieren. Enthusiastische Gründer mit einigen Ersparnissen sind es oft nicht. Sie beauftragen die billigste verfügbare Agentur oder den günstigsten Freelancer und werden vollständig von ihnen abhängig.

Wir hatten einmal einen Kunden in einer schlimmen Situation — er hatte eine Menge Geld für eine schlecht funktionierende App ausgegeben und bereitete bereits einen Rechtsfall vor. Der Vertrag mit dem ursprünglichen Anbieter enthielt eine Klausel, die es dem Kunden untersagte, die Identität des Anbieters jemals an Dritte weiterzugeben. Große rote Flagge.

Wir bei Moravio sind stolz auf unsere Arbeit. Wir ermutigen unsere Kunden, unsere Partnerschaft in ihrem Marketing zu erwähnen — denn wir stehen hinter unseren Ergebnissen.

Zu diesem Zeitpunkt stehen wir vor mehreren Herausforderungen. Wir müssen die technische Seite der Dinge evaluieren, unvollständige Spezifikationen sammeln, den Stand des Projekts beurteilen und empfehlen, ob eine Reparatur, eine teilweise Beibehaltung oder ein Wiederaufbau erforderlich ist — und das alles, obwohl der Kunde bereits den größten Teil seines Budgets ausgeschöpft hat.

Trotz unserer Bemühungen, effizient und kostenbewusst zu sein, ist Project Rescue für Kunden in dieser Situation oft finanziell unerreichbar.

Zu perfekt, zu spät

Ein weiteres häufiges Problem sind Kunden, die versuchen, das gesamte Produkt auf einmal zu erstellen, pixelgenau, funktionsreich und designintensiv, bevor sie den Markt testen. Sie überspringen die Validierung und verdoppeln ihre Annahmen darüber, was der Markt erwarten könnte.

Ein Kunde gab mehrere Jahre und fast eine Million Dollar für ein Produkt aus, das noch nicht auf den Markt gebracht wurde. Trotz unserer zahlreichen Interventionen weigern sie sich stur, es zu veröffentlichen, bis es „perfekt“ ist. In der Zwischenzeit ändern sich die Marktbedingungen ständig und die Anforderungen entwickeln sich ständig weiter. Diese Kunden sind definitiv nicht budgetsensibel. Das heißt aber nicht, dass sie mit Bedacht bauen.

Es ist eine übliche Falle. Anstatt es frühzeitig zu validieren und zu wiederholen, investieren Kunden in die Entwicklung der vollständigen Vision, ohne die Nachfrage zu bestätigen. Wir setzen uns immer dafür ein POC/MVP Strategien, und glücklicherweise kommen bereits mehr Kunden mit dieser Denkweise an.

Oft kommt der Kunde nicht aus der IT-Welt und vertraut seinem Anbieter voll und ganz. Wenn sie feststellen, dass die Dinge nicht gut laufen, verlangt der Anbieter normalerweise mehr Zeit und Geld, und bis dahin ist es zu spät.

Einer der größten Vorteile der agilen Entwicklung ist die Fähigkeit, kontinuierlich zu kommunizieren und Kurskorrekturen vorzunehmen — um nachzuverfolgen, was getan wird, was es kostet und ob es planmäßig ist. Selbst bei Projekten mit festem Preis und festem Umfang ist es wichtig, Meilensteine vom ersten Tag an zu definieren und zu überwachen. Das schlimmste Szenario? Vage Anweisungen geben und sechs Monate auf eine Überraschung warten — und die ist selten eine gute.

Warum selbst große Teams etwas falsch machen

Große Unternehmen wenden sich selten an uns, um komplette Projektrettungen zu erhalten — sie verfügen über interne Ressourcen, um die Entwicklung zu überwachen und zu steuern. Ironischerweise stehen sie jedoch oft vor den gleichen Problemen.

Wir haben an vielen Unternehmensprojekten gearbeitet, in der Regel als gemeinsame Entwicklungspartner. In der Regel hatten wir keinen Einfluss auf das Projektmanagement oder die Produktverantwortung — und das sind oft genau die Bereiche, in denen etwas schief geht. Es werden Apps entwickelt, die niemand braucht, oder Budgets werden schlecht verwaltet.

In diesen Umgebungen ist der ROI oft nicht die primäre Kennzahl. Es kann einfacher sein (obwohl es nicht sein sollte), das aufgewendete Geld, die Zeit und den Aufwand abzuschreiben. Das Ergebnis? Die Teams sind frustriert und fühlen sich ungehört. Die besten Entwickler sehen die Probleme oft kommen, äußern Bedenken und werden ignoriert.

Auch hier sind technologische Mängel selten die Hauptursache für Misserfolge. Sie sind nur der letzte Nagel im Sarg.

Kunden aus dem öffentlichen Sektor — zu starr, um sie zu retten?

Projektrettung im öffentlichen Sektor gibt es praktisch nicht. Wir hatten einige Gelegenheiten, in diesem Bereich zu arbeiten, und unserer Erfahrung nach (insbesondere in der Tschechischen Republik) verbinden öffentliche Auftraggeber oft die Nachteile sowohl kleiner Startups als auch großer Unternehmen.

Auf der positiven Seite sind die Projekte selbst oft bedeutsam und haben einen echten Wert. Anforderungen und Budgets sind jedoch starr und die Prozesse sind langwierig. Wie in der Unternehmenswelt werden gescheiterte Projekte oft abgeschrieben, anstatt gerettet zu werden.

Da diese Kunden in der Regel Verträge mit festem Preis und festem Umfang benötigen und selten agil arbeiten, wird das Projektmanagement absolut wichtig — und leider oft unzureichend.

Moravio Project Rescue — Mission erfüllt

Bei Moravio haben wir im Laufe der Jahre viele Projekte erfolgreich gerettet. Ohne bestimmte Kunden zu nennen, hier sind die häufigsten Kategorien, mit denen wir arbeiten:

• Problem: Budget- und Geschäftsvalidierung

Diese Kunden haben fast ihre Ressourcen für ein Projekt aufgebraucht, das noch nicht startbereit ist, dem wichtige Funktionen fehlen oder das Tests in der realen Welt nicht überlebt. Wir prüfen ihre Optionen und versuchen, das Produkt innerhalb einer begrenzten Zeit und eines begrenzten Budgets zur Produktion zu bringen. Leider sind einige Projekte zu weit fortgeschritten. Um erfolgreich zu sein, wären mehr Ressourcen, ein strategisches Umdenken oder sogar ein anderer Zielmarkt erforderlich.

• Problem: Strategiewechsel mitten im Projekt

Der Kunde erkennt, dass seine ursprüngliche Idee nicht realisierbar ist und möchte sich ändern. Sie wollen Teile der Plattform oder Codebasis retten. Wenn das früh genug passiert, stehen die Chancen auf eine erfolgreiche Rettung gut.

• Problem: Schlechtes Projektmanagement und zu hohe Ausgaben

Der Product Owner wird abtrünnig, fügt unendlich viele Funktionen hinzu und weicht vom MVP ab. Der Projektmanager versäumt es, Meilensteine durchzusetzen. Schätzungen sind ungenau, Zeitpläne verstreichen und niemand greift ein. Das ist typisch für große Unternehmen. Oft hilft eine Eskalation — durch den Austausch des Anbieters oder der Projektleitung kann der Prozess neu gestartet werden.

• Problem: Die Technik war das Problem

Manchmal die Grundursache ist schlechte IT. Eine schlechte Lösungsarchitektur oder mangelnde Skalierbarkeit werden erst offensichtlich, wenn es zu spät ist. Kunden ohne technische Kenntnisse können dies oft erst erkennen, wenn das System implodiert. Wir haben Fälle gesehen, in denen der ursprüngliche Anbieter zugab, dass er überfordert war, und um Hilfe bat.

Zusammenfassung und was als Nächstes zu lesen ist

Projektrettungsarbeiten sind in der IT-Welt üblicher, als die meisten Menschen denken — und bei Moravio machten sie im Laufe der Jahre einen erheblichen Teil unseres Geschäfts aus. Viele gehen zwar davon aus, dass gescheiterte Projekte auf eine schlechte technische Ausführung zurückzuführen sind, aber unsere Erfahrung zeigt, dass die wahren Probleme in der Regel viel früher beginnen: mangelnde Geschäftsvalidierung, unrealistische Budgets, Perfektionismus und schlechtes Projektmanagement.

Startups geraten oft in Schwierigkeiten, wenn sie ihr gesamtes Budget für eine ungetestete Idee ausgeben, während größere Unternehmen unter ineffizienter Führung und einer Diskrepanz zwischen Entwicklungs- und Geschäftszielen leiden. Im öffentlichen Sektor lassen starre Prozesse und Verträge mit festem Umfang kaum Spielraum für Kurskorrekturen.

Bei Moravio haben wir bei der Rettung von Projekten in all diesen Szenarien geholfen — von strategischen Wendepunkten und technischen Ausfällen bis hin zu schlecht verwalteten Entwicklungsprozessen. Der Schlüssel liegt in frühzeitiger Erkennung, realistischen Zielen und kontinuierlicher Kommunikation. In unserem nächsten Artikel werden wir uns mit den roten Fahnen befassen, die signalisieren, dass ein Projekt auf Schwierigkeiten stoßen könnte.

—

Möchten Sie die ersten Anzeichen eines Projekts erfahren, das gerettet werden muss? Möchten Sie wissen, wie die Statistiken aussehen und wie viele Projekte aus den oben genannten Gründen scheitern? Was sind die Erfahrungen auf dem Weltmarkt, was sind die Alarmglocken und was ist die übliche Strategie für die Rettung von Projekten? Lesen Project Rescue — Warnsignale, Warnzeichen und Strategien zur Schadensbegrenzung