Articles

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.

Témoignage recueilli à l’issue d’une mission de conseil en « GOUVERNANCE IT ET TABLEAUX DE BORD » menée auprès de la DSI de l’entreprise NORSKE SKOG GOLBEY :

« Ce que j’ai véritablement apprécié durant la prestation réalisée sont le retour d’expérience et la capacité du consultant à mettre en relation la théorie de la gouvernance IT avec la vie courante d’une DSI, y compris pour des petites structures.
Cela a le grand mérite de valider des plans d’actions de mise en oeuvre opérationnelle « réalistes » et grâce à des échanges très constructifs d’aligner le pilotage de ma gouvernance IT avec la stratégie de ma société.
Je mettrais particulièrement en avant les capacités d’écoute et d’analyse du consultant, saupoudrées d’un humour distillé avec subtilité. »

Eric POIROT
Responsable informatique
NORSKE SKOG
P.O.Box 109,
Route Jean-Charles Pellerin,
F-88194 Golbey CEDEX, France
Tel.: + 33 (0)3 29 68 68 68
Logo NORSKE SKOG

Située près d’Epinal dans les Vosges, la papeterie Norske Skog Golbey est la filiale du groupe papetier norvégien Norske Skogindustrier ASA, leader mondial de l’industrie des papiers de publication.
Démarrée en 1992, l’usine emploie aujourd’hui 440 collaborateurs, génère 300 millions d’euros de CA et produit chaque année 600 000 tonnes de papier journal standard et amélioré destiné aux principaux éditeurs et imprimeurs européens.

Témoignage recueilli auprès de la DSI de la société BODYCOTE-TECHMETA :

« Ankaa Engineering intervient depuis plusieurs années sur différentes problématiques liées à notre infrastructure informatique et nos mutations applicatives Le pragmatisme des conseils et la qualité des consultants délégués lors de chaque mission se traduisent par un excellent niveau de service. La relation établie avec Ankaa Engineering est celle d’un véritable partenariat »

Nathalie HOENY
Responsable informatique (DSI)

BODYCOTE TECHMETA
141 Route des Machurettes
74 METZ-TESSY

Logo TECHMETA

TECHMETA a été créée en 1964 et a participé durant 40 années au développement international de la technologie du FAISCEAU D’ELECTRONS selon 2 axes principaux :- la pratique à une échelle industrielle du soudage à façon par FAISCEAU d’ELECTRONS avec un parc intégré et diversifié de plus de 20 MACHINES à SOUDER par FAISCEAU d’ELECTRONS en exploitation au service de sa clientèle. – La conception et la production d’une gamme étendue d’équipements à faisceau d’électrons. Equipements standards et selon spécifications clients. Depuis 1985, elle a été choisie comme partenaire des plus grands projets nationaux et internationaux intégrant la technologie du faisceau d’électrons : Soudage des sous-marins nucléaires pour la Marine Nationale Française, grands développements du C.E.A., soudage des boosters de la fusée européenne ARIANE V, soudage en continu du supra-conducteur pour le projet international CERN/CMS pour lequel TECHMETA a reçu les  » golden  » et  » cristal  » awards 2003. Depuis 1990, elle a développé, en collaboration avec un laboratoire universitaire, une technologie spécifiques de couches minces déposées sous vide : en particulier les résistances électriques pelliculaires Ni-Cr et des produits de chauffage issus de cette technologie. Elle compte plus de 70 spécialistes internationalement reconnus et intervenant dans le monde entier.En février 2007, Techmeta rejoint Bodycote, leader mondial des procédés thermiques, aujourd’hui présent dans plus de 30 pays, sur près de 300 sites. L’entreprise, devenue Bodycote Techmeta, conserve et développe toutes ses activités, d’équipementier et prestataire de service dans le domaine du soudage par faisceau d’électrons.

La gouvernance d’un SI s’appuie sur la mise en place d’indicateurs de mesure et de suivi.

Le framework méthodologique développé par Ankaa Engineering® organise ces différents compteurs en 4 grandes familles :
Exploitation
– Temps d’arrêt des systèmes
– Charge LAN et WAN
– Indisponibilité applicative
– Temps de réponse
– Audit sécurité (Mises à jour anti-virus, patches, réinitialisation de mots de passe, etc)
Support
– Nombre d’appel total utilisateur
– Nombre de tickets (ouverts, en cours, fermés)
– Nombre moyen d’incidents par utilisateur (ou service)
– Durée moyenne de traitement d’un ticket
– Délai moyen de résolution d’un ticket
Projet
– Audit de conformité de la solution avec les attentes exprimées.
– Nombre de jours de correctifs post-livraison
– Ecarts entre le nombre de jours de tests prévus et celui réalisé
– Ecarts entre la documentation réalisée et celle prévue
– Ecarts entre le délai de livraison réalisé et celui prévu
– Ecarts entre le budget réalisé et le prévisionnel
– Tableau de capacité d’affectation réelle des ressources sur les projets
Finance
– Part du budget DSI / Budget global
– Part de l’effectif DSI / Effectif global
– Budget annuel d’acquisition de logiciel
– Budget annuel d’acquisition de matériel
– Budget annuel d’achats de services
– Budget de maintenance applicative, matériel
– Valeur annuelle du SI / utilisateur
– Cout de maintenance du SI / utilisateur

Compte tenu des moyens à mettre en oeuvre pour faire vivre ces compteurs, le but n’est pas d’avoir un tableau de bord exhaustif mais ne faire le choix des indicateurs les plus pertinents en fonction des besoins de suivi et/ou de l’organisation de la DSI.