PP: Warum dein Software-Update wieder scheitert und was du dagegen tun kannst

„Wir machen das Update nächste Woche. Oder übernächste. Irgendwann.“

Wenn du das über dein nächstes Software-Update denkst, bist du nicht allein. Die meisten kleinen Unternehmen planen ihre Softwareprojekte nicht. Sie improvisieren. Und dann wundern sie sich, warum alles schiefgeht.

Ein Unternehmen mit 8 Mitarbeitern beabsichtigt, eine neue Warenwirtschaft einzuführen. „Wir machen das mal schnell an einem Wochenende.“ Das Wochenende wird zu zwei Wochen. Die Hälfte des Teams kann nicht arbeiten. Kunden sind verärgert. Und am Ende läuft die alte Software parallel zur neuen, weil keiner weiß, ob alles funktioniert.

Das ist nicht „nur ein wenig chaotisch“. Das ist teuer. Und es ist vermeidbar.

Die Lösung? Wieder ein Begriff aus dem CMMI-Modell, der trockener klingt, als er ist: Projektplanung. Klingt nach Gantt-Diagrammen und Wochenreports? Ist es nicht. Es bedeutet nur: vorher wissen, was passieren soll! Wer macht was? Und bis wann?

Projektplanung (PP) = ein Prozessgebiet aus dem CMMI-Modell. Der Zweck der Projektplanung (PP) ist es, einen Plan zu etablieren und aktuell zu halten, der die Projektaktivitäten definiert.

Auf Deutsch: vorher wissen, was passiert, und nicht improvisieren.

Und hier ist der Twist: Du brauchst keinen 50-seitigen Projektplan. Du brauchst nur fünf Antworten, bevor du anfängst.

Warum das meiste Software-Chaos vor dem ersten Klick passiert

Du denkst vielleicht: „Wir sind doch nur 8 Leute. Wir brauchen keinen Plan. Wir reden darüber und fertig.“

Falsch gedacht. Gerade weil du klein bist, kannst du dir keine Ausfälle leisten. Wenn von 8 Mitarbeitern 3 zwei Tage lang nicht arbeiten können, weil die neue Software streikt, fehlen dir 37,5 Prozent deiner Kapazität. Das ist kein kleines Problem. Das ist ein Notfall.

Szenario 1: „Wir machen das an einem Wochenende“

Ein Produktionsbetrieb mit 10 Mitarbeitern. Neue CAD-Software soll eingeführt werden. Der Chef: „Wir machen das an einem Wochenende. Montag läuft alles.“

Freitag um 16 Uhr fängt der „IT-Kollege“ an. Um 20 Uhr merkt er: Die alten Dateien können nicht geöffnet werden. Um 22 Uhr: Das Backup funktioniert nicht wie erwartet. Samstag um 2 Uhr nachts: Panik.

Montagmorgen arbeiten 4 von 10 Mitarbeitern nicht. Die anderen improvisieren mit der alten Freeware-Version. 2 Tage Stillstand. 6.400 Euro verbrannt. Und du in der Rolle des Chefs fragst: „Warum hat das nicht geklappt?“

Weil vorher niemand gefragt hat: Was passiert, wenn das Backup nicht funktioniert? Was ist Plan B? Wer ruft wen an?

Szenario 2: „Peter macht das schon“

Ein Dienstleister mit 5 Mitarbeitern. Neues CRM-System. Einer soll es „mal einrichten“. Zwischendurch hat er noch normale Projekte. Also macht er das CRM nebenher. Nach 3 Monaten ist es halb konfiguriert. Niemand nutzt es, weil es nicht zu den Prozessen passt.

3 Monate verschwendet. Nicht weil Peter faul war. Weil vorher niemand definiert hat: Was soll das CRM eigentlich können? Bis wann? Und wer testet, ob es passt?

Szenario 3: „Alle sind dabei und keiner weiß, was er tut“

Ein Unternehmen in der Logistik mit 7 Mitarbeitern. Neue Lagerverwaltung. Alle sollen mitmachen. Aber: Wer schult wen? Wer ist für die Datenmigration zuständig? Wer testet, ob die Schnittstelle zum Versand funktioniert?

Ergebnis: 3 Mitarbeiter machen dasselbe. 2 wichtige Aufgaben bleiben liegen. Nach 4 Wochen läuft die neue Software, aber nur mit 60 % der Funktionen. Die restlichen 40 % werden „nachgereicht“. Nach 6 Monaten ist weiterhin nicht alles da.

Die fünf Antworten, die vorher feststehen müssen

Schätzung der Planungsparameter, interne und externe Zusagen und die Entwicklung des Plans für die Durchführung des Projekts.

Das klingt nach akademischem Geschwafel. Ist es nicht. Es sind fünf einfache Fragen, die du vor jedem Softwareprojekt klärst:

Was genau wollen wir erreichen?
Nicht „neues CRM einführen“. Sondern: „Wir wollen Angebote in unter 10 Minuten erstellen können, statt wie jetzt in 45 Minuten.“ Konkret. Messbar. Nicht wolkig.

Wer macht was?
Nicht „alle helfen mit“. Sondern: Maria migriert die Kundendaten (Start: Montag, Ende: Mittwoch), Tom konfiguriert die Schnittstellen (Start: Donnerstag, Ende: Freitag) und Lisa testet mit 3 realen Angeboten (Samstag). Jeder weiß: Das ist mein Job. Das ist mein Termin.

Was brauchen wir wirklich?
Ressource heißt nicht nur Geld. Heißt: Zeit. Heißt: Wer ist währenddessen nicht für normale Arbeit verfügbar? Heißt: Brauchen wir externe Hilfe? Ein Handwerksbetrieb mit 8 Leuten kann es sich nicht leisten, dass 3 Mitarbeiter eine Woche lang nur Software einrichten. Wer macht dann die laufenden Aufträge?

Was könnte schiefgehen und was tun wir dann?
Ein Projektplan ist ein formales, freigegebenes Dokument, das genutzt wird, um die Ausführung des Projekts zu lenken und zu steuern. „Formal“ heißt nicht: 30 Seiten. Heißt: aufgeschrieben. Heißt: besprochen. Heißt: Alle wissen Bescheid. Der wichtigste Teil: Was ist, wenn das Backup nicht funktioniert? Was ist, wenn die Schnittstelle nicht läuft? Was ist, wenn der „IT-Kollege“ krank wird? Plan B ist kein Luxus. Plan B ist Überleben.

Wer gibt grünes Licht?
Zusagen zum Projektplan werden etabliert und beibehalten. Nicht „Wir fangen an und schauen mal“. Sondern: Der Chef sagt: „Ja, das ist der Plan. Das sind die Termine. Das ist das Budget. Los geht’s.“ Und wenn sich was ändert: nicht heimlich, sondern: „Wir passen den Plan an. Alle wissen Bescheid.“

Was das wirklich bringt

Ich könnte dir jetzt eine ROI-Berechnung zeigen. Mache ich aber nicht, weil du die Effekte selbst kennst.

Statt 2 Tage Stillstand: 4 Stunden geplante Downtime mit Rollback-Plan.
Statt 3 Monate halb konfiguriert: 2 Wochen geplant, getestet, freigegeben.
Statt 6 Monate nachbessern: 3 Wochen fertig, weil vorher klar war, was „fertig“ heißt.

Wie das in der Praxis aussieht

Nochmals. Ein Unternehmen mit 8 Mitarbeitern. Neue Warenwirtschaft. Vorher: „Wir machen das an einem Wochenende.“ Nachher: 3 Tage Stillstand, Kunden verärgert, Umsatz weg.

Besser: Gemeinsam simple Fragen beantworten. Aufwand: ein halber Tag.

Ziel: Angebote und Aufträge in einer Software, statt Excel und Warenwirtschaft parallel.
Wer: Externer Berater konfiguriert (2 Tage). Tom testet mit realen Daten (1 Tag). Lisa schult das Team (1 Tag).
Ressourcen: Externer Berater: 1.600 Euro. Tom und Lisa: je 2 Tage freigestellt. Rest des Teams arbeitet normal weiter.
Risiken: Was, wenn die alten Daten nicht importierbar sind? Externer Berater prüft das vorab. Was, wenn jemand krank wird? Lisa kann auch testen.
Zusage: Du in der Rolle des Chefs: „Plan ist gut. Budget ist freigegeben. Los am 15.“

Ergebnis: 4 Tage geplant. 1 Tag tatsächliche Downtime (Samstag + Sonntag). Montag lief alles. Kosten: 1.600 Euro + 4 Mann-Tage. Statt vorher: 6.400 Euro Schaden + 3 Wochen Chaos.

Du in der Rolle des Chefs, freudestrahlend: „Ich hätte nicht gedacht, dass ein halber Tag Vorab-Planung so viel bringt. Aber wir haben diesmal gezielt gearbeitet, statt zu hoffen.“

Deine ersten Schritte

Du musst keinen Projektmanager einstellen. Du musst nur vorher simple Fragen beantworten. Nimm ein Blatt Papier und beantworte diese:

1. Das Ziel aufschreiben (10 Min)
Nicht „neue Software“. Sondern: „Wir wollen X erreichen. In Zeit Y. Mit Ergebnis Z.“ Ein Satz reicht.

2. Die Rollen verteilen (15 Min)
Wer macht was? Wer ist nicht verfügbar für normale Arbeit? Wer kann vertreten, falls jemand ausfällt? Drei Namen, drei Aufgaben.

3. Die Risiken benennen (15 Min)
Was könnte schiefgehen? Was tun wir dann? Wer entscheidet? Drei Sätze reichen.

Fertig. Das ist dein Plan. Ein Blatt Papier, 40 Minuten. Und du weißt, was du tust.

Du bist nicht zu spät dran

Die Frage ist nicht, ob dein nächstes Software-Update schiefgeht. Die Frage ist: Planst du es? Oder hoffst du, dass es gutgeht?

Die gute Nachricht: Du brauchst kein Projektmanagement-Tool. Keinen teuren Berater. Keine Wochenreports.

Du brauchst nur einen halben Tag: ein Ziel, Antworten auf simple Fragen und den Entschluss, nicht mehr zu improvisieren.

Mein Ansatz als Software-Denker: Schluss mit dem Update-Chaos

Du hast jetzt gesehen, was ein einfacher Plan vorher verhindert. Aber wie kommst du von „Wir machen das mal“ zu einem klaren, schlanken Plan, und das, ohne in Bürokratie zu ertrinken?

Genau hier setzt meine Software-Effizienz-Begleitung an. Ich helfe dir, für dein nächstes Softwareprojekt einen pragmatischen Plan zu entwickeln: simple Fragen, klare Antworten, kein Overhead.

Das Ziel: Du führst Software-Updates zielgerichtet durch, und nicht mehr durch Zufall.