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…