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

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

La DSI orientée services et centre de valeur

, ,

Préalablement la Direction des Systèmes d’Information (DSI) était perçue comme responsable des projets informatique et leur maintenance au sein de l’entreprise.
Appuyé sur le modèle de centre de coûts, le pilotage de la DSI est strictement établi sur les coûts et défini par le suivi des dépenses au regard d’un budget de fonctionnement (matériel, logiciels, ressources humaines, formations, etc).

Aujourd’hui, la DSI évolue de la notion de centre de coûts vers une approche de centre de service, voire de centre de valeur.    

Pour permettre cette transformation, la DSI devra mettre en place un nouveau système de pilotage de son activité.

Dans une première étape, la DSI doit identifier les différents services qu’elle apporte aux métiers, ses clients internes.
Cet inventaire fournit le catalogue de service de la DSI, au sein duquel chaque prestation ou produit se verra attribué un niveau d’engagement de qualité de service (SLA, Service Level Agrement).
Chaque niveau d’engagement verra alors la définition de son (de ses) indicateur(s) de suivi d’atteinte d’objectif  KGI (Key Goal Indicators) et de performance KPI (Key Performance Indicators).

Le suivi de la qualité de service amène immanquablement la DSI à progresser en terme de performance.
D’une part par challenge interne des pôles d’activité de la DSI qui en suivant leurs indicateurs respectifs vont chercher à influer sur les courbes et tendances.
D’autre part par les clients internes, les métiers, qui peuvent attendre une amélioration de la qualité de service de sa DSI. 

Technicien dans une salle informatique

Par ailleurs, dans le contexte des organisations ayant développé une comptabilité analytique par centre de coûts, chaque prestation ou produit du catalogue de service de la DSI peut être valorisée et engendrer des imputations internes.
Grâce à cette valorisation des services, chaque client interne abordera ses besoins avec une logique de calcul de ROI ou de Pback, ce qui contribue à mieux réguler les dépenses et frais généraux de l’entreprise.

En support à la mise en place d’une DSI orientée service, le framework ITIL (IT Infrastructure Library) assistera les activités de support, d’exploitation et de production à la transformation des activités.
Chaque niveau de service se trouve formalisé sous forme d’un contrat, établi selon les attentes des objectifs métiers de l’entreprise. A chaque contrat est associé une organisation des processus et fonctions opérationnelles.
En complément du périmètre des activités de support et de production, ITIL apportera un soutien aux services Etudes dans la définition de processus de gestion des changements.

Dans le modèle de centre de service, la DSI agit comme une société de service interne. La relation avec les métiers s’appuie sur la notion de fournisseur interne, soutenue par le catalogue de service interne.
Ce modèle peut influer l’évolution des relations avec les métiers vers celle de strict client-fournisseur au préjudice d’une cohésion des équipes de l’entreprise face aux enjeux communs. 

Au delà du modèle de centre de service et du support apporté par le référentiel ITIL dans la formalisation des services et niveaux de service, la DSI aura a définir un nouveau modèle de gouvernance.
Dans le périmètre de l’exploitation du système d’information, un organigramme clair des domaines opérationnels de la DSI et l’organisation RH associée par exemple peut aider à clarifier les fonctions et responsabilités au sein de l’équipe IT et auprès des métiers.
Dans sa fonction de soutien à la stratégie de l’entreprise, la DSI aura notamment à clarifier la stratégie d’alignement du SI, en décliner les technologies à mettre en oeuvre, appréhender une gestion de risque, évaluer les performances attendues et les moyens de contrôles à associer.

Tableaux de bord et indicateurs
Des référentiels de type Enterprise Architecture (EA) et les frameworks TOGAF et EAF peuvent aider la DSI à définir son management stratégique et choisir les meilleures affectation de ressources pour soutenir le développement de l’entreprise.

Dans ce modèle, la DSI est un partenaire stratégique de la direction générale.

La DSI est alors pilotée par des objectifs basés sur la génération de valeur pour le compte de l’entreprise.
Chaque mission menée que ce soit dans les services Etudes, Production, MCO, Support contribue à augmenter la productivité interne, ou améliorer la qualité de service ou produits pour améliorer la compétitivité de l’entreprise.
Dans ce mode de centre de valeur, chaque projet ou plan d’amélioration comporte une évaluation systématique des gains attendus.
Nous recommandons pour formaliser les gains de recourir aux principes d’une fiche projet telle que présentée dans nos articles précédents (Une vision partagée de l’objectif par exemple).
Chaque projet mené par la DSI contribue donc à la création d’une valeur ajoutée quantifiable.

La DSI devient enfin un centre de valeur.

/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

Témoignage client NORSKE SKOG

, , , , ,

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.

/par

Relations Métiers-DSI : Une éclaircie au milieu des nuages !

, ,

Les relations Métiers-DSI sont très souvent tendues au sein des organisations que nous côtoyons.

Les uns, pressés par les enjeux du marché et les attentes des actionnaires, expriment « leurs besoins à la machine à café », soucieux de transférer le dossier entre les mains de la DSI au plus vite.

Le rôle de la machine à café dans les relations Métiers-DSI

Le lieu privilégié pour engager des projets

Les autres, touchés dans leurs égos professionnels, apportent des réponses quasi spontanées sur le niveau d’engagement qu’ils peuvent apporter en terme de budget et de délai sur le besoin entendu.

Alors que ni l’un, ni l’autre n’ont le plus souvent pris le temps de définir de manière claire et précise une vision partagée de l’objectif !

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.

L’image du service IT interne se dégrade et,  à l’heure où les offres Saas et les mises en relation directe Métiers-Intégrateurs/Editeurs se multiplient, il peut y avoir danger à ne pas réagir pour la DSI.

Alors ? Aucune issue à la crise de confiance dans les relations Métiers-DSI ?

Qu’ils soient techniques, organisationnels ou comportementaux, il existe de nombreux axes de progression comme par exemple :

  • Améliorer la complémentarité et la définition des services fournis et faire en sorte que la DSI ne fonctionne plus en silo mais bien dans une organisation de support transversal.
  • Evoluer vers une relation ou la prise en compte de la valeur du système d’information de l’entreprise par les métiers (IT Value, ROI, Payback, NPV, IRR) atténue les griefs de performance à l’égard de la DSI.
  • Progresser dans la cohérence de l’alignement stratégique du système d’information pour viser un modèle d’activité de DSI proactive, avec un organigramme clair, partagé et compris.
  • Inventorier les indicateurs pertinents, communiquer ses tableaux de bord et « benchmarker » son organisation dans une démarche d’amélioration continue (Roue de Deming, PDCA).
  • Instaurer une méthodologie de gestion de projet transversale, commune et partagée entre les Métiers et la DSI et (re)définir les périmètres de responsabilité entre les rôles MOA et MOE.
  • Passer d’un mode de « faire plaisir » à celui motivé par le payback et soutenir les managers fonctionnels IT dans leur capacité à dire non face à des demandes « de confort ».
  • Instaurer un bureau « Méthode et planification » (PMO) et travailler sur l’évaluation des capacités réelles des ressources sur les nouveaux projets plutôt que de ne se concentrer que sur l’évaluation des charges.
  • Appliquer une gestion de risque structurée (AMDEC ou équivalent), valoriser les risques encourus et clarifier le périmètre de responsabilité entre MOA et MOE.
  • Suivre les charges de fonctionnement de la DSI au sein d’une comptabilité analytique permettant d’isoler CAPEX et OPEX, orientée dans une logique d’analyse de la valeur du SI et dans la mesure des progressions annuelles des charges d’exploitation et cycles de vie applicatifs.
  • Adapter et personnaliser son référentiel méthodologique interne selon les moyens et capacités disponibles, prendre en considération le niveau de maturité des processus et des équipes (CMMI) et ne pas être plus royaliste que le roi dans la définition des « dead-line ».
  • etc, etc

Toutes ces mesures doivent s’intégrer dans le management stratégique du système d’information et composer le référentiel interne de l’IT Gouvernance.

Chaque mesure doit donner lieu à l’identification de KPI (Key Performance Indicators) et KGI (Key Goal  Indicators).
Par exemple, un des indicateur pertinent dans l’évaluation de l’efficacité des mesures appliquées peut être celui du turn-over de l’équipe IT…

La mise en oeuvre opérationnelle d’un plan de gouvernance IT  demande la mise en place d’une organisation de pilotage de projet (formalisation de l’objectif, identification des acteurs directs et indirects, phasage des tâches et plan de charge, planification, plan d’assurance Qualité, niveau de documentation, tests, bascule en production et transfert en exploitation).
Nous sommes même, bien souvent,  dans le contexte d’une gestion de portefeuille ou de programme, puisque l’étendue du chantier amènera à identifier plusieurs sous-projets et objectifs.

Dans une logique d’amélioration continue, chaque fonction doit être monitorée à partir de quelques indicateurs finement choisis, et doit faire l’objet d’audit et de contrôles réguliers réalisés par un encadrement responsable et clairement identifié.

Ainsi, il n’est pas rare qu’à l’issue de ces chantiers, quelques rayons de soleil apparaissent au milieu des nuages.

Rayons de soleil dans les relations Métiers-DSI

Des rayons de soleil…enfin !

Je vous entends réagir et dire « Quid d’un ciel totalement bleu dans nos relations Métiers-DSI ? »
Restons pragmatiques, humbles et réalistes si vous le voulez bien.

/par