Il existe presque autant de manières de rater un projet que de projets. Néanmoins, certains principes, hélas, se vérifient trop souvent. Sans prétendre à l’exhaustivité, nous avons choisi de vous présenter vingt d’entre eux, des valeurs sûres pour (vraiment) échouer dans les règles.
Leçon n° 1 – Foncer comme un taureau sur la muleta (sans poser la question de la valeur du projet)
Un projet n’a de sens que s’il apporte de la valeur à l’organisation. Malgré cette évidence, certains projets sont parfois lancés trop vite, sans réelle justification : parce que le demandeur est « haut placé », parce que c’est l’occasion d’utiliser une « techno sympa », parce qu’on manque de temps ou qu’on ne sait pas faire… Autant de leurres, de mauvaises raisons qui empêchent de se poser la question de la valeur du projet. Bâcler l’analyse préalable de la valeur, voire l’omettre, c’est foncer vers une conclusion qui a peu de chances d’être favorable. Attention, ne nous y trompons pas : le projet pourra se dérouler correctement et même réussir (ô miracle) à livrer le résultat prévu. Néanmoins, un projet bien mené, mais à côté de la plaque au niveau stratégique, ne contribuera pas aux objectifs de l’organisation. Pire, il pourra même détourner des ressources qui auraient pu être utilisées de manière plus judicieuse.
Leçon n° 2 – S’identifier au personnage de Oui-Oui (dire oui à tout et à n’importe quoi)
Dans un projet, comme en toutes choses, l’équilibre des forces est nécessaire. Si le donneur d’ordres est considéré comme un « dieu tout puissant » et que les responsables du projet disent « amen » à toutes ses requêtes, même les plus farfelues, les problèmes ne se feront pas attendre. L’analyse des besoins est un exercice qui ne fonctionne pas s’il est fait à sens unique. Un projet est par essence limité en termes de temps, de budget et de ressources : ne pas en tenir compte et accepter tout et n’importe quoi mène droit aux dérives. Mieux vaut donc être franc avec les utilisateurs et les prévenir quand les demandes deviennent irréalistes.
Leçon n° 3 – Se transformer en « petit père des peuples » (agir en dictateur face aux besoins du client)
De la même façon qu’il est imprudent d’accepter toutes les exigences des utilisateurs, il est risqué de chercher à les deviner, voire de les définir à leur place. Au lieu de les aider à affiner et préciser leurs besoins, on se retrouve alors avec des équipes projet qui interprètent les demandes selon leur propre vision, et réalisent le projet tels qu’ils l’imaginent. Au final, peu de chances que les résultats correspondent à ce qu’attendait réellement le client…
Leçon n° 4 – Jouer à la chasse au trésor (partir en quête de solutions avec un besoin flou)
Il n’y a que dans les histoires qu’une vague carte avec trois indications mène à un fabuleux trésor. Quand le projet implique de faire appel à des prestataires et autres fournisseurs, mieux vaut attendre d’avoir un besoin un minimum cadré et défini avant d’aller les consulter. Sans cela, les commerciaux auront toute latitude pour influencer des clients encore peu sûrs de ce qu’ils veulent, et gonfler ainsi leurs bonus. L’entreprise qui se laisse dicter ses besoins se retrouvera contrainte d’acquérir des options indispensables, ou de payer très cher des conseils dont elle ne fera rien, avec des slides rangés dans les tiroirs… Résultats : des solutions surdimensionnées, des audits qui s’éternisent et des coûts qui grimpent !
Leçon n° 5 – Lancer des dés pipés (passer en revue les différentes options en ayant déjà fait son choix)
Il arrive que des entreprises lancent des consultations et des appels d’offres de pure forme, la donne étant déjà fixée. Entamer un projet en ayant déjà une idée bien arrêtée de la solution qui sera choisie, ou de celles qui seront écartées, n’est pas forcément une mauvaise chose. Cela le devient si l’idée ne repose sur aucune justification concrète : nous sommes alors en présence d’a priori : « c’est notre fournisseur historique » et peu importe s’il n’a aucune légitimité sur le domaine du projet ; « je ne veux surtout pas d’Open Source chez moi », alors que vous en avez sans doute déjà sans le savoir ; « les métiers réclament absolument telle solution », alors qu’en réalité ils n’ont vu qu’une démo lors d’un salon. Mieux vaut laisser ses préjugés de côté le temps d’envisager toutes les options possibles, faute de quoi le risque est de passer à côté d’options ou de fournisseurs valables et pertinents.
Leçon n° 6 – Devenir daltonien (ne pas définir une vision commune de la qualité)
La qualité ne va pas de soi, ne se crée pas automatiquement et n’a rien d’évident. Ce qui semble vert pour l’un sera loin de l’être pour l’autre. Il est important de se mettre d’accord avec le client sur les critères qui définiront la qualité des livrables et des résultats, et celà dès le démarrage du projet. Sinon, on se prépare une longue succession d’incompréhensions et de désaccords.
Leçon n° 7 – Devenir adepte du « One size fits all » (la même taille pour tout le monde)
« Des spécificités ? Quelles spécificités ? De toute façon, ce projet est le même que celui qu’on a fait pour untel… » Voilà un moyen sûr pour aller dans le mur. Si beaucoup de projets se ressemblent, ils ne touchent pas forcément les mêmes populations, ils n’interviennent pas dans le même environnement, ont des périmètres différents et n’ont pas à faire face aux mêmes contraintes opérationnelles. Parfois, ce sont la culture d’entreprise ou les rapports de pouvoir qui diffèrent. Occulter ces différences est dangereux, ne serait-ce qu’en termes de conception de la solution ou de conduite du changement.
Leçon n° 8 – Adopter une hydre à neuf têtes (quand plus personne ne sait qui est responsable)
Trois personnes ayant des responsabilités de chef de projet sur un même projet, un parrain qui assure également la gestion opérationnelle du projet, un stagiaire qui prend les décisions ou au contraire une équipe qui ne sait vers qui se tourner… Autant de cas où les responsabilités n’ont pas été définies et établies de manière claire.
Conséquence : une absence de management ou, pire, des conflits sur les décisions à prendre, qui font que le projet n’avance pas. Si personne ne se sent responsable, ou si au contraire tout le monde se croit responsable, cela aboutit à une situation ubuesque, où plus personne ne sait qui décide quoi. On ne le redit jamais assez, il ne faut pas diluer les responsabilités : définir et assigner les rôles est indispensable.
Leçon n° 9 – Appliquer au planning les principes de la logique floue
En matière de planification, l’imprécision n’aboutit que rarement à une bonne solution. En effet, la plupart du temps, les équipes chargées de la réalisation du projet n’ont pas que celui-ci à gérer. Elles peuvent avoir d’autres projets en parallèle, ou bien des activités opérationnelles qui leur prennent du temps. Le chef de projet doit donc préparer un planning suffisamment précis pour permettre à tous de s’organiser. Si le planning se contente d’indiquer les grandes phases sans préciser les activités à mener, la durée estimée et les personnes responsables, les membres de l’équipe risquent de faire passer le projet en dernier dans la liste de leurs priorités. Résultat : un magnifique « effet tunnel », avec un projet qui se voit sans cesse relégué aux calendes grecques.
Leçon n° 10 – Confondre planning et « to do list »
Établir un planning précis constitue une bonne pratique, à condition de ne pas basculer dans l’excès, ni de noyer les équipes sous les détails. En dehors de cas particuliers comme la formation d’un débutant, inutile de tout préciser jusqu’à la moindre ligne : cela risque même d’être contre-productif. Qu’ils soient développeurs, architectes ou experts sécurité, les membres de l’équipe, surtout s’ils sont expérimentés, savent ce qu’ils ont à faire pour produire le résultat demandé. Si le chef de projet ou le client entreprennent de leur expliquer leur métier, les relations vont vite se tendre. En outre, avec un planning trop détaillé, l’équipe peut aussi perdre de vue les objectifs réels, se décourager ou encore passer du temps sur des tâches qui ne sont pas essentielles. Le planning très détaillé n’est pertinent que sur des échéances courtes, comme une semaine.
Leçon n° 11 – Pratiquer les estimations au doigt mouillé
Généralement, les prestataires qui vendent un projet à un client ont tendance à gonfler artificiellement les charges pour facturer plus. En ce cas, le seul à souffrir est le porte-monnaie du client. Parfois, cependant, certaines charges sont sous-estimées, notamment pour les projets gérés en interne. Le risque est alors de se retrouver avec des équipes sous pression, surchargées de travail, et, là encore, un projet en retard.
Leçon n° 12 – Méconnaître la loi de Murphy
Le pire est toujours sûr, comme le dit en substance cette fameuse loi de Murphy. Dans le cadre d’un projet, mieux vaut donc être réaliste et gérer les risques plutôt que de subir de plein fouet les imprévus. Outre les facteurs énumérés dans cet article, chaque projet a ses propres risques : ceux-ci peuvent être liés, par exemple, au contexte politique dans l’organisation, à la feuille de route des fournisseurs clés, au niveau d’expérience et à la motivation des équipes, ou encore au désir de certains « d’aller voir ailleurs si l’herbe est plus verte ». Oublier ces éventualités s’avère dangereux. Confronté à la concrétisation d’un de ces risques, le projet peut se retrouver au pied du mur, bloqué parce qu’une compétence manque, qu’un produit n’est plus supporté ou qu’un « grand manitou » s’y oppose.
Leçon n° 13 – Faire l’autruche
Lorsqu’un problème survient, la procrastination (remettre au lendemain ce que l’on peut faire le jour même) peut sembler une option séduisante. Qui sait, avec un peu de chance, le problème n’aura pas de conséquences et personne ne s’en rendra compte… Et c’est ainsi que l’on se retrouve avec une multitude de problèmes non résolus à traiter à la dernière minute : autant de petits problèmes qui en sont devenus un gros. Pour qu’un projet se déroule de manière fluide, il est préférable d’estimer son impact dès que celui-ci se présente, et de prendre des mesures pour le résoudre rapidement. Si le problème ne peut être résolu par l’équipe projet, ne pas hésiter à remonter au management…
Leçon n° 14 – Se transformer en « Grande Muette »
« Ne pas oublier la communication » est un conseil si souvent répété qu’il en devient un mantra des projets systèmes d’information. Si on l’entend aussi souvent, c’est que rares sont les projets où la communication fonctionne comme prévu… Lorsqu’elle est prévue ! Certains sont même de véritables boîtes noires : les informations nécessaires pour le démarrage sont fournies par les clients, mais ensuite ceux-ci n’ont plus qu’à attendre la fin du projet en croisant les doigts. Rares sont les informations qui leur parviennent en cours de route, et quand elles existent, elles sont bien souvent tronquées ou inadaptées. Il existe aussi des projets où personne ne se parle, y compris les membres de l’équipe entre eux. Les experts restent dans leur coin, les développeurs se contentent de coder et le chef de projet, n’arrivant pas à obtenir la visibilité nécessaire sur le travail fourni, produit de beaux rapports vides, qui ne sont lus par personne. Les outils collaboratifs constituent-ils une solution ? Probablement pas… Aucun outil en tant que tel ne pourra jamais générer de la communication là où il n’y a pas de volonté de partager l’information.
Leçon n° 15 – Accueillir avec bienveillance tous les parasites
Tâches non prioritaires et interruptions incessantes peuvent vite générer une surcharge de travail. Même les meilleurs peuvent se retrouver submergés s’ils sont sans cesse dérangés par d’autres sollicitations moins importantes. Cela va du collègue qui demande un conseil, pas bien gênant en soi, sauf si c’est dix fois par jour, aux chargés de clientèle qui leur remontent toutes les questions un peu hors normes de leurs clients, en passant par les responsables qui imposent de remplir quinze pages de rapports d’activité et de reporting tous les deux jours… qui finiront dans un tiroir. Tout cela laisse peu de temps aux équipes projets pour faire le travail pour lequel elles sont payées, à savoir livrer le projet en temps et en heure. Un bon manager doit aider son équipe à filtrer les tâches et événements parasites.
Leçon n° 16 – Multiplier les pénalités pour l’équipe projet
Pour qu’une équipe projet fonctionne bien, elle doit communiquer facilement. Il faut le vouloir, comme nous l’avons vu, mais il faut aussi le pouvoir. Sans espaces de travail et de réunion partagés, cela sera déjà plus délicat. Si les membres de l’équipe projet sont répartis dans quinze lieux différents, il va être difficile de les coordonner, même avec les meilleurs outils collaboratifs du monde. De même, l’infrastructure mise à leur disposition a son importance : s’ils n’ont pas de machines dédiées aux tests par exemple, il ne faudra pas s’étonner que ceux-ci soient négligés.
Leçon n° 17 – Envoyer la documentation dans un trou noir
La rédaction de la documentation est rarement une partie de plaisir pour les équipes. C’est même considéré comme une corvée. Bien souvent, la documentation se retrouve peu à peu happée par un trou noir au fil du projet. Pourtant, elle est cruciale pour assurer la réussite du projet dans le temps, et permettre aux clients de maîtriser les résultats livrés. Même un code qui semble clair dans l’esprit de son concepteur ne le sera pas forcément pour un autre. Sans documentation, comment feront les entreprises le jour où elles voudront effectuer une petite modification ? Soit elles feront appel aux personnes ayant travaillé sur le projet, mais encore faut-il que ces dernières n’aient pas changé d’employeur, ni été affectées à un autre projet et qu’elles soient disposées à collaborer… Soit elles tenteront de confier la tâche à des tiers, qui devront parfois scruter le code ligne par ligne avant de s’y retrouver.
Leçon n° 18 – Se lancer sans filets (en négligeant les tests)
Un projet n’est pas une mission spatiale, certes, mais il faut tester et retester ! Là encore, il s’agit d’une antienne souvent entendue. Mais la réalité est moins rose que ce que l’on croit. Les tests sont encore trop souvent sous-estimés, insuffisants voire zappés, faute de temps, de ressources, de moyens techniques… Pourtant la phase de test est tout sauf une option, en particulier pour les projets stratégiques : par exemple, ne pas tester les performances d’un site Web de e-commerce est une excellente méthode pour garantir un crash le jour du lancement.
Leçon n° 19 – Raconter une histoire sans fin
Un projet est un peu comme un conte. Pour que les héros mènent leur vie heureuse et sans histoires, il faut à un moment donné qu’intervienne le mot « Fin ». Un projet qui n’a pas de clôture officielle risque de se retrouver tapi, caché dans les recoins, mais prêt à ressurgir à la moindre velléité des utilisateurs ou clients.
Leçon n° 20 – S’inspirer des méthodes de certains fournisseurs
Beaucoup de vos fournisseurs (mais pas tous, heureusement) appliquent la technique des 3F (Find it, F… and Forget), autrement dit : trouvez un client, b…-le et oubliez-le ! Pourquoi ne pas faire de même avec les clients et utilisateurs d’un projet ?