Cette conférence TED populaire de Simon Sinek s'applique bien à notre contexte. Lorsqu'on exprime un besoin, il est important d'exprimer le pourquoi, plus que le comment.
C'est notre biais en tant qu'humain : on est très concentrés sur les solutions.
Mais si l'on souhaite démarrer un projet et solliciter des personnes pour le réaliser, c'est sans doute parce qu'elles sont meilleures que nous dans l'implémentation et la résolution de ce problème. Alors si le besoin leur est présenté sous un angle solution, on leur masque de facto une partie du problème, rendant la réponse moins adaptée.
Par contre, si vous êtes porteur du besoin, vous êtes sans nul doute meilleur·e dans la connaissance de votre besoin et de votre métier. Dans la rédaction d'un cahier des charges, c'est ça qui doit transpirer.
Au delà de la réalisation, vous allez donc avoir des personnes en charge de porter et suivre le projet, la fameuse maitrise d'ouvrage (MOA).
Que vous choisissiez des personnes internes ou externes, vous devez à la fois avoir accès aux personnes qui utiliseront l'application pour comprendre le besoin final mais également aux décideurs qui seront en mesure de faire les arbitrages nécessaires.
Essayez de vous entourer de personnes pragmatiques pour éviter les comités de pilotage sans fin, qui drainent l'énergie de tous et se soldent par un nombre croissant de questions ouvertes.
Il est normal et nécessaire de faire des arbitrages en cours de route, tout ne peut pas être borné au préalable, et votre projet a le droit d'évoluer au fil du temps.
Beaucoup de projets échouent car on peine à comprendre leurs objectifs.
Quelle est la finalité du projet : améliorer votre productivité ? Obtenir un avantage concurrentiel ? Augmenter votre panier moyen, votre chiffre d'affaire ?
Il est important également de savoir qui est à l'origine du projet, même si cette ou ces personnes ne sont pas en charge de son suivi.
Une fois que vous avez listé les quelques objectifs majeurs (il ne devrait pas y en avoir plus de 3), il est important de savoir comment ils pourront être mesurés. En effet, comment affirmer si le projet est une réussite si l'on n'est pas capable de le mesurer ?
Comme les projets sont plus nombreux à échouer qu'à réussir, vous pourriez vous retrouver dans une situation d'échec sans même comprendre pourquoi.
Mettons les pieds dans le plat : personne n'aime lire un cahier des charges de 100 pages, encore moins l'écrire.
Le cahier des charges n'a pas un rôle de spécification technique : il n'est pas nécessaire de faire 10 pages pour expliquer comment fonctionne un renvoi de mot de passe oublié.
Notre préconisation est même simple : n'en écrivez pas ! En tout cas, pas au sens où on l'entend classiquement, c'est-à-dire une somme de fonctionnalités.
Ce temps perdu vous pénalise doublement, car il retarde le démarrage effectif et il vous enferme dans un besoin, vous interdisant toute forme de changement.
Passez du temps à décrire vos enjeux, vos objectifs, vos ambitions qui justifient la mise en place de ce projet.
Les contraintes doivent être claires et explicites.
Qui n'a jamais entendu au cours d'un projet le fameux « c'était pourtant évident qu'il fallait faire ça » qui survient généralement une fois le projet réalisé à 80%.
Les contraintes peuvent être très variées : une orientation de la DSI qui implique l'usage d'un outil particulier, une interconnexion avec un système existant, et tant d'autres. Prenez le temps de les identifier.
La complexité d'un projet se démultiplie à mesure qu'il interagit avec des systèmes tiers. C'est pour cela qu'il n'est pas rare de se retrouver avec des équipes « shadow IT » dans les grands groupes, afin de contourner toutes ces contraintes et être en mesure de mettre en place rapidement des solutions simples répondant à des besoins précis.
« On a plein d'usages possibles », « tout est indispensable », « il faut prévoir quand on aura 5 000 utilisateurs connectés en simultanés ».
À tout prioriser, on ne priorise plus rien.
Oui, il est difficile d'arbitrer, mais c'est indispensable. Il est important également de rester concentré sur un usage précis.
Vous n'avez sans doute pas les mêmes contraintes que Facebook ou Google, inutile d'être trop en avance de phase et trop anticiper le futur de votre projet.
On vous reprochera moins d'avoir échoué sur un projet à quelques milliers d'euros qu'à plusieurs centaines de milliers d'euros.
Vous serez également plus à même de solliciter des moyens supplémentaires en ayant prouvé rapidement la valeur ajoutée du projet.
Soyez tolérant également sur la finition d'un projet, car la loi de Pareto nous guette en permanence et ce sont bien les 20% de finition qui prendront 80% du temps global d'un projet.
S'il est évident que vous n'irez pas loin sans budget, il est moins intuitif que vous n'irez pas beaucoup plus loin avec seulement un budget.
Vous vous souvenez de l'échec cuisant de Louvois, le logiciel de paie unifié de l'armée ? Un coût annuel évalué à 150 à 200M€ par an. Vous voyez que les budgets ne résolvent pas tout.
En conclusion, identifier les bons interlocuteurs, leur disponibilité, avoir une vision claire des enjeux et des contraintes du projet et allouer des moyens en conséquence : voilà les éléments clés de la réussite de votre projet.
