Cadrer, découper, suivre, et surtout laisser une trace de ce qui a été décidé. Sur un projet technique, ce qui coûte cher n’est presque jamais la difficulté technique : c’est le malentendu découvert trois mois trop tard.
Ce que je fais
- Cadrage : ce qui est dans le projet, ce qui n’y est pas, et ce qui décidera qu’il est fini.
- Découpage en lots livrables, chacun utilisable seul. Un projet qui ne produit rien avant six mois est un projet dont personne ne sait où il en est.
- Suivi dans un outil accessible au client — tickets, états, temps passé — plutôt que dans un tableur qu’on s’envoie.
- Arbitrages : dire ce qu’une demande coûte avant de la prendre, et proposer l’option moins chère quand elle existe.
- Recette et transfert : la documentation et la formation font partie de la livraison, pas d’un devis suivant.
La traçabilité n’est pas de la paperasse
Chaque décision est écrite sur le ticket qui la porte : pourquoi cette option, ce qui a été essayé, ce qui a été écarté. C’est ce qui permet de reprendre un dossier deux ans plus tard sans réinventer le raisonnement — et de répondre à « pourquoi c’est fait comme ça ? » autrement que de mémoire.
J’utilise Redmine comme référentiel, et l’outillage que j’ai écrit autour : voir Karl. Le client y a accès ; un suivi qu’il ne peut pas consulter n’est pas un suivi.
Interlocuteur unique
Sur les projets où l’ERP, la boutique et l’infrastructure se répondent, la difficulté est souvent de faire parler trois prestataires. Je tiens les trois bouts, ou je pilote ceux qui les tiennent — voir Partenaires et sous-traitants.