Que les choses soient bien claires : je parle ici des raisons de ne pas lancer un projet en particulier car il est voué à  l’échec, étant entendu qu’à  l’inverse il y a des projets qui ont toutes les chances de réussir. Un petit guide pour trier le bon grain de l’ivraie donc.

1°) Votre interlocuteur veut des droits par niveau hiérarchique : il est impossible qu’un utilisateur lambda ait les mêmes droits que son supérieurs et ainsi de suite. A la fin le simple collaborateur n’aura que le droit de lire (et encore pas tout) sans réagir. Cela s’appelle un intranet et ça existe déjà .
2°) Votre interlocuteur fait une fixation sur la gestion documentaire : les technologies 2.0 traitent davantage d’échanges, et les contenus s’appréhendent plus comme un flux que comme un stock. S’il veut un répertoire partagé cela existe également déjà .
3°) 50% des membres de l’équipe projet ne sont utilisateurs ni de facebook, ni de linkedin : cela signifie que ceux qui seront vos relais et les chevilles ouvrières du projet n’ont aucune expérience du fonctionnement en réseau, des pratiques etc…Vu les sollicitations en la matière cela n’est pas un accident, ça traduit un refus du concept.
4°) Votre interlocuteur veut mettre en place des workflows de publication : personne ne publie rien sans l’imprimatur hiérarchique. Or l’objectif du projet n’est il pas de fluidifier les échanges ? En attendant on transforme le responsable en gare de triage, comité éditorial, censeur (plusieurs réponses possibles) et on est sur d’avoir un impact sur la productivité. Mais pas celui qu’on attend.
5°) Votre interlocuteur veut un planning prévisionnel de l’évolution des comportements : Humm…comment vous dire ? L’humain est irrationnel et encore davantage lorsqu’il est interconnecté.
6°) Votre interlocuteur vise une population cible de gens qu’il aimerait voir travailler ensemble mais qui n’ont aucune raison de le faire : il essaie de résoudre par la technologie un problème de management et ça ne marchera pas.
7°) Votre interlocuteur n’a aucun pouvoir sur la population cible : il va donc parler de voeux pieux à  des gens dont il ne peut changer le quotidien.
8°) Votre interlocuteur ne veut en aucun cas que ses collaborateurs changent leur manière de travailler : on ne fait pas de neuf sans toucher au vieux, surtout s’il c’est ce qu’on veut améliorer.
9°) Votre interlocuteur a pour objectif d’installer une plateforme 2.0: sans se soucier de son utilité. Il oublie que c’est la fonction qui crée l’organe et qu’il y a assez de plantes vertes sur les bureaux pour ne pas en ajouter sur les intranets.
10°) Votre interlocuteur a pour objectif ultime de collaborer et partager l’information : « collaborez et partagez l’information » ne veut rien dire pour ses équipes. Il faut leur dire clairement ce qu’on attend qu’ils fassent. En plus ce ne sont que des moyens : les vrais buts sont opérationnels et les méconnaitre empêche d’évaluer le projet. Cela empêche même que le projet avance et reçoive le moindre support, manque de sens oblige.
11°) Votre interlocuteur (en tout cas celui qui achète et paie) n’a pas sa place dans le projet qui va démarrer : Il va donc partir à  la pêche aux projets et dire à  quelqu’un qui n’a rien demandé : on va expérimenter sur tes équipes pour un besoin que tu n’as pas identifié et mettre en place quelque chose que tu n’arrives même pas à  visualiser. Pire, en recrutant une population de volontaires désignés, il peut saborder le projet en donnant l’impression de faire du détournement de ressources.
12°) Le manager de l’équipe a pour surnom Terminator : et à  l’habitude de répondre à  tout par « c’est nul », « tais toi et bosse ». Sur que ses premières contributions risquent de donner à  tout le monde l’envie de continuer.
13°) L’équipe projet n’a pas la moindre idée de l’utilisation qui sera faite des contenus : rien ne sert de produire du contenu qui n’est pas réutilisé dans le travail des collaborateurs. Une boite à  idée que personne ne lit ne risque pas de donner naissance à  quoi que ce soit. Une « bulle informationnel » sans connexion avec le business réel ne sert à  rien. Et finit par mourrir d’elle-même d’ailleurs.
14°) Votre interlocuteur n’envisage de recourir à  la conduite du changement qu’en cas de succès du pilote : ce qui veut dire en gros « je mettrait les mains dedans [je me mouillerai] qu’à  condition d’avoir la preuve que ça peut marcher sans qu’on le fasse ».
15°) Votre interlocuteur veut tester un outil : une fois qu’il aura validé les fonctionalités à  blanc il sera bien en peine de prouver quoi que ce soit faute d’une utilisation pertinente en contexte business. Au pire il va faire du reverse engeneering : « maintenant qu’on a un outil, trouvons lui une raison d’être ».
16°) Votre interlocuteur veut des échanges « one to one » : il s’inquiète que ce qu’échangent deux personnes puisse être lue par une troisième. C’est un email qu’il lui faut.
17°) Votre interlocuteur n’a pas le temps : cela veut dire qu’il veut que ça fonctionne seul, sans qu’il se mouille et que vous ne pourrez pas compter sur son « executive sponsorship ».
18°) Votre interlocuteur confond leadership, expertise et hiérarchie : il veut bien être sur que les expertises qui émergeront correspondront à  ce que l’entreprise a décrêté et qu’un stagiaire ne peut pas avoir une meilleure idée que son boss.
19°) Votre interlocuteur veut un pilote de 1 mois pour 10 personnes : au bout duquel il est certain de ne rien démontrer.
20°) Votre interlocuteur attend la fin du pilote pour en faire un projet business : il veut donc faire travailler ses équipes sur des choses peu importantes pour lesquelles on est sur qu’elles ne se mobiliseront pas avant de passer à  des sujets sur lesquelles elles attendent qu’on facilite leur travail quotidien.

Et la dernière :

Dès que vous parlez de l’aspect « social », du centrage sur l’individu, il vous répond « oh la attention…on est pas là  pour faire des RH hein ! ».

A contrario vous pouvez en tirer quelques conditions de réussite…

 
  • Formidablement clair et explicite.
    Je m’en vais coller ça sur le forum 2.0 (oui) que l’on m’a demandé de créer sans objectifs métiers, sur un groupe pilote très restreint et fermé d’experts divers qui n’utilisent pas de réseaux sociaux, juste « pour voir » et pour collaborer.
    Et le faire suivre par mail (sinon, il ne le lira jamais) à  mon « sponsor » en cochant toutes les lignes qui correspondent à  notre merveilleux exemple.
    Merci !

  • Vincent M

    Brillant !

  • Thierry

    Je souhaiterais nuancer le n°3 :

    Le fonctionnement en réseau et les pratiques collaboratives existaient avant facebook, linkedin et consorts…

    Ceci étant dit, c’est une très bonne synthèse des meilleurs arguments pour que les choses n’avancent pas ! 🙂

  • Très bon article !

  • Romain D

    Merci, excellent article, et l’on retrouve beaucoup de faits vécus. J’aimerai nuancer toutefois le point 4 sur les workflow de publication. Non pas qu’il faille tout verrouiller et que seul un « comité restreint d’élus » puisse publier de l’information, mais dans le cas contraire, si tout le monde est responsable, alors personne ne l’est non plus.
    Pour l’avoir mis en place dans différents projets, les workflow ont une utilité lorsqu’il s’agit de « populer » la voà»te documentaire. Ils n’ont pas d’utilité par contre pour les espaces de collaboration. Qu’en pensez-vous ?

  • @Romain D : bien sur il faut un minimum de contrôle. Même si l’expérience montre que très souvent il suffit que ce contrôle soit possible sans qu’il soit nécessaire de l’exercer : s’il s’agit de faire n’importe quoi et de semer la pagaille les collaborateurs évitent ces expaces ou tout est visible et tracé pour utiliser le bon vieil email.
    Il est évident qu’un worflow doit exister pour les contenus officiels…mais dans ce cas on parle plus de l’intranet traditionnel que de plateformes de réseaux sociaux.
    Pour ce qui est des espaces collaboratifs o๠on est davantage sur l’échange, la proposition en contexte opérationnel c’est comme si on devait soumettre toute intervention lors d’une réunion projet à  celui qui l’organise. Non seulement ça n’apporte rien mais ça dévore énormément de ressources.

  • Romain D

    Merci Bertrand pour ce complément, vous me confirmez que votre axe de pensée était strictement sur l’axe collaboratif.

  • j’applaudis de toutes les mains disponibles!
    et j’ai ri aussi même si ce n’est pas drôle… 😉

  • La forme Bertrand, le Terminator m’a fait bien rire 🙂

    Ceci étant si on t’écoute peu de projets verraient le jour 😉

    • @Vincent : malheureusement l’important n’est pas qu’un projet puisse voir le jour. L’important est qu’il réussisse…sinon le lancer n’aurait aucun sens. Alors bien sur plus tu lances de bouteilles à  la mer plus tu as de chances d’en voir une tomber entre de bonnes mains. Maintenant un manager est également (et surtout aujourd’hui) jugé à  l’utilisation faite des ressources. Quand tu n’as qu’une ou deux balles dans ton fusil tu ne te comportes pas comme si tu avais une caisse de munitions à  coté de toi. C’est de ta capacité à  réussir un coup au but quasiment du premier coup que dépendent les ressources supplémentaires que tu pourras demander pour aller plus loi.
      Autant je n’apprécie pas les crises de rigueur mal placées autant il est quand même important de ne pas partir dans tous les sens.

      Remarque en termes méthodologiques : rien n’empêche de lancer un projet lorsqu’on a identifié plusieurs de ces points. Il faudra simplement les « évacuer » en amont pour se donner toutes les chances de réussites. Ca s »appelle du pilotage par les risques et ça ne me semble pas hors de propos non ?

  • Cyril

    Bonjour,

    Merci pour cet article.
    Je rejoins beaucoup de ces points (à  vrai dire, la totalité). Une question sur le point 2 et la gestion documentaire : on parle d’échanges, d’instantanéité, de flux d’informations, on est d’accord … est-ce un soucis qui m’est propre que de vouloir tout garder sans cesse ? je peux le concevoir, mais peut-être un « stock » (mot à  mesurer) est nécessaire après un tri/sélection « naturelle » des informations ? je reconnais avoir tendance comme beaucoup de monde à  stocker les informations pour au final ne pas les reconsulter (histoire de me donner bonne conscience) .. mais les informations primordiales ? checklists, livres blancs ? ne pourrait-on pas nuancer le propos ?

  • Cyril

    Disons après relecture des commentaires que nous considérons ce point sur l’aspect collaboratif. Je rejoins alors 🙂

  • Vraiment très bon article Bertrand! Par rapport à  la nuance apportée par Thierry. Je pense que Bertrand a raison de souligner l’importance des réseaux en ligne même si Thierry dit que cela existait déjà  avant. La différence avec ces réseaux et les outils collaboratifs est qu’ils sont ouverts et sociaux.