Comment rater à coup sûr son projet web ?
(Pourquoi on n’en parle jamais ? Comme par hasard...)
Personne ne pose jamais la question et on n’en parle non plus jamais dans les médias “mainstream”. Ne vous êtes-vous pas demandé pourquoi ? Je dis ça je dis rien.
Heureusement, je suis là pour ré-informer vos neurones et je n’ai pas peur de la censure, je vous dis tout, sans filtre.
J'espère qu’avec tous ces “bons” conseils vous ferez de superbes loupés ! Arrêtez de croire tout ce que l’on vous dit… Enfin, sauf moi.
Nous allons nommer :
- La MOA la Maîtrise d’Ouvrage (vous, le client)
- l’AMO sera le chef de projet (il vous assiste c’est donc l’Assistant à Maîtrise d’Ouvrage)
- et la MOE (la Maîtrise d'Oeuvre) les personnes qui réalisent le projet.
Sans plus attendre commençons par la première règle :
1. Être absent tu préféreras
Oui, ça c’est très important, ne vous rendez pas disponible. C’est vraiment un très bon début pour bien rater votre projet. Ne pas avoir de réponse à ses questions permet de naviguer en eau trouble ce qui est vraiment très bon pour perdre du temps et de l’énergie, c'est idéal pour créer des conflits.
Vous n’apportez pas les réponses : le temps passe, le stress et les tensions montent. L’occasion pour l’AMO (le chef de projet) d’éventuellement rejeter la faute sur la MOE (ceux qui réalisent), créant ainsi quelques tensions très utiles.
Idéal aussi pour rendre problématique l’enchaînement des tâches !
Non vraiment c’est un très très bon départ et la suite ne s’en verra que plus compliquée.
Par exemple, la phase de recette ? Un vrai régal :
- “Ah mais ça ne me convient pas du tout, mais rendez-vous compte !”
- “Mais justement nous vous avons demandé à 3 reprises si…”
- “Oui mais j’étais débordé vous auriez pu / dû…”
Ce sera le moment d’être de mauvaise foi et ça, nous savons tous parfaitement bien le faire, à croire même que nous y sommes entraînés depuis le plus jeune âge.
Affaiblir la qualité et les délais, créer des tensions dans l’équipe et avec le client : check !
(Ceci est la première des trois raisons majeures d'échec)
2. Plusieurs interlocuteurs tu auras
Alors ça aussi pour bien noyer la demande et la rendre la moins claire possible, avoir 2 (ou même plus !) interlocuteurs est une très bonne idée.
Assurez-vous de diriger le projet avec quelqu’un d’autre ou de nommer deux personnes et si possible qu’elles soient, même légèrement, en compétition pour “piloter” le projet. Vous enverrez alors des ordres contradictoires qui, cumulés dans le temps, rendront le pilotage quasiment impossible.
Faire défaire et refaire, la MOE déteste ça, surtout s’ils se sont engagés sur prix forfaitaire.
Augmenter les tensions dans l’équipe / client : recheck !
3. Ton intuition tu te fieras
Oui à la limite, en y réfléchissant bien, vous le connaissez votre besoin. Alors bon, pourquoi payer un AMO ? Voilà une option assez intéressante pour rater son projet, vous allez pouvoir vous appuyer sur vos “connaissances” (votre intuition donc) en réalisation de logiciel ! De plus, vous éviterez certainement de gérer la résistance au changement et ne maîtriserez pas du tout les phases de réalisation d’un tel projet.
Et puis, l’AMO pourrait venir vous avertir des pièges à éviter pour louper votre projet en argumentant de son expérience, ses études etc. Faudrait pas que ça vous aide non plus.
Se mettre des bâtons dans les roues : check !
4. Ton besoin tu ne détailleras pas
Certains voudront vous inciter à clarifier votre besoin, pourquoi pas même réaliser une analyse des besoins… Une sorte de liste permettant d’écrire noir sur blanc vos besoins, les raisons de ces besoins et l’importance qu’ils ont pour vous ou le projet. L’AMO est même capable de mettre le doigt sur des besoins non identifiés mais réels. Imaginez un peu. Évitez, hein, on ne sait jamais.
Et s’il commence à vous parler d’analyse des risques, feignez de ne pas avoir entendu… Faites tomber votre stylo par exemple et tout en le ramassant parlez donc de votre séjour à la montagne, il n'y verra que du feu.
Générer des incertitudes et favoriser la mauvaise foi : check !
(Ceci est la seconde des trois raisons majeures d'échec)
5. Aux risques tu ne t’intéresseras pas
Voilà pourquoi vous ne devez pas non plus faire d’analyse des risques. Non seulement vous allez devoir en prendre conscience et ça… Ce serait aussi devoir les classer par importance mais surtout trouver pour chacun d’eux une contre mesure, imaginez un peu. Prévoir les risques c’est vraiment tout faire pour les éviter, exactement ce que l’on ne veut pas.
Faire l’autruche : check !
6. Le cahier des charges tu ne rédigeras pas
Jusque là on est pas mal parti mais on peut encore faire beaucoup mieux : détailler le moins possible ce que l’on souhaite. L’AMO aura la drôle d’idée de vous proposer de réaliser un cahier des charges. Il lui permet soit disant de définir vos besoins et de mieux chiffrer les coûts, baliverne. Il veut juste vous faire dépenser de l’argent, ne l’écoutez surtout pas.
Et si jamais vous craquez, je vous conseille alors vivement de bien lui faire comprendre qu’il exagère à vouloir détailler encore et encore, tout ça pour rallonger son intervention. Vous voyez son manège, qu’il le sache ça lui mettra la pression pour finaliser au plus vite son travail.
Avec un tel cahier des charges, peu détaillé donc, vous avez toutes les chances que la MOE ne réalise pas ce que vous voulez, idéal.
- Ah mais ce n’est pas du tout ce que je voulais !
- Mais ce n’était pas dans le cahier des charges…
- C'est vous ou moi qui savez faire un logiciel ?
Réduire la qualité de votre projet : check !
(Ceci est aussi la seconde des trois raisons majeures d'échec)
7. De la réunion de cadrage tu te moqueras
Alors voilà, ça c’est à éviter le plus possible. Ce serait bête de faire en sorte que tout le monde ait bien compris les tenants, aboutissants et contraintes du dossiers, ça pourrait leur permettre d’être proactif, il ne vaut mieux pas.
Elle permettrait aussi que chacun s’engage et se comporte en prenant en compte les autres… A éviter.
Fragiliser la cohésion d’équipe : check !
8. Planifier tu éviteras
Figurez-vous qu’il existe des logiciels de gestion de tâches… Ils veulent nous faire réussir nos projets ou quoi ?
Le principe est de lister toutes les tâches à réaliser, d’y prévoir un temps et de les assigner aux bonnes personnes. De quoi maîtriser la réalisation de son projet, d’autant que ces logiciels existent depuis déjà bien longtemps et sont donc particulièrement efficaces. Faites très attention, à éviter impérativement.
Favoriser les retards et la désorganisation : check !
9. Le rétro planning tu oublieras
Un autre point auquel vous devez ne surtout pas porter attention c’est le rétro planning. Il permettrait le cas échéant d’avoir une vue globale sur l'avancement du projet, de prendre de la hauteur par rapport au timing, vous comprenez bien que ce serait contre productif.
Non, ne le faite pas, encore moins si le projet prend du retard, il parait que ne pas voir les problèmes les règles naturellement.
Laissez donc les différentes parties se renvoyer la balle, vous allez voir ça marche très bien ! C'est même presque jouissif.
Perdre le contrôle du projet : check !
10. Un chef de projet incompétent tu préfèreras
On a déjà parlé de votre propre incompétence (si si souvenez vous, absent et désintéressé), quand aux personnes qui réalisent il est facile de repérer l’incompétence et d'en changer, mais quid du chef de projet (AMO) ?
Voici donc mes bons conseils pour trouver la perle (pas) rare.
Vous pouvez préférez quelqu’un qui débute, il sont souvent plus faciles à promener, ils ont le sentiment d’avoir des choses à prouver ! Vous allez pouvoir jouer là dessus.
Ou alors un manipulateur, ça c'est sympa aussi.
TOUT le monde l'aime !
Et surtout il se débrouille tout le temps pour passer pour le héro alors qu'en fait, à bien y regarder... Quand il arrive dans une équipe, d'un coup l'ambiance se plombe un peu, on ne sait pas trop dire pourquoi. Puis, rapidement, des tensions naissent entre de personnes qui, jusque là, s'entendaient bien ou avaient une relation neutre. Toujours au fil du temps, certains commencent à montrer de la nervosité et à se sentir "abandonnés" par l'équipe ou pire, ostracisés. D'un coup, comme ça.
Certains peuvent même devenir nerveux et avoir des sautes d'humeur ou au contraire commencer à déprimer. Ah, le (la aussi hien) manipulateur est un super numéro pour bien louper tous ces projets et bousiller une équipe (ne me dites pas que vous en avez déjà rencontré ?).
Le "vieux" chef de projet qui croit qu'il a tout vu. Ca aussi c'est pas mal, il adore répéter : "On fait comme ça depuis toujours !"... On a presque envie de l'écouter. Là où il est intéressant c'est lorsqu'en plus il a de l'autorité ou du charisme. Un bel atout pour louper son projet.
Ensuite, préférez quelqu’un qui ne sait pas dire “non”, très important (surtout s'il a de la bouteille et qu'il en impose un peu), vous allez pouvoir en faire ce que vous voulez et il rapportera vos moindre caprices, même les plus farfelus, à la MOE qui ne sera pas trop quoi en faire. Du retard sera pris, des tensions naîtront, impeccable. De fortes chances pour que les uns et les autres se trouvent incompétents. Les reproches commenceront à pleuvoir.
Pour peu qu’il ne sache pas non plus dire non à la MOE, vous êtes doublement gagnant.
Si vous êtes une petite structure, je vous conseille de choisir quelqu’un qui ne maîtrise pas non plus la technique. Très important car, n’étant pas lui-même de la partie, il se fera aussi promener par la MOE générant beaucoup de situations inextricables, du bon sens quoi.
Avoir une équipe bancale : check !
11. Le cycle en “V” tu préfèreras
En gestion de projet vous avez 2 grandes façons de faire.
Le cycle en “V” et les méthodes Agiles.
Ne nous penchons pas trop sur les méthodes agiles, elles donnent beaucoup plus de chances à votre projet de réussir, elles sont donc à proscrire.
Le cycle en “V”
Imaginez un V. Sur la pointe en haut à gauche vous définissez le besoin et rédigez le cahier des charges (enfin si vous en faites un). La descente et la remontée ne vous sont plus accessibles, ce sont les phases de réalisation du projet et de tests internes. A l’autre bout du V vous revoilà enfin, vous testez le logiciel (on appelle ça la phase de Recette) et c’est fini.
Alors c’est super parce que si le temps de réalisation est long, par exemple plusieurs mois ou années, vous n’allez rien voir du tout ! Et le jour de la recette (la première livraison donc), vous allez découvrir un logiciel qui aurait éventuellement pu vous convenir mais… À l'époque ! Votre entreprise a évolué, c’est adaptée à la clientèle, à l’économie, à la concurrence, aux changements internes et j’en passe, bref, elle a vécu. Il faut donc retoucher ce logiciel qui ne vous correspond plus. Mais voilà, il va donc falloir remettre la main au portefeuille et ça, il n’en sera pas question, sauf à repartir sur un autre cycle de plusieurs mois...Ce serait un super beau loupé remarquez, je dois bien en convenir…
Je sens que certains doutent encore, laissez-moi vous présenter rapidement les méthodes Agiles vous verrez qu’elles ne sont clairement pas le bon choix.
Pour faire court, en agile, on va devoir travailler avec une liste de besoins que l’on appelle “backlog” et qui peut changer à partir du moment où les besoins en question ne sont pas en cours de développement.
Des livraisons régulières seront effectuées vous permettant de voir au fur et à mesure ce qu’il se passe et d’apporter vos remarques.
Enfin, les tâches les plus importantes sont développées en priorité, ce qui permet d’être certain d’avoir ce qu’il vous faut le plus rapidement.
Vous voyez, la catastrophe, avec une telle méthode vous prenez la mesure de ce qui est fait en temps réel. Pire, vous pouvez même réagir et modifier la liste des tâches en fonction de ce vous avez déjà, de l’évolution de votre entreprise etc. Une horreur, comment voulez vous rater votre projet dans ces conditions ?
Non, soyons sérieux : méthode en V, pas de cahier des charges etc. Les bonnes vieilles recettes, on ne change pas une équipe qui gagne et puis après tout... On fait comme ça depuis 50 ans !
Favoriser le travail en boîte noire, rigidifier la gestion : check !
12. Ceux qui utiliseront le logiciel tu n’écouteras pas
En effet, il ne faut surtout pas interviewer les personnes qui utiliseront le logiciel, il vaut bien mieux penser à leur place. C’est qu’elles pourraient vous apporter la connaissance experte de leur métier, leurs processus, leurs cas d’utilisation, tout ce qui les gêne actuellement et pire, les solutions qu’elles préconisent pour gagner temps et efficacité...
Autre point extrêmement négatif, étant impliquées elles risqueraient d’attendre avec impatience ce nouvel outil performant et adapté qu’elles auraient contribué à réaliser, imaginez... Vous risquez du coup de réussir la gestion de la résistance au changement alors que c’est un atout majeur pour tout louper… Oui, sachez que beaucoup de logiciels sont, terminés, sans bugs et conformes au cahier des charges mais ne sont pas utilisés par les collaborateurs, ils n’en veulent pas.
Mais que les gens sont rustres, vous qui avez fait tellement d'efforts pour imaginer ce qui est le mieux pour eux... Que voulez-vous...
Réaliser un logiciel inadapté et favoriser la résistance au changement : check !
(Ceci est la dernière des trois raisons majeures d'échec)
13. Conclusion
Bon là vous êtes pas mal, normalement votre projet devrait tomber dans les 71% des dossiers ratés en informatique, surtout que vous n’avez pas obligatoirement besoin de tout faire. Quelques-uns de ces conseils devraient suffirent à ébranler votre dossier et avec un peu de mauvaise foi tout devrait s'écrouler sans trop d’efforts.
(Effectivement, selon les experts interrogés, les 3 points les plus importants pour la réussite d’un projet :
- un fort soutien de la direction
- la participation des utilisateurs
- une définition claire du besoin)
Ah oui, et ce sera mon dernier conseil, j’ai déjà insisté à plusieurs reprises, mais usez et abusez de la mauvaise foi, après tout c’est vous qui payez oui ou non ?