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 :
- Analyse de l’existant
- Conception
- Développement
- Test
- Déploiement
- 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 ⬅️
Besoin d’aide ?
Chez Cool IT, nous avons développé nos propres méthodes, largement éprouvées (depuis plus de dix ans !), pour vous aider à mener à bien vos projets informatiques.
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.
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