Comment mettre en place une feuille de route pour un projet informatique ?

« Alors on en est où ? »

Cette question anodine suscite à la fois de l’enthousiasme (quand on a bien avancé) mais aussi beaucoup de frustration (quand on est en retard ou qu’on ne sait pas).

Pour arriver à y répondre sans stress, il y a un outil imparable, à la fois collaboratif et structurant : le feuille de route (ou roadmap).

Quelle que soit la forme que vous lui donnez, la feuille de route permet à tous les intervenant•es d’un projet informatique :


  • Identifier les rôles et les relations entre chaque personne
  • Comprendre les objectifs du projet
  • Suivre les avancées et les communiquer
  • Prioriser et réagir en cas de retard

C’est l’outil qu’il vous faut ? On vous explique en quelques étapes comment définir votre feuille de route IT.


#1 — C’est quoi une feuille de route concrètement ?

Une feuille de route, également appelée roadmap, est un document qui présente les principales étapes à suivre pour réaliser un projet. Ces étapes ont pour vocation d’être ensuite planifiées dans le temps.

Pour un projet informatique, à quelques spécificités près, le découpage est assez standard :


  1. Analyse de l’existant
  2. Conception
  3. Développement
  4. Test
  5. Déploiement
  6. Maintenance


#2 — Comment structurer une feuille de route ?

Une feuille de route se structure en trois grandes parties :


  • Tout d’abords, vous définissez des « jalons », c’est-à-dire un ensemble de temps forts et/ou d’objectifs à atteindre
  • Dans ces jalons, vous spécifiez des tâches à réaliser pour atteindre chaque objectif. En fonction des jalons, il y a peut-être un ensemble de tâches à rassembler en « chantier », qui constituent un « sous-jalon »
  • Pour chaque tâche ou chantier, vous associez des personnes qui auront chacune des responsabilités dans la réalisation des tâches
  • Ceci fait, vous inscrivez un niveau de priorité et des échéances pour chaque tâche ou chantier
  • À l’issue de ce découpage, vous avez suffisamment d’éléments pour faire un planning


#3 — Quels sont les contenus les plus importants à suivre dans une feuille de route ?

Pour que votre feuille de route soit efficace, il y a plusieurs éléments importants à intégrer, et à valider régulièrement :


À intégrer À valider
Les charges temps Combien de temps faut-il pour réaliser une tâche ?
Ce temps a-t-il été respecté ?
Le budget Combien a-t-on investi pour aboutir un jalon ?Combien a-t-on réellement dépensé ?
Les rôles et responsabilités Les rôles sont-ils cohérents ?
Les niveaux de responsabilité sont-ils clairs ?
Les effectifs sont-ils suffisants ?

C’est uniquement sur la base de ces éléments, qu’il est possible de définir une feuille de route claire, et suffisamment précise pour piloter un projet.


#4 — Comment mettre à jour une feuille de route ?  

Nous mettons une feuille de route à jour dans les situations suivantes :


  • Quand un chantier, une tâche ou un jalon est terminé
  • Quand un risque vient impacter ou remettre en question la réalisation d’un chantier ou d’une tâche
  • Quand une tâche a été mal estimée, ou qu’une nouvelle tâche doit être ajoutée et planifiée


#5 — Qui doit avoir la charge du suivi d’une feuille de route ?

Une feuille de route est gérée et pilotée par un•e chef•fe de projet, qui la met à jour en collaborant avec les différents intervenant•es du projet :


  • Les équipes métiers ;
  • Les services IT ;
  • Les intervenant•es externes.


#6 — Quels sont les supports les plus pertinents pour mettre en forme une feuille de route ?

Il n’existe pas de supports prédominants pour définir une feuille de route, cela dépend des affinités du/de la responsable du projet, avec les outils qu’il/elle utilise habituellement.

En revanche, on peut identifier des usages spécifiques en fonction du support :


  • Les outils de bureautique (type Suite Office) :
    • EXCEL : Utiliser pour définir le planning et organiser les chantiers du projet
    • PowerPoint : Utiliser pour communiquer les avancées et réaliser le reporting lié à la feuille de route
    • Sharepoint : Utiliser pour communiquer les avancées de manière plus ludique et visuelle, pour associer des documents
  • Les outils de gestion de backlog type JIRA ou Trello : Outil tout-en-un, très orienté développement informatique, pour planifier et définir les chantiers d’un projet en même temps
  • Les outils de planning type Planner ou Monday : Outil collaboratif, plutôt orienté processus, qui permet à la fois de planifier et de donner une vue d’ensemble au projet



Une fois structurée, les rôles clarifiés et les différentes charges du projet définies, le suivi d’une feuille de route offre plusieurs bénéfices :


  • Fluidifier la communication : Une feuille de route est facile à lire ce qui permet de rapidement communiquer sur ses avancées, blocages, etc. auprès de n’importe quel interlocuteur d’un projet
  • Renforcer la collaboration : Ce document unique et central permet de renforcer les échanges et le travail entre les équipes IT et les équipes métiers
  • Faciliter la prise de décision : Une feuille de route permet de rapidement mettre en avant des risques capacitaires, financiers ou les conflits de planning, afin de prendre des décisions
  • Prioriser les chantiers : Une feuille de route permet rapidement d’identifier et de définir des priorités vis-à-vis des jalons importants, de leur complexité de réalisation et des délais de livraison


Prêt à mettre en pratique nos conseils ?

Voici un outil signé Cool Kit pour vous exercer à définir votre feuille de route informatique
➡️ https://coolkit.coolitagency.fr/toolspage/details/14 ⬅️


Transformation digitale : quels sont les impacts de la surcharge d’outils ?

« On ne pourrait pas trouver un outil pour ça ? » Qu’il s’agisse de sujets RH, IT, commerciaux ou managériaux, on vient à poser cette question pour combler un manque ou pour gagner en efficacité. Au prime abord, cette question peut paraître sans risque.

Cependant, à force de la répéter, on peut frôler alors le « solutionnisme technologique »[1]. Cette idéologie sociale, véritable biais de notre ère numérique, transforme chaque problème en sujet technique, auquel on apporte une solution technique, même quand le problème n’a pas été pleinement adressé aux personnes concernées. En d’autres termes, à force mettre en place logiciel sur logiciel, application sur application, on en oublie les problèmes de fond.

Un outil est un moyen de résoudre des problèmes, mais il n’est jamais une solution « miracle ». Alors quels sont les impacts de la surcharge d’outils sur l’entreprise ? Comment éviter d'installer trop d'outils ?

#1 - Les impacts sur l’Humain

Derrière chaque nouvel outil, il peut y avoir 2 types de besoin

  • Le Besoin Interne, remonté par le Métier ou le Management
  • Le Besoin Externe, remonté par le Client ou le Commercial ou le Marketing

…Et plusieurs parties prenantes :

  • La direction et le management
  • La chefferie de projet
  • Les équipes techniques
  • Les équipes métier
  • Les ressources externes

Quels sont les impacts de la surcharge d’outils sur ces personnes ?

  • Le rejet et le désengagement
  • La perte de cohésion
  • Des difficultés à maintenir l’activité opérationnelle
  • Le cloisonnement
  • L’augmentation de risques psychosociaux

À quel moment, on se risque à imposer une surcharge ?

  • Quand on ne prend pas le temps de questionner le besoin en fonction de l’émetteur
  • Quand on n’étudie pas le temps, ni la capacité des utilisateurs finaux à prendre en main le nouvel outil
  • Quand on traite toutes les demandes comme un besoin général

Pour éviter la surcharge, il y a plusieurs questions à se poser en amont de chaque lancement d’outil :

  • Qui sont les personnes concernées par l’outil : les décisionnaires, les sponsors, les ambassadeurs, les référents techniques, les référents métiers et surtout les utilisateurs finaux ?
  • Depuis combien de temps est-ce que le besoin a été émis ?
  • Le besoin qui a été remonté est-il un besoin général ou un cas particulier ?
  • Le problème à résoudre soulève-t-il des sujets de fonds : défaut d’organisation, conflits, manque de compétences en interne, manque de moyens… ?
  • Avez-vous suffisamment de personnes qualifiées pour mettre en place l’outil de bout en bout ?
  • Les utilisateurs finaux ont-ils été sollicités dans la validation du besoin ?
  • Les utilisateurs finaux ont-ils le niveau de compétences suffisant pour utiliser l’outil ?
  • Des dispositifs d’accompagnement et/ou d’acculturation sont-ils à prévoir ?

Qu’est-ce que ces questionnements vont apporter ?

  • Une structuration complète d’un cahier des charges fonctionnel
  • La validation d’une solution technique ou d’une solution managériale
  • Une conduite du changement anticipée
  • La réduction des frictions aux changements
  • La réduction des risques psychosociaux

#2 - Les impacts sur l’Organisation

Dans le cadre de la mise en place d’un nouvel outil, il y a plusieurs sujets organisationnels à soulever :

  • Les objectifs associés à la mise en place de l’outil et leur suivi
  • Les moyens de suivi des avancées
  • Le planning global et sa répartition de temps
  • Les disponibilités des équipes
  • Les contrats et les coûts financiers

Quels sont les impacts de la surcharge d’outils sur l’organisation ?

  • Le cloisonnement
  • Les retards
  • La perte de visibilité sur les avancées
  • La perte de visibilité sur les dépenses et les surcoûts
  • La multiplication des contrats et/ou les litiges fournisseurs
  • Le manque de fluidité dans la communication interne voire une absence de communication interne

À quel moment, on se risque à surcharger l’organisation ?

  • Quand on n’a pas clarifié et formalisé les objectifs associés à l’outil
  • Quand on n’a pas défini de suivi de projet : moyens de suivi, communication interne, critères de réussite, points d’attention, gouvernance, rôle…
  • Quand on n’a pas planifié les actions de mise en place
  • Quand on n’a pas estimé avec les équipes concernées le temps nécessaire pour aboutir chaque action
  • Quand on n’a pas validé les disponibilités des équipes
  • Quand on n’a pas analysé le référentiel d’outils existant
  • Quand on n’a pas passé en revue les contrats fournisseurs actuels

Pour l’éviter, il y a plusieurs questions à se poser en amont de chaque lancement d’outil :

  • Qu’est-ce que vous attendez du nouvel outil ?
  • Avez-vous un budget clair ? Savez-vous réaliser un budget pour un projet informatique ?
  • Comment allez-vous suivre et communiquer sur les avancées de la mise en place ?
  • Quelles sont les échéances du projet ? Un planning a-t-il été fait ?
  • Combien de temps faut-il aux équipes, aux fournisseurs pour délivrer leurs tâches ?
  • Les équipes ont-elles d’autres projets en parallèle ? Sont-elles disponibles ?
  • A-t-on déjà un outil similaire ? Qu’est-ce qui fonctionne ou ne fonctionne pas avec cet outil ?
  • A-t-on des contrats à résilier ? Quels sont les délais ? Les coûts de résiliation ?

Qu’est-ce que ces questionnements vont apporter ?

  • Une structuration de la gestion de projet : planning, charges, coûts, gouvernance…
  • La définition de la stratégie de communication interne
  • Des équipes peu voire pas immobilisées pour leurs autres activités
  • Une orientation projet plus cohérente : maintien de la mise en place d’un nouvel outil ou commande de développement spécifique pour un outil existant ou amélioration de l’existant
  • Un budget plus maîtrisé, plus transparent
  • Une maîtrise des coûts : pas de doublon, pas de litige de contrat, des délais de résiliation anticipés…

#3 - Les impacts techniques

L’environnement technique de l’entreprise regroupe plusieurs périmètres :

  • L’équipe technique
  • Le matériel informatique et/ou le système d’information
  • Les logiciels existants et la gestion des données
  • La maintenance

Quels sont les impacts de la surcharge d’outils sur l’environnement technique ?

  • Des retards
  • Augmentation de la dette technique
  • Incompatibilité des logiciels et/ou du système d’information
  • Perte de visibilité sur l’inventaire des logiciels existants
  • Augmentation des risques de sécurité
  • Perte de données
  • Surcoût de maintenance et de support

À quel moment, on se risque à surcharger l’environnement technique ?

  • Quand on multiplie les anciennes versions de logiciel ou d’application
  • Quand on choisit un outil sans valider s’il est compatible avec l’existant
  • Quand on ne tient pas à un jour son inventaire d’outils
  • Quand on n’intègre pas de critères de sécurité dans le choix et le paramétrage de l’outil
  • Quand on n’intègre pas suffisamment les équipes techniques dans les études de faisabilité et/ou analyse de risque
  • Quand on n’intègre pas suffisamment les équipes techniques dans l’estimation des temps
  • Quand on n’a pas de référentiel de données ni de programmes de reprise de données
  • Quand on n’a pas anticipé les charges de maintenance (temps et coût) ou qu’on a omis la maintenance

Pour l’éviter, il y a plusieurs questions à se poser en amont de chaque lancement d’outil :

  • Les équipes techniques sont-elles disponibles ?
  • Les technologies requises sont-elles maîtrisées ?
  • Quels sont les outils existants ? En avons-nous besoin pour le nouvel outil ?
  • Les outils existants sont-ils tous à jour ?
  • Est-ce que l’outil choisi est compatible avec les outils existants ?
  • La mise en place d’un nouvel outil nécessite-t-elle une montée en version ?
  • Quel est le niveau de sécurité du nouvel outil ?
  • Quelles sont les contraintes de sécurité à appliquer au nouvel outil ?
  • Quelles sont les données à intégrer dans le nouvel outil ? Où sont ces données ? Qui est en mesure de les intégrer ?
  • A-t-on prévu le support du nouvel outil ?
  • Des évolutions sont-elles à prévoir ?
  • La maintenance a-t-elle été intégrée au budget ?

Qu’est-ce que ces questionnements vont apporter ?

  • Un cahier des charges technique réaliste
  • Un planning de mise en œuvre détaillé
  • La validation technique de l’outil
  • La mise en place de bonnes pratiques de sécurité
  • Le maintien de la continuité d’activité
  • La maîtrise des coûts

 

Un trop grand nombre d’outils, loin de valoriser le caractère innovant d’une organisation, surcharge surtout les équipes et l’environnement nécessaire à son bon fonctionnement.

Si le sujet n’est pas résolu assez tôt, cela impact très fortement l’Humain, l’Organisation et l’Environnement technique. Un nouvel outil révèle souvent des problématiques de fonds. Si celles-ci ne sont pas résolues avant la mise en place, on ne fait que répliquer voire renforcer des problèmes managériaux, dans les processus de la solution technique.

Ce qui entraîne :

  • des retards ;
  • une perte de visibilité ;
  • des surcoûts et des litiges contractuels ;
  • des limites techniques difficiles à maintenir ;
  • du désengagement des équipes.

Face à la surcharge d’outil, il y a un ensemble de questions à se poser en amont de la mise en place d’un nouveau logiciel ou d’une nouvelle application. Ces questions peuvent paraître un peu lourdes et chronophages mais elles ont le méritent de :

  • Rassembler tous les acteurs concernés par la mise en place
  • Consolider une vision commune
  • Clarifier les objectifs et les problèmes de fond
  • Résoudre ces problèmes de fond
  • Structurer la gestion de projet
  • Maîtriser les investissements financiers
  • Miser sur l’amélioration et la consolidatio

[1] Idéologie sociologique définie et démontée par le chercheur et auteur Evgeny Morozov


Quels indicateurs utilisés pour suivre un projet informatique ?

La gestion de projet est une activité de communication et de suivi. Elle a pour objectif de veiller à ce que les étapes du projet se déroulent bien et en cas de difficultés de pouvoir impulser des solutions. On utilise pour cela des indicateurs qui permettent de réaliser ce suivi tout au long de la vie du projet. La difficulté pour définir ces indicateurs est alors d’identifier ceux qui vont être pertinents, de ceux qui n’apportent pas de valeurs ajoutées au pilotage du projet. Il faut donc comprendre à quoi sert un indicateur afin d’identifier ce dont on a besoin puis l’intégrer dans un processus de suivi. Quand est-il dans le cadre d’un projet informatique ?

Retrouvez dans cet article les sujets à aborder pour définir vos objectifs, votre processus de suivi et les indicateurs associés.

#1- À quoi sert un indicateur de pilotage projet ?

Un indicateur de pilotage de projet est une donnée objective, quantifiable et temporelle.

Il permet de s’assurer que la méthode de gestion de projet est cohérente et efficace à chaque jalon du projet.

À partir de ces indicateurs, on définit un tableau de bord qui synthétise les données de suivi, de consommation et de performance. Pour être le plus accessible possible, ce tableau de bord doit être visuel et concis.

Les indicateurs facilitent également les prises de décisions, mais aussi la valorisation des actions et des investissements engagés dans le projet.

#2- Comment définir un indicateur ?

Pour définir un indicateur, il faut identifier en premier lieu les critères qu’on souhaite remplir, ces critères sont généralement liés à des thèmes :

• Humain : Indicateurs principalement liés au suivi des équipes projet

• Budget : Indicateurs liés à la gestion des coûts et des charges

• Planning : Indicateurs liés aux délais, avancements

• Risque : Indicateurs liés aux retards, aux conflits, aux incidents d’organisation…

Il est indispensable d’intégrer les équipes projet dans ce processus, car celles-ci peuvent avoir des enjeux complémentaires à ces thèmes. C’est également elles qui centralisent la majorité des informations opérationnelles.

Chaque critère peut ensuite être traduit en indicateur auquel on associe une fréquence de mise à jour, une vue générale, une vue détaillée ainsi qu’un processus de suivi. Le tableau de bords qu’on génère ensuite constitue alors la base de travail pour tous les points projets : COMEX, COPIL, COPROJ, revue de sprint, etc.

#3 Quels indicateurs pour piloter un projet informatique ?

Pour piloter un projet informatique, on identifie les indicateurs suivants :

Indicateur Humain :

1) Indice de confiance — Évaluer le degré de confiance des équipes dans la réalisation des tâches du projet

2) Taux de satisfaction — Identifier si les ressources et les méthodes sont utilisées, validées et comprises par les parties prenantes au projet

3) Indice de compétences — Mesurer si les compétences requises pour chaque étape du projet sont suffisantes

4) Indice de compréhension — Mesurer la compréhension des équipes vis-à-vis des attendus et objectifs du projet

Indicateurs Budget

1) Évolution des dépenses vs budgets initialement validés — Surveiller l’évolution du budget et des surcoûts

2) Évolution des dépenses par équipe et/ou projet — Identifier des surcoûts en fonction des équipes et projet

3) Moyenne ETP par équipe et/ou projet — Identifier des surcharges en fonction des équipes et projet

Indicateurs Planning

1) Taux d’inscription des tâches dans les backlogs — Valider que toutes les équipes projets ont inscrit dans leurs backlogs les tâches de chaque chantier dans leur outil projet

2) Taux d’avancement des tâches — Identifier le pourcentage d’avancement de chaque chantier composant le projet

3) Taux de couverture des spécifications fonctionnelles à la MEP — Évaluer le taux de finalisation d’un projet vis-à-vis des spécifications initiales

4) Évolution du temps initialement estimé vs temps réellement réalisé — Suivre les surconsommations et sous-consommations entre le temps réellement travaillé et celui estimé

Indicateurs Risque :

1) Indice de valeurs des risques — Surveiller l’évolution de la mitigation des risques

2) Taux de confiance retard — Mesurer le taux de confiance quant au respect du planning et des livraisons du projet

3) Indice de résolution — Mesurer le taux de résolution du projet vis-à-vis des incidents en cours

Les indicateurs permettent de structurer et de suivre efficacement un projet informatique. Ils doivent être concrets, pertinents et simples à utiliser. Plus un indicateur est difficile à comprendre, plus il sera difficile de l’utiliser. Ils peuvent ainsi être regroupés dans des thèmes : Humain, Budget, Planning et Risques projet. Ces thèmes permettent de mesurer des critères spécifiques au projet et faciliter le processus de suivi. Néanmoins, il est également important de réaliser ce processus de définition des indicateurs avec les équipes pour s’assurer d’intégrer l’ensemble des enjeux du projet.


À quoi sert un Ingénieur en Système d'Information ?

L’ingénieur en Système d'Information (SI) fait partie de la catégorie « Ingénieur informatique », dans lequel se retrouve les Ingénieurs Développeurs, Ingénieurs Réseaux et Télécoms, Ingénieur en informatique Industrielle etc.

Son rôle majeur est de piloter le bon fonctionnement du Système d’Information de l’entreprise en assurant la cohérence des projets IT avec celui-ci.

Quel est le rôle de l’Ingénieur SI dans un projet IT ?

Le rôle de l’Ingénieur SI dans un projet IT est d’être garant·e de l’intégration du projet IT dans le fonctionnement du SI. Il/Elle possède une forte capacité d’adaptation et de montées en compétences sur des processus métiers, de nouveaux outils informatiques, de nouveaux langages ou nouvelles tendances… L’Ingénieur SI dispose donc d’un profil généraliste avec une appétence forte pour la remise en question et la veille de tendance technique, à savoir :

- Structurer l’ensemble du portefeuille projets : choix de la solution, phasage, procédures, gouvernance, planning, budget, ressources et moyens… ;

- Identifier et anticiper les risques ;

- Assimiler et traduire les besoins métiers auprès du Service informatique ;

- Préparer les développements informatiques ;

- Anticiper les impacts des projets IT sur le Système d’information ;

- Valider la cohérence des choix IT réalisés par les Services informatiques ;

- Documenter le Système d’information en tenant compte des évolutions techniques ;

- Accompagner le maintien des bonnes pratiques ;

- Garder une vision globale du SI de l’entreprise tout au long du développement de celui-ci ;

- Prévenir et assurer la rationalisation des solutions intégrée au SI.

Qu’est-ce que l’Ingénieur SI ne fait pas ?

Bien que l’Ingénieur SI ait un profil généraliste, il/elle n’est pas censé réaliser toutes les tâches qu’incombent un projet IT telles que :

- La gestion opérationnelle des activités informatiques – Ce poste est celui d’un·e DevOps ou d’un Administrateur. En revanche, l’ingénieur SI peut intervenir sur les besoins des opérationnels telles que l’amélioration des outils de gestion de projet, la conception d’outil de suivi, la définition d’indicateurs, la résolution d’incidents trop récurrents…

- Le développement informatique – Ce poste est celui d’un·e Développeur·se dont les compétences sont spécifiques en fonction des solutions et du langage qu’elles requièrent. L’ingénieur SI doit plutôt intervenir dans le pilotage global d’un projet de développement si celui-ci sollicite le Système d’information

- L’administration et le paramétrage d’outils - Ce poste est celui d’un·e administrateur·rice. L’Ingénieur intervient davantage en amont pour la cohérence des paramétrages avec les besoins Métier et le bon fonctionnement du SI

Quand doit-on faire appel à un·e Ingénieur SI ?

Il est conseillé d’être accompagné par un·e Ingénieur SI pour chaque projet qui a un impact fort sur le Système d’information, et ce, dès la détection du besoin jusqu’aux premiers mois de mise en place.

Quelle est la différence entre un Ingénieur SI, un Informaticien et un Chef de projet technique ?

Le/La chef de projet technique coordonne la réalisation d’un ou plusieurs projets informatiques, de la formalisation du besoin jusqu’à la mise en production. L’ingénieur SI, quant à lui ou elle, coordonne les sujets des Chefs de projet qui ont un impact sur le Système d’information. Il/elle a une vision globale de l’ensemble des projets IT afin d’assurer le maintien du Système d’information au fil des avancées des différents projets.

Quant à l’Informaticien·ne, il/elle est sollicitée pour réaliser des actions qui nécessitent une expertise technique spécifique : proposer une solution, la développer, l’intégrer et la maintenir. Il/elle peut aussi assurer le support technique pour les utilisateurs. C’est un rôle plus opérationnel que stratégique.



À quoi sert un Change Manager dans le cadre d'un projet IT ?

Chef·fe de projet ? Communicant·e ? Coach ou Formateur ? La transversalité du Change Manager (CM) peut parfois porter à confusion. Sa mission principale est de définir des méthodes pour généraliser des changements induits par l’évolution de l’entreprise (nouveaux outils, pivot commercial, nouvelle organisation…).

Dans le cadre d’un projet IT, les changements ont une incidence sur l’organisation de travail :

- des Services IT, qui structurent et mettent en place une nouvelle solution (nouvel outil, nouvelle procédure, changement d’éditeurs, rationalisation etc.) ;

- du Métier qui formalise ses besoins et pilote les sujets fonctionnels ;

- des Salariés qui doivent comprendre et s’adapter aux changements.

Le/La Change Manager est une fonction clé pour généraliser les changements tout en préservant le climat de travail et la productivité de l’entreprise tout au long de ses évolutions.

Quel est le rôle du Change Manager dans un projet IT ?

Le rôle du Change Manager c’est d’être un·e « Garant·e du Bon sens ».

Le « Bon sens » dans un projet IT, consiste à consulter l’Utilisateur final pour confirmer les orientations qui le concernent, et ce, même si ses connaissances techniques sont limitées. En fonction de la densité des portefeuilles de projets, le « Bon sens » peut vite se perdre.

Le rôle du Change Manager est de solutionner les questionnements nécessaires à la généralisation d’une nouvelle organisation tels que :

- Analyser la structuration et la clarté du projet IT afin de valider sa compréhension de la part des futurs utilisateurs ;

- Définir les différents profils d’utilisateur pour anticiper les différents leviers de résistance et d’adhésion ;

- Valider et négocier l’alignement du projet IT avec les appétences, les connaissances et les disponibilités des Utilisateurs ;

- Définir une méthode et un plan d’accompagnement ciblé en fonction de la Culture d’entreprise, des objectifs du projet et des utilisateurs ;

- Simplifier les jargons et vulgariser les éléments complexes ;

- Détecter, prévenir et solutionner les éléments qui peuvent générer de la résistance ;

- Rassurer les utilisateurs et désamorcer les irritants (peurs, préjugés, rumeurs…) ;

- Valoriser et communiquer les réussites du projet ;

- Réaliser un reporting régulier sur la bonne prise en main de l’outil après sa mise en place.

Qu’est-ce que le/la Change Manager ne fait pas ?

Un peu communicant·e, chef·fe de projet, coach et formateur·rice, le/la CM a une fonction transverse qui susciter des confusions quant à ses tâches. Pourtant, il y a bien des actions qu’il/elle n’est pas censé·e assurer au cours d'un projet IT :

- Le SAV, la gestion de ticket/backlog, la gestion des incidents – Le/La Change Manager est uniquement là pour s’assurer que l’outil soit compris et utilisé. En revanche, le/la Chef de projet, en charge de la remontée d'incidents, peut faire appel au CM pour les problèmes de résistance au changement.

- La Gestion de projet technique – Le CM doit seulement être en mesure de comprendre les sujets Tech pour pouvoir les vulgariser. Si le/la CM est trop proche de l’IT, il y a un risque à ce que les contraintes techniques prennent trop le pas sur l’accompagnement des utilisateurs finaux.

- La Gestion de projet fonctionnel – Même si le Change Management est un sujet plus fonctionnel que technique, un·e CM n’est pas non plus un·e Référent·e métier. Il/elle doit baser sa stratégie d’accompagnement sur les compétences et appétences des Utilisateurs mais ne doit pas non plus omettre la faisabilité technique.

Quand doit-on faire appel à un·e Change Manager ?

Pour éviter une conduite du changement en mode « Pompier », il faut anticiper l’intervention du Change Manager pour anticiper les actions qui vont limiter les résistances et renforcer l’engagement.

L’idéal est de faire intervenir le/la CM après la validation du cahier des charges, du budget et du planning. Ainsi, il/elle dispose de suffisamment d’informations pour analyser les changements et préparer les actions d’accompagnement.

En parallèle, le/la CM doit être dans la boucle de la communication projet, non pas pour valider les avancées du déploiement, mais pour accéder aux prises de décision qui pourraient nécessiter des actions d’accompagnement ou de communication.

Quel est le ROI de la Conduite du changement ?

Bien que le/la Change Manager ne contribue pas directement au ROI de l’entreprise, ses actions permettent de :

- Limiter les conséquences des changements sur la productivité, le climat social et la QVT ;

- Réduire les coûts de maintenance et les développement sur-mesure inhérents à une non prise en compte des besoins, compétences et appétences des utilisateurs ;

- Réduire les pertes liées à la non-utilisation des outils mis en place.

Ainsi, on ne peut pas précisément évaluer le ROI d’un programme de Change Management mais davantage évaluer ce que la stratégie de conduite du changement a permis de ne pas perdre, les risques qui ont été évités, les critères de réussite atteints et les données de satisfaction des Utilisateurs.

En conclusion, engager des actions de Conduite du changement requiert une personne ou une équipe dédiée afin d’éviter d’imposer de nouveaux outils et pour insuffler plus de transversalité et de travail collaboratif au cours d’un projet IT. Le rôle des Change Manager est un rôle central dans l’atteinte des objectifs car ils veillent à ce que l’Humain reste au cœur de la réussite d’un projet IT.


 

 


Pourquoi structurer correctement un projet informatique ?

#1 - Qu’est-ce qu’un projet informatique ?

Un projet informatique est un projet dont les livrables sont constitués d'outils (logiciels, applications web ou mobiles, infrastructure…), de méthodes ou de services informatiques (infogérances, dépannage…).

Il s’articule autour de différents acteurs :

  • Les sponsors : Acteur(s) qui défend la pertinence et les enjeux d’un projet pour débloquer un budget
  • La DSI ou le service informatique (en fonction de la taille de la structure) : Responsable de la validation, du paramétrage et de l’intégration de la solution informatique
  • Le(s) chef(s) de projet : Acteur(s) transverse(s) qui traduit les besoins du Métier vers l’IT et les impératifs de l’IT vers le Métier (tests, spécifications fonctionnelles etc.)
  • Les services métiers : Acteurs sollicités pour leur expertise métier sur un projet car directement impactés (en tant qu’utilisateurs ou administrateurs notamment)
  • Les fournisseurs et les experts : Prestataire de service, éditeurs de logiciel, consultants…

Cet article vous présente les risques majeurs d’un projet informatique mal structuré et comment détecter les facteurs d’un manque de structuration afin de les solutionner en amont.

#2 - Quels sont les risques d’un projet mal structuré ?

  • Le projet est livré avec des retards importants. Ces retards surviennent quand on omet d’intégrer et de suivre régulièrement :
    • La disponibilité des acteurs du projet (incluant le Métier)
    • La revue des ressources (Compétences) et des moyens (Outils) nécessaires au bon déroulé du projet
    • Le suivi d’un planning trop ambitieux ou un planning incomplet
    • La communication interne
  • Le budget initial est dépassé avec des coûts imprévus. Les surcoûts sont liés à des éléments qui n’ont pas été anticipés :
    • La rédaction du cahier des charges comprenant les exigences techniques IT ou Métier
    • La cartographie des utilisateurs finaux
    • L’adéquation des spécificités fonctionnelles avec l’environnement technique existant
    • L’anticipation du planning et des imprévus
  • La solution est peu ou pas utilisée. Elle peut ne pas convenir aux utilisateurs finaux et donc ne pas être utilisée, et ce, quand plusieurs actions n’ont pas été abouties :
    • La conduite d’ateliers auprès des utilisateurs, auprès des métiers impactés
    • La cartographie des utilisateurs finaux et leurs usages
    • La validation des fonctionnalités proposées par la solution en accord avec le cahier des charges et les exigences
    • La communication interne entre les différentes parties prenantes
    • Les tests utilisateurs
    • L’accompagnement au changement des utilisateurs finaux
  • La maintenance coûte plus chère que prévue. En fonction du déploiement et de(s) solution(s) choisie(s), la maintenance génère des coûts plus élevés que prévus en raison de :
    • Manque d’adéquation entre les spécificités fonctionnelles et l’environnement technique existant
    • Commande de fonctionnalités qui ne figurent pas dans le cahier des charges
    • Peu de cadrage des développements spécifiques
    • Manque d’anticipation du planning et des imprévus
    • Recettes fonctionnelles et techniques incomplètes
  • L’entreprise est dépendante de ses expertises externes (Éditeur, Prestataires, Consultants etc.) La manque d’autonomie dans votre relation avec un Éditeur peut poser des problèmes de maîtrise des coûts et des temps pour des interventions mineures. Cette dépendance est le résultat :
    • D’absence de suivi des actions de l’Éditeur ou d’outil de reporting central
    • D’un cahier des charges imprécis quant au planning, aux ressources et aux utilisateurs concernés
    • D’un besoin qui n’a pas été traduit en fonctionnalité, en actions concrètes (le fameux : « Il me faut un site »)
    • D’un manque de rigueur dans les tests et les validations signées
  • Personne n’est disponible : Vos collaborateurs ont d’autres tâches à réaliser au quotidien. Un projet informatique même s’il est essentiel n’est pas toujours considéré comme prioritaire. Par manque de sensibilisation et de communication interne, vous risquez de manquer de plusieurs compétences, au mieux vos délais seront fortement retardés.

#3 - Comment mieux appréhender les facteurs de risque d’un projet informatique mal structuré ?

Quand le cahier des charges est incomplet

Le cahier des charges doit intégrer à minima les éléments suivants :

  • La présentation du besoin et le détail des fonctions attendues
  • La liste des exigences métiers et techniques (IT)
  • La cartographie des utilisateurs finaux
  • L’analyse des spécificités fonctionnelles avec l’environnement technique existant

Le cahier des charges doit être validé par toutes les parties prenantes avant de lancer les phases de négociations commerciales.


Quand le planning est incomplet

Un planning projet est découpé en phase dont voici la liste :

  • Définition du besoin fonctionnel et technique
  • Cadrage du projet
  • Validation de la solution et/ou du prestataire
  • Développement
  • Tests
  • Déploiement
  • Conduite du changement

Le planning doit intégrer :

  • Le découpage des phases dans le temps
  • Les actions par phase
  • Les acteurs associés à chaque action et/ou phase (responsable, valideur, consulté, informé) ainsi que leurs disponibilités
  • Le temps nécessaire pour réaliser chaque action
  • Les livrables pour chaque action et/ou phase

Quand les critères de choix du Prestataire/Éditeur ne sont pas clairs ou inconnus

Le prestataire et/ou l’éditeur doivent être choisis de manière objective grâce à ces éléments :

  • L’adéquation de l’offre du Prestataire/Éditeur avec le cahier des charges
  • La pertinence des préconisations et une bonne reformulation du cahier des charges 
  • Le coût total du produit et de sa maintenance
  • Le coût des expertises éventuelles (atelier, test, audit etc.)
  • La réactivité
  • La documentation et autres supports d’accompagnement des utilisateurs

Quand l’analyse de l’environnement technique IT est incomplète

L’analyse de l’environnement technique intègre :

  • La revue de l’existant
  • Un référentiel des moyens et ressources techniques
  • La cartographie des flux de données
  • La validation de la faisabilité des spécificités fonctionnelles ou des alternatives si tout n’est pas faisable
  • Des spécifications techniques

Quand le plan de communication projet est inexistant

Plus vous communiquerez régulièrement, mieux vous préparerez vos utilisateurs à l’arrivée d’une nouvelle solution informatique, et plus vous sensibiliserez aux enjeux d’un tel projet pour mettre toutes vos parties prenantes au même niveau d’information tels que :

  • Les enjeux du projet et ses bénéfices
  • Les avancées et blocages
  • Les points d’attention et les problèmes résolus
  • Les mobilisations requises (ateliers, tests, questionnaires etc.)
  • Le plan d’accompagnement au changement (atelier, formation etc.)

En conclusion

Un projet informatique se structure donc avant son lancement. Si votre projet recense trop de facteurs de risque, il est préférable de le passer en revue afin d’éviter les retards, les surcoûts, le désengagement et les projets abandonnés