Articles

La DG devrait savoir qu’on est surbookés !

Le nombre de fois où nous avons entendu cette réaction durant nos missions de conseil est incalculable.
A chaque fois nous avons précisé à notre interlocuteur que non, la DG ne peut pas savoir tant qu’on ne lui dit pas.

En d’autres termes, l’absence de gouvernance de l’activité va amener à un manque de visibilité de la part du monde extérieur.
On ne parle pas ici de développer un système complexe de cubes OLAP et autres Big Data…
Mais seulement d’identifier quelques indicateurs simples qui ne manqueront pas de fournir une lecture de l’activité au monde qui nous entoure.

Exemple d’indicateurs de gouvernance simples

– Nombre de projets en portefeuille
– % de capacité projet de l’équipe
– Nombre d’incident ou nombre d’appel téléphonique reçu
– Nombre de jours de charge engagés sur l’équipe
– etc, etc

 

Thermomètre

Bref, toute indication qui fournisse au monde extérieur la position du curseur relatif à l’activité de l’équipe.

Sur l’idée de mise en place d’une gouvernance d’activité, deux réactions classiques s’opposent :

1- On n’a pas de temps à consacrer à une mise en oeuvre de ce type car nous sommes déjà très en retard sur l’ensemble des projets.  
Il est hors de question d’initialiser un projet de gouvernance d’activité sans l’officialiser auprès des instances de décision.
La mise en ouvre d’une gouvernance est un projet à part entière qui nécessite temps et budget.
Hors de question d’essayer de le mettre en place en catimini…cela ne fonctionne pas.

Les équipes ne collaborent pas au reporting puisqu’elles n’en comprennent pas l’objectif.
Les données collectées sont affichées ou publiées officieusement, sans explications et sont donc mal interprétées.

Il faut donc accorder a ce type de mise en place, un statut officiel, du temps et argent.

2 – On va développer une base d’infocentre qui fera pâlir la NASA.
Nous rencontrons à l’inverse des organisations trop créatives qui en partant d’un indicateur simple, dans la lancée de réunions d’analyse, imaginent de nouveaux référentiels, multiplient les tableaux de bords, et finissent par poser les plans d’un data warehouse digne d’un centre de recherche scientifique.
Entre rien et des analyses digne de processus de Data mining ou big data…il existe probablement une juste mesure.

Rester pragmatique, rester simple sont peut être des qualités qui se perdent.

 

En résumé, communiquer sur son activité et donner de la visibilité sur ses (limites de) capacité demande à mettre en place une organisation spécifique.
Sa mise en place prend du temps et selon le principe de Deming, il est judicieux de faire simple au début et d’améliorer à l’usage.

Donner de la visibilité sur son activité permet de faire prendre conscience au monde qui nous entoure des charges que nous avons à gérer.
Bien souvent cela permet de démontrer une surcharge, ou les limites de capacité de son organisation.
Non pas dans une déclinaison négative de ne pas être capable de faire, mais dans une vision réaliste de ses capacités réelles.

En synthèse, il faut savoir investir le temps d’une mise en oeuvre de sa gouvernance pour en gagner ensuite.

 

 

 

 

Comment favoriser la communication et le partage entre les membres d’une équipe projet notamment lorsque celle-ci est en partie interne, en partie externe ?

Ankaa Engineering® a résolu cette problématique de partage et de synchronisation d’équipe en mettant gracieusement à disposition de ses clients un environnement de site de travail collaboratif.

Chaque projet dispose ainsi d’un environnement dédié au sein duquel chaque contributeur au projet qu’il soit interne ou externe peut collaborer et partager ses informations avec le reste du monde (le monde du projet intra-muros bien sûr !).

Sites Projet Ankaa Engineering

L’espace de publication de document donne lieu à une traçabilité du versioning.

Spécifications fonctionnelles, techniques, procédures, documentation utilisateur et fiches de tests et de recette peuvent ainsi être stockées, partagées.
La gestion de version permet à l’espace de devenir le référentiel des documents du projet.

L’espace de discussion permet de statuer sur les cas et situations ou le traitement de cas.
Les équipes peuvent aborder des points d’analyse, des choix d’architecture mineurs, des points de validation ou de contrôles.
Cet espace ne remplace pas les réunions projet, les entretiens téléphoniques, les mails.
Il permet de partager les informations, les décisions mineures, les choix opérationnels.

Une todo-list permet d’affecter des travaux ou vérifier que certains jalons sont respectés.
Cette liste permet au chef de projet de mémoriser des actions stratégiques, de matérialiser un PAQ en affectant des travaux ponctuels à une ou plusieurs ressources.

Bien entendu, l’accès aux données est géré par profils.
Les documents publiés sont en fin de projet extraits et restitués au client.

Cet environnement ne se substitue pas aux réunions d’équipe, ne remplace pas les mails, le chat ou les appels téléphoniques.

Il se limite à être le référentiel des documents du projet, autorise l’interactivité entre les participants, le support « pense-bête ».

Mais très souvent, le site de travail collaboratif Ankaa Engineering® est adopté et devient rapidement indispensable pour les équipes réparties (interne – externe) ou en mobilité.

Position du PM dans l’organisation

Pour certains projets a faible enjeux, le chef de projet affecté est à temps partiel, dépend lui même d’une direction métier (FM). C’est l’organisation type du Kaisen.
Facilitateur
Dans ce schéma, le PM a un faible pouvoir décisionnel. Son rôle est l’animation d’équipe.
L’organisation la plus répandue est celle de chef de projets (chargés d’un ou plusieurs projets) qui animent une équipe transverse

 

Matricielle

Le(s) chef(s) de projets doivent négocier auprès des directions métier et arbitrer entre eux l’affectation des ressources.
C’est l’organisation la plus répandue dans les projets au sein des PME-PMI.

Le modèle équipe dédiée ou Task Force demande la mise en oeuvre de moyens importants et concerne les projets stratégiques ou « très en retard ».

Task

Le chef de projet bénéficie d’une équipe avec des ressources dédiées temps plein. Le PM gère directement l’affectation des charges.

Il existe bien sur quelques variantes des schémas principaux présentés ci-dessus.

Matrice de responsabilités

Nous retrouvons une matrice à 5 niveaux qui identifie la position occupée par le PM dans le pilotage et les décisions.

 
Leader fonctionnel
Matrice faible
Matrice équilibrée
Forte Matrice
Leader Project Manager
Description
Le FM est la seule autorité de gestion.
Le PM et FM partagent la responsabilité, mais le FM a plus d’autorité.
Le PM et FM partagent la responsabilité de façon équilibrée
Le PM et FM partagent la responsabilité, mais le PM a plus d’autorité.
Le PM est la seule autorité de gestion.
Autorité du chef de projet
Très faible.
Faible.
Faible à moyenne.
Moyen à élevé.
Haut.
La disponibilité des ressources
Très faible.
Faible.
Faible à moyenne.
Moyenne à élevée.
Haute.
La participation du chef de projet
À temps partiel.
À temps partiel.
À temps plein.
À temps plein.
À temps plein.
L’implication du personnel
À temps partiel.
À temps partiel.
À temps partiel.
À temps plein.
À temps plein.
Avantages
Le FM détient la responsabilité du projet.
Le PM collabore à la gestion du projet.
Le PM et FM partagent la responsabilité du projet.
Le PM a plus d’autorité pour affecter les ressources et gérer le projet.
Le PM a pleine autorité pour la gestion du projet et l’affectation des ressources.

Dans les scénarios d’équipes dédiées en mode « Task Force » (la colonne la plus a droite de la matrice) et malgré la position hiérarchique ou l’influence très marquée du PM dans le projet, il reste néanmoins important que le FM (le métier) soit impliqué.

Ne serait-ce lors des étapes d’expression du besoin, de choix des solutions, de test, d’accompagnement au changement, ou celle de recette, donc au final quasiment sur l’ensemble du projet, hormis les étapes de conception proprement dites, et encore…
En synthèse, quelque soit le projet, l’implication du FM doit être importante.
Bon nombre de projet sont en échec à cause d’un manque d’implication suffisant des métiers.
A compter du moment où un PM est affecté à un projet, les FM délèguent trop souvent à tort l’intégralité des responsabilités au PM en partant du principe que le PM a l’autonomie suffisante pour prendre en charge, en totale indépendance, la réalisation avec son équipe affectée à la conception.
D’un autre côté, si le PM ne s’assure pas du niveau d’engagement du FM et de ses ressources sur le projet, il se trouve très rapidement confronté à des difficultés dues, soit à des retards d’avancement du à l’attente d’information stratégiques, soit des rejets des livrables du projet du à l’absence de validation régulière de la part des métiers.

En résumé

Nous pouvons considérer que l’implication du FM et des ressources métier doivent être permanente et suffisantes tout au long du projet.
Le rôle de PM reste celui d’un assistant délégué à organiser, communiquer, coordonner, piloter, suivre, reporter.
Le PM pourra avoir recours à la matrice de RACI pour l’affectation des rôles des ressources.

Le scénario d’un projet dans lequel la MOA confie le projet au PM et réapparaît pour la recette finale implique, au lancement du projet, la remise par la MOA d’un cahier des charges exhaustif et détaillé. Le monstre du Loch Ness, beaucoup en parlent, peu l’ont vu !

Formation ordonnance pour pm surbooké

Beaucoup de chefs de projet considèrent qu’ils sont surchargés, surbookés, noyés par les demandes et leur activité.

Mais combien prennent conscience qu’ils sont eux-mêmes bien souvent à l’origine de cette situation ?

Ankaa Engineering® met à votre disposition ses experts pour un webinaire  « ORDONNANCE POUR PROJECT MANAGER SURBOOKE ».

Le moyen, en 1h30 de séminaire, de prendre du recul sur son quotidien et de repartir du bon pied.

Prochaine session jeudi 9 octobre de 17 à 18h30 (GMT Paris)

Cliquez ici pour vous inscrire

 

 

Réfléchir avant de faire, faire et corriger les écarts en réfléchissant à comment les mettre en application avant de les mettre en oeuvre, étudier les nouveaux écarts constatés et mettre en application les correctifs non sans avoir analysé avant la meilleure manière de les implémenter, etc…

William Edwards Deming,  professeur et consultant américain en amélioration des processus a formalisé cette routine sous la forme de la « roue de Deming » qui représente un cycle de 4 phases répétitives qui ont pour objectif l’amélioration qualité du produit fini.

Roue de Deming PDCA

  • Plan

    Planifier et préparer ce que l’on doit réaliser. Clarifier l’objectif, ordonnancer les tâches, planifier.

  • Do

    Exécuter les travaux prévus.

  • Check

    Contrôler et vérifier les résultats. Evaluer et comparer avec le prévisionnel.

  • Act

    Corriger, agir, réagir et réajuster les processus si nécessaire.

On entre alors dans un cycle répétitif d’amélioration permanente d’un produit ou d’un service.

Dans une logique d’évolution permanente, une cale symbolise la capacité à gérer les non-régressions.

Cette démarche d’ajuster et d’améliorer en avançant ressemble beaucoup à la logique des méthodes agiles.

Méthodes agiles

Les méthodes agiles s’appliquent au développement applicatif et reposent sur un principe de cycle de développement itératif, incrémental, adaptatif.

Parmi les plus répandues, nous trouvons les méthodes EVO, RAD, DSDM, ASD, FDD, Kanban, Scrum et XP Extremeprogramming.

Toutes s’appuient sur une approche d’amélioration continue :

– Affinage itératif du besoin en cours de réalisation :

– Fonctionnel, selon les résultats de la validation permanente des utilisateurs (RAD, XP)

– Technique, par révision du code (refactoring)

– Découpage incrémental du projet en fonctionnalités de quelques jours
– Techniques de contrôle du livrable dans un périmètre variable et adaptatif.

– Implication du client qui permet d’adapter et modifier « au fil de l’eau » le détail des fonctionnalités attendues.

méthode-agile

Les méthodes agiles se rapprochent de la logique de la roue de Deming dans la mesure ou les deux principes s’appuient sur une analyse empirique basée sur l’expérience terrain.

Concevoir avec pragmatisme et clarifier le besoin fonctionnel en avançant contribue à se concentrer sur l’utile et l’important au final.

Ce type d’approche contribue à une meilleure génération de valeur pour le compte de l’entreprise puisque les choix opérés portent sur des unités fonctionnelles plus petites, facilement compréhensibles et dont la valeur ajoutée est mieux ressentie et plus facilement évaluable.

En matière de gestion de projet, le Reporting est l’élément fondamental qui permet d’éviter le mur…
Mais c’est surtout l’information la plus délicate à collecter.

Reporting projet

En effet, lorsque mal présenté ou expliqué le Reporting peut être ressenti par les équipes comme une demande de justification du travail fourni.
Alors que l’objectif est d’identifier des écarts entre une organisation prévisionnelle du projet et la réalité de réalisation.

Nous rencontrons alors des scénarios ou la collecte des informations s’apparente plus,  pour le chef de projet, à un parcours du combattant !
Car pour être pertinent, le Reporting doit être collecté simultanément auprès de l’ensemble des ressources, sous forme d’une « photographie » de la situation.

Ce qui dans la phase initiale de mise en place d’une organisation de Reporting, contraint le chef de projet à faire très régulièrement le tour des équipes pour relancer les retardataires et ceux qui ont « oublié » cette tâche.
Il n’est pas rare que ces relances soient à renouveler de très nombreux mois d’affilés, jusqu’à ce que les équipes, soumises à la ténacité du chef de projet, finissent par capituler.

Dans le contexte de projets importants, les flux de Reporting devront être organisés en terme de circuit et d’outils.
Dans ce cas, l’essentiel des apports des outils sera la décentralisation des données de reporting, avant les capacités d’analyse consolidée des informations collectées.

Pour ce qui est du contenu, il est clair que si chaque action de reporting projet réclame des heures de mise en page de documents, les profils opérationnels, généralement peu enclins à formaliser leurs travaux, arriveront vite à saturation de cet exercice et « traîneront les pieds ».
Ce qui fourni peut être un élément de cause à la situation décrite plus haut.

Une seule information de reporting projet est pertinente !

Un projet étant formalisé par le chemin entre le point A (l’existant) et le point B (l’objectif), le chef de projet se doit d’être en permanence tournée vers le point B.
Son métier consiste à suivre, piloter et réorganiser les travaux pour garantir l’atteinte de l’objectif. Il se doit donc de ne pas perdre du vue le point B.
De plus, les événements survenus entre le point A et l’instant présent sont de l’ordre des constats. Plus aucune action ne peut les affecter. Le passé est le passé.
Le chef de projet est un homme d’avenir…

boule de cristalboule de cristal

A partir de cela, obtenir les informations sur le passé n’apportera pas un éclairage nécessaire et suffisant au chef de projet.
Savoir que les travaux ont débutés à l’heure, que le temps de travail réalisé à l’instant présent est conforme au prévisionnel n’a aucun intérêt pendant l’exécution du projet.
Revenir sur l’histoire, le passé, n’a de pertinence uniquement dans un but de rechercher et identifier les causes des incidents et ainsi éviter de les reproduire.
C’est normalement l’analyse qui est réalisée dans une phase de clôture de projet (phase rarement réalisée par ailleurs… mais c’est une autre histoire).

Ce qui veut dire que la seule information qui intéresse le chef de projet ne concerne que des éléments d’avenir.
En l’occurrence le RESTE A FAIRE.

En obtenant le reste à faire pour chaque travaux en cours, le chef de projet peut réévaluer le cas échéant la pertinence du plan prévisionnel.
Il est dans l’amélioration continue (roue de Deming) et peut interagir immédiatement pour atténuer l’impact des situations annoncées.

Finalement, dans ce schéma, le reporting projet ne se résume qu’à une seule information réévaluée sur les seules tâches en cours d’exécution.
Un flux d’information sans superflu et totalement utile et efficace.

 

 

 

Formation ordonnance pour pm surbooké

L’orientation stratégique de l’entreprise et l’alignement des différents projets, la définition de la hiérarchie et de la priorité des projets, la transversalité des projets et le partage des ressources, l’évaluation des charges et la capacité réelle des ressources, la gestion des risques et leurs contre-mesures, le circuit d’approbation et de décision, la communication horizontale et verticale, etc. constituent le champ d’intervention des  gestionnaires et responsables de projet.

Beaucoup considèrent qu’ils sont surchargés, surbookés, noyés par les demandes et leur activité.
Mais combien prennent conscience qu’ils sont eux-mêmes bien souvent à l’origine de cette situation ?

Ankaa Engineering® met à votre disposition ses experts pour un webinaire  « ORDONNANCE POUR PROJECT MANAGER SURBOOKE ».

Le moyen, en 1h30 de séminaire, de prendre du recul sur son quotidien et de repartir du bon pied.

Cliquez ici pour vous inscrire sans tarder, les places sont limitées.

Dans les organisations de taille intermédiaire, nous constatons très souvent que le titre de chef de projet s’apparente plus à un titre honorifique qu’une responsabilité véritable affublée de moyens pour l’assumer.

Dans ces structures, qui plus est, le chef de projet se voit affecté au pilotage et suivi de multiples projets parallélisés.
Il doit en outre et en complément assurer sa fonction initiale, ou alterner entre rôle de chef de projet et celui de ressource.

Dans ce type de scénario, l’une des principales difficultés pour l’individu est d’équilibrer sa charge de travail entre ses multiples casquettes.
La question récurrente est : « Quel temps dois-je passer au suivi de mes projets ? »

Selon différents abaques méthodologiques, on peut considérer que le temps que le chef de projet doit affecter correspond entre 10 et 20% du nombre de jours total du projet. Bien entendu, cette charge n’est pas constante entre les projets, ni selon les phases du projet.

Le curseur du pilotage par le chef de projet sera le plus souvent ajusté selon le niveau de risque encouru.

Graphes affichés sur l'écran du chef de projet

Un projet novateur demandera probablement plus d’engagement de la part du chef de projet qu’une évolution fonctionnelle d’un système existant.

De même, au sein d’un projet, la présence du chef de projet sera variable selon la criticité des phases ou de l’impact des incidents rencontrés.

Mais comment savoir si le dosage « chef de projet » est le bon ?

Un indicateur très simple permet de déterminer si le temps consacré est le bon.

Si, à la question posée par la MOA « Comment se passe le projet ? », le chef de projet ne peut répondre que d’une formule laconique du type « Globalement ca se passe pas mal ! », le temps alloué à la fonction chef de projet est largement insuffisant.

Un chef de projet qui suit ses affaires correctement formulera une réponse claire et quantifiée du type « On est en retard de 10 jours sur l’objectif du à des problèmes rencontrés sur l’intégration de la fonction  de sécurité ».

En résumé, tant que le chef de projet n’a pas une vision claire et précise de la situation du projet, il doit se mettre à la tâche.

Dans le contexte des projets, et notamment ceux portant sur l’amélioration des processus, il peut être nécessaire d’identifier précisément les causes des incidents de manière à appliquer les bonnes mesures correctives. L’outil Qualité diagramme d’Ishikawa, appelé également diagramme de causes et effets, diagramme en arêtes de poisson ou le diagramme 5M (variantes 6, 7, 8M) aide à l’identification des sources (causes) d’un dysfonctionnement (effet). Cet outil a été conçu par Kaoru Ishikawa (1915 – 1989), ingénieur japonais employé par NISSAN, et membre de groupe de progrès auxquels participaient également Deming, Juran ou Taguchi.

Comment utiliser le diagramme d’Ishikawa?

1 – Clarifier l’objectif recherché Comme pour tout travail, il est important de clarifier l’objectif recherché et notamment de définir avec précision l’incident (l’effet) à supprimer. Il est important de considérer qu’un diagramme d’ Ishikawa ne traite qu’un problème unique. Si un problème peut être subdivisé en incidents élémentaires, chacun d’eux devra initier son propre diagramme. diagramme d'Ishikawa, diagramme de causes et effets, diagramme en arêtes de poisson, diagramme 5M Nous plaçons alors le libellé du problème dans le cadre « effet », c’est le problème pour lequel on recherche les « causes possibles ».

2- Séance de brainstorming

On inventorie tout ce qui peut être à l’origine de l’effet. 3- Regrouper les éléments selon les causes commençant par M. Matériel : pannes d’origine matérielle, outils.  Moyens ou Machines remplacent parfois la catégorie Matériel. Main-d’oeuvre : l’origine de l’incident a ou peut avoir une cause humaine. Méthodes : l’absence de méthodes, de procédures, d’organisation est la cause du problème. Matières : matières premières, consommables de qualité insuffisante engendrent des incidents. Milieu : L’environnement de travail n’est pas adapté et engendre des difficultés dans l’accomplissement du travail. Accessoirement, une sixième catégorie, celle des Mesures peut être ajoutée pour regrouper  les causes liées à l’absence de contrôle ou de mesures. Il existe enfin des variantes 7 et 8 M avec l’adjonction des arêtes Management (pour isoler les causes liées à un problèmes d’encadrement) et Moyens financiers (pour identifier les insuffisances de ressources financières affectées sur un sujet). On arrive quelquefois au modèle 9M dans le monde de la production qui isole parfois les origines d’effet liées à la Maintenance pour mettre en avant l’absence d’entretien du Matériel. A partir des « arêtes secondaires » qui représentent les M, on associe les causes répertoriées à l’aide de petites flèches horizontales.  4 – Déterminer la cause la plus probable

En ayant recours à la méthode des « 5 pourquoi« , le groupe affine son analyse. Taiichi OHNO (1912 – 1990), ingénieur japonais, est le promoteur de la méthode des 5 Pourquoi. Le principe est, pour chaque causes symptomatiques identifiées lors du brainstorming du groupe, d’aller chercher ses causes racines, les causes fondamentales, véritable source du problème. La méthode des 5 Pourquoi s’applique en posant  une question commençant par « Pourquoi » et pour chaque réponse apportée une nouvelle question commençant par « Pourquoi », 5 fois de suite. Ceci pour remonter graduellement aux causes fondamentales du problème.

5 –  Elaborer le plan d’action correctif 

Chaque cause fondamentale se verra affectée un plan d’actions correctives. Chaque plan d’action se verra attribué un gestionnaire.

Le diagramme de Kano a été inventé par le Dr Noriaki Kano en 1984 afin d’évaluer la satisfaction client.

L’approche de  Noriaki Kano s’appuie sur l’interrogation d’un client sur son niveau de satisfaction et de non satisfaction au regard de la présence ou de l’absence d’une fonction.

L’analyse simultanée des deux tendances va permettre de hiérarchiser les points de l’interview.

L’analyse des réponses va amener à une classification de chaque point  :

1- Les attentes de base (B) : ces points doivent impérativement être satisfaits pour répondre au besoin et sont considérés comme obligatoires et leur présence est considérée comme « juste normale » alors que leur absence à l’inverse engendre des dysfonctionnement.

2 – Les attentes proportionnelles (L) : Les fonctionnalités linéaires augmente avec le niveau de performance et ont un impact direct avec la satisfaction des clients

3 – Les attentes attractives (E) : c’est les options qui apportent un plus significatif mais dont l’absence n’engendre pas de critique de la part du client. Ce sont celles qui font la différence sur le marché.

4 – Indifférents – (I) :  Aucun impact en cas de présence/absence, peu de valeur ajoutée.

5 – A double tranchant – (Q, R) :  Incohérence de réponses ou réponses ambiguës.

Courbes de la matrice de Kano

C’est un outil d’évaluation «Qualitatif » qui repose sur des interviews.
Pour construire ce diagramme, un questionnaire Kano recueil pour chaque fonction le niveau de satisfaction de l’interviewé sur une échelle de 5 valeurs :

  1. ca me plait (Like)
  2. c’est normal (Expect)
  3. ca m’est égal (Neutral)
  4. je fais avec (Live with)
  5. ca me dérange (Dislike)

La méthode consiste à évaluer successivement le niveau de satisfaction d’une part si la fonction est présente et d’autre part si elle absente.
On consolide les réponses obtenues et selon le plus grand nombre de réponse similaires, on se reporte à la matrice de Kano pour obtenir sa classification

Matrice de Kano

Toute l’originalité de cette approche consiste en fait à poser la question que l’on ne pose jamais ou très rarement : Et si tu n’as pas ce que tu demandes… que se passe-t-il ?

Utiliser Kano pour hiérarchiser les demandes utilisateurs ?

Dans le périmètre d’un projet fonctionnel ou d’une activité de MCO (Maintien en Condition Opérationnelle), face à un volume important de demande, le recours à la matrice de Kano permet de hiérarchiser les demandes, de les pondérer de façon à concentrer les énergies sur celles génératrices de valeur ajoutée.