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)

La méthode COBIT (Control Objectives for Information and Related Technology)  définie les indicateurs d’objectif et de performance ainsi que les processus d’une gouvernance du système d’information de l’entreprise.
Elle décompose la gouvernance des systèmes d’information en 4 étapes  : planifier, mettre en place, faire fonctionner et surveiller.

Ces 4 étapes comportent 34 processus et 215 activités.

Framework COBIT

Le CMM (Capability Maturity Model) a été élaboré en 1987 par Watts Humphrey, du SEI (Software Engineering Institute) de l’université Carnegie Mellon de Pittsburgh en Pennsylvanie.

CMMI est le référentiel des bonnes pratiques liées à la gestion, au développement et à la maintenance d’applications. Le référentiel est organisé autour de 4 fonctions (Process ManagementProject ManagementEngineering et Support).

5 niveaux de maturité permettent de valider le respect des bonnes pratiques.

Niveau 1 : InitialPoint de départ, à partir duquel CMM considère que si le projet respecte les délais et le budget, cela sera plus l’histoire de chance que d’une organisation sciemment réfléchie pour l’atteinte des objectifs.

Niveau 2 : ReproductibleA partir de l’expérience acquise sur les réalisations passées, l’organisation met en place une démarche de gestion de projets, identifie ses processus et formalise les fonctionnalités prévues et les budgets associés, dans une ébauche d’assurance qualité.

Niveau 3 : DéfiniLes procédures et méthodes d’organisation de projet sont diffusées, comprises et appliquées par l’équipe.

Niveau 4 : MaitriséLes méthodes et étapes de développement sont industrialisés et appliquées dans un contexte multi-projet.

Niveau 5 : OptimisationLes méthodes sont l’objet d’optimisations constantes pour intégrer les évolutions technologiques et optimiser les processus dans une orientation LEAN…

Le Framework CMMI n’apporte que des recommandations.

Le service ou la société doit choisir et travailler sur la méthodologie à mettre en oeuvre pour satisfaire aux critères CMM.

Elle élaborera alors son référentiel des processus projet (étapes, phases, tâches, etc), des méthodes (UML, RUP, etc) et bonnes pratiques, (procédures de tests, etc.).

Les organisations qui se lancent dans un cursus de certificiation CMMI visent de manière générale le Niveau 3.

Des organismes comme l’AFNOR sont qualifiés pour valider la certification.

Un Lead appraiser (consultant certifié SEI) est mandaté pour l’audit, l’évaluation, le déroulement du SCAMPI (Méthode d’évaluation), et bien entendu son approbation…

La méthode MEHARI fournit une méthode d’analyse et de gestion des risques particulièrement dans le domaine de la sécurité de l’information.
Elle est conforme aux exigences de la norme ISO/IEC 27005:2008.
Elle se décompose en 3 phases
Chaque phase se décompose en 3 étapes
Framework Méhari

Framework Méhari

Chaque étape est constituée de 2 à 3 actions.

Le terme SWOT employé dans l’expression analyse SWOT ou matrice SWOT est un acronyme dérivé de l’anglais pour Strengths (forces), Weaknesses (faiblesses), Opportunities(opportunités), Threats (menaces).

A l’aide de cette matrice, on analyse les éléments qui ont un impact positif ou négatif sur l’atteinte de l’objectif.
Chaque élément est classé selon si son origine est interne et maîtrisable, ou externe et donc à priori, à considérer comme une contrainte dans le projet.

Le plus important pour le recours à l’outil SWOT est de cerner avec précision la problématique, la tâche, le point à analyser.
Faute de quoi les informations collectées seront rapidement nombreuses et diffuses.

Analyse SWOT

La matrice n’apportera donc aucun éclairage complémentaire si elle est utilisée à des niveaux d’analyse trop globaux.

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.

Selon la méthode agile SCRUM, les développements applicatifs sont organisés selon une récurrence de « Sprints », cycles de développements partiels.
Pendant un Sprint, des réunions appelées « Scrum » établissent le point d’avancement des travaux depuis la dernière réunion et organise la suite jusqu’à la réunion suivante.
Chaque Sprint se termine par une phase de test des fonctionnalités livrées « en l’état ».
Le « Backlog » de produit référence les fonctionnalités implémentées.

Le fait de livrer « au fil de l’eau » les modules applicatifs réalisés permet de vérifier l’appréciation du « client » à chaud et d’opérer sans attendre les corrections et ajustements, dans une situation de correctifs mineurs.

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.

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.

Développée dans les années 80 par Noriaki Kano, cette méthode vise a classer les besoins selon 5 catégories :
Attractive – Attirant : La présence de la fonction augmente la satisfaction du client, mais n’entraine pas de mécontentement en cas d’absence.
One-Dimensional – Proportionnelle : La présence de la fonction contribue à la satisfaction du client, et son absence entraine un mécontentement.
Must-Be – Obligatoire : La fonction dont la présence est considérée comme normale. Son absence procure un dysfonctionnement et une insatisfaction.
Indifferent – Indifférent : Les fonctions n’ont aucune influence sur la satisfaction ou l’insatisfaction.
Reverse – Contraire : Fonctions amenant des jugements inverses selon les clients.

L’originalité de la méthode de Kano réside dans la mise en forme d’un questionnaire a deux niveaux d’évaluation.

A chaque question posée, le client porte une appréciation selon une liste de réponse prédéfinies selon la liste :
– Ca me plait
– C’est le minimum attendu
– Ca m’est égal
– Je l’accepte
– Cela ne me plait pas
Le premier niveau consiste à évaluer la présence de la fonction. Le second niveau vise à évaluer l’absence de la fonction.

La consolidation des résultats dans la matrice fournit l’évaluation de chaque fonction selon son caractère d’attractivité, de proportionnalité ou d’obligation.
En terme de support, vous trouverez ici un modèle de fiche d’interview avec hiérarchisation automatique des fonctions selon la matrice.

Cette méthode est utile pour hiérarchiser l’expression du besoin et clarifier l’objectif du projet aux fonctions « vitales » et à forte valeur ajoutée.