Articles

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

Vendre sa gestion des risques

, , , , , ,

Dans le domaine de la gestion de projet, la gestion des risques fait partie intégrante de la responsabilité du chef de projet.

En effet, il est de la responsabilité du chef de projet de veiller à ce que les risques potentiels ne se transforment pas en incidents durant les phases de conception ou d’implémentation.
Aussi le chef de projet veillera, dès les phases d’étude de faisabilité et d’étude préalable à mettre en place une gestion de risque organisée et documentée au sein de l’équipe.

Chaque risque identifié durant ces phases préparatoires du projet sera alors recensé, puis évalué individuellement.

En la matière il existe le référentiel AMDEC.
Selon les principes AMDEC, chaque risque est évalué sur les axes « Fréquence ou probabilité d’apparition », « Gravité », « Probabilité de non-détection ».

Face à la difficulté d’évaluation du paramètre « Probabilité de non-détection », pas toujours très évident à quantifier dans les scénarios des projets, nous avons au sein du framework méthodologique Ankaa Engineering simplifié l’approche AMDEC pour ne retenir que les deux premières dimensions.

Chaque risque est alors ventilé dans une matrice à deux dimension :

  • Potentialité d’occurrence établie selon
    nulle = jamais
    faible = deux fois par an
    possible = une fois par mois
    élevée = une fois par semaine
    Très forte = une fois par jour
  •  Impact de l’incident en cas de sinistre
    faible = affecte un individu
    moyen = affecte un service
    important = affecte une unité
    critique = affecte l’organisation

Les niveaux de rapports indiqués ci-dessus servent de référentiels « de base » et peuvent être ajustés en fonction des règles de jugement et d’évaluation au sein de chaque organisation (ajout de niveau de potentialité et d’impact pour gagner en précision si besoin).

Grille aversion aux risques du framework méthodologique Ankaa Engineering

Chaque risque sera alors positionné dans la matrice dans la cellule répondant à la double analyse « potentialité » et « impact ».
Le chef de projet décidera alors de « prendre les risques » pour ceux pour lesquels la matrice annonce un niveau « Nul », « Faible », « Tolérable ».
Bien souvent, les risques « Tolérables » seront d’ailleurs anticipés et gérés grâce au simple fait de les avoir identifiés.

Par contre le chef de projet aura la responsabilité de présenter à la MOA l’inventaire des risques évalués « Insupportables » ou « Inadmissibles » puisque ceux-ci impactent très fortement le périmètre du projet et peuvent être un critère de choix de « NO-GO » au final.
Lors de cette présentation, le chef de projet devra bien entendu apporter à la MOA les alternatives organisationnelles et/ou techniques au sein du projet permettant de contourner ces risques.

Bien souvent les solutions de contournement des risques engendreront des besoins en matière de budget (ressources supplémentaires, équipements de sécurité ou de backup, etc).

Et dans ce contexte, la MOA soucieuse de préserver un périmètre budgétaire raisonnable de son projet évaluera chaque moyen de contournement bien entendu comme onéreux à sur-dimensionné.
La réponse de fin de non-recevoir de la MOA au chef de projet prendra alors des tournures de « tu verras, ça va bien se passer » ou « nous avons toute confiance dans les capacités professionnelles de l’équipe »…

Alors ? Comment vendre sa gestion de risque ?

Comment faire souscrire l’achat d’assurance à la MOA soucieuse de maîtriser les budgets de son investissement ?

Et bien en lui valorisant les risques… en lui donnant le coût des incidents si ces derniers se produisent.
Dans la matrice ci-dessus, chaque entrée du tableau est valorisé
Potentialité
nulle = jamais, soit 0
faible = deux fois par an, soit 2
possible = une fois par mois, soit 12
élevée = une fois par semaine, soit 52
Très forte = une fois par jour, soit 365

Impact
faible = affecte un individu, coût journalier d’un ETP dans l’organisation,
moyen = affecte un service, coût journalier d’un ETP x nb d’ETP du service.
important = affecte une unité, coût journalier d’un ETP x nb d’ETP de l’unité
critique = affecte l’organisation, coût journalier d’un ETP x nb d’ETP de l’organisation, plus les pertes d’exploitation, l’impact commercial, etc

Il va sans dire que la multiplication des deux paramètres va amener à des montants colossaux pour les risques évalués inadmissibles.
En même temps, dans la vraie vie, peu de risques seront positionnés dans ces cellules.
En effet, les organisations soumises à des potentiels de risques importants avec des impacts critiques ne durent pas longtemps…voir ne voient jamais le jour.

L’essentiel des discussions tournera donc autour des risques évalués insupportables.
Et c’est la valorisation des risques qui permettra à la MOA de relativiser les budgets de contournements et autres « assurances ».
L’investissement supplémentaire de gestion de risque apparaîtra alors dérisoire face aux coûts potentiels des incidents.

Au delà de l’exercice de valorisation de risque, il est de la responsabilité du chef de projet d’avoir inventorié les risques encourus et d’avoir proposé les solutions de gestion adaptées.
Et c’est de la responsabilité de la MOA de souscrire aux « assurances » proposées.

/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

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

Norme ISO 27001, pour qui et pour quoi?

, , , ,

Les certifications ISO 9001 et ISO 14001 ont démontrées les avantages concurrentiels qu’elles procurent aux entreprises.

Alors que l’interconnexion croissante des systèmes soumet les organisations à de nombreuses menaces (virus, d’espionnage industriel, ou de sabotages), les services informatiques se doivent aujourd’hui de manager et piloter au quotidien la sécurité de l’information et protéger ainsi le patrimoine informationnel, les processus et métiers critiques, et assurer la continuité de service.


Intégrité-Confidentialité-Disponibilité
C’est là que se pose la question d’une certification ISO 27001, qui atteste de la mise en place d’un système efficace de protection, de sécurité et d’une surveillance rigoureuse de tous les processus via ce certificat reconnu internationalement et qui s’imbrique parfaitement aux normes qualités existantes.

Faire appel à un consultant certifié 

Savez-vous qu’à ce jour seule une dizaine d’entreprises sont certifiées en France, contrairement à des pays comme l’Inde ou le Japon ?

Pour être certifié, un organisme doit faire appel à l’un des deux certificateur accrédité en France, lequel va mandater un auditeur, appelé « Lead Auditor », lui même habilité à remettre après Audit le sésame… ou pas.

La certification Lead Auditor ISO/CEI 27001 permet d’attester qu’un  consultant a acquis l’expérience et les capacités à mener un audit selon la norme ISO/CEI 27001 ainsi que le maintien de son savoir-faire par la réalisation d’audits réguliers.

Elle passe par la maitrise de deux normes, la 27001 bien sûr, mais aussi la norme19011 qui défini les lignes directrices pour l’audit des systèmes de management, l’ensemble sanctionné par un examen.

En tant que Consultante certifiée Lead Auditor j’accompagne les DSI et/ou RSSI dans l’analyses périmètres et applique dans tous les cas la démarche de certification, qu’elle soit visée ou non.

Pour l’entreprise c’est un avantage méthodologique et un gain de temps potentiel important.

L’essentiel de cet accompagnement consiste à piloter, analyser et traiter les risques, contrôler, sensibiliser et enfin gérer la documentation et les preuves. Cela implique une bonne connaissance des enjeux business, l’intégration des processus métiers dans une démarche d’amélioration continue, de comprendre les risques et concentrer les actions selon leurs impacts.

Facteurs de réussite

A mon sens, la réussite de ce type de projet repose en premier lieu sur une bonne compréhension des enjeux et des processus métiers afin hiérarchiser efficacement les risques.
Il est également primordial et nécessaire de s’assurer tout au long de l’étude de l’implication sans faille de la direction et de posséder un bon sens de la communication pour conserver l’enthousiasme de tous les métiers à faire progresser l’organisation et son système d’information.

 

Muriel MOENZA

Muriel MOENZA
Directrice régionale
Ankaa Engineering® PACA
Lead Auditor ISO 27001

 

 

/Ajout du Service communication Ankaa Engineering®/
Muriel est par ailleurs diplômée :
– Exécutive MBA en Management de la Sécurité de l’Information IAE Aix en Provence et HEG de Genève
– Maîtrise en Sciences et Techniques en Communication des Entreprises et Collectivités
– Certification Lead Auditor Iso 27001
– Diplôme de l’Institut des Hautes Etudes de Défense Nationale et accréditation « confidentiel défense »

/par

Matrice de RACI : définir les rôles et responsabilités au sein d’un projet

,

Rien de tel qu’une matrice de RACI pour affecter les rôles et responsabilités selon les phases ou étapes d’un projet.
Cette matrice se présente sous forme d’un tableau avec en ligne les phases, étapes ou tâches (selon la granularité de l’étude) et en colonne les acteurs directs et indirects du projet.
Selon RACI, 4 rôles peuvent être affectés aux acteurs :
– R : Ressource qui exécute la tâche
– A : Responsables de la réalisation
– C : Consultés pour avis (utilisateurs, maître d’ouvrage)
– I : Destinataires du reporting

Matrice de RACI

A la matrice initiale, Ankaa Engineering® a ajouté au sein de son framework méthodologique deux niveaux de responsabilité complémentaires.
– S : Signataire, maître d’ouvrage, sponsor
– V : Vérifieur, testeur, recetteur
A noter que les rôles S et V sont uniques sur une ligne de la matrice.

Il est important préalablement à l’affectation des rôles de s’assurer que l’inventaire des acteurs soit le plus exhaustif possible.
Soyez vigilants d’identifier correctement les acteurs indirects, principaux destinataires de la communication autour du projet et pourtant souvent oubliés.

/par