Wie du ein Salesforce-Projekt so planst, dass es puenktlich liefert

Ein Salesforce-Projekt liefert puenktlich, 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 darueber, 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 unterschaetzt wurde. Bauschaetzungen 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-Einfuehrungen ihre geplanten Ziele verfehlten, rund 30% den geplanten Termin hielten und nur 25% Ziele, Termin und Budget zusammen erreichten. Sieben von zehn ueberschritten den Terminplan um 30% oder mehr. Diese Ueberschreitungen sind selten Engineering-Ueberschreitungen.

Der eigentliche Mechanismus sieht so aus. Eine Umfangszeile sagt "Genehmigungsprozess fuer Rabatte ueber 15% bauen". Der Bau dauert drei Tage. Die offene Frage darunter lautet: Wer genehmigt, ab welcher Schwelle, in welcher Waehrung, was passiert im Urlaubsfall, und gehoert 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 hinzufuegst. Das Projekt wartet, und dieses Warten landet auf dem Liefertermin.

Was heisst es, Entscheidungen statt Funktionen zu bepreisen?

Eine Funktion ist Arbeit. Eine Entscheidung ist eine Abhaengigkeit von einem Menschen. Eine Umfangsplanung, die nur die Arbeit zaehlt, liefert eine Schaetzung, 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 fuehrend 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 geschaetzten Aufgabe versteckt.

Wie planst du den Umfang, damit das Projekt puenktlich liefert?

1. Schreibe einen Ergebnissatz mit Zahl und Datum. Nicht "Serviceeffizienz verbessern", sondern "die woechentliche 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 Faelligkeitsdatum. Dieses Dokument sagt deinen Go-live voraus, nicht der Terminplan.
3. Trenne Bekanntes von Unbekanntem. Arbeit, die du schon gemacht hast, bekommt eine Schaetzung. Arbeit, die du noch nie gemacht hast, bekommt eine Zeitbox und eine ausdrueckliche 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 abhaengt, lehrt dich nichts ueber die Entscheidungen, die du falsch getroffen hast.
6. Fixiere die Taktung, nicht den Umfang. Zweiwoechige Sprints mit lauffaehiger Software am Ende jedes Sprints sind das, was Umfangstausch ohne Vertragsneuverhandlung erlaubt. So arbeiten wir bei Tekunda, und deshalb ueberlebt ein fester Termin eine geaenderte Anforderung.

Was gehoert in eine Liste von Nichtzielen?

Ein Nichtziel ist etwas, das ein vernuenftiger Mensch als enthalten annehmen wuerde, schriftlich als ausgeschlossen festgehalten. Es ist das billigste Artefakt im Projekt und das am haeufigsten uebersprungene.

• 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 ausserhalb von Salesforce bleiben.
• Integrationen, die in dieser Version einseitig sind, obwohl sich alle beidseitig vorstellen.

Die Regel, die das funktionieren laesst: Ein Nichtziel zaehlt nur, wenn die Person, die es angefragt hat, es schriftlich gesehen und nicht widersprochen hat. Eine ungelesene Liste ist nur ein Beweisstueck fuer 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:

• Aendert sie die Ergebniszahl? Wenn ja, ist es eine Neuplanung und gehoert 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 Groesse verlaesst die Version und wandert am selben Tag schriftlich in die Nichtziele. Hinzufuegen ohne Wegnehmen ist, wie ein Termin leise stirbt.

Was enthaelt ein Umfangsdokument, das die Wirklichkeit ueberlebt?

• Einen Ergebnissatz mit Kennzahl und Datum.
• Ein Entscheidungsregister: Frage, Verantwortlicher, Faelligkeit, Status.
• Annahmen, jede davon widerlegbar.
• Nichtziele, benannt und bestaetigt.
• Datenumfang: welche Objekte, wie weit zurueck, wer die Bereinigung verantwortet.
• Fuehrendes System je Objekt und die Richtung jeder Integration.
• Eine Definition of Done fuer die erste Version, in Nutzerbegriffen.
• Was nach dem Go-live passiert, samt der Frage, wer das Backlog haelt.

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

FAQ

Wie lange sollte die Salesforce-Analysephase dauern?

Lange genug, um die Entscheidungen zu schliessen, die die erste Version blockieren, und keinen Tag laenger. Beurteile sie am Zustand des Entscheidungsregisters, nicht an einer festen Wochenzahl.

Ist fester Umfang immer das falsche Modell fuer 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 dafuer.

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 spaeter verteidigbar ist.

Wer sollte das Entscheidungsregister halten?

Jemand auf Kundenseite mit Eskalationsbefugnis. Haelt es dein Dienstleister, wird jede ueberfaellige Entscheidung zur Lieferantenbeschwerde statt zu einer internen Frist.

Kann Phasenbildung einen zu grossen Umfang retten?

Nur wenn jede Phase fuer echte Nutzer live geht. Phasen, die alle am Ende landen, sind ein Projekt mit zusaetzlichen Dokumenten.