Cadrer un projet Salesforce pour qu'il livre a l'heure

Un projet Salesforce livre a l'heure quand le perimetre chiffre les decisions dont le projet a besoin, et non les fonctionnalites qu'il va construire. La plupart des projets a perimetre fixe derapent parce que la phase de cadrage a produit une liste de fonctionnalites, et une telle liste ne dit rien de qui doit decider quoi, ni quand. Le remede: un resultat, un registre de decisions, et une liste ecrite de non-objectifs.

Pourquoi les projets Salesforce a perimetre fixe derapent-ils?

Pas parce que la construction a ete sous-estimee. Les estimations de build sont en general proches du reel. Le calendrier casse ailleurs.

Les chiffres sont severes. Dans son etude 2025 sur l'echec des projets CRM, Johnny Grow releve que 55% des deploiements CRM n'ont pas atteint leurs objectifs, qu'environ 30% ont tenu le calendrier prevu, et que seuls 25% ont tenu objectifs, calendrier et budget ensemble. Sept sur dix ont depasse le calendrier de 30% ou plus. Ces depassements sont rarement des depassements d'ingenierie.

Voici le mecanisme reel. Une ligne de perimetre dit "construire un processus d'approbation pour les remises superieures a 15%". Le build prend trois jours. La question non tranchee en dessous est: qui approuve, a partir de quel seuil, dans quelle devise, que se passe-t-il si cette personne est absente, et qui de la Finance ou des Ventes possede l'exception. Cette question exige quatre personnes difficiles a reunir. Elle n'accelere pas si vous ajoutez des developpeurs. Le projet attend, et cette attente atterrit sur la date de livraison.

Que signifie chiffrer des decisions plutot que des fonctionnalites?

Une fonctionnalite est du travail. Une decision est une dependance envers un etre humain. Un cadrage qui ne compte que le travail produit une estimation juste sur le build et fausse sur le calendrier.

Votre perimetre a ete chiffre en fonctionnalites si:

• Chaque ligne commence par construire, configurer ou migrer.
• Aucune ligne ne nomme une personne devant trancher quelque chose.
• Les lignes d'integration ne disent pas quel systeme fait foi pour chaque objet.
• La migration de donnees tient en une ligne.
• Il n'y a pas de section non-objectifs.

Chacun de ces points est un endroit ou une decision non prise se cache derriere une tache estimee.

Comment cadrer un projet Salesforce pour qu'il livre a l'heure?

1. Ecrivez une phrase de resultat, avec un chiffre et une date. Pas "ameliorer l'efficacite du service" mais "reduire le tri manuel hebdomadaire des cas de X a Y avant la fin du T2". Si personne ne s'engage sur un chiffre, vous n'avez pas encore un projet, vous avez un interet.
2. Construisez un registre de decisions avant une liste de taches. Chaque question ouverte qui bloque un build, avec un proprietaire nomme et une date de reponse. C'est ce document qui predit votre mise en production, pas le diagramme de Gantt.
3. Separez le connu de l'inconnu. Le travail deja fait recoit une estimation. Le travail jamais fait recoit une enveloppe de temps et une condition de sortie explicite. Ne moyennez jamais les deux en un seul chiffre.
4. Ecrivez les non-objectifs et faites-les lire a voix haute. Voir plus bas.
5. Decoupez vers une premiere version utilisee en production par un vrai groupe d'utilisateurs. Une equipe, un processus, en production. Un pilote dont personne ne depend n'apprend rien sur les decisions manquees.
6. Fixez la cadence, pas le perimetre. Des sprints de deux semaines avec du logiciel fonctionnel a la fin de chacun: c'est ce qui permet d'echanger du perimetre sans renegocier le contrat. C'est ainsi que nous travaillons chez Tekunda, et c'est pourquoi une date fixe survit a une exigence qui change.

Que met-on dans une liste de non-objectifs?

Un non-objectif est quelque chose qu'une personne raisonnable croirait inclus, ecrit noir sur blanc comme exclu. C'est l'artefact le moins cher du projet et le plus souvent saute.

• Ce que les parties prenantes ont demande et qui n'est pas dans cette version, nomme et non resume.
• Les hypotheses silencieuses: donnees historiques au-dela d'une limite annoncee, mobile hors ligne, une deuxieme langue, la fiscalite d'un deuxieme pays.
• Les processus qui restent hors de Salesforce pour l'instant.
• Les integrations qui seront unidirectionnelles dans cette version alors que tout le monde imagine du bidirectionnel.

La regle qui rend la liste utile: un non-objectif ne compte que si la personne qui l'a demande l'a vu ecrit et n'a pas objecte. Une liste que personne n'a lue n'est qu'une piece a conviction pour le bilan.

Comment traiter la demande qui arrive en semaine six?

Elle arrivera, et la refuser d'emblee est souvent une erreur, car les demandes de la semaine six sont souvent mieux informees que celles de la semaine une. Posez deux questions:

• Change-t-elle le chiffre de resultat? Si oui, c'est un recadrage et cela remonte au sponsor.
• Invalide-t-elle une decision deja prise et deja construite? Si oui, chiffrez la reprise a part et de facon visible.

Si ni l'un ni l'autre, echangez. Quelque chose de taille comparable quitte la version et rejoint la liste des non-objectifs, par ecrit, le jour meme. Ajouter sans retrancher, c'est ainsi qu'une date meurt en silence.

Que contient un document de perimetre qui resiste au reel?

• Une phrase de resultat avec une mesure et une date.
• Un registre de decisions: question, proprietaire, echeance, statut.
• Des hypotheses, chacune refutable.
• Des non-objectifs, nommes et reconnus.
• Le perimetre de donnees: quels objets, sur quelle profondeur, qui possede le nettoyage.
• Le systeme de reference par objet, et le sens de chaque integration.
• Une definition de fini pour la premiere version, en termes utilisateur.
• Ce qui se passe apres la mise en production, y compris qui detient le backlog.

Huit points. Cela tient sur deux pages et en dit plus sur votre date de livraison qu'une matrice d'exigences de trois cents lignes.

FAQ

Combien de temps doit durer le cadrage Salesforce?

Assez pour fermer les decisions qui bloquent la premiere version, pas davantage. Jugez-le a l'etat du registre de decisions, pas a un nombre de semaines fixe.

Le perimetre fixe est-il toujours un mauvais modele pour Salesforce?

Non, mais il ne marche que si les decisions sont deja prises. Fixer le perimetre sur un processus non tranche fige la mauvaise variable, et la date en paie le prix.

Quelle difference entre un non-objectif et le hors perimetre?

Le hors perimetre est contractuel. Le non-objectif est communique. La valeur tient a ce que la partie prenante l'ait lu, pas a ce qu'il soit defendable plus tard.

Qui doit detenir le registre de decisions?

Quelqu'un cote client, avec le pouvoir d'escalader. Si votre partenaire le detient, chaque decision en retard devient une plainte contre le fournisseur au lieu d'une echeance interne.

Le phasage peut-il reparer un perimetre trop grand?

Seulement si chaque phase passe en production pour de vrais utilisateurs. Des phases qui atterrissent toutes a la fin forment un seul projet avec des documents en plus.