Session spectrum groupe
Présentation de la session « Retours d’expériences collaboratives » par Michel Operto.

Courant décembre 2013 a eu lieu la 2ème Journée du Management de Projet, événement dédié à la gestion de projet, au centre de conférence de Microsoft. Plus d’une centaine de personnes ont assisté aux 6 interventions regroupées en 2 thèmes, à la présentation des nouveautés Microsoft et à la table ronde finale.

Nous avons été invités à partager notre expérience de management de projet de déploiement de plateforme collaborative. Ce fut l’occasion de prendre du recul sur notre méthode de travail. Voici donc le résultat de cette réflexion (postures, méthodes, phases projet) accompagnée d’un retour d’expérience de transformation d’un projet d’expérimentation de plateforme collaborative (Confluence) pour le groupe Thales en un véritable déploiement.

Management de projet: Postures, méthode

Les projets de déploiement de plateformes collaboratives, de Réseaux Sociaux d’Entreprise (RSE), ou plus généralement de solutions de gestion de l’information sont des projets complexes. En effet, l’utilisation de ces outils (2.0) touchent autant « l’humain » que la partie « outils ». La culture du numérique et du collaboratif n’est pas encore réellement diffusée en entreprise. D’une part, les parties prenantes du projet doivent être représentatives des futurs utilisateurs, avec toute la diversité de leurs situations d’usages. D’autre part, les fonctionnalités des  nouvelles plateformes collaboratives se comptent en centaines même pour les plus simples; En 2012, YoolinkPro, une des solutions les plus simples et « user friendly » du marché a comptabilisé 138 fonctionnalités.

Aborder un système complexe constitue souvent une difficulté; en réduire la complexité par l’expérimentation est à notre avis plus approprié que prétendre la « résoudre » par un cahier des charges qui tend vers l’exhaustivité.

Pour ce type de projets (souvent nouveau dans l’organisation), commencer par un cahier des charges peut s’avérer contre productif, et causer une perte de temps. Les paramètres humains et techniques sont nombreux, interdépendants et souvent non entièrement connus à l’avance. L’expérimentation permettra, en revanche, de découvrir de nouvelles facettes, d’identifier des problématiques pertinentes, d’analyser les paramètres projet et de mieux cerner les nouveaux usages pour un déploiement plus fluide par la suite (à lire « Réseaux sociaux d’entreprise : faut-il brûler le cahier des charges ?« ).

Posture du chef de projet « expérimentation »

Un projet du « collaboratif » efficace commence par un questionnement: « Où avez-vous mal ? », « À qui s’adresse la plateforme ? ». L’animation d’ateliers d’exploration facilite une co-construction du projet en modélisant les modes de travail existants autour d’une vraie problématique (un business case) :

  • Comprendre les processus,
  • Dessiner les interactions humaines,
  • Analyser  les flux d’informations,
  • Étudier les échanges de documents
  • etc.
  • ==> Modéliser et imaginer des Usages 2.0
Atelier d'exploration
Support d’atelier d’exploration. Description de flux interactions d’un projet de création d’un nouveau site (pris d’un cas réel).

En effet, connaître les problématiques clients et leurs méthodes de travail permet de commencer le projet par des problèmes concrets à résoudre. La posture du chef de projet devient celle de l’expérimentateur, ou aussi du chef de projet innovation. Ces situations réelles sont alors des terrains d’expérimentation !

Parlons d’expérimentations au pluriel car se limiter à un seul terrain est risqué. En avoir quelques-uns (3 à 4) permet non seulement de diversifier les cas à analyser et avoir plus de hauteur de vue, mais aussi garantit la pérennité de la démarche, au cas où l’une des expérimentations stagne.

Cette phase de POC (proof of concept) permet de découvrir les besoins, de valider des usages et de récolter des bonnes histoires/pratiques : graines des futures réussites.

Posture du chef de projet « déploiement »

Se limiter à la posture « expérimentale » et perdre de vue la réalité d’un projet de « déploiement » est un écueil classique. En effet, l’expérimentation est la première phase d’un projet souvent plus grand, plus ambitieux. Un projet « Entreprise 2.0 » modifie les méthodes de travail, impacte le management et peut avoir des effets sur l’organisation.

Notamment il est nécessaire de  :

  • anticiper les risques
  • gagner les sponsors du projet pour en légitimer les actions futures
  • révéler des utilisateurs « champions » et les convertir en véritables « boosters » des usages collaboratifs
  • définir une stratégie de conduite de changement adéquate

Il est évident que la posture idéale d’un chef de projet est celle d’un expérimentateur qui porte la « vision long terme ». Un propos qui semble trivial, mais souvent difficile à mettre en oeuvre sur le terrain, où l’une ou l’autre des posture peut prendre le dessus.

Du POC au déploiement – Retour d’expérience, cas Thales

Le projet

Passer d’une expérimentation réussie à un projet de déploiement n’est pas immédiat. Ce retour d’expérience illustre notre posture de management de projet dans la préparation d’un déploiement groupe après une expérimentation.

Nous sommes intervenus en 2011, dans un projet d’expérimentation victime de son succès. Un premier POC avait commencé en 2006 se propageant rapidement de bouche à oreille pour atteindre un grand nombre d’utilisateurs quotidiens (+ 2000 personnes)… toujours en mode expérimental, spontané et libre.

Ce projet n’était pourtant pas appuyé par une communication interne. Des usages spontanés se sont multipliés :  projets agiles, veille partagée, organisation d’événement , bases de connaissances, etc.  Mais cette multitude de méthodes s’est faite sans unité… Si ce constat de richesse est très encourageant en phase expérimentale – il s’est transformé en un vrai « casse-tête » quand la volonté d’en faire un déploiement Groupe s’est présentée. Plusieurs difficultés ont fait surface :

  • Quels usages déployer finalement ?
  • Comment accompagner le changement dans une telle diversité ?
  • Quelle gouvernance prévoir ?
  • Comment gérer le risque de non acceptation de contrôle par des « expérimentateurs » finalement habitués à une certaine liberté ?

Pour répondre à ces questionnements, la démarche s’est déroulée en trois étapes :

La première étape est une phase d’observation de l’existant :

  1. un « audit » qui permet d’identifier les usages, les bonnes pratiques qu’une expérimentation aussi riche et longue a pu dégager.
  2. construire une feuille de route pour piloter une phase de déploiement à un périmètre plus large.

Nous avons interviewé une dizaine d’utilisateurs de la plateforme sur diverses thématiques (contexte, statistiques, lacunes, usages, architecture, appropriation) caractérisant  leurs espaces collaboratifs. Ces utilisateurs illustraient la diversité des usages, des métiers, des profils.

La deuxième étape est une phase de synthèse. Elle met en avant les points forts, identifie les points à améliorer.

Nous avons pris le choix de se limiter à 4 points / actions clés par thème audité. L’équipe projet peut ainsi prioriser les livrables.

Guide simplifié d'audit
Guide simplifié d’audit

La troisième étape est une phase d’ateliers en mode itératif.

Le projet comptait 5 thèmes x 2 itérations, soit une dizaine d’ateliers, déroulés en 10 semaines.

La durée classique d’un atelier est de 2 à 3 heures.

La gouvernance générale de la solution a été repensée pour s’assurer de la bonne diffusion des usages et permettre ainsi un déploiement plus large et efficace (à lire: retour d’expérience présenté au salon de l’intranet de 2011).

Les enseignements

Il est vrai que cette approche projet n’est pas du tout classique. Elle peut nécessiter un temps d’appropriation, vu certaines caractéristiques :

  • Durée très courte (relativement),
  • Rythme assez dense,
  • Pas de jalons figés ou un diagramme détaillé, étayés dans le temps, mais plutôt des phases projets contenant des itérations,
  • Nécessite une disponibilité élevée de la part des acteurs impliqués.
  • Logique de co-conception et d’implication des acteurs (clients) dans la prise des décisions et la  réalisation des livrables 
  • ==> Rôle du consultant : facilitateur 
Appropriation
Approche projet « itérative » – les difficultés de l’appropriation

Pour réussir un tel projet, le consultant – facilitateur doit redoubler d’efforts :

  • Prendre le temps nécessaire pour expliciter / expliquer la démarche

Une démarche itérative ne veut pas dire illimitée. Afficher dès le départ le nombres d’itérations permet d’éviter des dérives planning.

  • Etre à l’écoute pour pouvoir réagir et adapter la méthode et les livrables. L’approche peut déstabiliser quand on la pratique pour la première fois.

L’équipe peut avoir l’impression de ne pas savoir où l’on va. Avoir une posture d’accompagnement du changement dans toutes les phases du projet permet d’atténuer ce sentiment.

  • Impliquer et responsabiliser l’équipe projet.

Encore une fois, le consultant – facilitateur est maitre du cadre projet pas du projet en lui même. Chaque atelier avait un responsable interne au projet.

Clefs de réussite
De l’expérimentation au déploiement – approche « consultant – facilitateur », les clés de succès.

Les bénéfices sont indéniables. Nous avons pu observé dans ce projet 1) une meilleure prise de décision 2) une amélioration de la productivité ainsi qu’une 3) implication plus forte des acteurs projet. Enfin pour en savoir plus : un aperçu rapide de notre méthodologie est présenté ici.

Laisser un commentaire

Fermer le menu