–




       Réussir son analyse des besoins
    Dans la conduite d’un projet informatique




Octobre 2007
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                       Octobre 2007




Préambule




Ce document est réalisé dans le cadre du PRAI (Programme Régional d’Actions
Innovatrices) conduit par la Région Midi-Pyrénées et soutenu et cofinancé par l’Union
Européenne.
Il est accessible dans le centre de ressources pour l’Internet Public et Citoyen financé par le
PRAI : www.ardesi.fr
L’objectif de ce programme est de favoriser le développement de contenus et de services
numériques de qualité créés par les collectivités territoriales de la Région.




Pour aller plus loin :

    -   Le Programme régional d’actions innovatrices sur le site Internet de la Région :
        www.midipyrenees.fr

    -   La boîte à outils « Internet Public et Citoyen » : cet espace a pour objectif de fournir
        des indications et des outils à toute collectivité désireuse de réaliser ou développer
        son projet Internet local.
        www.ardesi.fr/page481.htm




« La présente communication n’engage que son auteur. La Commission européenne n’est pas
responsable de l’usage qui pourrait être fait des informations contenues dans cette communication. »

                                                                                                    1

                                                                                       SLM/07/315
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                    Octobre 2007




L’analyse des besoins est la phase initiale de toute mise en œuvre de projet. Et même si
elle demande une phase préparatoire assez longue, elle conditionne pour une grande
part la réussite et la performance de l’outil à venir. De la qualité de la demande
dépendra la qualité de la réponse.

Voici quelques clés pour mener à bien votre démarche




1 – Connaître son environnement

La conduite de projet fait appel à des environnements différents qui coexistent de l’étude
préalable au moins jusqu’à l’installation de l’outil.
Il faut prendre en compte :
       - le contexte et les porteurs de projets avec leur environnement et leurs contraintes
(délais, budget…)
       - les fournisseurs : service informatique interne ou prestataire de services et leur
culture (notamment leur niveau technique qui n’est pas accessible aux autres acteurs)
       - l’outil et l’impact qu’il aura sur les utilisateurs (parfois agents et administrés) quel
que soit leur niveau d’intervention




              Enjeux du projet
              OBJECTIFS                      Fournisseurs
                                       FONCTIONNALITES              Solution
                    Utilisateurs
                    BESOINS




                                                                                                    2

                                                                                       SLM/07/315
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                     Octobre 2007




2 - Constituer l’équipe projet

 Il faut s’appuyer sur des référents dynamiques et identifier tous les acteurs. Le groupe
 doit être représentatif des utilisateurs du futur outil.
 Il vaut donc mieux sélectionner des personnes :
       - favorables à la dynamique de groupe et l’émulation qu’elle entraîne
       - disponibles : leur participation au projet ne va pas ajouter une charge de travail
 supplémentaire
       - motivées et volontaires qui seront le premier réseau à communiquer sur l’état du
 projet, et qui seront donc très utiles au moment du déploiement pour l’accompagnement
 du changement

 Attention : le mode projet gomme la ligne hiérarchique alors qu’elle doit continuer
 d’exister par ailleurs. Il convient de communiquer finement sur les enjeux du projet, et de
 définir le jeu des acteurs avec des objectifs définis.

 Penser à définir un planning de réunion qui devra être absolument respecté. A chaque
 réunion, son objectif avec une prise de décision concrète sur la mise en œuvre du
 projet, par exemple :

              - Grille d’analyse des besoins,
              - Choix des fonctionnalités prioritaire,
              - Validation du cahier des charges fonctionnel,
              - Choix du ou des prestataires,
              - Etablissement du plan de communication,
              - Planning de déploiement et de formation
              -…


3 – Bien communiquer pour éviter les écueils

 Travailler sur un référentiel commun :
 Le principe de l’équipe projet implique niveaux de technicités différents. Hors tous les
 utilisateurs ne sont pas ingénieurs ou informaticiens. Il faut donc s’entendre sur un
 vocabulaire commun permettra de travailler dans un cadre de référence précis et
 d’éviter les quiproquos.

 Faciliter l’expression du besoin :
 Il faut être à l’écoute des futurs utilisateurs. Lors d’un entretien il est important de mettre
 une personne à l’aise, de l’écouter et de reformuler pour prouver que son opinion est
 importante. Le cadre d’une réunion empêche parfois les plus discrets de s’exprimer. Il
 faut surveiller les temps de paroles de chacun et vérifier à la fin de l’exercice que toutes
 les idées ont bien été prises en comptes



                                                                                                   3

                                                                                      SLM/07/315
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                       Octobre 2007




4 - Les questions fondamentales du besoin

 Toujours penser au postulat de base : un outil informatique est toujours une interface
 entre deux environnements majeurs qui justifient son existence.

 Il n’est pas nécessaire de développer des fonctionnalités qui serviront à la marge de vos
 activités. Il est faux de penser que l’automatisation (par le biais d’un nouvel outil
 informatique) va effectuer le travail à la place des agents. Il permet de repenser les
 métiers pour les faciliter les tâches et rendre les agents plus performants.
        - Quels sont les deux environnements majeurs qui justifient le développement
           (ou l’acquisition) de cet outil ? QUI ? QUOI ?
        - Quel est le service fondamental rendu par cet outil ? POUR QUOI ? Quelles
           finalités ?
        - Dans quel but ce service est-il rendu ? (dans ce cas on évoque notamment
           l’ensemble des fonctionnalités de l’outil à venir) COMMENT ?
 C’est la réponse à cette troisième question qui représente le besoin.

 Il est très important de distinguer :

      -     POUR QUOI, dont la réponse doit commencer par « afin de… » et formalise
            l’objectif (on peut aussi remplacer la question par Dans quel but ?)
      -     POURQUOI, dont la réponse est « parce que » et formalise la cause.

 A partir de ces questions initiales il est intéressant de s’intéresser au :

      -     QUAND ? : Dans quel délai ? Quelle fréquence ?
      -     OÙ ? : Dans le cas d’une solution informatique, il s’agira essentiellement de se
            pencher sur les problématiques de mobilité des agents, de multi sites, et
            d’accessibilité (borne, PC …)
      -     COMBIEN ? Aborde la problématique du coût.

 Il faut idéalement répondre à ces 7 interrogations, car si la simplicité et le manque de
 temps incitent à n’aborder que les quatre premières. Les suivantes décrivent souvent les
 contraintes qui vont border le champ du projet lui-même. Il arrive aussi qu’elles soient
 prépondérantes dans la problématique à définir (par exemple un outil en multi sites)




                                                                                                   4

                                                                                      SLM/07/315
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                      Octobre 2007




5 – Hiérarchiser les besoins
  La hiérarchisation des besoins permet de définir les priorités.
  Il est important de construire un tableau de bord simple qui va proposer de lister
  l’ensemble des fonctionnalités qui sont souhaitées.

  Pour les classer on peut par exemple leur attribuer une valeur numéraire :
       3 : indispensable :
       2 : important :
       1 : utile …

  Ne pas oublier : les utilisateurs.
  Il peut être intéressant de faire une grille croisée. Lors de la mise en place d’un outil
  collaboratif, la valeur du besoin peut changer en fonction du métier. Les fonctionnalités
  qui sont indispensables aux Ressources Humaines, sont différentes de celles des
  agents d’accueil. Aussi il faut penser au projet dans son ensemble.

  Exemple :
                                                                                        Faire apparaître
                   Utilisateurs       Accueil           RH           Cabinet            la « valeur » du
                                                                                        besoin de 1 à 3
Besoins                                                              Du maire
 Communiquer les décisions
 Faire apparaître les congés
             …




6 - Avant la rédaction du cahier des charges

  Une fois les éléments du besoin défini et pour confirmer que le cadre du projet est
  cohérent, l’idéal est de voir ce qui se fait ailleurs. Essayer de trouver une collectivité
  semblable à la votre en taille et en compétence et observer les solutions qu’elle a
  choisies. Ne pas hésiter à se pencher sur ses réussites mais également sur ces erreurs.
  Cela pourrait permettre de gagner un temps précieux.




                                                                                                  5

                                                                                     SLM/07/315
Réussir son analyse des besoins dans la conduite de projets informatiques
                                                                     Octobre 2007




Conclusion

 Le résultat de ce travail peut parfois aboutir à un projet complexe. Il arrive que la
 solution choisie implique alors un grand nombre de changement qu’il soit en terme de
 formation (à un nouvel outil) que de culture (partage de l’information).
 Il ne faut alors pas hésiter à phaser et à expérimenter des sous projets plus courts. Ainsi
 les futurs utilisateurs pourront s’approprier cet outil à leur rythme (fonctionnalité par
 fonctionnalité).




BIBLIOGRAPHIE

Paul Hubert des Mesnards. Réussir son analyse des besoins. 2007




                                                                                                 6

                                                                                    SLM/07/315

Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)

  • 1.
    Réussir son analyse des besoins Dans la conduite d’un projet informatique Octobre 2007
  • 2.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 Préambule Ce document est réalisé dans le cadre du PRAI (Programme Régional d’Actions Innovatrices) conduit par la Région Midi-Pyrénées et soutenu et cofinancé par l’Union Européenne. Il est accessible dans le centre de ressources pour l’Internet Public et Citoyen financé par le PRAI : www.ardesi.fr L’objectif de ce programme est de favoriser le développement de contenus et de services numériques de qualité créés par les collectivités territoriales de la Région. Pour aller plus loin : - Le Programme régional d’actions innovatrices sur le site Internet de la Région : www.midipyrenees.fr - La boîte à outils « Internet Public et Citoyen » : cet espace a pour objectif de fournir des indications et des outils à toute collectivité désireuse de réaliser ou développer son projet Internet local. www.ardesi.fr/page481.htm « La présente communication n’engage que son auteur. La Commission européenne n’est pas responsable de l’usage qui pourrait être fait des informations contenues dans cette communication. » 1 SLM/07/315
  • 3.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 L’analyse des besoins est la phase initiale de toute mise en œuvre de projet. Et même si elle demande une phase préparatoire assez longue, elle conditionne pour une grande part la réussite et la performance de l’outil à venir. De la qualité de la demande dépendra la qualité de la réponse. Voici quelques clés pour mener à bien votre démarche 1 – Connaître son environnement La conduite de projet fait appel à des environnements différents qui coexistent de l’étude préalable au moins jusqu’à l’installation de l’outil. Il faut prendre en compte : - le contexte et les porteurs de projets avec leur environnement et leurs contraintes (délais, budget…) - les fournisseurs : service informatique interne ou prestataire de services et leur culture (notamment leur niveau technique qui n’est pas accessible aux autres acteurs) - l’outil et l’impact qu’il aura sur les utilisateurs (parfois agents et administrés) quel que soit leur niveau d’intervention Enjeux du projet OBJECTIFS Fournisseurs FONCTIONNALITES Solution Utilisateurs BESOINS 2 SLM/07/315
  • 4.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 2 - Constituer l’équipe projet Il faut s’appuyer sur des référents dynamiques et identifier tous les acteurs. Le groupe doit être représentatif des utilisateurs du futur outil. Il vaut donc mieux sélectionner des personnes : - favorables à la dynamique de groupe et l’émulation qu’elle entraîne - disponibles : leur participation au projet ne va pas ajouter une charge de travail supplémentaire - motivées et volontaires qui seront le premier réseau à communiquer sur l’état du projet, et qui seront donc très utiles au moment du déploiement pour l’accompagnement du changement Attention : le mode projet gomme la ligne hiérarchique alors qu’elle doit continuer d’exister par ailleurs. Il convient de communiquer finement sur les enjeux du projet, et de définir le jeu des acteurs avec des objectifs définis. Penser à définir un planning de réunion qui devra être absolument respecté. A chaque réunion, son objectif avec une prise de décision concrète sur la mise en œuvre du projet, par exemple : - Grille d’analyse des besoins, - Choix des fonctionnalités prioritaire, - Validation du cahier des charges fonctionnel, - Choix du ou des prestataires, - Etablissement du plan de communication, - Planning de déploiement et de formation -… 3 – Bien communiquer pour éviter les écueils Travailler sur un référentiel commun : Le principe de l’équipe projet implique niveaux de technicités différents. Hors tous les utilisateurs ne sont pas ingénieurs ou informaticiens. Il faut donc s’entendre sur un vocabulaire commun permettra de travailler dans un cadre de référence précis et d’éviter les quiproquos. Faciliter l’expression du besoin : Il faut être à l’écoute des futurs utilisateurs. Lors d’un entretien il est important de mettre une personne à l’aise, de l’écouter et de reformuler pour prouver que son opinion est importante. Le cadre d’une réunion empêche parfois les plus discrets de s’exprimer. Il faut surveiller les temps de paroles de chacun et vérifier à la fin de l’exercice que toutes les idées ont bien été prises en comptes 3 SLM/07/315
  • 5.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 4 - Les questions fondamentales du besoin Toujours penser au postulat de base : un outil informatique est toujours une interface entre deux environnements majeurs qui justifient son existence. Il n’est pas nécessaire de développer des fonctionnalités qui serviront à la marge de vos activités. Il est faux de penser que l’automatisation (par le biais d’un nouvel outil informatique) va effectuer le travail à la place des agents. Il permet de repenser les métiers pour les faciliter les tâches et rendre les agents plus performants. - Quels sont les deux environnements majeurs qui justifient le développement (ou l’acquisition) de cet outil ? QUI ? QUOI ? - Quel est le service fondamental rendu par cet outil ? POUR QUOI ? Quelles finalités ? - Dans quel but ce service est-il rendu ? (dans ce cas on évoque notamment l’ensemble des fonctionnalités de l’outil à venir) COMMENT ? C’est la réponse à cette troisième question qui représente le besoin. Il est très important de distinguer : - POUR QUOI, dont la réponse doit commencer par « afin de… » et formalise l’objectif (on peut aussi remplacer la question par Dans quel but ?) - POURQUOI, dont la réponse est « parce que » et formalise la cause. A partir de ces questions initiales il est intéressant de s’intéresser au : - QUAND ? : Dans quel délai ? Quelle fréquence ? - OÙ ? : Dans le cas d’une solution informatique, il s’agira essentiellement de se pencher sur les problématiques de mobilité des agents, de multi sites, et d’accessibilité (borne, PC …) - COMBIEN ? Aborde la problématique du coût. Il faut idéalement répondre à ces 7 interrogations, car si la simplicité et le manque de temps incitent à n’aborder que les quatre premières. Les suivantes décrivent souvent les contraintes qui vont border le champ du projet lui-même. Il arrive aussi qu’elles soient prépondérantes dans la problématique à définir (par exemple un outil en multi sites) 4 SLM/07/315
  • 6.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 5 – Hiérarchiser les besoins La hiérarchisation des besoins permet de définir les priorités. Il est important de construire un tableau de bord simple qui va proposer de lister l’ensemble des fonctionnalités qui sont souhaitées. Pour les classer on peut par exemple leur attribuer une valeur numéraire : 3 : indispensable : 2 : important : 1 : utile … Ne pas oublier : les utilisateurs. Il peut être intéressant de faire une grille croisée. Lors de la mise en place d’un outil collaboratif, la valeur du besoin peut changer en fonction du métier. Les fonctionnalités qui sont indispensables aux Ressources Humaines, sont différentes de celles des agents d’accueil. Aussi il faut penser au projet dans son ensemble. Exemple : Faire apparaître Utilisateurs Accueil RH Cabinet la « valeur » du besoin de 1 à 3 Besoins Du maire Communiquer les décisions Faire apparaître les congés … 6 - Avant la rédaction du cahier des charges Une fois les éléments du besoin défini et pour confirmer que le cadre du projet est cohérent, l’idéal est de voir ce qui se fait ailleurs. Essayer de trouver une collectivité semblable à la votre en taille et en compétence et observer les solutions qu’elle a choisies. Ne pas hésiter à se pencher sur ses réussites mais également sur ces erreurs. Cela pourrait permettre de gagner un temps précieux. 5 SLM/07/315
  • 7.
    Réussir son analysedes besoins dans la conduite de projets informatiques Octobre 2007 Conclusion Le résultat de ce travail peut parfois aboutir à un projet complexe. Il arrive que la solution choisie implique alors un grand nombre de changement qu’il soit en terme de formation (à un nouvel outil) que de culture (partage de l’information). Il ne faut alors pas hésiter à phaser et à expérimenter des sous projets plus courts. Ainsi les futurs utilisateurs pourront s’approprier cet outil à leur rythme (fonctionnalité par fonctionnalité). BIBLIOGRAPHIE Paul Hubert des Mesnards. Réussir son analyse des besoins. 2007 6 SLM/07/315