Skip to content
Tekunda Team

Tekunda Team

Wie du ein Salesforce-Projekt so planst, dass es pünktlich liefert

Wie du ein Salesforce-Projekt so planst, dass es pünktlich liefert

Ein Salesforce-Projekt liefert pünktlich, wenn der Umfang die Entscheidungen bepreist, die das Projekt braucht, und nicht die Funktionen, die es bauen wird. Die meisten Festumfangsprojekte rutschen, weil die Analysephase eine Funktionsliste hervorgebracht hat, und eine Funktionsliste schweigt darüber, wer was bis wann entscheiden muss. Das Gegenmittel: ein Ergebnis, ein Entscheidungsregister und eine geschriebene Liste von Nichtzielen.

Warum rutschen Salesforce-Projekte mit festem Umfang?

Nicht weil der Bau unterschätzt wurde. Bauschätzungen liegen meist nah dran. Der Kalender bricht woanders.

Die Zahlen sind unfreundlich. In seiner CRM-Fehlschlagsstudie 2025 stellte Johnny Grow fest, dass 55% der CRM-Einführungen ihre geplanten Ziele verfehlten, rund 30% den geplanten Termin hielten und nur 25% Ziele, Termin und Budget zusammen erreichten. Sieben von zehn überschritten den Terminplan um 30% oder mehr. Diese Überschreitungen sind selten Engineering-Überschreitungen.

Der eigentliche Mechanismus sieht so aus. Eine Umfangszeile sagt "Genehmigungsprozess für Rabatte über 15% bauen". Der Bau dauert drei Tage. Die offene Frage darunter lautet: Wer genehmigt, ab welcher Schwelle, in welcher Währung, was passiert im Urlaubsfall, und gehört die Ausnahme Finance oder Sales. Diese Frage braucht vier Menschen in einem Raum, die schwer in einen Raum zu bekommen sind. Sie wird nicht schneller, wenn du Entwickler hinzufügst. Das Projekt wartet, und dieses Warten landet auf dem Liefertermin.

Was heißt es, Entscheidungen statt Funktionen zu bepreisen?

Eine Funktion ist Arbeit. Eine Entscheidung ist eine Abhängigkeit von einem Menschen. Eine Umfangsplanung, die nur die Arbeit zählt, liefert eine Schätzung, die beim Bau stimmt und beim Kalender nicht.

Dein Umfang wurde als Funktionsliste bepreist, wenn:

  • Jede Zeile mit bauen, konfigurieren oder migrieren beginnt.
  • Keine Zeile eine Person nennt, die etwas entscheiden muss.
  • Integrationszeilen nicht sagen, welches System pro Objekt führend ist.
  • Datenmigration eine einzige Zeile ist.
  • Es keinen Abschnitt mit Nichtzielen gibt.

Jeder dieser Punkte ist eine Stelle, an der sich eine ungetroffene Entscheidung hinter einer geschätzten Aufgabe versteckt.

Wie planst du den Umfang, damit das Projekt pünktlich liefert?

  1. Schreibe einen Ergebnissatz mit Zahl und Datum. Nicht "Serviceeffizienz verbessern", sondern "die wöchentliche manuelle Fallsichtung bis Ende Q2 von X auf Y senken". Bindet sich niemand an eine Zahl, hast du noch kein Projekt, sondern Interesse.
  2. Baue ein Entscheidungsregister, bevor du eine Aufgabenliste baust. Jede offene Frage, die einen Bau blockiert, mit benanntem Verantwortlichen und Fälligkeitsdatum. Dieses Dokument sagt deinen Go-live voraus, nicht der Terminplan.
  3. Trenne Bekanntes von Unbekanntem. Arbeit, die du schon gemacht hast, bekommt eine Schätzung. Arbeit, die du noch nie gemacht hast, bekommt eine Zeitbox und eine ausdrückliche Abbruchbedingung. Mittle die beiden nie zu einer Zahl.
  4. Schreibe die Nichtziele auf und lass sie laut vorlesen. Siehe unten.
  5. Schneide auf eine erste Version, die eine echte Nutzergruppe produktiv benutzt. Ein Team, ein Prozess, live. Ein Pilot, von dem niemand abhängt, lehrt dich nichts über die Entscheidungen, die du falsch getroffen hast.
  6. Fixiere die Taktung, nicht den Umfang. Zweiwöchige Sprints mit lauffähiger Software am Ende jedes Sprints sind das, was Umfangstausch ohne Vertragsneuverhandlung erlaubt. So arbeiten wir bei Tekunda, und deshalb überlebt ein fester Termin eine geänderte Anforderung.

Was gehört in eine Liste von Nichtzielen?

Ein Nichtziel ist etwas, das ein vernünftiger Mensch als enthalten annehmen würde, schriftlich als ausgeschlossen festgehalten. Es ist das billigste Artefakt im Projekt und das am häufigsten übersprungene.

  • Was Stakeholder gefordert haben und in dieser Version nicht enthalten ist, benannt, nicht zusammengefasst.
  • Stille Annahmen: historische Daten jenseits eines genannten Stichtags, Offline-Mobil, eine zweite Sprache, das Steuerrecht eines zweiten Landes.
  • Prozesse, die vorerst außerhalb von Salesforce bleiben.
  • Integrationen, die in dieser Version einseitig sind, obwohl sich alle beidseitig vorstellen.

Die Regel, die das funktionieren lässt: Ein Nichtziel zählt nur, wenn die Person, die es angefragt hat, es schriftlich gesehen und nicht widersprochen hat. Eine ungelesene Liste ist nur ein Beweisstück für die Nachbetrachtung.

Wie gehst du mit der Anfrage in Woche sechs um?

Sie kommt, und sie rundweg abzulehnen ist meist falsch, denn Anfragen aus Woche sechs sind oft besser informiert als die aus Woche eins. Stelle zwei Fragen:

  • Ändert sie die Ergebniszahl? Wenn ja, ist es eine Neuplanung und gehört zum Sponsor.
  • Entwertet sie eine bereits getroffene und bebaute Entscheidung? Wenn ja, bepreise die Nacharbeit getrennt und sichtbar.

Wenn keines von beidem, tausche. Etwas von vergleichbarer Größe verlässt die Version und wandert am selben Tag schriftlich in die Nichtziele. Hinzufügen ohne Wegnehmen ist, wie ein Termin leise stirbt.

Was enthält ein Umfangsdokument, das die Wirklichkeit überlebt?

  • Einen Ergebnissatz mit Kennzahl und Datum.
  • Ein Entscheidungsregister: Frage, Verantwortlicher, Fälligkeit, Status.
  • Annahmen, jede davon widerlegbar.
  • Nichtziele, benannt und bestätigt.
  • Datenumfang: welche Objekte, wie weit zurück, wer die Bereinigung verantwortet.
  • Führendes System je Objekt und die Richtung jeder Integration.
  • Eine Definition of Done für die erste Version, in Nutzerbegriffen.
  • Was nach dem Go-live passiert, samt der Frage, wer das Backlog hält.

Acht Punkte. Das passt auf zwei Seiten und sagt mehr über deinen Liefertermin als eine Anforderungsmatrix mit dreihundert Zeilen.

FAQ

Wie lange sollte die Salesforce-Analysephase dauern?

Lange genug, um die Entscheidungen zu schließen, die die erste Version blockieren, und keinen Tag länger. Beurteile sie am Zustand des Entscheidungsregisters, nicht an einer festen Wochenzahl.

Ist fester Umfang immer das falsche Modell für Salesforce?

Nein, aber er funktioniert nur, wenn die Entscheidungen schon gefallen sind. Fester Umfang auf einem unentschiedenen Prozess fixiert die falsche Variable, und der Termin zahlt dafür.

Was unterscheidet ein Nichtziel von "nicht im Umfang"?

Nicht im Umfang ist vertraglich. Ein Nichtziel ist kommuniziert. Der Wert liegt darin, dass der Stakeholder es gelesen hat, nicht darin, dass es später verteidigbar ist.

Wer sollte das Entscheidungsregister halten?

Jemand auf Kundenseite mit Eskalationsbefugnis. Hält es dein Dienstleister, wird jede überfällige Entscheidung zur Lieferantenbeschwerde statt zu einer internen Frist.

Kann Phasenbildung einen zu großen Umfang retten?

Nur wenn jede Phase für echte Nutzer live geht. Phasen, die alle am Ende landen, sind ein Projekt mit zusätzlichen Dokumenten.

Ähnliche Artikel