Pilotage de Programme/Projet: vision générale

Comme vous aussi j'imagine, j'ai pas mal lu, vu, entendu sur la Gestion de Programme et de Projet (la différence importe peu ici). J'ai également pratiqué et pratique toujours. Qu'en retenir ? 

Je vous propose ici une vision générale du sujet qui peut servir d'aide au démarrage du Programme ou Projet, pour ne rien oublier et établir tout le nécessaire. Cela ne prétend pas à l'exhaustivité, j'affiche seulement l'essentiel.

Le cadre : l'Entreprise

Vous voyez sur le schéma général ci-dessus que tout est encapsulé dans l'Entreprise porteuse de l'activité. En effet, celle-ci va conditionner tout son déroulé :

• Organisation (Matricielle ?)
• Us et coutumes
• Outils (de gestion de Projet, ERP, ...)
• Culture
• etc.

Tous ces éléments vont aider et/ou contraindre l'aventure. Il faut les avoir en tête et les exploiter dès le départ.

Les Ressources Humaines

Elément central et essentiel : les personnes ! Aucune activité ne se fait seule, il faut quelqu'un pour la porter & apporter sa compétence.

Le chef doit s'assurer de :

• La disponibilité des personnes pour le projet (négociation de ressources à faire - J'ai besoin de Jean-Luc du 28/02 au 17/05 pour concevoir cette carte électronique)
• Les coordonner (organisation des activités, réunions hebdo etc.)
• Communiquer et faire communiquer (les informations de planning, les difficultés car l'oscillo n°8 est tombé en panne etc.)
• Distribuer les responsabilités sur les périmètres de chacun (Zinédine doit fournir à Bixente telle information à tel moment)

Le niveau de formation des personnes est important, c'est pourquoi le Chef de Programme/Projet doit s'assurer que les personnes impliquées sont bien compétentes pour leurs missions. Et si mise à niveau il doit y avoir, alors soit, on peut (faire) réaliser des formations.

Parfois les compétences en internes sont trop compliquées ou chronophages à obtenir. On peut alors consulter à l'extérieur : experts indépendants, freelance, agences de consultants etc.

La Planification

C'est l'une des premières activités du Programme/Projet. Et elle se poursuit tout du long.

Il s'agit, à partir de la volonté du Client (qui peut être interne à l'entreprise) :

• De récapituler les Objectifs du Programme/Projet (on veut réaliser 1 produit qui réalise 1 fonction, en limitant le coût à X€, ...)
• De clarifier les Hypothèses induites (recrutement, réutilisation de telle partie de tel autre produit, ...)
• D'en déduire un Calendrier jalonné (via un Gantt potentiellement)
• De reboucler sur tous ces éléments si le Retour sur Investissement n'est pas clair/favorable en l'état
• De documenter toutes ces informations (Objectifs, Hypothèses, Revues à telles dates, ...) dans des documents signés (Plan de Management Programme par ex.) par les principaux intéressés
• D'établir et alimenter une base d'actions (dans un Excel, dans un board Trello...), qui seront distribuées aux équipes pour démarrer et avancer

Les Risques/Opportunités

Les Risques liés au Programme sont à gérer dès le début, et tout au long de ce dernier.

Ils peuvent être de plusieurs type :

• Business (concurrence un peu trop farouche qui va sortir le bon produit avant nous?)
• Organisationnels (je ne peux pas avoir telle personne sur mon projet à tel moment ?)
• Techniques (nous allons devoir utiliser dans notre Produit tel processeur qu'on n'a jamais utilisé auparavant ?)
• Humain (tensions palpables entre deux équipes qui doivent collaborer?)

L'important est de les repérer et de les mitiger. Cette liste initiale de Risques va évoluer tout au long du projet car certains risques vont disparaître; d'autres au contraire vont montrer le bout de leur nez. 

Et ne pas oublier: les Opportunités ! De la même manière qu'on traque les choses qui pourraient mal se passer, il faut aussi monitorer les éventuelles joyeusetés à saisir.

Les Opportunités se regroupent selon les mêmes types que les Risques:

• Business (concurrence qui flanche ?)
• Organisationnels (telle personne va peut-être se libérer pour mon Projet à tel moment, je vais tâcher de la faire plancher sur tel sujet ?)
• Techniques (nous allons utiliser tel processeur qui possède une fonction bluetooth car il est fort probable qu'on fasse évoluer le Produit en ce sens pour tel client futur?)
• Humain (bonne entente entre deux équipes qui doivent collaborer?)

Livraison du Produit

Si vous voulez en savoir plus sur comment concevoir, développer, valider et livrer un Produit à client, je vous invite à lire la partie Ingénierie Systèmes de mon site.

La Qualité

La Qualité peut se résumer à ces quelques points:

• Répondre de manière satisfaisante à la demande du client
• Appliquer les règles et bonnes pratiques pour faire du produit conçu un produit fiable, sécurisé ("Ne pas utiliser telle lib de code car connue comme défaillante ou non sécurisée")
• Suivre les Règlementations, Normes, Lois qui contraignent votre Produit ("Il ne doit pas émettre de perturbations électromagnétiques" par exemple) et la façon de le concevoir ("sa conception doit forcément passer par une étape de tests de Validation en présence du client")

C'est très haut niveau évidemment. On pourrait faire 10 articles sur chaque point.

Enfin, vous pouvez prétendre à des certifications de votre produit (CE, ...) si les standards qui intéressent ces organismes sont respectés.

La gestion de Configuration

Il s'agit ici de s'assurer que vous maîtrisez tous les Produits, Outils, Document que vous manipulez pendant le Programme :

• Si vous avez besoin de vous fier à un document technique (une Spécification Générale par exemple), il faut que vous sachiez quelle est la version en vigueur (v1.4? v1.5? v1.5finalfinal?)
• Si vous devez vous servir d'un script pour analyser des données de simulation du fonctionnement du Produit que vous concevez, idem, il faut savoir quelle version utiliser
• Si vous produisez des Produits qui sont similaires ou qui évoluent au cours de leur vie, il faut bien les distinguer et les gérer séparément (Le Dossier de Définition en vigueur pour ce Produit est le 3.5.4, et une fois assemblé et testé selon la procédure 5.1.0 il doit aller dans la corbeille jaune de l'étagère bleue)

Cela vaut pour les Produits, Outils, Documents orientés Techniques, mais également pour les Documents non Techniques (par exemple : les Documents d'initialisation du Projet vus plus haut).

La gestion de l'Information

Une grande partie de ce qu'on manipule pendant un Programme/Projet n'est "que" de l'information: des fichiers, documents, mails, codes, plans, gerber, schémas, ...

Il faut donc des outils et des supports pour pourvoir générer, modifier, stocker et partager ces informations:

• Boîtes mails
• Réseau d'entreprise
• Disques partagés
• Outils (Microsoft Office, Environnements CAO, Git, ...)
• Et évidemment toutes les infrastructures porteuses associées

Ces outils doivent assurer pour l'information qu'ils contiennent l'acronyme DICTAR :

• Disponibilité (le fichier que je cherche dans les répertoires partagés de mon intranet doit être accessible quand je le souhaite)
• Intégrité (ce fichier doit pouvoir être ouvert... On ne souhaite pas avoir de pop up "une erreur a été rencontrée à l'ouverture du fichier" ...)
• Confidentialité (ce fichier ne doit être accessible qu'à ceux qui doivent en connaître. Une protection/administration d'accès nécessaire doit être en place)
• Traçabilité (je veux savoir qui a modifié ce fichier à quel moment et ce qu'il a fait)
• Authenticité (on doit être raisonnablement sûr que le fichier qu'on regarde provient bien de qui on pense)
• Redondance (il est toujours important d'avoir des back ups... Et pouvoir les solliciter/rétablir si nécessaire)

A noter que ce sujet est en lien étroit avec la gestion de la Configuration vue plus haut. En effet, le Système d'Information de l'Entreprise doit permettre de faire de la Gestion de Configuration.

Enfin, des canaux de communication (Mails, Slack, ...) doivent exister pour tout simplement se tenir informés de ce qu'il se passe dans le Programme, s'envoyer des news, instructions etc.

Le Passage à l'échelle

Vaste sujet. Si ce que vous faite actuellement tient à :

• Fabriquer des produits en série
• Réaliser des études
• Gérer des projets

Et si vous voulez faire cela mieux et de manière plus rapide, il faut :

• Maîtriser l'existant : clarifier le Process à suivre, les Méthodes que vous utilisez
• Vous outiller : avec des Outils (logiciels, physiques etc. ) qui vont vous faciliter la vie
• Documenter tout cela de manière écrite : l'info sera plus facile à transmettre, et le fait de schématiser fait apparaître s'il y a des trous dans la raquette
• Former les intéressés à ces PMO (Process, Méthode, Outils)
• Enfin, automatiser tout ce que vous pouvez. A noter que cette étape vient habituellement en dernier, mais on peut être malin et la considérer dès le début dans nos choix de Process et d'Outils.

Exemple : Vous souhaitez produire en série des Produits.
Il vous faut alors définir clairement un processus à suivre pour la production, avec les méthodes à suivre --> Dossier de Fabrication et de Contrôle.
Vous devez acheter/fabriquer les outils qui vont vous permettre de faire bien et vite : visseuse électrique, ERP, scannette pour scanner vos produits et suivre leur déplacement sur les lignes de prod, édition automatique de PV de production, ...
Former et entraîner tous les protagonistes à la mise en oeuvre de ces PMO.
Automatiser au maximum : au poste X, on peut supprimer la scannette (que l'utilisateur doit saisir puis passer sur l'étiquette Produit) en la remplaçant par une caméra à demeure sur le poste qui vient détecter, reconnaître, et enregistrer le code barre du Produit que l'opérateur est en train de manipuler.

La Gestion du Programme/Projet

Les éléments vus dans les paragraphes ci-dessus sont des parties intégrantes de la Gestion de Programme/Projet, bien qu'ils puissent être vus comme ne faisant pas partie du cœur du travail du Chef. Ils sont essentiels à la réussite de l'activité.

Pour ce qui est considéré généralement comme le cœur, voilà à très haut niveau le contenu:

• Evaluation à maille régulière des coûts (heures de travail, dépenses €, entretien des moyens, capital) récurrents et non récurrents
• Evaluation de l'avancée des activités face au planning en vigueur
• Evaluation du niveau de qualité atteint
• Evaluation d'autres indicateurs divers, qu'on peut se définir en début de projet si on le souhaite
• Comparaison aux prévisions coûts, planning, qualité.
• Prise de décisions pour piloter le Programme (rectifier le tir ou rester dans la dynamique)
• Un regard sur ce qui se passe autour de son entreprise (les marchés et secteurs qui bougent, les métiers et façons de travailler qui évoluent...)

Tout ceci est à mettre en regard du Chiffre d'Affaires afin de remplir les 2 objectifs essentiels d'une activité :

• La satisfaction du client (objectif externe)
• Dégager une marge (objectif interne)

Une bonne pratique souvent oubliée : faire un post mortem à la fin de l'aventure pour faire le point sur ce qui a bien marché, ce qui a été handicapant etc. Pour alimenter ce post mortem au-delà des chiffres, il faut du contexte. D'où la bonne idée pour le Chef de Programme/Projet de tenir une sorte de Journal de Bord du Programme/Projet !

Les relations entre toutes ces considérations

Voir le schéma général et ses flèches !

‍

En espérant avoir dégrossi le sujet au besoin, et a minima avoir fourni un pense-bête utile !

N'hésitez pas à me faire vos suggestions et commentaires via les moyens que vous trouverez en bas de page (Mail, Twitter, LinkedIn) !

Aurélien NARDINI