Accueil du site > Les articles > Conduite de projet : principes de la méthode SDMS.
Version à imprimer Enregistrer au format PDF

Conduite de projet : principes de la méthode SDMS.

mardi 11 mai 2004, par David Malle Visites  6950 |Popularité : 95%  Première mise en ligne le mercredi 8 octobre 2003.

Il est impossible de mener à bien un projet informatique sans appliquer une méthode de conduite de projet, qu’elle soit issue d’une méthode connue, ou résultat de l’expérience acquise.

J’ai vu trop de projets tourner à la catastrophe, à cause d’une absence totale de méthode de conduite de projet.

L’application d’une méthode contraint à une rigueur dans le travail. Une bonne raison pour ne pas s’en passer.

Pourtant, il est difficile d’appliquer systématiquement une même méthode sur tous les projets : Selon la taille des projets et des équipes, une méthode, dans son intégralité peut se révéler trop lourde.

Toutes les structures d’accueil ne se révèlent pas ouvertes à l’application d’une méthode. Il faut parfois composer avec cette réalité.

Prenez ce qui suit au chapitre "Méthodes", comme un ensemble d’outils à votre disposition pour la conduite de projet. A vous de décider ce qui peut vous servir, et dans quel contexte.

Les quelques outils exposés sont issus en grande partie de la méthode de conduite de projet SDMS et de mon travail au quotidien.

Je remercie les professeurs de l’Afpa de créteil, pour les excellents cours que j’y ai suivis. Ils ont été un bon complément à mon expérience pratique en la matière.


Principes de la méthode SDMS

Promouvoir la méthode :

Pour promouvoir une méthode de travail, il faut pouvoir en parler, en termes précis, qui soulignent les avantages de son utilisation.

Faîtes vous une présentation "Diapositives Powerpoint", "Slides", ou autres, qui résume les principes de votre méthode de travail. Elle sera un parfait support à chaque fois que vous devrez "discuter méthodes" avec des décideurs, ou des membres de votre équipe.

Appelez ce document "Principes de base de la méthode" et incluez le dans le dossier de projet. Il faut que ce document soit accessible à tous les acteurs du projet.

Découper un projet pour un meilleur suivit

Un projet est découpé en 10 phases de 9 tâches chacune.

Ce découpage est accompagné par une documentation associée au produit :


    -  à chaque fin de phase.
    -  à la fin du projet

La méthode permet un engagement progressif, phase après phase  :


    -  estimations détaillées de la phase suivante
    -  extrapolation au reste du projet
    -  décision sur la suite du projet

Notez bien les deux phrases suivantes :


    -  "Je m’engage pour la phase suivante".
    -  "Je donne des estimations pour l’ensemble du projet, mais je ne m’y engage pas".

Vous avez noté, que la majeure partie des projets au forfait sont estimés au départ et conclus sur cette base, sans prévoir de ré estimation au cours du projet.

Pas étonnant que nombre d’entre eux se transforment en grosses pertes financières.

Principes de base


    -  Un cadre commun de référence :

      -  couvre tout le cycle de vie
      -  indépendant de la structure de l’organisation, des langages utilisés, des matériels utilisés.
      -  adapté aux grands projets comme aux petits projets.
      -  capable d’intégrer les diverses méthodes nécessaires.

    -  Concepts structurés : Cycles (développement, évolution, maintenance) , Phases, Tâches.
    -  Produit tangible.
    -  Engagement progressif.
    -  Implication des hiérarchies.
    -  Participation de l’utilisateur.
    -  Tests intégrés.
    -  Utilisation des compétences.
    -  Assurance qualité intégrée..

Découpage du projet en 10 phases.


    - DS / EO, Demande de service - Etude d’opportunité
    - DBS, Définition des besoins
    - CAS, Choix d’architecture
    - SES, Spécifications externes
    - SIS, Spécifications internes
    - PRG, Programmation
    - TST, Tests
    - CONV, Conversion
    - INST, Installation
    - BILAN, Bilan

Chaque phase est découpée en 9 tâches.


    - 1, Définition du cadre de travail de la phase. En d’autres termes, "réfléchissons avant d’agir !"
    - 2 à 7, Travail spécifique lié à la phase.
    - 8, Préparation du document de fin de phase.
    - 9, Actualisation du planning et approbation du document de fin de phase.

A Chaque fin de phase.

Lorsqu’une phase est terminée, le document de fin de phase doit être approuvé, avant d’officiellement passer à la phase suivante. La hiérarchie est donc "obligée" de s’impliquer, c’est un gage de réussite d’un projet.

A chaque fin de phase :


    - préparation et approbation du document de fin de phase.
    - on effectue une estimation détaillée de la phase suivante,
    - une extrapolation au reste du projet
    - les décisions sur la suite du projet sont revues à chaque fois que le besoin s’en fait sentir.

Estimations détaillées de la phase suivante.

Pour effectuer cette estimation, vous pouvez utiliser un "guide des estimations" et votre expérience, conjugués à votre "flair".

Extrapolation par ratio sur l’ensemble du projet : estimation des coûts


    - DS/EO, Demande de service - Etude d’opportunité
    - DBS, Définition des besoins, 6%
    - CAS, Choix d’architecture, 9%
    - SES, Spécifications externes, 15%
    - SIS, Spécifications internes, 20%
    - PRG, Programmation, 20%
    - TST, Tests, 25%
    - CONV, Conversion
    - INST, Installation, 5%
    - BILAN, Bilan

Engagement progressif

GIF - 10.6 ko
Engagement progressif

Ce graphique souligne pourquoi beaucoup de projets au forfait se révèlent non rentable : On ne devient vraiment précis sur un planning détaillé global du projet, q’une fois terminée la phase de "spécifications externes".

Implication des hiérarchies.

GIF - 6 ko
Implication des hiérarchies

La réussite d’un projet passe par l’implication des hiérarchies au sein du projet. Implication des utilisateurs

Implication des hiérarchies.

GIF - 5 ko
Implication des hiérarchies

La réussite d’un projet passe par une participation active des utilisateurs. Cela implique que la charge de travail qui leur est imposée par le projet soit admise et prise en compte par la hiérarchie.

Implication des hiérarchies.

GIF - 5.6 ko
Implication des hiérarchies

La préparation des tests est intégrée dès les phases de conception.

Assurance qualité intégrée.

A chaque phase du projet, une structure désignée au début du projet doit examiner, recommander, contrôler les documents de projet, afin de vérifier l’adéquation avec les normes mises en place par la méthode.

Quelles compétences pour chacune des phases ?

GIF - 6 ko
Quelles compétences pour chacune des phases ?

Ne vous arrêtez pas là. Plongez vous dans les chapitres suivant décrivant chacune des phases de la méthode SDMS, en fouinant via notre moteur de recherche.  [1]