Warum Digitalprojekte scheitern: fast nie an der Technik

Die Technik ist fast nie der Grund

Ein Projekt, das ich begleitet habe, stand elf Tage still. Kein Bug, keine Schnittstelle, kein Server. Es stand still, weil eine Designfreigabe fehlte und niemand im Projekt sagen konnte, wer sie geben darf.

Die Person, die wir gefragt hatten, wollte nicht ohne die Marketingleitung entscheiden. Die Marketingleitung wollte nicht ohne die Geschäftsführung. Die Geschäftsführung wusste nicht, dass sie gefragt war. Alle drei waren guten Willens, alle drei haben schnell geantwortet, und trotzdem lagen elf Tage dazwischen.

Das ist kein Einzelfall und kein Kundenproblem. Es ist der Normalfall. Digitalprojekte scheitern selten an der Technik. Sie scheitern daran, dass mit den falschen Leuten gesprochen wurde, dass das Konzept nicht getragen hat und dass am Ende niemand entscheiden durfte.

Was in den Zahlen steht

Das Project Management Institute hat für den Pulse of the Profession 2018 5.402 Projektverantwortliche gefragt, woran ihre Projekte der vergangenen zwölf Monate gescheitert sind. Mehrfachnennung, bis zu drei Angaben pro Person.

Ganz oben steht der Wechsel der Prioritäten in der Organisation mit 39 Prozent. Danach unzureichende Vision oder Zielsetzung mit 37 Prozent und ungenaue Kostenschätzung mit 35 Prozent. Weiter unten folgen geänderte Projektziele, unzureichende Kommunikation und schlechtes Change Management, alle im Bereich um die 28 Prozent.

In der gesamten Liste steht keine einzige technische Ursache. Technologieversagen kommt nicht vor, Integrationsprobleme auch nicht, Performance ebenso wenig. Was dort steht, sind Ziele, Prioritäten, Kommunikation und Zuständigkeiten.

Die Standish Group, die seit 1994 den CHAOS Report herausgibt, benennt die Wurzel des Problems mit zwei Wörtern: „decision latency“. Nicht falsch entschieden. Zu spät entschieden.

McKinsey hat gemeinsam mit der Universität Oxford über 5.400 IT-Projekte ausgewertet. 45 Prozent überschreiten das Budget, 56 Prozent liefern weniger Wert als geplant. Rund 40 Prozent der Kostenüberschreitungen führt die Studie auf Team-, Anreiz- und Projektmanagement-Praxis zurück, also auf Faktoren ohne technische Komponente.

Für den deutschsprachigen Raum gibt es dieselbe Beobachtung in klein. Die GPM Deutsche Gesellschaft für Projektmanagement hat 151 Projektverantwortliche im deutschsprachigen Raum nach Misserfolgsfaktoren gefragt. Am höchsten bewertet wurde, dass Rollen und Schnittstellen zwischen der Stammorganisation und den projektgebundenen Teilen nicht klar definiert sind. Nicht die Werkzeuge. Nicht die Methode. Die Frage, wer wofür zuständig ist.

Ich habe vor ein paar Jahren aufgeschrieben, warum ein gutes Konzept am Anfang so viel wert ist. Die Daten sagen dasselbe, nur mit größerem N.

Wann es doch die Technik ist

Es kommt vor. Eine Schnittstelle zu einem ERP, die anders funktioniert als dokumentiert. Ein Altsystem, aus dem sich Daten nur in Teilen exportieren lassen. Eine Zahlungsart, die im Zielmarkt anders zertifiziert werden muss als angenommen. Das sind echte technische Verzögerungen, und wir hatten sie.

Der Unterschied liegt im Verlauf. Technische Probleme haben ein Ende. Sie sind benennbar, sie lassen sich einschätzen, und irgendwann sind sie gelöst. Ein Projekt, in dem niemand entscheidet, hat kein Ende. Es hat nur einen neuen Termin.

Wie schief das Bauchgefühl liegt, zeigt eine Zahl aus einer ganz anderen Ecke. Das Content Marketing Institute hat 1.015 B2B-Marketer nach ihren größten Hürden gefragt. Technologie landete mit 8 Prozent auf dem letzten Platz. Fehlende Ressourcen kamen auf 39 Prozent, abteilungsübergreifende Zusammenarbeit auf 21. Auch dort, wo Menschen den ganzen Tag mit Systemen arbeiten, ist das System selten das Problem.

Beim Kaufen ist das gut untersucht, danach sieht niemand hin

Vor der Unterschrift gibt es Zahlen dazu. Matthew Dixon und Ted McKenna haben für The JOLT Effect 2,5 Millionen Verkaufsgespräche ausgewertet. Ergebnis: 40 bis 60 Prozent der Abschlüsse scheitern nicht am Wettbewerb, sondern an Unentschlossenheit auf Kundenseite. 56 Prozent davon aus Angst, das Falsche zu wählen, 44 Prozent aus Zufriedenheit mit dem, was schon da ist.

Für die Zeit nach der Unterschrift gibt es keine vergleichbare Untersuchung. Niemand hat gemessen, wie viele Freigaberunden ein Website-Projekt normalerweise braucht oder wie oft sich ein Go-Live verschiebt. Ich habe danach gesucht. Es gibt das nicht.

Nach unserer Erfahrung wiederholt sich dort dasselbe Muster. Die Unentschlossenheit verschwindet mit dem unterschriebenen Angebot nicht. Sie wandert nur von der Frage, ob gebaut wird, zur Frage, wie.

Woran du es vor dem Start erkennst

Die gängigen Fragenkataloge für den Projektstart fragen nach Zielen, Zielgruppe, Inhalten, Budget und Technik. Sie sind gut, und sie fragen alle nach dem Was. Keiner von ihnen fragt nach dem Wer.

Die Fragen, die im Kickoff fehlen, klingen unbequemer, als sie sind. Sie dauern zwanzig Minuten und sparen Wochen.

• Wer gibt das Design frei, und darf diese Person allein unterschreiben?
• Wer muss vorher gesehen haben, was wir bauen, damit es später keine Grundsatzdebatte gibt?
• Was passiert, wenn diese Person zwei Wochen im Urlaub ist?
• Wer schreibt die Texte, und steht das im Kalender dieser Person?
• Wer hat Zugriff auf Domain, Analytics und Zahlungsanbieter, und wissen wir das jetzt oder erst in der Go-Live-Woche?
• Welche drei Dinge soll die neue Website ausdrücklich nicht können?

Die letzte Frage ist die wichtigste, und sie ist die einzige, die zuverlässig für Stille sorgt. Ein Projekt, das kein Nein enthält, hat kein Konzept, sondern einen Umfang, der noch nicht feststeht. Genau daran arbeiten wir in der Konzeption, bevor die erste Zeile Code entsteht.

Was du auf deiner Seite klären kannst

Was auf Auftraggeberseite am meisten bringt, kostet kein Budget.

Erstens: eine Person benennen, die freigeben darf, und diese Benennung im eigenen Haus einmal aussprechen. Nicht gegenüber der Agentur, sondern gegenüber den eigenen Kolleginnen und Kollegen. Der Satz „Das entscheidet Miriam für uns“ spart später mehrere Schleifen.

Zweitens: die Leute früh dazuholen, die später ohnehin mitreden werden. Wenn der Vertrieb im Kickoff sitzt, kostet das eine Stunde. Wenn er im ersten Review sitzt, kostet es eine Woche.

Drittens: aufschreiben, was die Website nicht leisten soll. Das ist die unbequemste Übung des ganzen Projekts und die einzige, die den Umfang stabil hält.

Was wir daraus geändert haben

Wir haben Verzögerungen lange als etwas behandelt, das auf der anderen Seite passiert. Freigabe kommt nicht, Text fehlt, Zugang ist nicht da: notiert, nachgehakt, weitergearbeitet. Das war nicht falsch, aber es war zu wenig. Wenn eine Freigabe zwei Wochen liegen bleibt, hat meistens niemand geklärt, wer sie geben darf. Das zu klären ist unser Job, nicht der des Kunden.

Drei Dinge haben wir deshalb geändert.

Wir fragen im Kickoff nach Namen, nicht nach Rollen. Nicht „Wer gibt das Design frei?“, sondern „Wie heißt die Person, die das Design freigibt, und sitzt sie hier im Raum?“ Das ist kurz unangenehm und dauert fünf Minuten.

Wir schreiben Freigaben mit Datum in den Plan, so wie Entwicklungspakete. Eine Freigabe ohne Termin ist keine Aufgabe, sondern eine Hoffnung.

Und wir arbeiten in kurzen Takten, damit eine offene Frage nicht das ganze Projekt anhält, sondern nur einen Strang. Ob dabei agil oder im Wasserfall gearbeitet wird, ist weniger entscheidend als die Frage, wie schnell eine Entscheidung durch die Organisation kommt.

Schneller werden Projekte davon nicht automatisch. Aber es wird sichtbar, woran sie hängen, und zwar in Woche zwei statt in Woche zwölf.

Am deutlichsten sehen wir den Unterschied bei Auftraggebern, die das selbst schon einmal anders erlebt haben. Wer im Kickoff von sich aus sagt, wer freigibt und wer vorher gesehen haben muss, was gebaut wird, verschiebt seinen Go-Live selten. Das hat wenig mit Budget zu tun und nichts mit Unternehmensgröße. Es hat damit zu tun, dass vorher jemand die Entscheidung getroffen hat, wer entscheidet.