L’article Comment mettre en place une feuille de route pour un projet informatique ? est apparu en premier sur Cool IT.

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

« 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

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

L’article Transformation digitale : quels sont les impacts de la surcharge d’outils ? est apparu en premier sur Cool IT.

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.

L’article Quels indicateurs utilisés pour suivre un projet informatique ? est apparu en premier sur Cool IT.

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

L’article Pourquoi structurer correctement un projet informatique ? est apparu en premier sur Cool IT.