Articles

Roue de Deming PDCA et méthode agile

, ,

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.

/par

Reporting projet : Une seule information pertinente !

,

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.

 

 

 

/par

Comment réguler sa fonction « chef de projet » au quotidien

,

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.

/par

Diagramme d’Ishikawa

, ,

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.

/par

Hiérarchiser les demandes utilisateur avec Kano

, , ,

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.

/par

Négocier son triangle

,

Le rôle et la responsabilité d’un chef de projet ou Project Manager est de garantir l’atteinte de l’objectif  dans le respect des contraintes de délais et de budget. Un formalisation de ce périmètre de responsabilité est souvent établie sur la base du triangle QCD (Qualité, Coûts, Délais).
Nous avions abordé l’importance d’une vision partagée de l’objectif au sein de notre article précédent.

En s’appuyant sur le symbole du triangle, nous pourrions scénariser les échanges entre la MOA et le chef de projet selon, bien entendu, une vision initiale différente du périmètre du triangle.

1) La MOA a naturellement tendance à considérer le périmètre du projet sous la forme d’un triangle extrêmement pointu, soit la réalisation de l’objectif ambitieux (Qualité) avec un budget (Coût) des plus réduit et une durée d’obtention (Délai) des plus courtes.

2) Dans la phase d’étude de faisabilité, la responsabilité du chef de projet va être d’évaluer le périmètre réaliste du triangle (avec une base élargie), pour l’amener en superposition avec celui de la MOA et entrer dans une phase de discussion-négociation de moyens.

3) Face à des exigences de respect budgétaire, le chef de projet va aménager le plan projet avec une probable extension de durée de réalisation pour limiter au mieux les appels à la sous-traitance externe.

4) Face à l’expression d’une contrainte de délai de livraison impérative, le chef de projet va organiser le plan projet avec une probable demande de budget complémentaire pour disposer des ressources suffisantes.

5) Face à une double pression temporelle et budgétaire, les discussions amèneront (normalement) la MOA à une révision de l’exigence en terme d’objectif.

6) Le compromis entre la MOA et le chef de projet permettra de définir le périmètre de réalisation du projet et par extension les engagements et le périmètre de responsabilité du chef de projet.

7) Ce dernier aura bien entendu intégré à son étude et négociation une gestion des risques (AMDEC ou autre) puisque ces derniers font partie intégrante de la responsabilité d’un chef de projet dans le pilotage des réalisations qui lui sont confiées.

Triangle QCD animé

 

Cette étape d’évaluation des moyens et de négociation est critique puisqu’elle conditionne les chances d’atteinte de l’objectif du projet.
Le chef de projet dans sa mission de pilotage des réalisations et à partir du REPORTING, devra suivre l’évolution des paramètres QUALITE, COUTS et DELAIS.

A la clôture du projet, la superposition du triangle « réalisé » sur le triangle « prévisionnel » permettra d’évaluer les écarts sur l’objectif.

Tout repose donc sur la capacité du chef de projet à négocier les moyens adaptés à la réalisation.

/par

Témoignage client Région Alsace

, , , ,

Témoignage recueilli à l’issue d’une mission de formation « Fondamentaux de la gestion de projets » menée auprès de la DSI de la Région Alsace :

« La formation sur le thème de la gestion de projet a été très enrichissante : elle m’a permis de poser les bases d’une nouvelle méthode de travail plus efficace et optimisée. En effet, grâce à l’expérience du formateur et à l’efficacité du support de cours, j’ai pu dégager rapidement les mots et les phases clés d’un projet bien géré. Elle m’a également permis d’ouvrir les yeux sur un certain nombre de mauvaises habitudes et m’a offert de nouveaux outils pour une meilleure organisation au quotidien. »

Jérôme SALEH
Direction Informatique (DSI)
Région Alsace
1, Place Adrien Zeller – BP 91006
67070 STRASBOURG CEDEX
Tél : (+33) 3 88 15 68 67		 Région Alsace

La Région Alsace assure des missions dans les domaines variés de l’apprentissage, la formation professionnelle, le développement économique, les transport, l’aménagement du territoire…Certaines sont obligatoires, d’autres sont issues d’un choix régional. Le Conseil Régional d’Alsace est constitué de 47 élus (29 Bas-Rhin et 18 Haut-Rhin). Son budget annuel est d’environ 800 millions d’euros. Sur 1 869 agents, 523 agents sont rattachés à la Maison de la Région et répartis au sein des différentes directions opérationnelles et fonctionnelles et 1 346 agents TOS (techniciens et ouvriers de services) travaillent dans les lycées alsaciens

/par

Décider en toute connaissance de ROI

, ,

La gestion de portefeuille de projet est un art complexe.
Qui plus est au sein des structures de tailles modestes, celles où les projets sont eux mêmes de taille réduite mais en nombre important, tous plus prioritaires et critiques les uns que les autres, avec de fait un niveau de parallélisation extrême.

Dans ce type de structure les PMO et autres instances organisationnelles existent rarement.
Face à des marchés challengés, des marges d’erreur limitées, tout se résume à aller vite dans une dynamique confuse la plupart du temps.

La direction générale définie les projets stratégiques, ceux qui doivent concentrer l’intérêt et l’attention de toutes les équipes.
Et malgré ces consignes, ces projets prennent du retard.

Parmi les multiples causes des retards, l’une est le traitement simultané de micro-projets, demandes MCO, ou tâches de support qui viennent consommer de la capacité temps sur l’équipe affectée aux projets.

Comment gérer le flux des tâches MCO et micro-projets pour en réduire le volume ?

Nous recommandons pour cela d’adjoindre à chaque demande de travaux, le calcul d’un indicateur d’évaluation de rentabilité tels que ROI (Return of Investment) ou Pback (Payback Period) ou NPV (Net Present Value) ou IRR (Internal Rate of Return).

Calculer le Payback ou le ROI pour savoir si les économies sont présentes.
En d’autre termes, faire identifier de manière chiffrée, les gains et opportunités attendues de la demande.

Pour cela, il faut instaurer la formalisation de toutes les demandes émanant des métiers sur le modèle de document fiche projet  présentée dans notre précédent article « une vision partagée de l’objectif « .

Les paragraphes MOTIVATIONS ET FAITS DECLENCHEURS et GAINS ET OPPORTUNITES ATTENDUS de la fiche projet comporteront les évaluations des gains financiers attendus, évaluations établies directement par les demandeurs (MOA).
La fiche projet sera alors reprise par le service Etude de la DSI qui définira dans un second temps les moyens matériels et humains à affecter à l’atteinte de l’objectif, la durée de réalisation, la gestion des risques associés à la réalisation, et évaluera le coût total de possession (TCO) associé au projet. 

Les charges du projet une fois confrontées aux gains attendus permettra alors de déterminer le ROI (Return of Investment) ou Pback (Payback Period) ou NPV (Net Present Value) ou IRR (Internal Rate of Return), bref, la rentabilité  de la demande.

Les demandes sans apports de performance significative pour l’organisation seront alors plus facilement refusées.
La hiérarchisation du portefeuille de projets en sera dans tous les cas facilitée.

En sus l’analyse de la valeur du SI (tant convoitée) sera (enfin) possible puisque chaque demande, initiative, projet comportera l’évaluation de ses apports au sein de l’organisation.

Ainsi le statut GO/NOGO sur la demande sera décidé en connaissance du ROI.

/par

PM, ne soyez pas des héros

, ,

Quelle est la première chose que vous imaginez lorsque vous entendez le mot «héros»?
Un pompier, un chevalier, Superman, Spiderman ?

Super-héros Superman

Il y a fort à parier que le rôle d’un gestionnaire de projet n’est pas susceptible d’être le premier choix pour la plupart des gens !

Cependant, parfois les chefs de projet et leurs équipes doivent accomplir des actes d’héroïsme pour réussir les projets.
Et nous sommes là dans un contexte culturel entretenu, non dans une obligation d’effort induite par des difficultés particulières rencontrées.

La culture des entreprises est trop friande de prouesses et l’éducation reçue, établie sur la valeur de l’effort, influe sur le reste.
– Etes vous au courant pour l’équipe IT ?
– Non, que s’est-il passé ?
– Ils enchaînent les nuits blanches depuis deux jours !
– Que ferions-nous sans eux ?

Il est alors offert une reconnaissance minimale à ceux qui qui achèvent leurs projets sans efforts et tensions.
Le message communiqué est qu’il est préférable d’être un héros, un battant, que d’être un chef de projet calme, fiable avec une bonne maîtrise de la situation.

Dans de tels environnements, les équipes de projet qui évoluent dans un environnement établi sur ces distinctions peuvent planifier et gérer leurs projets de sorte que l’héroïsme et l’effort permanent soit l’un des composants principal.

Ancré culturellement, ce type de comportement n’est peut-être pas toujours conscient, mais est induit par la marginalisation ou l’élimination totale de la gestion des risques, la prise de raccourcis sur les bonnes pratiques de gestion de projet ou par un empressement lors de l’évaluation du périmètre des projets.

Le problème est double:

– Être un héros ne favorise pas un bon équilibre travail-vie privée et il est peu probable que tous les membres de l’équipe adhèrent au choix du chef de projet de réaliser des exploits de manière permanente, notamment pour les générations Y.
– La chance finit toujours par tourner  – même pour les plus grands héros.

Alors ? Faut-il abattre les héros ?

Il est donc important d’identifier les comportements héroïques pour émettre des recommandations et encouragement à l’apprentissage et l’utilisation de méthodes de gestion de projet dans le but d’inverser le contexte et faire que les actes d’héroïsme ne soient plus assimilés à la méthode…
Et, donc promouvoir et féliciter les équipes projet qui atteignent l’objectif après avoir définit un prévisionnel réaliste et une organisation équilibrée et respectueuse.

Comme l’a dit Christopher Reeve  « Ce qui rend Superman un héros n’est pas qu’il a le pouvoir, mais qu’il a la sagesse et la maturité nécessaire pour utiliser la puissance à bon escient.  »

En sus, il est important d’intégrer dans la management et la conduite de projet la dimension des différences générationnelles (Générations X, Y, Z).

Article à la base de cette publication

/par

La gestion de projet vue côté ressources

, ,

Parmi les modes d’organisation du management par projet en entreprise, nous rencontrons le plus souvent le mode « matricielle ».

Ce mode voit le chef de projet animer une équipe transversale, pour laquelle il ne dispose d’aucune capacité de management hiérarchique. Le chef de projet sera donc contraint de négocier les disponibilités des ressources sur son projet auprès des directions métiers, qui bien entendu, ne lâcheront pas facilement leurs précieuses capacités de « production ».

A noter qu’un schéma est une représentation simpliste du mode matriciel puisque que chaque chef de projet impacte des équipes différentes.

Or, dans la vraie vie des organisations, c’est bien souvent toujours les mêmes individus qui sont impliqués dans les projets, à cause de leurs compétences ou connaissances de leurs activités. Le chef de projet se retrouve rapidement en conflit d’intérêt avec les autres chefs de projets qui « visent » l’affectation des mêmes profils dans leurs projets.
Ainsi la fonction « chef de projet » devra impliquer des talents de négociation quasi permanents.
En effet, les projets qui respectent le planning initial font partie des mythes et légendes de la profession et chaque modification de planification en cours de projet nécessitera, selon les règles de l’art, un nouveau contrôle de disponibilité de chaque ressource.

Nous voyons ici que le job de chef de projet n’est pas de tout repos, mais ca…ca ne date pas d’hier et nous le savions déjà.

Dans ce contexte, intéressons-nous par contre à la perception du mode projet par les équipes.

Chaque personne impliquée dans les projets verra différents chefs de projet venir le rencontrer pour clarifier les tâches attendues.
Si le mode projet matriciel et la responsabilité du chef de projet ne sont pas clairement expliqués aux participants, cela peut être interprété comme une « multiplication des chefs » et entraîner pour les individus concernés une perte de repères dans le système hiérarchique de l’organisation.

Élargissons le périmètre et prenons en compte l’effectif global de l’organisation.
Apparaît alors deux ensembles de personnes : ceux qui sont impliqués dans les projets, et les autres.
Sachant que, bien souvent, ceux qui participent aux projets sont toujours les mêmes, du fait de leurs compétences ou connaissances particulières de leurs activités, cela veut dire qu’une partie de la population n’est jamais impliquée dans les phases d’étude et de conception des projets.
Les membres de ce groupe se sentent mis à l’écart, mal considérés, et doivent qui plus est, absorber les charges de travail supplémentaire induites par l’absence de leurs collègues, partis eux en réunion projet.
L’organisation peut alors rencontrer des phénomènes de fractures et/ou de démotivation d’équipes.

La solution ?

Selon les principes du Lean Management, la solution peut, dans certains cas, être établie sur un principe d’alternance des ressources à chaque nouveau projet pour permettre à chacun de pouvoir participer aux innovations de l’organisation.
Nous sommes ici dans un scénario dans lequel tous les membres potentiels disposent d’un niveau de compétence et d’expérience suffisant pour apporter une valeur ajoutée au projet.

L’autre alternative s’appuie sur un plan de communication auprès de l’ensemble de l’effectif de l’organisation pour officialiser les projets et leurs équipes associées.
En d’autres termes, il faut considérer les personnes de l’organisation non impliquées directement dans les projets comme acteurs indirects devant être informées (Rôle « I » d’une matrice de RACI  https://ankaa-pmo.com/matrice-de-raci-definir-les-roles-et-responsabilites-au-sein-dun-projet/).

Sur un plan managérial, il s’agit tout simplement de marquer de l’intérêt et valoriser cette part de population délaissée. (Se reporter à l’effet Rosenthal & Jacobson ou l’effet Hawthorne pour s’en convaincre)

/par