Projektmanagement digitaler Projekte: ein Leitfaden für Kunden ohne technisches Wissen

Ein digitales Projekt, das ohne eine klare Managementstruktur beginnt, endet fast immer mit einem von drei Ergebnissen: Verzögerungen, die niemand antizipiert hatte, einem Budgetüberschuss, den niemand wirklich verstanden hat, oder einer Lieferung, die technisch funktioniert, aber das Problem nicht löst, das der Kunde im Sinn hatte. Keines dieser Ergebnisse ist unvermeidlich und keines ist ausschließlich ein technisches Problem — alle haben ihre Wurzel darin, wie das Projekt von Anfang an geführt wurde, wie Anforderungen definiert wurden, wie Fristen gesetzt wurden, wie Änderungen kommuniziert wurden und wie Entscheidungen getroffen wurden, als Situationen auftraten, die die Spezifikation nicht vorhergesehen hatte. Ein Kunde ohne technisches Wissen ist beim Management eines digitalen Projekts nicht benachteiligt, wenn er ein paar Schlüsselprinzipien versteht, die den Unterschied zwischen einem Projekt, das plangemäß geliefert wird, und einem ausmachen, das zur Quelle der Frustration für alle Beteiligten wird.

Wie man ein digitales Projekt ohne technisches Wissen managt

Ein digitales Projekt ohne technisches Wissen zu managen bedeutet nicht, alle Entscheidungen dem Entwicklungsteam zu überlassen, sondern die eigenen Verantwortlichkeiten im Prozess zu verstehen und klar zwischen Entscheidungen zu unterscheiden, die technisch sind und die das Entwicklungsteam treffen muss, und Entscheidungen, die geschäftlich sind und die der Kunde treffen muss, weil niemand sonst den Geschäftskontext gut genug versteht. Die primäre Verantwortung des Kunden in einem digitalen Projekt ist es, zu definieren, was das System für den Nutzer und das Unternehmen erreichen muss, Anforderungen zu priorisieren, wenn es mehr gibt als im verfügbaren Zeitrahmen und Budget geliefert werden kann, zeitnah Feedback zu definierten Überprüfungspunkten zu geben und Entscheidungen über Umfangsänderungen bewusst zu treffen, mit einem Verständnis ihrer Auswirkungen auf Zeitplan und Kosten. Kommunikation, die strukturiert und vorhersehbar ist, mit klar definierten Kanälen, Häufigkeit und Berichtsformat, ist einer der Schlüsselfaktoren für den Erfolg digitaler Projekte, da Unsicherheit über den Projektstatus fast immer zu einer Eskalation führt, die mehr Zeit in Anspruch nimmt als die regelmäßige Berichterstattung, die diese Unsicherheit verhindert hätte. Die Dokumentation von Entscheidungen, einschließlich dessen, was vereinbart wurde, wer die Entscheidung getroffen hat und wann, ist keine bürokratische Formalität, sondern ein Schutz für beide Seiten, wenn die Frage aufkommt, warum etwas auf eine bestimmte Weise gemacht wurde oder wer eine bestimmte Änderung genehmigt hat. Ein Entwicklungsteam, das mit einem Kunden ohne technisches Wissen arbeitet, hat die Verantwortung, technische Entscheidungen und ihre geschäftlichen Implikationen verständlich zu kommunizieren, anstatt Komplexität hinter technischem Fachjargon zu verbergen, der dem Kunden nicht die Informationen gibt, die er für Entscheidungen benötigt.

Waterfall, Agile und Scrum: was es für Sie als Kunden bedeutet

Waterfall ist eine Methodik, bei der ein Projekt sequenzielle Phasen durchläuft, von der Anforderungsanalyse und dem Design über die Entwicklung und das Testen bis zur Lieferung, wobei jede Phase abgeschlossen sein muss, bevor die nächste beginnt, und Änderungen der Anforderungen nach Abschluss einer Phase formelle Änderungsanfragen generieren, die Zeitplan und Budget beeinflussen. Für den Kunden bedeutet Waterfall eine größere Vorhersehbarkeit zu Beginn des Projekts, da Anforderungen im Voraus detailliert definiert werden, aber auch weniger Flexibilität während des Projekts, da jede Änderung formelle Zeit- und Finanzkosten hat, und ein Risiko, dass die gelieferte Lösung am Ende des Projekts weniger relevant erscheint als zu dem Zeitpunkt, als die Anforderungen definiert wurden, da sich der Geschäftskontext inzwischen verändert haben kann. Agile ist eine Reihe von Prinzipien, die iterative Entwicklung, kontinuierliche Wertlieferung und Anpassung der Anforderungen auf Basis von Feedback betont, anstatt einem zu Beginn definierten festen Plan zu folgen, was für den Kunden mehr Flexibilität und frühere Sichtbarkeit von Ergebnissen bedeutet, aber auch ein aktiveres Engagement des Kunden während des gesamten Projekts erfordert, da Prioritäten und Anforderungen regelmäßig überprüft werden. Scrum ist das am häufigsten verwendete Agile-Framework, das ein Projekt in Sprints organisiert, kurze Entwicklungszyklen, die typischerweise zwei bis vier Wochen dauern, an deren Ende das Team ein funktionales Produktinkrement liefert, das der Kunde überprüfen und bewerten kann, wobei die Prioritäten für den nächsten Sprint auf Basis dieser Bewertung und der Veränderungen im Geschäftskontext definiert werden. Für den Kunden ohne technisches Wissen ist es am wichtigsten zu verstehen, dass Methodik kein Selbstzweck ist, sondern ein Werkzeug, das zur Natur des Projekts, dem Team und den Kapazitäten des Kunden für Engagement passen muss, da Scrum, das einen aktiven Product Owner auf Kundenseite erfordert, nicht gut funktionieren wird, wenn der Kunde nicht die Zeit oder Kapazität für diese Rolle hat.

Wie man realistische Fristen für die Entwicklung einer Website oder Anwendung setzt

Unrealistische Fristen sind eine der häufigsten Ursachen für das Scheitern digitaler Projekte und entstehen fast immer aus einem von drei Gründen: Der Kunde hat eine Frist ohne Rücksprache mit dem Entwicklungsteam gesetzt, das Entwicklungsteam hat einer Frist zugestimmt, von der es wusste, dass sie zu eng war, um das Projekt zu gewinnen, oder beide Seiten haben bekannte Risiken ignoriert und angenommen, dass das Projekt reibungslos verlaufen würde. Eine realistische Frist für die Entwicklung einer Website oder Anwendung kann nicht ohne Spezifikation definiert werden, da die Frist eine Funktion des Umfangs ist, und ein nicht definierter Umfang kann nicht realistisch geschätzt werden, was bedeutet, dass jede Frist, die vor Abschluss der Spezifikation vereinbart wird, im Wesentlichen eine Schätzung ist, die mehr oder weniger fundiert sein kann, aber nie wirklich zuverlässig ist. Faktoren, die Projekte systematisch verlängern, aber selten in der initialen Schätzung berücksichtigt werden, umfassen die Zeit für Feedback und Genehmigungen auf Kundenseite, Integrationen mit externen Systemen, die von der Verfügbarkeit und Dokumentation dritter Parteien abhängen, Design-Iterationen, die entstehen, wenn der Kunde das implementierte Design in einem Kontext sieht, der sich von statischen Mockups unterscheidet, Tests und Fehlerbehebungen, die schwerer zu schätzen sind als die Feature-Entwicklung, und das Deployment und die Konfiguration der Produktionsumgebung, die oft Probleme aufdeckt, die in der Entwicklungsumgebung nicht sichtbar waren. Ein Puffer für Unvorhergesehenes von zwanzig bis dreißig Prozent der geschätzten Projektdauer ist kein Pessimismus, sondern eine realistische Anerkennung der Tatsache, dass jedes Projekt etwas aufdeckt, das die Spezifikation nicht vorhergesehen hat, und ein Entwicklungsteam, das diesen Puffer nicht einschließt, lügt entweder den Kunden oder sich selbst an.

Wie man Scope Creep bei digitalen Projekten reduziert

Scope Creep, die schrittweise Ausweitung des Projektumfangs über die ursprünglich vereinbarten Grenzen hinaus, ist eine der häufigsten Ursachen für Frist- und Budgetüberschreitungen und tritt besonders häufig bei Projekten auf, bei denen zu Beginn keine präzise Spezifikation vorlag oder kein formeller Prozess für das Änderungsmanagement etabliert wurde. Jede Umfangsänderung, ob groß oder klein, hat Kosten, die nicht nur in der Zeit für die Implementierung liegen, sondern auch in der Zeit für Analyse, Planung, Tests und Integration mit dem Rest des Systems, und die Anhäufung mehrerer kleiner Änderungen, die einzeln trivial erschienen, kann zu Wochen zusätzlicher Entwicklung führen, die weder geplant noch budgetiert waren. Ein formeller Change-Request-Prozess, der erfordert, dass jede Umfangsänderung dokumentiert, geschätzt und vom Kunden mit explizitem Verständnis der Auswirkungen auf Zeitplan und Kosten genehmigt wird, ist kein bürokratisches Hindernis, sondern ein Mechanismus, der beide Seiten schützt, da er dem Entwicklungsteam eine Grundlage für die Neuplanung gibt und dem Kunden Sichtbarkeit darüber gibt, wofür er zahlt und was jede Änderung tatsächlich kostet. Eine klare Definition dessen, was im Umfang ist, in der Spezifikation, die explizit auch angibt, was nicht im Umfang ist, ist das stärkste Werkzeug zur Verhinderung von Scope Creep, da es den Interpretationsspielraum eliminiert, der die Quelle der meisten Missverständnisse darüber ist, ob eine bestimmte Funktionalität vereinbart wurde oder nicht. Die Priorisierung von Anforderungen im Backlog, die klar zwischen Must-have, Nice-to-have und Won't-have in dieser Version unterscheidet, hilft dem Kunden, eine bewusste Entscheidung darüber zu treffen, was er in der ersten Version des Systems haben möchte, anstatt jede Idee, die im Laufe des Projekts auftaucht, als etwas zu behandeln, das in der endgültigen Lieferung sein muss.

Was ein MVP ist und warum Sie damit beginnen sollten

MVP, Minimum Viable Product, ist eines der Konzepte, das in Gesprächen über digitale Projekte am häufigsten erwähnt, aber selten präzise definiert wird, was zu zwei entgegengesetzten Fehlern führt: Kunden, die einen MVP als fertiges, aber mageres Produkt verstehen, das für den Markt nicht gut genug ist, und Entwicklungsteams, die MVP als Rechtfertigung für die Lieferung eines unfertigen Systems verwenden, das in der Produktion nicht funktionieren kann. Ein echter MVP ist der kleinste Satz von Funktionalitäten, der ein echtes Problem für echte Nutzer auf eine Weise löst, die gut genug ist, damit diese Nutzer das System verwenden wollen, dem Team Feedback darüber gibt, was funktioniert und was nicht, und die Schlüsselannahmen validiert oder widerlegt, von denen der Rest der Entwicklung abhängt. Der Wert des MVP-Ansatzes liegt nicht darin, dass er billiger ist als die Entwicklung eines vollständigen Systems, obwohl er es oft ist, sondern darin, dass er Lernen aus der tatsächlichen Nutzung ermöglicht, bevor Ressourcen in die Entwicklung von Funktionalitäten investiert werden, die möglicherweise nicht so wertvoll sind, wie sie in der Planungsphase erschienen. Ein Unternehmen, das einen Web Shop mit einem minimalen Satz von Kategorien, ohne komplexe Suche, ohne Treueprogramm und ohne erweiterte Filterung, aber mit einem zuverlässigen Bestell- und Lieferprozess startet, kann lernen, welche Produkte sich verkaufen, welche Nutzer kaufen und welche Schritte im Bestellprozess Reibung erzeugen, und diese Informationen formen direkt Entscheidungen über nachfolgende Entwicklungsphasen, die auf Daten und nicht auf Annahmen basieren. Prolink hilft Kunden bei der Projektplanung aktiv dabei, einen MVP zu definieren, der klein genug ist, um schnell geliefert zu werden, und groß genug, um nützlich zu sein, da diese Balance bestimmt, wie schnell die Investition beginnt, eine Rendite zu generieren.

Wie Prolink digitale Projekte leitet

Prolink wendet einen strukturierten Ansatz im Projektmanagement an, der eine klare Spezifikation und einen vereinbarten Umfang zu Beginn des Projekts mit der Flexibilität der iterativen Entwicklung im Verlauf kombiniert und dem Kunden kontinuierliche Sichtbarkeit in den Fortschritt gibt, ohne die technischen Details der Implementierung verstehen zu müssen. Jedes Projekt beginnt mit einer Definitionsphase, in der Anforderungen geklärt, priorisiert und in eine Spezifikation übersetzt werden, die präzise genug für eine realistische Schätzung von Zeitplänen und Kosten ist, und der Kunde hat jederzeit Zugang zur Entwicklungsumgebung, wo er sehen kann, was erledigt wurde, und Feedback geben kann. Umfangsänderungen, die im Laufe des Projekts entstehen, und sie entstehen immer, werden durch einen dokumentierten Prozess behandelt, der dem Kunden klare Informationen darüber gibt, was jede Änderung für Zeitplan und Kosten bedeutet, ohne Überraschungen bei der endgültigen Lieferung. Kunden, die ein digitales Projekt planen und ein Gespräch darüber führen möchten, wie sie das Projektmanagement strukturieren, realistische Fristen setzen und die häufigsten Fehler vermeiden können, sind eingeladen, das Prolink-Team für eine kostenlose Beratung zu kontaktieren, in der der Ansatz definiert wird, der dem konkreten Projekt und den Kapazitäten des Kunden für Engagement entspricht.