Pourquoi les projets TI échouent vraiment (rarement à cause de la technologie)

Il y a déjà sur ce blogue un article sur les raisons pour lesquelles les projets numériques échouent. Il couvre les suspects habituels — exigences floues, dérive de la portée, mauvaise communication. Tout à fait vrai. Mais après deux décennies à travailler au sein d'entreprises, de municipalités et de grandes organisations, je veux aller plus loin. Parce que les modes d'échec les plus dangereux ne sont pas techniques. Ils sont organisationnels. Et ils sont presque toujours visibles avant que le projet commence — si on sait quoi regarder.

Le mauvais commanditaire

Chaque projet a un commanditaire exécutif. La question est de savoir si ce commanditaire est réellement propriétaire du problème, ou s'il a simplement été assigné au projet.

Un commanditaire qui est propriétaire du problème en perd le sommeil. Il se présente aux réunions du comité directeur avec des opinions. Il prend des décisions rapidement parce qu'il comprend les enjeux. Il protège le budget du projet quand le directeur financier vient poser des questions.

Un commanditaire qui a été assigné au projet envoie son chef de cabinet aux réunions. Il approuve des décisions sans lire les notes d'information. Quand le projet frappe un mur — et il le frappera — il est introuvable.

J'ai vu plus de projets tués par le désengagement du commanditaire que par n'importe quelle défaillance technique. Le signe avant-coureur est habituellement visible dès la première réunion de lancement. Observez comment le commanditaire parle du problème. Décrit-il sa propre douleur, ou lit-il une diapositive que quelqu'un d'autre a préparée ?

L'approvisionnement comme tueur de projet

Dans les grandes organisations — surtout dans le secteur public, où j'ai passé beaucoup de temps — les processus d'approvisionnement peuvent détruire un projet avant qu'une seule ligne de code ne soit écrite.

Le problème n'est pas que l'approvisionnement existe. La gouvernance compte. Le problème, c'est quand les échéanciers d'approvisionnement sont complètement déconnectés de la réalité technique. Un processus d'appel d'offres de six mois pour un projet qui doit être en service dans quatre mois. Un cadre de sélection de fournisseurs qui évalue les propositions selon des critères rédigés il y a deux ans pour un autre problème. Une négociation de contrat qui introduit des exigences dont l'équipe technique n'a jamais entendu parler.

Le temps que le projet démarre réellement, la fenêtre s'est souvent refermée. Le besoin d'affaires a évolué. Des parties prenantes clés sont passées à autre chose. Le budget a été reprévu. Et on s'attend à ce que l'équipe livre selon des exigences qui ne reflètent plus la réalité.

La solution n'est pas de sauter l'approvisionnement — c'est d'impliquer le leadership technique dans la conception de l'approvisionnement, pas seulement dans son exécution.

Le comité qui conçoit par consensus

Il existe un type précis de dysfonction organisationnelle que j'ai vu tuer plus de projets que je ne peux compter, et ça se déroule ainsi : on forme un comité directeur. Chaque membre du comité a une définition différente du succès. Plutôt que de résoudre ce conflit dès le départ — ce qui est inconfortable — le comité approuve une portée de projet assez vague pour que tout le monde soit d'accord.

Le projet est lancé. Des décisions se prennent. Chaque décision est jaugée à l'aune de la définition privée du succès de chaque membre du comité. Personne ne s'entend. Le projet s'enlise. La portée s'élargit pour accommoder tout le monde. Le budget explose. L'échéancier glisse. Le moral s'effondre.

On blâme l'équipe technique. On remplace le gestionnaire de projet. On classe un document de leçons apprises. Et six mois plus tard, le même comité approuve le projet suivant avec la même portée floue.

La solution exige quelqu'un avec assez d'autorité organisationnelle pour forcer la conversation difficile dès le début : à quoi ressemble le succès, exactement, et qui tranche quand nous ne sommes pas d'accord ? Si personne dans la salle ne peut répondre à cette question, le projet n'est pas prêt à démarrer.

Les gens qui vont réellement s'en servir

J'ai fait partie de projets où un système entier a été conçu, bâti, testé et lancé sans une seule conversation avec les gens qui allaient s'en servir au quotidien. Les exigences venaient des gestionnaires. Les critères d'acceptation ont été rédigés par l'équipe de projet. La formation a été donnée dans une séance de deux heures la semaine avant la mise en service.

Puis le système est entré en service, et le personnel de première ligne — celui qui comprenait vraiment le flux de travail — a trouvé cent façons dont il ne correspondait pas à la réalité. Pas parce que les développeurs ont mal travaillé, mais parce que personne n'a jamais posé les bonnes questions aux bonnes personnes.

La recherche utilisateur n'est pas un luxe optionnel. C'est le fondement d'un système qui est réellement utilisé. Et se tromper là-dessus coûte cher — pas seulement au lancement, mais sur toute la durée de vie du système, à mesure que les contournements prolifèrent et que l'adoption demeure faible.

Ce que je fais différemment

Avant d'écrire une ligne de code ou de recommander une technologie, je prends le temps de comprendre le contexte organisationnel d'un projet. Qui est le véritable commanditaire ? Quel est son véritable intérêt dans le résultat ? Comment les décisions se prennent-elles, et qui détient un droit de veto ? Qui sont les utilisateurs finaux, et ont-ils été consultés ?

Ce ne sont pas des questions accessoires. Ce sont les questions qui déterminent si un projet réussit ou échoue — bien plus que n'importe quel choix technique.

Après 20 ans, j'ai appris que la meilleure technologie au monde ne peut pas compenser une dysfonction organisationnelle. Mais un projet bien mené, avec une responsabilité claire, un alignement honnête des parties prenantes et une véritable implication des utilisateurs, peut réussir même avec des choix techniques imparfaits.

C'est la partie du conseil que personne ne met dans la proposition. C'est aussi celle qui compte le plus.