Cadre général du projet décisionnel
- Introduction
- Cadre général du projet décisionnel
- Conception : Étude Préalable
- Conception : Collecte des besoins (spécifications très peu détaillées)
- Conception : Analyse des besoins
- Conception : Analyse des indicateurs
- Conception : L’importance de la qualité des données
- Conception : Spécifications des restitutions (ce que j’envisage de vous proposer)
Tout projet peut être caractérisé par 3 dimensions : Coût, Délai et Qualité. La qualité porte ici le sens défini par l’ISO 9000 : “L’aptitude d’un ensemble de caractéristiques intrinsèques à satisfaire des exigences”. Cette triple dimension du projet est généralement représentée par ce que nous nommons le triangle d’or du projet. Cependant en matière de gestion de projet cette mise en œuvre du Portail de Restitution de données au sein de l’entreprise Pythagore Immobilier est caractérisée par un schéma singulier, celui d’un projet qui devait être réalisé :
– En Interne
– Sans aucun budget spécifique alloué
– En temps masqué
– En fonction du temps disponible mais, tout de même, aussi vite que possible
En d’autres termes le Responsable des Systèmes d’Information, seul technicien au sein de l’entreprise au lancement du projet, se doit de prendre en charge ce projet sans disposer de ressources supplémentaires (internes ou externes) et tout en le gérant en parallèle de ses différentes activités qui remplissent déjà à 100% son planning.
Ce projet aura donc une date de début mais aucune date de fin annoncée ou exigée et aucun budget spécifique ne sera alloué à celui-ci. Cette situation sous-entend bien évidemment une importance toute relative des dimensions « coûts » et « délais »
mais cette situation sous-entend aussi, et surtout, que ce projet sera intégralement piloté par la performance (qualité).
En effet si dans notre triangle d’or nous éliminons les variables coûts (temps masqué, pas de budget) et délais (pas de délai défini par les commanditaires) seule reste la qualité, même si tout ceci est bien plus nuancé, comme nous le verrons. Nous insistons sur le fait que la qualité exprime ici l’adéquation entre le besoin exprimé (imaginé) et le résultat fourni et non la qualité intrinsèque et technique de la réalisation.
En partant de ce postulat nous admettrons donc que la réussite de ce projet de BI résidera dans l’atteinte d’une adéquation optimale entre le besoin « exprimé » et le résultat produit. L’un des principaux facteurs clé de succès devrait donc être une définition claire des objectifs à atteindre. A cette fin ce projet devrait donc, idéalement (en tout cas d’un point de vue théorique), s’inscrire dans une démarche de gestion de projet en V ou en cascade, avec des besoins clairement définis dès
le départ, une expression des besoins détaillée et bornée. A ce titre dans leur ouvrage « Business Intelligence et Portails » (Corbillé & Dumas, 2006) les auteurs posent le cadre idéal d’un projet décisionnel dans un environnement web.
Découpé en phases de conception et de réalisation, le projet décisionnel obéirait, selon les auteurs, à une démarche en cascade et suivrait un certain nombre d’étapes clés dans chacune de ces deux phases. La conception se décomposerait ainsi en 9 étapes (étude préalable, collecte des besoins, analyse des données, étude de cadrage, spécifications des flux de données, modélisation, spécifications des restitutions, architecture et choix des briques logicielles), la phase de réalisation quant à elle serait découpée en 3 étapes (réalisation, validation et déploiement). Nous verrons que les choses ne sont pas aussi figées.
Nous pourrons constater, en effet, que certaines étapes n’existent pas ou que le poids de chacune d’elles est très relatif mais aussi que l’ordre de celles-ci ne suit pas toujours l’ordre théorique. Le plan de cet article sera donc le reflet de la réalité : une
phase de conception et une de réalisation, composées de certaines étapes clés et faisant impasse sur d’autres étapes majeures.
En fin de compte, disons-le dès le départ, la gestion de ce projet a été bien plus proche de la méthodologie Agile que de cette approche séquentielle proposée par les auteurs, une méthodologie qui, d’après le manifeste Agile, peut se définir de la manière suivante.
Ø Les individus et leurs interactions, de préférence aux processus et aux outils
Ø Des solutions opérationnelles, de préférence à une documentation exhaustive
Ø La collaboration avec les « clients », de préférence aux négociations contractuelles
Ø La réponse au changement, de préférence au respect d’un plan
Un projet marqué donc par beaucoup d’agilité et conduit, en tout cas dans le périmètre initial de cette première partie, de manière confidentielle, avec un faible nombre d’acteurs.
Le Tableau 1, ci-dessous, présente la liste des salariés directement impliqués dans ce que nous pourrions nommer « groupe projet » du périmètre initial. Quant à la Figure 1, elle donne un aperçu général de la répartition des tâches tout au long de cette phase initiale de ce projet. Projet qui connaitra par la suite, comme nous le verrons, dans les articles qui suivront, de nombreuses évolutions.
Tableau 1: Acteurs du périmètre initial du portail de restitution
Nom | Service | Poste | MOA / MOE | Fonction dans cette phase du projet |
Responsable SI | Informatique | Responsable | MOE | Chef |
Monsieur B. | Webmarketing | Responsable | MOA | Référent |
Madame D. | Informatique | Assistante | MOE | Tests |
Monsieur D. | Communication | Responsable | MOA | Utilisateur |
Monsieur C. | Commercial | Directeur | Sponsor | Sponsor |