Articles

Machine à café

Une vision partagée de l’objectif

, , , ,

Prise en charge de projets à la machine à café

Le DSI d’une société est à la machine à café de l’entreprise. Le responsable logistique arrive à son tour.

Machine à café

Machine à café

Le responsable logistique : « Salut ! Ca tombe bien que tu sois là, il fallait que je te vois.

La direction logistique a décidé d’appliquer une stratégie de magasin interne à l’entrepôt sur son process de picking pour regrouper les produits a forte rotation et réduire les déplacements. Pour les commandes relatives à d’autres produits, ils veulent procéder à du picking en commandes groupées.

Est-ce possible de ton côté de faire le nécessaire au niveau informatique pour que ces changements soient faits au plus vite ? »

Le DSI : « Salut ! Passer à du picking en commande groupées ? Ca devrait pas être grand chose à faire puisque dans l’ERP les processus sont déjà organisés pour une gestion en picking. Cette semaine ca ne sera pas possible car on doit livrer un dossier pour les Finances, mais on devrait pouvoir s’en occuper la semaine prochaine. »

Le responsable logistique : « Super ! Je compte sur toi pour que cela soit opérationnel fin de semaine prochaine. »

Toute ressemblance avec des personnes ou situations …

Bien entendu, les personnages et les situations de ce récit étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite.  ;-)

Avec un peu de recul sur la scène, nous nous demandons ce que le DSI va bien pouvoir fournir comme livrable au responsable logistique dans deux semaines…

Les interrogations ou déductions que la scène soulèvent :

1) Le DSI doit probablement être un expert es-logistique puisqu’il n’a posé aucune question complémentaire à son interlocuteur.

2) Le DSI doit avoir une parfaite connaissance de la modélisation des processus Logistique dans l’ERP pour évaluer de manière mentale la complexité des modifications induites par la demande du service Logistique.

3) Le DSI doit suivre de près le projet Finances et est optimiste sur la Qualité de la réalisation car à l’en croire, dès le lendemain de la livraison au service Finances, l’équipe sera totalement disponible pour passer au sujet Logistique.

4) Le DSI doit avoir une visibilité très claire et précise du PMO IT puisqu’il est capable d’évaluer les charges et capacité de son équipe pour s’engager sur un planning de mise en oeuvre

5) Tout laisse penser que le DSI n’a entendu et pris en compte que la dernière partie de la demande, mais le responsable logistique lui fait confiance sur sa capacité à fournir une réponse sur tout le périmètre visiblement.

6) Le responsable logistique conclue, à partir de spéculations, que la livraison est annoncée pour la semaine prochaine.

7) Le DSI doit repartir de la machine à café fier et satisfait d’avoir démontré son professionnalisme avec des réponses spontanées et de bénéficier ainsi du respect et de la confiance du responsable logistique.

etc, etc

Avec un peu de recul sur la scène, celle-ci est-elle vraiment très éloignée de la réalité « terrain » des projets ?

Là ou l’intérêt des deux parties serait d’avoir une vision partagée de l’objectif pour en garantir l’atteinte, ces dernières se contentent d’une cible floue entourée de déductions implicites non validées.

L’absence d’une vision partagée de l’objectif est l’une des causes principales des difficultés rencontrées dans les projets puisque dès le départ, les moyens à associer à l’atteinte de l’objectif sont erronés.

De plus, avec une simple vue « de la partie émergée de l’iceberg », les chances de livrer un produit en adéquation avec le besoin sont donc très faibles.

Par contre les impacts de « service après-vente » eux sont colossaux puisque qu’il faudra bien finir par aligner le projet technique avec les attentes fonctionnelles… coûte que coûte, dans l’effort et l’urgence, en surcharge de tous les autres projets en cours.

Comment inverser ces habitudes et amener les deux parties à une vision partagée de l’objectif ?

Dans un processus normalisé, c’est au maître d’ouvrage de formaliser et rédiger son besoin au sein d’un cahier des charges.

Or cette étape essentielle de formalisation est trop souvent négligée et les cahiers des charges, lorsqu’ils existent, sont réduits à une ou quelques pages A4 rédigées sur un coin de table.

Ce document étant indispensable au services ETUDES et PMO de la DSI pour évaluer sereinement le périmètre du projet, définir les processus de réalisation, budgets, durées, impacts et risques pour garantir l’atteinte de l’objectif, nous recommandons que  la rédaction du cahier des charges soit fait par la DSI à partir de ce qu’elle a cru comprendre de l’expression du besoin par le Métier.

La fiche Projet

Les spécifications fonctionnelles sont alors formalisées au sein d’un document de référence : la fiche projet disponible en téléchargement.

Ce document est issu du framework méthodologique Ankaa Engineering et défini dans la phase « Initiative » pour le sujet « Scope »

Ce document, associé à la gestion de projet, est complété au fur et à mesure de l’avancement et contient l’ensemble des données (directes ou sous forme de liens) liées à la vie du projet. L’ensemble des acteurs du projet y ont accès.

Bien entendu, à l’étape d’expression du besoin, seul le chapitre OBJECTIF, PERIMETRE ET NATURE DU PROJET seront complétés par le chef de projet fonctionnel de la DSI et soumis à relecture auprès de l’émetteur de la demande Métier.

Après quelques aller-retours inévitables, l’émetteur confirmera que le besoin a parfaitement été entendu et compris et que les deux parties MOA et MOE ont enfin une vision partagée de l’objectif.

Le fait que la fiche projet intègre la formalisation d’une vision partagée de l’objectif va d’une part faciliter la recette du projet.

Enfin et surtout, la fiche va surtout protéger le chef de projet et son équipe des incontournables demandes d’ajouts ou adaptations en cours de réalisation, les fameuses intervention de la MOA « pendant que tu es dessus, cela serait bien d’ajouter… »,  dans lesquels le sous-entendu à entendre est « puisque cela ne nous coûte rien ».

Durant les phases de réalisation, grâce à la fiche projet, chaque demande hors scope initial formalisé, fait l’objet d’une analyse d’impact et demande une révision (selon les cas) des paramètres budget et délai du projet.

Le versionning du projet est dans tous les cas facilité.

Une fois l’objectif clarifié, 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.

Avec ce rapport d’étude en main, le demandeur n’aura plus qu’à aller négocier auprès de la direction générale ou financière les moyens  nécessaires à la réalisation de son projet métier…car effectivement, petit rappel s’il en est besoin, c’est bien dans le périmètre de la MOA de garantir le sponsoring des projets.

/par

Piloter un projet metier avec une communication efficiente

Ou la nécessité d’imposer un rythme et de donner du feed-back

Contexte

Pour un groupe français de l’aéronautique, leader mondial de son secteur, et pourtant… il a fallu récupérer un projet voué à l’échec ; projet dédié à la construction d’une plateforme pluridisciplinaire regroupant les métiers des Achats-Qualité-Technique-Performance Fournisseurs.

Le motif de cette situation… un problème de relations humaines, de communication et de cadrage de ce projet métier. Démarré il y a un (1) an, le projet bloquait depuis six (6) mois. Des tensions naissaient entre les équipes dans la vie de tous les jours. A l’origine, le projet avait révélé un réel engouement de la part des équipes pluridisciplinaires concernées. Le statu quo du projet minait donc l’ambiance générale de travail.

Actions

Une fois repris en main, c’est-à-dire :

  • des réunions d’avancement rythmées à la semaine ;
  • des actions clairement définies, attribuées à chacun et limitées dans le temps ;
  • une redescente régulière de l’information effectuée par le Chef de projet et sur les différents sujets du projet ;
  • un retour d’avancement régulier et communiqué plus largement, vers les équipes transverses notamment, afin de lever les freins puis de temporiser les esprits ;
  • une présence, un soutien, une disponibilité assurée par le Chef de projet envers l’équipe projet ;

… le projet fut remis sur les rails en un mois et demi (1,5) (4 COPRJ et quelques actions parallèles, entrecoupées d’autres activités liées la fonction initiale du Chef de projet).

Résultat

Le « GO » pour la mise en place (dixit la phase de Démarrage lors d’un projet SI) a été prononcé. Le Chef de projet a transmis le relais à la maîtrise d’œuvre, en maintenant une surveillance d’adéquation à ce que validé fonctionnellement et prototypé techniquement. Un (1) mois plus tard le plateau était construit et les équipes pluridisciplinaires installées.

Entre temps, les équipes transverses et les Interlocuteurs du projet avaient retrouvé le sourire. La motivation était revenue et l’ambiance de travail s’était améliorée.

Leadership

Leçon à retenir

  • Instaurer, au sein de l’équipe projet, un relationnel fondé sur l’écoute, l’équité, la transparence, la réactivité.
  • S’attacher à donner le même niveau d’information à tous, et surveiller que chacun de l’équipe projet se situe au même niveau d’information.
  • Donner de l’information et des feed-back jusqu’aux équipes transverses au projet. Ca a l’intérêt de rassurer et de rendre palpable le projet, et par conséquent de s’accompagner de « porteurs au projet ».
  • Autant que possible… Nommer à la tête de vos projets (projets métiers tout particulièrement, au vu des contextes inhérents) une personne à la communication efficiente, qui s’inscrit dans le partage et la conciliation, ouverte d’esprit, créative, adaptable, dégageant éthique et conviction voire de la passion… un Leader !

 

Sandrine
Consultante Ankaa Engineering®
Professionnelle de 20 ans en Management de la fonction Achat et en Conseil organisationnel et de transformation, Sandrine a travaillé au sein d’environnements multiculturels, aux côtés d’équipes pluridisciplinaires.
Elle a exercé aussi bien auprès de grands Groupes que de PME-PMI, lui permettant ainsi d’approcher des problématiques différentes, des modes de fonctionnement hétérogènes, des circuits de décisions variés, des priorités et enjeux originaux.
Le parcours à dominante industrielle de Sandrine, lui a donné la possibilité de développer certaines compétences dont quelques-unes la distinguent ; telles qu’une double compétence métier, une bonne capacité d’adaptation, un fort sens du résultat et du service, une grande pratique de méthodes et outils métiers.
Ses domaines de prédilection :

  • Strategies achats – Optimisation de processus – Organisation – Methode
  • Sourcing, negociation, contractualisation
  • Pilotage de projets et changements – Evaluation sous KPI
  • Perimetres internationaux, Gestion simultanee, Management transverse
/par

A quand une gestion de projet transversale en entreprise ?

, ,

Lors de nos prestations en entreprise, nous constatons très régulièrement le même schéma d’organisation :

  • Le bureau d’étude à mis en place intra-muros une organisation de stockage et de partage des données
  • Le service informatique utilise des logiciels divers et variés pour le suivi de leurs déploiements
  • Tel ou tel service à formalisé ses processus, bien souvent sous la contrainte d’ISO
  • Chaque service gère son activité dans l’indifférence des modèles d’organisation des voisins
  • Les métiers regardent l’initiative de méthodologie du service IT comme s’ils n’étaient pas concernés
  • Etc, etc.

Et chacun travaille en silot !

Silots et gestion de projet transversale

La faute à qui ?

  • Probablement à la productivité à fournir qui fait que chacun avance « la tête dans le guidon »
  • Probablement aux métiers qui ne considèrent que trop rarement les impacts de leurs changements sur le monde qui les entourent
  • Probablement à la direction générale qui se concentre sur la stratégie commune au détriment de l’organisation commune

Alors à quand une gestion de projet transversale en entreprise ?

Très certainement lors de la création d’un « Bureau de gestion de projets » (PMO) général à l’entreprise.
Initiatives très marginales aujourd’hui, et pourtant tellement salvatrices de dysfonctionnements.
Imaginez un bureau fédérateur et garant d’une méthodologie transversale, avec qui plus est une visibilité sur les charges supportées par toutes les équipes !
Attention ! Pas d’amalgame avec les fonctions actuelles d’un service Qualité…on ne parle pas des mêmes objectifs.

Avec l’arrivée de l’informatique dans les années 70, sous le prétexte que cela faisait « ringuard », les informaticiens ont « virés » les panneau muraux avec leurs fiches cartonnées qui faisaient qu’à l’époque chaque manager savait qui faisait quoi quand.
Mais en face, aucune solution efficace n’a été proposée.
De fait, avec la perte de visibilité sur les capacités des équipes, le règne de la surcharge est apparu.
Le manager, sans outils de mesure, a alors tendance à surcharger ses équipes afin de se rassurer sur le fait de n’avoir personne payé à ne rien faire !

Ce qui provoque des effets de bord dévastateurs dans l’organisation de l’équipe, du service, de l’organisation de l’entreprise.

Alors à quand un PMO chez vous ?

La mise en oeuvre d’un « Bureau de gestion de projets » (PMO) apporte une cohérence dans l’organisation.
Mais attention de ne pas vouloir être plus royaliste que le roi en espérant de son PMO une gestion de planning à l’heure et de l’ordonnancement de tâches !
Avec la mise en oeuvre d’un PMO, il faut considérer une démarche d’amélioration Qualité graduelle et progressive.
Dans l’entreprise, toute mise en oeuvre brutale ne s’inscrit pas dans la durée et l’accompagnement au changement prend toute son importance dans une mise en oeuvre à impact transversal.
On se doit de respecter la logique de DEMING…

/par

Pourquoi se tirer une balle dans le pied en faisant de la compression de planning ?

,

Combien de Project Manager travaillent sur le prévisionnel de leur projet en essayant de réduire au maximum le temps de réalisation ?

Mais fondamentalement :
– un bon PM se reconnait-il à ses capacités de présentation d’un prévisionnel record ?
– les constats opérés « dans la vraie vie » ne démontrent-ils pas un retard systématique des projets ?
– les retards n’engendrent-ils pas au final une dégradation de la qualité du livrable ?
– la non qualité d’un projet n’amène-t-elle pas une charge supplémentaire de « SAV » non budgétée /non planifiée ?

Alors pourquoi persister à vouloir compresser le planning prévisionnel ?

Par crainte d’une baisse de la sacro-sainte « productivité » ?

Et pourtant, quels sont les phénomènes constatés dans les projets trop comprimés ?
– sous couvert d’une méthodologie de gestion de projet, les plannings sont revus quasi-quotidiennement pour resynchroniser les ressources sur les dérives constatées
– communication inexistante, tout le monde à la « tête dans le guidon », ce qui amène à une désynchronisation des actions de l’équipe
– Plan d’Assurance Qualité réduit à « peau de chagrin », contrôles et tests « passés aux oubliettes »
– documentations, guides, compte rendus, documents de spécification passés « à la trappe »
– ressources qui « voient le mur arriver » et se démobilisent du projet
– ressources surchargées et donc qui arbitrent leurs travaux quotidiens en choisissant ce qu’elles « aiment faire » au détriment de ce qu’elles « devraient faire »
– tensions relationnelles, pertes de crédibilité, pression croissante
– délais de livraison non respectés, ou respectés au détriment de la qualité
– budgets « explosés »
– etc etc

Une grosse pagaille en fait !

Se tirer une balle dans le pied

Alors…
– pourquoi chercher la compression de planning maximale,
– pourquoi faire abstraction de l’indisponibilité des ressources,
– pourquoi être autant optimisme quant aux risques potentiels,

Un mixte de besoin de reconnaissance et d’incapacité « à dire non » justifie ce scénario.
« Le N+1 impose les délais, les budgets et exige une qualité maximale, on a pas le choix… »
Notre compétence professionnelle nous alerte bien sur le fait que c’est une mission impossible, vouée à l’échec dans le périmètre attendu, mais… on ne dit rien, on n’ose pas, on ne se permet pas.
Pire, afin d’obtenir du N+1 une reconnaissance de ses compétences, on va travailler sur l’organisation prévisionnelle du projet en respectant les contraintes imposées par son chef.
Ceci en minimisant les moyens matériels, en faisant abstraction des capacités réelles de ressources, et en réduisant la potentialité et l’impact des risques.

Dans tous les cas, « l’omission de réserves » vis-à-vis du N+1 amène à un transfert de responsabilité et le projet devient « notre bébé », notre « patate chaude ».

Compte tenu de ce qui a été évoqué précédemment, durant la réalisation, bien entendu le projet sera une catastrophe.
Alors que le PM cherche à obtenir reconnaissance et respect de sa compétence, il obtient l’effet inverse.
Nous serons évalués par notre N+1 sur notre incapacité à assumer nos engagements !

Pourquoi faire de la compression prévisionnelle et ne pas se donner les moyens de réussir ?

La VRAIE compétence d’un PM  n’est-elle pas
– d’opérer une gestion de risque efficace
– de communiquer, coordonner, reporter
– de respecter la Qualité, les budget et le délai annoncé
Bref, d’assurer dans les phases de réalisation du projet le respect du prévisionnel

Alors pourquoi se tirer une balle dans le pied en acceptant « sans réserves » les missions casse-cou ?
Pourquoi ne pas se donner les moyens d’améliorer ses chances d’obtenir la reconnaissance tant attendue en négociant des moyens cohérents ?

/par

Logiciels pour chef de projet

, ,
Référencement de solutions logicielles de planification, de tracking de bugs et de temps, de collaboration et de suivi de projet.
Diagramme de Gantt
Je sais… vous vous dites…y’a même pas d’évaluation fonctionnelle, ni de spécifications techniques d’environnement cible !
Nous comprenons largement votre déception mais…les évaluer toutes et établir des grilles comparatives se révélerait un travail de titan !
Alors pas de favoritisme, classement alphabétique établi à partir du nom d’usage du produit et lien vers le site éditeur pour tous !
A noter que si vous contribuez à nous adresser vos remarques, analyses, appréciations personnelles sur les produits que vous avez expérimentés, cela pourrait amorcer le travail et peut être nous donner l’envie d’avancer dans ce sens lors de longues soirées d’hiver… Merci à vous.
Liste mise à jour régulièrement.
Logiciels pour le chef de projet :
/par

Lean Office pour gagner en efficacité

,

La DSI d’un Grand Groupe industriel devait se réapproprier ses objectifs, renouveler ses compétences, revaloriser son image, récupérer une crédibilité et la confiance des métiers (les Clients internes et Fournisseurs externes).
Dans le cadre de cette démarche, je suis intervenue auprès de son équipe pour définir et mettre place une méthodologie en pilotage de projet et conduite du changement, puis en fournir les outils métiers.

Il s’agissait d’outiller les Chefs de projets de façon professionnelle (« best practice ») et complète.

J’ai mené une première phase d’observation de l’équipe de Chefs de projets, de ses modes de fonctionnement, de sa charge de travail, des périmètres de ses projets, du type de sujets traités par ses projets.

Ensuite, je me suis attachée à collecter et étudier l’éventuel existant, au vu de quelques échos reçus par certains Chefs de projets.
En effet, un grand Cabinet de la place avait fourni une base de 130 documents ; documents et guide diffusés en masse sur l’intranet de l’entreprise.
Ce référentiel non personnalisé, pensé sur une base « standard », sans accompagnement, n’a donc pas obtenu d’adhésion.
Contenant et contenu donnaient lieu à une certaine répulsion des équipes dans leur exploitation opérationnelle.

un régime administratif du framework méthodologique serait judicieux

Framework méthodologique

 

En troisième lieu, je me suis appuyée sur mes propres livrables, éprouvés par les pilotages de projets antérieurs. Cela représente une approche de type knowledge management.

Après une analyse réalisée sur ces trois phases, j’ai fait le choix de sélectionner certains de mes livrables en propre, car ils trouvaient leur place ainsi. Puis, j’ai amélioré d’autres documents de mon référentiel ou ceux issus de la livraison initiale du Cabinet.
L’ensemble fut adapté aux observations et attentes notées en première étape, puis mis à disposition accompagné d’un bref guide d’utilisation (1 slide). Les modèles de livrables ont été marqués de signalétiques ludiques, pour permettre une appropriation rapide et simple.

Le bénéfice tiré… les métiers ont pu exprimer leur besoin en systèmes d’informations corporate ou dédiés métier, d’une façon assez professionnelle pour permettre à la DSI de traiter correctement les demandes des Clients internes.
Les Chefs de projets ont rapidement pris possession des modèles pour les exploiter.

Lean Office et rendu assez pragmatique, qui a réduit le référentiel projet de 130 à 30 modèles de livrables.

L’optimisation de la démarche est apparue sous la forme de :

  • une préconisation d’axes d’améliorations, transmis à la DSI centrale sur les documents qu’elle détenait en termes de pilotage d’un projet et d’une conduite du changement.
  • un coaching des Chefs de projets, au comportement à adopter en cas de difficultés et dérives. Cette sensibilisation a fait l’objet d’un support sous la formalisation d’un guide, reprenant une approche Lean Office adaptée, et une liste de livrables structurée selon les étapes et phases d’un projet, suivie d’un Glossaire des signalétiques utilisées.

A retenir…

Dans le monde technique des « système d’information », il est recommandé de respecter les « standards » pour des raisons principalement de coûts et de maintenabilité.
Lorsqu’on aborde les processus et les modes de fonctionnement, il est nécessaire de répondre de façon personnalisée et pragmatique avec une touche de créativité.
Ainsi,

  • l’adhésion est plus facilement obtenue ;
  • il est plus aisé d’emmener tout le monde vers l’objectif ;
  • les gains sont réels ;
  • l’existant est optimisé.

Pour ce faire, le diagnostic « terrain » (en rappel au « Gemba » – méthode TPS) et préalable couvre une étape importante.

Copier-coller l’intégralité d’un framework méthodologique n’est pas gage d’efficacité.
Ecoute, adaptation et personnalisation : les composants d’une mission de conseil réussie…

 

Sandrine
Consultante Ankaa Engineering®
Professionnelle de 20 ans en Management de la fonction Achat et en Conseil organisationnel et de transformation, Sandrine a travaillé au sein d’environnements multiculturels, aux côtés d’équipes pluridisciplinaires.
Elle a exercé aussi bien auprès de grands Groupes que de PME-PMI, lui permettant ainsi d’approcher des problématiques différentes, des modes de fonctionnement hétérogènes, des circuits de décisions variés, des priorités et enjeux originaux.
Le parcours à dominante industrielle de Sandrine, lui a donné la possibilité de développer certaines compétences dont quelques-unes la distinguent ; telles qu’une double compétence métier, une bonne capacité d’adaptation, un fort sens du résultat et du service, une grande pratique de méthodes et outils métiers.
Ses domaines de prédilection :

  • Strategies achats – Optimisation de processus – Organisation – Methode
  • Sourcing, negociation, contractualisation
  • Pilotage de projets et changements – Evaluation sous KPI
  • Perimetres internationaux, Gestion simultanee, Management transverse
/par

Projets en retard = mauvaises évaluations de charge ?

, ,

Et si les mauvaises évaluations de charge n’étaient pas la seule cause des projets en retard ???

Pour qui veut apprendre comment évaluer des charges d’un projet, les supports ne manquent pas : Méthodes des points de fonctions, COCOMO, RAD, DELPHI, STIMA, ARAMIS, ESI, PRT, etc…

On se retrouve dans certains cas rapidement confronté à des méthodes conçues par des mathématiciens en mal de reconnaissance…LOL

Il existe bien sûr des quotas moyens qui ressortent à l’usage, et  pour certains référentiels, la répartition des charges entre les étapes d’un projet se présente selon :

Etude de faisabilité : 15%
Etude détaillée : 25%
Conception : 45%
Mise en production : 15%

Ces rapports peuvent varier selon les projets bien sûr.
Certains projets seront plus consommateurs de temps d’étude et moins en réalisation par exemple.
La matrice n’est donc pas aussi simple.

Charge, durée, délai ?

La notion de charge est la quantité de travail à produire et elle se traduit en nombre de jours/homme dans le contexte de projet d’ingénierie.
Le nombre de ressources affectées à produire le travail attendu influera (ou pas) sur le temps de réalisation et fournira la notion de durée.
Quant au délai, il correspond lui à la date de fin de réalisation (ou de livraison) et est directement dépendant des disponibilités des ressources pour accomplir le travail attendu.

75% des projets dépassent le délai de 30%.

Et très souvent, trop souvent, la cause annoncée de ce retard est une mauvaise estimation des charges.

Après 28 années de recul en gestion de projet de tout type et toute taille, le constat que j’ai opéré est que les projets en retard le sont bien souvent pour une autre raison qu’une mauvaise évaluation de charge.

En effet, un temps certain est passé sur l’évaluation des charges par les équipes, les chefs de projet, la maîtrise d’ouvrage.
Les charges sont même très souvent à l’origine de négociations et de discussions.
Bref les charges retiennent toute l’attention qu’elles méritent.

Mais quid de la capacité des ressources ???

Là, je ne sais pas pourquoi, même dans les projets avec des équipes non dédiées, le raccourci d’une affectation de ressources à temps plein est très très très souvent pris.
Or dans la vraie vie, les membres d’une équipe sont très rarement mobilisés 100% de leur temps sur le projet.
Plein de tâches parasites viennent grignoter leur capacité d’affectation (autres projets, autres projets en retard, maintenance, support, études, vacances, etc).
Leur capacité d’affectation est inférieure à du temps plein, voir largement inférieure.

Petit rappel de calcul simple :
1 jour de charge attribué à une ressource affectée à 100% de son temps demandera 1 jour de durée pour être réalisé.
1 jour de charge attribué à une ressource affectée à 50% demandera 2 jours de durée
1 jour de charge attribué à une ressource affectée à 25% demandera… 4 jours de durée

L’impact de la disponibilité des ressources n’est pas neutre puisque les coefficients sont significatifs.
Un projet réalisé avec des ressources d’une disponibilité réelle de 25% mettra 4 fois de temps à être réalisé que ce qui a été imaginé sur la base d’une affectation temps plein !

Alors une charge de travail parfaitement estimée à l’aide de toute les méthodes scientifiques du monde ne garantira pas la maîtrise du délai (et donc des coûts associés) si l’on ne met pas en face des capacités très clairement évaluées elles aussi.

C’est juste une histoire de contenant et de contenu.

Le problème est :
– qu’avec l’arrivée de l’informatique, les panneaux muraux et les fiches cartonnées des chefs d’équipe d’antan ont disparus.
– que les PMO (bureaux de planification des travaux) sont plutôt rarissimes dans les organisations.
– que compte tenu des deux points précédents, personne ne sait plus qui fait quoi quand et que de fait la surcharge règne (le règne des surbookés ?).

La solution :
– évaluer au cas par cas des projets les capacités des équipes/ressources impactées pour mesurer le coefficient de disponibilité et identifier de manière réaliste les délais jouables.
– réinstaurer les fonctions de PMO au sein des équipes.
– responsabiliser les équipes sur leur propre gestion de disponibilité et donc les autoriser à négocier/refuser des missions et travaux lorsque ceux-ci sont en conflit avec leur capacité…Oups !

Oups ! car dans ce cas, on met les pieds dans le plat d’un changement culturel d’entreprise ou le système hiérarchique historique risque d’être bousculé avec tous les problèmes d’ego que cela peut induire pour l’équipe d’encadrement de l’organisation .

Management transverse…A grands maux, grands remèdes ?

/par

10 rappels pour une conduite de changement efficace

, ,

Petit mémento pour chef de projet stressé ou 10 rappels pour une conduite de changement efficace.

Clarification et partage d’objectif

Une règle d’or à appliquer, y compris si l’on a défini de travailler avec agilité, est la clarification et le partage de l’objectif.
Pour que tous les acteurs du projet rament dans le même sens en direction du coeur de la cible définie, il est impératif d’avoir identifié le résultat recherché et de l’avoir présenté et partagé au sein de l’équipe projet.
Tout changement de cap devra déclencher une nouvelle coordination des acteurs sur la cible, le processus et le délai.

Identifier la roadmap

Il est impératif que le processus choisi pour aller du point A au point B soit clairement choisi et officialisé auprès des acteurs.
La roadmap du projet a posé les règles de pré-requis entre les tâches et a donc positionné dans l’espace temps des enchaînements de travaux.
Tout ne se fait pas en même temps, les réalisations nécessitent le respect d’une « recette de cuisine » où chaque action a sa justification pour la suite des opérations.

Acteurs directs et indirects

Qui fait quoi quand.
Pour chaque travail à réaliser il est nécessaire d’identifier quelle personne ou équipe dispose de la meilleure compétence pour garantir une réalisation conforme aux exigences de qualité, de maîtrise des délais et de coûts.
Cet inventaire permettra de définir la cartographie des acteurs directs du projet.
En management de projets transverses, l’affectation des acteurs directs amène à des négociations de disponibilité de ressources puisque ces dernières ne sont pas dédiées au projet.
Au delà des acteurs directs, chaque entité concernée ou impactée doit être identifiée (clients externes, autres services, etc).
Le plan de communication sera défini selon la cartographie obtenue des acteurs.
Pour mener cette réflexion de qui fait quoi, une matrice de RACI peut être utilisée.

Impliquer la maîtrise d’ouvrage dans le projet

Le donneur d’ordre (MOA) doit être impliqué à plusieurs niveaux dans la réalisation.
– En amont, dès la clarification d’objectif à atteindre, car la MOA est la seule à pouvoir définir et choisir le cœur de cible (fonctionnalités, design, etc).
– Pendant, afin de participer aux COPIL pour suivre l’avancement et valider des changements de roadmap.
– Pendant encore en déléguant les capacités d’acteurs directs sur les phases de tests, de formation, de recette, …
– En aval, pour ajuster et optimiser les processus métiers au changement

La MOA est bien souvent le sponsor financier du projet et doit être décideur dans les options fonctionnelles, techniques ou de gestion des risques.
Chaque investissement, chaque affectation de ressource, qu’elles soient externes ou internes augmente le coût d’acquisition et dégrade le ROI du projet.

Mettre en place les comités, le reporting et communiquer

Choisir et officialiser les membres du comité de pilotage (COPIL), définir la fréquence de réunion de cette instance de décision auprès de laquelle sera présenté de manière synthétique .
Clarifier auprès des membres la possibilité d’ajout de réunions extraordinaires et spontanées en cas de situation de crise.
Définir la fréquence et le contenu du reporting pour que les informations de la réalisation effective sur le « terrain » viennent se confronter à celles du prévisionnel.
Organiser la fréquence et les modalités des réunions de suivi de projet (COPROJ).
Mails, téléphone, conf-call skype ou Google Hangout mais aussi et surtout réunion en face à face pour évaluer à se juste mesure « la communication non verbale » des acteurs.

Communiquer, coordonner, synchroniser

Informer, communiquer doit être le travail essentiel du chef de projet.
Les acteurs directs doivent eux se concentrer sur la qualité des travaux à mener dans le respect des délais et du budget.
La coordination est l’affaire du chef de projet qui doit animer les COPROJ, assurer la synchronisation des acteurs entre eux, reporter au COPIL et communiquer vers les acteurs indirects selon le plan de communication identifié.

Adaptations, agilité et versioning

Un projet se doit d’être agile et ce pour deux raisons.
1- Le projet dans sa vraie vie ne se déroulera jamais comme prévu.
Les capacités de réadaptation sont donc essentielles pour ajuster l’organisation aux aléas rencontrés.
2- La MOA explicitera bien entendu en cours de projet des besoins impératifs, essentiels, importants, critiques, … d’ajouts non prévus.
L’art de gérer ce type de situation se résume à faire définir la version de rattachement des « add-on » demandés (version en cours ou report au sein de la version suivante).
Ne pas oublier que chaque travail supplémentaire ajouté au périmètre initial du projet a une influence sur la date de fin et le budget.
Accepter des « add-on » au sein de la version en cours sans réviser le périmètre initial du projet augmente le risque de ne pas respecter les engagements de qualité, maîtrise du budget et de respect du délai.

Communication positive

Penser à communiquer sur l’avancement du projet au sein de l’équipe.
Chaque acteur direct a bien souvent « la tête dans le guidon » et ne voit et ne vit QUE les problèmes du projet.
Insuffler une énergie positive en officialisant des passages de jalons importants comme des fin de phase ou d’étape permet à tous de prendre conscience que le projet avance malgré tout.

Accompagner au changement

La livraison d’une solution au client devra être accompagnée d’un plan d’accompagnement au changement.
Simple « flyer » ou dispositif pédagogique complexe et lourd, l’accompagnement au changement n’est pas une option dans un projet.
La réussite d’un projet ne s’appuie pas uniquement sur la maîtrise des processus de conception mais aussi et surtout sur la capacité d’adaptation et d’adhésion des clients par rapport au produit.

Clôturer le projet

Comment gérer efficacement le versioning des évolutions sans effectuer une clôture de projet ?
Cette étape d’évaluation et de mesure des écarts entre le prévu et le réalisé est trop souvent oubliée.
De fait, la version 1.0 du projet perdure dans le temps et le sentiment d’échec lamine peu à peu les équipes.
Tous les acteurs directs ont le sentiment que les clients n’ont pas été satisfaits puisque des demandes de nouvelles évolutions sont incessantes.
Se rappeler alors ce qui composait le périmètre initial de la version 1.0 en terme fonctionnel est primordial car cela va permettre de vérifier si ces besoins ont bien été couverts.
Que les clients demandent de nouvelles adaptations et fonctionnalités est plutôt un signe positif.
Cela sous-entend qu’ils ont assimilé et digéré le fonctionnement de la version 1.0 et en demandent plus.

Fil rouge

Ces 10 points ne sont pas exhaustifs bien sûr.
Ils ne sont que des jalons importants dans la mise en oeuvre d’une conduite du changement.
Mais paradoxalement, tout ou partie de ces éléments sont souvent oubliés par les directions de projet.
Alors, un petit rappel du fil rouge de temps à autre ne fait pas de mal…

 

 

 

/par

Agile manifesto, Boehm, EVO, Deming : l’œuf ou la poule ?

, ,

Agile manifesto, Boehm, EVO, Deming

Ils ont en commun de s’appuyer sur des concepts de gestion de projet itératif, incrémental et adaptative.
Mais quid de l’oeuf ou la poule ?

Apparu en 2001, Agile manifesto a démocratisé la terminologie « Agile » en regroupant au sein d’un même référentiel diverses méthodes itératives de développement de produit.
Historiquement les méthodes RAD, DSDM, XP Extreme programming et Scrum sont les principales représentation de ces méthode et poussent des principes de planification pilotée par les résultats des tests utilisateurs ou l’auto-organisation des équipes et l’apprentissage de groupe.

Avant cela ?

Barry Boehm en 1986 a formalisé une approche itérative des tâches selon un processus en spirale.

Agile manifesto, Boehm, EVO, Deming : La spirale de Boehm

4 étapes dans l’approche itératives

1. Définition de l’objectif à atteindre
2. Évaluation des risques
3. Conception et tests
4. Mesure des écarts entre le livrable et l’objectif

Retour à 1. pour l’objectif suivant…

Avant cela ?

En 1976, Evo (Evolutionary Project Management), aborde la mise en place d’un processus organisationnel dynamique pour permettre la prise en compte des changements et nouvelles idées aussi souvent qu’on le souhaite au sein d’un projet.
Cette approche étant stimulée pour générer le maximum de valeur ajoutée auprès des acteurs.

Avant cela ?

Le statisticien William Edwards Deming  à popularisé dans les années 1950 un outil développé par Walter A. Shewhart.

La symbolique est une roue qui tourne selon un cycle PDCA (Plan-Do-Check-Act).

Roue de Deming

 

 

 

Cet outil d’amélioration continue a été intégré au sein de la méthode de gestion de la Qualité Kaisen.

On est la aussi dans une logique d’itération.

Avant cela ?

Rien de clairement identifié…

Donc

Agile manifesto, Boehm, EVO, Deming, même principes fondamentaux…

Au final, Deming n’a-t-il pas initié un mouvement sans cesse renouvelé et amélioré ?
Et la roue n’a pas finie de tourner…

/par

Développer ses compétences en gestion de projet

,

La gestion de projet n’est pas innée, elle s’apprend.

Quel que soit notre métier et statut au sein de l’entreprise, nous faisons tous de la gestion de projet au quotidien, parfois sans le savoir.
Certes, face à des retours d’expérience terrain parfois difficiles où simplement parce que la fiche de poste stipule ce savoir-faire, certains bénéficierons de formations dédiées sur cette compétence.

Mais dans tous les cas, il reste des fondamentaux à ne pas oublier :

– L’élément le plus important dans le projet est… le client, le donneur d’ordre, le maître d’ouvrage.
C’est LA personne à satisfaire alors même qu’il ne sait pas toujours ce qu’il veut.

– Tentez autant que faire se peut de clarifier l’objectif avant le lancement du projet.
Plus la cible est visible, plus il sera facile d’atteindre le cœur.
Le recours à de l’agilité dans projets ne doit pas faire oublier l’objectif final recherché.
L’agilité doit prendre sa place dans l’organisation des travaux de conception et non dans la définition d’objectif.

– Aider le client à clarifier son besoin en échangeant avec lui grâce à un vocabulaire simple et compréhensif.
L’usage d’un vocabulaire élaboré, spécifique ou trop technique ne fournit pas de garantie à votre client que vous que vous compreniez vous même vos propos…La culture, c’est comme la confiture…

– Soyez persuasif car le client n’a pas toujours raison.
Les choix doivent être portés par le ROI et les résultats attendus.
Vouloir en faire trop nuit à l’objectif principal.
L’important dans le projet est l’atteinte de l’objectif et non la complexité de ce dernier.
Le mieux est parfois l’ennemi du bien…

– Modélisez l’enchaînement des travaux pour partager le « fil rouge » avec l’équipe.
Par quoi on commence, par quoi on finit, et comment on s’organise entre les deux.
Élaborez un modèle de plan projet détaillé pour anticiper les problématiques organisationnelles des travaux à mener et assurer une gestion de risque cohérente.
– Estimez les charges des travaux mais pensez surtout à évaluez les capacités réelles des ressources sur le projet.
Diffusez l’organisation du « qui fait quoi quand », les ressources s’auto-organisent rarement correctement…

Définissez une date de livraison cohérente au regard des capacités réelles des ressources.
Un projet débuté en retard restera en retard (rappel : l’étude fait partie intégrante d’un projet…).
Et lui positionner une date de livraison utopiste ne réglera pas le problème initial.

Impliquez le client dans l’atteinte de l’objectif.
Le client est un acteur important et il mérite d’être impliqué dans l’organisation des travaux et l’atteinte de l’objectif.
Il est incontournable en phase de tests, de recette.
L’impliquer lui rappelle combien il est parfois difficile de faire plusieurs choses en même temps (notamment pour les hommes! LOL).

Ne négligez pas l’accompagnement au changement, élément fondamental de la gestion de risque.
50% de réussite dans les projets sont liés à l’organisation de la réalisation du produit.
50% sont dépendants de l’accueil du produit par le consommateur.
Communication, formation ne sont pas des tâches optionnelles et doivent avoir leur place au même titre que celles de l’ingénierie de conception au sein du projet.

– Mettez en place une organisation de reporting efficace.
Sans reporting un projet va dans le mur.
Plutôt qu’imaginer le reporting sous forme de compte rendus circonstancier, focalisez vous sur la donnée fondamentale qui est « le reste à faire ».
C’est la seule donnée sur laquelle peut être appliqué de l’influence et des modifications pour corriger les écarts constatés.
Le passé est le passé. On ne peut (malheureusement) pas revenir en arrière.

Mais l’élément fondamental de la gestion de projet reste la capacité de réadaptation de l’organisation « au fil de l’eau ».
Car aucun projet ne se déroule tel qu’il a été prévu et organisé.
D’ailleurs, la roue de Deming expliquait le processus bien avant que les méthodes agiles apparaissent.
Pour pouvoir réadapter un processus pour maintenir l’atteinte de l’objectif initial sans dégradation des ambitions et contraintes, il faut disposer de capacité de pouvoir le faire.
Un plan projet initial trop « optimisé » ne fournira pas de solutions, et selon la loi de Brook, la solution n’est pas d’ajouter des ressources…
La solution passe par la présence de « jokers » dans le plan projet qui sont les garants de l’atteinte qualitative du produit, la maîtrise budgétaire projet et le délai de livraison.

La vrai valeur du chef de projet se mesure à sa capacité de gestion de crise.
Élaborer un « joli » prévisionnel s’apparente à définir les plans de la construction.
On est dans le domaine du conceptuel et cela reste « sur le papier ».
Et pas toujours facile pour autant…
Mais faire en sorte que la construction ressemble aux plans…c’est le vrai défi du chef de projet !

/par