Die meisten Unternehmer, die zum ersten Mal Software beauftragen, haben eine ähnliche Erwartung: Sie beschreiben, was Sie brauchen, übergeben den Auftrag — und ein paar Monate später erhalten Sie ein fertiges Produkt.
So funktioniert es nicht ganz.
Individuelle Software ist keine Ware, die man kauft und abholt. Sie entsteht gemeinsam — in einer Zusammenarbeit zwischen Ihnen, der das Unternehmen kennt, und dem Entwicklungsteam, das die Technologie beherrscht. Wie gut diese Zusammenarbeit läuft, hängt genauso von Ihrem Beitrag ab wie von den Fähigkeiten des Teams.
Dieser Artikel führt Sie durch jede Phase eines typischen Projekts und erklärt genau, welche Rolle Sie dabei spielen — was Sie vorbereiten sollten, worauf Sie achten müssen und wo Ihr Beitrag den größten Unterschied macht.
Vor dem Projektstart: Klären Sie das Problem
Das Wertvollste, was Sie vor Projektbeginn tun können, ist wirkliche Klarheit darüber zu gewinnen, welches Problem Sie lösen wollen — nicht welche Funktionen Sie sich wünschen, sondern was in Ihrem Unternehmen tatsächlich nicht so funktioniert wie es sollte.
Was Sie vorbereiten sollten:
- Eine Beschreibung der aktuellen Situation: wie die Dinge heute laufen, wo die Reibungspunkte liegen, was Sie das in Zeit oder Geld kostet
- Ein Bild davon, wer betroffen ist — welche Mitarbeiter, welche Kunden
- Eine grobe Vorstellung davon, wie Erfolg in sechs bis zwölf Monaten aussieht
- Rahmenbedingungen, die von Anfang an wichtig sind: Budgetrahmen, erforderliche Integrationen, regulatorische Anforderungen, Zeitdruck
Sie brauchen kein vollständiges Lastenheft. Sie brauchen genug Klarheit für ein produktives Erstgespräch. Das Entwicklungsteam hilft Ihnen, die Spezifikation zu erarbeiten — aber dafür braucht es ein Ausgangsmaterial von Ihrer Seite.
Während der Discovery: Teilen Sie auch das Unordentliche
Die Discovery-Phase ist die Phase, in der Ihr Beitrag am wichtigsten ist — und am häufigsten unterschätzt wird.
Viele Kunden versuchen, eine idealisierte Version ihres Unternehmens zu präsentieren. Bei einem Softwareprojekt ist das kontraproduktiv. Das Team muss verstehen, wie die Dinge wirklich funktionieren — einschließlich der Workarounds, Ausnahmen, inoffiziellen Prozesse und der Abläufe, die peinlich manuell sind.
Was Sie tun sollten:
- Wirklich verfügbar sein für Workshops und Gespräche — nicht einfach einen Stellvertreter schicken
- Die Menschen einbeziehen, die die Arbeit tatsächlich erledigen, nicht nur die, die sie managen
- Echte Beispiele zeigen: zeigen Sie die Tabelle, gehen Sie eine echte Bestellung durch, führen Sie den gesamten Prozess vor
- Ehrlich sein, was Sie nicht wissen — „ich bin mir nicht sicher, wie wir das in diesem Fall handhaben" ist deutlich nützlicher als eine sichere Antwort, die sich als falsch herausstellt
Je realistischer das Bild, das das Team in der Discovery erhält, desto genauer kann es gestalten und einschätzen, was es baut.
Während des Designs: Reagieren Sie schnell und sprechen Sie aus, was Sie sehen
Wenn die Discovery abgeschlossen ist, übersetzt das Team Ihre Anforderungen in konkrete Entwürfe — Bildschirmlayouts, Nutzerflüsse, Funktionslisten und technische Entscheidungen.
Das ist Ihre letzte klare Chance, das Produkt zu formen, bevor die Entwicklung beginnt. Änderungen im Design kosten fast nichts. Änderungen, wenn die Entwicklung läuft, sind erheblich teurer.
Was Sie tun sollten:
- Entwürfe zeitnah überprüfen — Verzögerungen hier verschieben den gesamten Zeitplan
- Auf den tatsächlichen Entwurf reagieren, nicht auf das, was Sie erwartet haben: spiegelt das wider, wie Ihr Team es wirklich nutzen wird?
- Auf alles hinweisen, das nicht mit der tatsächlichen Funktionsweise Ihres Unternehmens übereinstimmt
- Fragen stellen, auch wenn Sie nicht sicher sind, ob sie wichtig sind — hier ist Überkommunikation immer die richtige Wahl
- Klare Entscheidungen treffen: wenn das Team Ihnen zwei Ansätze vorstellt, geben Sie eine direkte Antwort
Stimmen Sie nichts zu, nur weil es auf dem Bildschirm vernünftig aussieht. Bitten Sie darum, dass man Sie durch die gesamte Nutzungsreise führt — so als würden Sie die Arbeit selbst täglich erledigen.
Während der Entwicklung: Bleiben Sie eingebunden, aber überarbeiten Sie nicht
Die Entwicklung ist die Phase, in der das Team den Großteil der Arbeit leistet — aber Ihre Rolle hört damit nicht auf.
Typischerweise werden Ihnen alle ein bis zwei Wochen Zwischenpräsentationen gezeigt. Das sind keine bloßen Statusupdates. Das sind Kontrollpunkte, an denen Sie Probleme frühzeitig erkennen können, solange die Behebung noch relativ günstig ist.
Was Sie tun sollten:
- Die Testumgebung wirklich nutzen — nicht nur einen Screenshot oder ein Video ansehen
- Die Szenarien testen, die für Ihr Unternehmen am wichtigsten sind: häufige Abläufe und schwierige Grenzfälle
- Fragen des Teams ohne Verzögerung beantworten — eine verspätete Antwort kann das gesamte Team tagelang blockieren
- Wenn Sie feststellen, dass sich etwas ändern muss, sagen Sie es sofort — und verstehen Sie, dass Umfangsänderungen Zeit und Budget kosten
Was Sie nicht tun sollten:
- Neue Anforderungen hinzufügen, ohne die Auswirkungen zu besprechen — jede Ergänzung verschiebt etwas anderes
- Bedenken verschweigen, um nicht schwierig zu wirken
- Davon ausgehen, dass das Team etwas herausfindet, das Sie ihm nicht mitgeteilt haben
Eine praktische Regel: Wenn Sie etwas sehen, das nicht stimmt, sagen Sie es noch am selben Tag. Nicht nächste Woche.
Während des Testens (UAT): Das ist Ihre Verantwortung
User Acceptance Testing — bei dem Sie und Ihr Team das System vor dem Go-live prüfen — ist keine Formalität. Es ist eine entscheidende Qualitätsprüfung, die nur Sie durchführen können.
Das Entwicklungsteam testet auf technische Korrektheit: Verhält sich das System wie spezifiziert? UAT testet auf fachliche Korrektheit: Funktioniert das System so, wie Ihr Unternehmen es braucht? Das sind zwei verschiedene Fragen — und nur Sie können die zweite beantworten.
Worauf Sie sich konzentrieren sollten:
- Prozesse, die Ihr Team täglich ausführen wird — diese gründlich und wiederholt testen
- Ausnahmen und Grenzfälle, von denen Sie wissen, dass sie im realen Betrieb auftreten
- Datenintegrität: wenn Sie von einem bestehenden System migrieren, prüfen Sie, ob Schlüsseldaten korrekt übertragen wurden
- Die Erfahrung für verschiedene Nutzertypen — was ein Manager sieht, kann sich erheblich von dem unterscheiden, was ein Außendienstmitarbeiter oder ein Kunde sieht
Notieren Sie alles, was nicht wie erwartet funktioniert. Kategorisieren Sie nach Schwere: was muss vor dem Go-live behoben werden, was sollte bald danach kommen, und was kann warten.
Beim Launch: Führen Sie das Change Management intern
Der Launch-Tag wirkt wie der große Moment des Entwicklungsteams. Aber das interne Change Management liegt vollständig in Ihren Händen.
Ein technisch hervorragendes System kann bei der Einführung scheitern, wenn Ihre Mitarbeiter nicht darauf vorbereitet sind. Das Entwicklungsteam kann bei Schulungsunterlagen und Dokumentation helfen — aber es kann die Gewohnheiten und Kultur Ihres Unternehmens nicht verändern. Das ist Ihre Aufgabe als Führungsperson.
Was Sie tun sollten:
- Ihr Team rechtzeitig informieren: was sich ändert, wann und warum das wichtig ist
- Interne Botschafter identifizieren — Personen, die Kollegen bei der Eingewöhnung unterstützen und positiv zur Veränderung beitragen
- Schulungen vor dem Launch durchführen, nicht am Tag des Go-live
- Mit einem vorübergehenden Produktivitätsrückgang rechnen, während sich die Mitarbeiter eingewöhnen — das ist völlig normal und lohnt sich im Voraus einzuplanen
- Klare Eskalationswege für die ersten Wochen einrichten: an wen wendet sich ein Mitarbeiter, wenn etwas nicht funktioniert oder keinen Sinn ergibt?
Je reibungsloser das interne Change Management, desto schneller erzielen Sie die Ergebnisse, die Sie sich von der Investition erhofft haben.
Nach dem Launch: Lassen Sie jemanden die Verantwortung tragen
Dies ist die Phase, die am häufigsten vernachlässigt wird — und die letztendlich bestimmt, ob Ihre Software zu einem dauerhaften Unternehmensasset wird oder anfängt zurückzufallen.
Jedes Softwaresystem braucht einen internen Eigentümer: jemanden, der für die Beziehung zum Entwicklungspartner verantwortlich ist, für das Sammeln und Priorisieren von Nutzerfeedback und dafür, dass das System dem Unternehmen dient, wenn sich das Unternehmen weiterentwickelt.
Wie das in der Praxis aussieht:
- Eine konkrete interne Person, die die Entwicklungsbeziehung managt
- Eine einfache Möglichkeit für Teammitglieder, Probleme zu melden oder Verbesserungen vorzuschlagen
- Regelmäßige Abstimmungen mit dem Entwicklungspartner — selbst quartalsweise — um zu überprüfen, was aufgetaucht ist, und die nächsten Schritte festzulegen
- Ein realistisches, laufendes Budget für Wartung und schrittweise Weiterentwicklung — keine neue Verhandlung jedes Mal, wenn etwas ansteht
Die Unternehmen, die das meiste aus ihrer Softwareinvestition herausholen, behandeln sie als lebendiges Produkt: als etwas, das mit dem Unternehmen wächst und sich anpasst — nicht als Projekt, das abgeschlossen, abgehakt und abgelegt wurde.
Denken Sie über Ihren ersten Softwareauftrag nach — oder möchten Sie den Verlauf eines laufenden Projekts verbessern? Sprechen Sie uns an — wir sagen Ihnen direkt, wie es bei uns abläuft und was wir von Ihnen brauchen.